关于生产系统性能和一致性引发的思考

一、关于生产系统若干问题描述

1、存量账户补录，外包人员读取补录任务缓慢。为了确保同一账户不被多个人同时补录，使用了线程同步，单web服务；此时，20个外包人员排队获取补录任务时，将存在长时间等待，用户体验不好，如果超过50个人同时获取任务，那又将如何呢？
2、信用卡分件，在分件时有可能两个人分到同一件，生产上使用了F5集群，而synchronized只是锁定了当前jvm，两个tomcat是两个独立的jvm，相当于有两个入口； 另外，之前系统同一用户同一时刻只允许一人在线，现在由于多web容器，此控制已失效，直接造成的后果是，同一个用户可以在不同的客户端浏览器上登录到后台不同的web服务器上（虽然F5开启了会话保持，即同一session的多次请求会分配到同一个服务器，但是在用户的客户端IP变化后，读不到上一次的sessionid，会认为是新用户登录，故而不能分发到之前已登录过的服务器上），那么他们看到的页面将是一样的，有可能造成页面访问异常，以及数据库死锁等意想不到的问题。

---

二、《存量账户获取补录任务》方案演进

V1.0 流程图：
日前生产上系统就采用如此方案，所有的外包人员排队读取补录任务，20个人都成功获取到补录任务，与数据库的交互次数>=40次，即每个人至少与数据库交互2次。再如查询的目标数据集增长到100万，1000万以上，那此时系统的吞吐量又如何？系统直接假死，谁都访问不了！！！

V2.0 流程图：
在单web应用下，可以在内存中缓存队列，假如设定队列大小为100，第一次向队列中填满100个待补录任务，当队列容量少于60时，就从数据库里获取40笔任务填充到队列尾部，如此作法相比前作可以减少与数据库的交互次数，队列中保存的是待补录账号，外包人员获取了某一账户后，该账户即从队列中移出，下一个外包人员可继续从队列中获取任务，获取到任务后的处理逻辑保持不变，先前的从核心查询，组装数据都不需要线程同步，如此相比前作，在效率上至少提升了20倍以上。
建议队列大小是并发用户量的5~10倍，那么监听队列大小的阀值可以设定为容量的30~50%，准确地说通过测试设定一个最佳的值。在每次从队列获取任务时，都去触发检查队列的大小事件，事件的具体执行逻辑可以异步。

V3.0 工业时代: 系统运行环境图

三、集群和负载均衡环境下，传统的synchronized失效，我们如何应对？

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。

---

针对分布式锁的实现，目前比较常用的有以下几种方案：
（1）基于数据库的锁实现。
（2）基于redis实现分布式锁。
（3）基于zookeeper实现。

---

三种方案的比较
上面几种方式，哪种方式都无法做到完美。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所以，根据不同的应用场景选择最适合自己的才是王道。

• 从理解的难易程度角度（从低到高）
  数据库 > 缓存 > Zookeeper

• 实现的复杂性角度（从低到高）
  Zookeeper >= 缓存 > 数据库

• 从性能角度（从高到低）
  缓存 > Zookeeper >= 数据库

• 从可靠性角度（从高到低）
  Zookeeper > 缓存 > 数据库

备注：
这三种方案的具体实现，可以参考以下博客：
https://www.cnblogs.com/austinspark-jessylu/p/8043726.html