聊聊（贷款）分布式

目录

凶神恶煞

工作很机车

妥协

嚣张

再苦不能苦了孩子

小白感言

---

详细了解分布是可以参考这篇文章：分布式(计算机算法)-CSDN博客

凶神恶煞

开始之前，先说我之前的一家公司。是做小额贷款的，对，就是你们理解的那种，但是不是高利贷。肯定也有对应的催收人员，你别说，在公司里面我还真没有见过催收的人员，为什么说没见过呢，因为感觉催收的人一般张的都是这种类型的（凶神恶煞），要不然怎么镇得住，对吧。

正片开始，不方便说公司名称，所以一下都称为某公司好了。

工作很机车

某贷款公司主要做的贷款方向是机车，轿车这些类的东西，只要是贷款买的这些，相对的 这些车子上面都会有对应的定位。

而我做的记录车辆的位置地点数据，做到10分钟更新一次做记录，当然也可以做到实时更新，这是根据这个人的征信来调整的，而且这些数据都是设计个人隐私，数据量又很庞大。

妥协

因为是一家有年代的公司了，人员也很少开发一共也就三个人加上我，用的技术还是很老的技术，Struts2+hibernate应用层面还有很多需要完善的地方，我想着呢这个事情说小也不算小，说大也不算大，但是如果说为了以后方便管理，可以简单做一个日志系统做记录，后面催收日志等其他一些也可以都盘到这个应用上，方便以后数数据分析，做失信人员的记录扫描等等。

可惜天不遂人愿（领导不同意呢，说是单开一个浪费资源，浪费钱，等等）最后意思就是不让新的需求立项，只在原来的应用上添加功能。怎么办呢，没办法，毕竟考虑层面不一样，他们要的是省钱，我考虑的是系统以后的维护。

谁让别人是领导呢，那就按他方式做好了。

嚣张

日志做成了菜单，后面功能一个又一个的加（查看某失信用户当天的运动轨迹，赛选用户，统计地点用户主要的城市，等等）结果搞得系统越来越臃肿，好好的一个身材苗条的美少女，硬生生的被生活养成了一个胖子（不是杨玉环）。关键是每次做统计拉去数据的时候还压的应用占的内存更大了，结果导致一些信用不要的用户也进来了（是因为线下贷款时，系统响应慢，导致用户失去耐心，销售又怕失去用户，就先给贷了，后面再录信息）。不敢肯定是赛选用户跟校验的日志有关系，但是既然到这一步了

就顺嘴给他提上去了，后面又加内存又加服务器的，算下来，也不比多一个应用的钱少。

再苦不能苦了孩子

大概也是没有过多久（半年左右）还是把项目拆开了，做了重构，风控，用户，日志，催收等多个，当时还是做得Struts2的，做了大概三个月，其中用户和日志两个是我来负责的，风控催收是另外两个开发，应用做得是内网处理，接口也可以不做签名验证等，但是为了安全，还是做了一些基本参数的校验，怎么说咱也是很负责的，就算是公司那啥，但是自己做的项目怎么说都是自己的孩子的，事大事小都不能牵连和苦了孩子不是。

我是对一些失信用户做了缓存处理，因为这些是要着重去观察的，对于他的定位地点，催收信息记录都是要做特殊对待的额，毕竟他不一样。现在整个的用户信息提取，已经数据统计记录都是在单个应用上去做的统计，再做贷款签约时候，就很方便，也快了很多很多。用过的都说好。（分布式计算，分布式数据库）

就算是后面新加一些功能，比如说我要给那些信用极好的人做一些优惠或者是发一些礼品卷之类的，也就是增值配送产品功能，完全可以在其对应的业务系统上去添加，而且不会影响到其它对应的业务流程（分布式计算）

小白感言

完美结束后，我就离开了这家公司，总体来说还是不错的。也算是从零到一进行了一次项目的重构，第一次以分布式部署应用，提升了自己的能力于见解，也让自己学到了很多很多。分布式系统就像是一群分散在不同地方的人，他们通过网络相互沟通和协作，共同完成一项任务。每个人（风控。用户。日志。催收。即节点）都有自己的能力和资源，可以独立工作，但也可以与其他人共享信息和合作。为了确保任务能够顺利进行，他们需要遵循一些规则（即协议和算法），确保信息的一致性和准确性。同时，他们也需要有应对各种突发情况的能力，比如某个人突然离开或网络中断等情况。