大学男生寝室应该是看这种比赛最有氛围的

双向链表和循环链表 依旧满足逻辑上线性表的定义，除了 start 和 end 两个元素，都是 1 对 1 前后链接

@mortonnex
在线反欺诈的流程就是根据 用户 提供的基本信息，调取一堆三方接口
然后 进行 变量加工，通过规则引擎和机器学习算法 进行决策出额

有时也会开发一些 ETL 基本工具

网贷反欺诈

没拿到双证？

百度 高德 都有网页
你可以抓包研究下

你还不会打日志，这是最大的问题
很多地方 try except 是必要的，这是程序健壮性必须的
后端接口，不要直接把 exception 直接抛给 接口调用方，无论调用方是 web 前端，还是其他服务
调用方并不关心你究竟又啥异常

楼主还是多向公司有经验的问问，日志打不好，排查线上问题是很老火的

@tabris17 单机的话的直接对电话号码字段加锁就行
如果部署多台分布式的话，肯定就代表业务的并发正在或者以后潜在面临挑战，在这种背景下，把压力扔给 db 不合适，数据库的唯一索引校验，也是给数据库压力，当然如果 db 能接受，数据库唯一索引也行
这个唯一索引做幂等的本身的扩展性也是问题，当前业务下，我们是对 电话号码添加 unique 校验，但是后来 需要的是限制 姓名+电话号码，来防止重复注册，再到线上的已经膨胀的表中更改索引是不可取的，大表加个索引就可能影响整个 db

如果是 单机的话，synchronized (user.telephone.intern())就行了，也不用考虑分布式锁带来的问题

这为老兄的 user.telephone 写法也是很不讲究

年纪轻轻怕啥

@q397064399 如果单机就是 普通的字段加锁就行
上了多台服务，肯定要用 redis 或者 zk 之类对相应字段加锁
我目前做的的都是 一个服务部署多台，用的是 redis 加锁
总之，别把压力抛给 db

依据我浅薄的经验来看，把这种幂等性教研扔给 db 的唯一索引来做不合适，
即使有唯一索引，也最好在应用程序中加锁来实现

单机的话
```
synchronized (user.telephone.intern())
```
分布式的话，直接给
给 telephone 用 redis 加锁就行了

性能影响不大吧

超时 挂掉等必须重试，无解
按你的描述，肯定不是如支付 交易等强事务的接口，超时，挂掉的不频繁的话，重试的费用可以接受，只是你要设置好重试的规则，
对方暴露接口中不设置流水号，也是很不合理的

这个意思应该是爬取风控建模元数据的意思
比如 运营商个人账单 淘宝个人账单 京东个人账单 学信网 邮箱信用卡账单 社保 航旅 法院 等信息，这是互联网金融大数据风控的核心数据，爬虫背景下，大多是需要用户为了贷款 贡献出自己的账号密码 或者其他隐私数据进行查询

城中村没人管的 ，有些城中村 还有祠堂，天天都有鞭炮声

@darmau 几大钢铁企业大面积裁员才过去没几年，还不用谈到九十年代下岗潮

数据库实体 bean 以及业务相关的 VO 之类不用提取成 公共模块
通信过程中 的 参数 可以封装成 dto，暴露相应的服务 api 包出去就行，这中间涉及序列化。原则上，业务相关的 bean 不应该直接暴露，暴露的应该是调用方需要的 dto 信息
当然如果不是纯粹的微服务，只是业务太复杂需要拆分并且也做不到分库，数据库的 bean 也会暴露出去

这是我这个菜鸡的理解

@zhuangzhimin 你这只要 mybatis 配置多数据源就行