"一致性"架构设计的探讨
摘 要
互联网的一致性架构指的是数据的一致性，在实际业务场景中同一份数据会有多种副本，我们可以采用多种同步策略让数据达到一致性。主要有弱一致性、最终一致性、强一致性。数据的一致性时刻影响着软件系统在业务场景的准确合理性和用户体验。因此本篇文章的主要目的是介绍分析现有业务场景的数据一致性解决方案
关键字
一致性；架构；CAP理论；分布式
1 相关理论背景
1.2 CAP理论
- CAP
- C即Consistency一致性，客户端每次访问都能保证返回最新写入的数据。
- A即Availability可用性，每次访问都要给出正确合理的响应，尽可能的减少宕机的可能性。
- P即Partition分区容错性，在大型系统通信中每个子网络被划分为一个区，在两个区域无法通信系统仍能正常运行。
cap理论包含了三个分布式系统最重要的特性[1]。在分布式系统中一组节点共享数据，在读取操作下只可以满足两个特性而牺牲另一个特性。
2.具体业务场景分析
2.1 session一致性
一、session的概念
session是一种记录客户端状态的机制，存储在服务端，理论上用一个session id可以存储任何关于当前用户的数据，但是在高并发的状态下如果服务器存储的个人的数据过多又会存在内存溢出或者硬盘爆满的情况。所以对session的存储应当有所选择并且有淘汰策略，比如加上过期时间。当客户端再次访问时只需要读取服务端session id相关联的客户数据并解析来确定当前的访问状态就可以了。
当在单机服务时，每次客户端访问都能在服务器正确的取到对应的session，因为只有一台服务器所以每次访问请求只能被分配在这台。但是在分布式系统中每次访问请求落到的服务器不一定是同一个，所以在这种环境下保持服务器集群里session数据的一致性至关重要。
关于解决上述session一致性问题可以有以下几种方案[2]。
a）服务器之间相互复制。
每一次session的变化都通过同步机制通知其他服务器进行数据同步
优点：不需要对原来的服务端代码做修改，整体架构基本保持不变，只需要增加对应的同步数据接口服务就可以，适合有少量服务器低并发访问的业务环境。
缺点：在高并发或者数据量很大的情况下，同步会造成网络的阻塞和访问的延迟，如果是用户量快速增加当前的服务器架构很难水平扩展。
b）存储在客户端即基于cookie的管理。
优点：把每个客户端对应的cookie都存在本地，每次访问的时候通过网络传输给服务器，这样就避免了服务端存储不一致的问题。
缺点：通过网络传输会占用网络带宽，还有传输过程中被窃取或者修改等安全问题，本地的cookie只能存储少量的文本信息，长度有限。
c）session集中存储。
这是目前最常用的方法，后端服务器接到请求再访问一次统一存储session的集群取到对应的session数据。
优点：单独的存储省去了服务器在内存中存储的压力，服务器宕机或者重启也不会造成session丢失，存储服务器可以水平扩展。
缺点：多加了访问session集群的操作，服务端的代码要修改。
2.2 数据库与缓存一致性
在实际操作中当有数据的变更时，是先更新缓存后更新数据库还是反过来，一直很有争议。最大的难点在于在复杂的多序列操作再加上外部的环境如网络延迟阻塞等等影响，同时对同一份数据的读写容易出现脏数据。
最简单的在单数据库即只有主库的情况下，通过主库的串行化操作可以解决数据库与缓存的不一致问题。
目前主要有以下几种策略[5]。
a）先更新数据库，再更新缓存
缺点：1.有两个先后顺序的A(先)，B（后）如遇到网络阻塞等原因B先到的话B先更新缓存，导致出现脏数据。
2.如果业务读的场景较多，导致缓存被不断的更新影响性能。
b）先删除缓存，再更新数据库
出现不一致是存在以下情况
同时有两个操作请求A写操作，B读操作
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
此时缓存中的值还是原来数据库里面的旧值。
解决的策略是在读操作A在上述操作（5）后面等待一段时间再加上删除缓存的操作，如果是数据库读写分离的架构删除缓存之前等待的时间还需要加长一点，因为涉及到数据库之间数据同步的问题。
c）先更新数据库，再删除缓存
具体的步骤如下
- 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
- 命中：应用程序从cache中取数据，取到后返回。
- 更新：先把数据存到数据库中，成功后，再让缓存失效。
基于写操作会比读操作耗时，且大部分情况下不会出现脏数据。另外当出现小概率的并发情况时可以加上一些容错策略如设置缓存失效的时间或者上面延时删除缓存的策略。
2.3 消息时序一致性
在很多业务场景中，发送时序和接收时序的一致性对系统至关重要。主要的难点是需要一个全局的时间基准或者全局的递增ID来保证时序。在复杂的分布式环境下一般根据实际场景选择客户端或者服务端的时序，一般是本地的时间或者生成的唯一递增ID。
典型的场景
a）数据库加中间件生成递增ID[4]
每次ID直接从数据库取得话会造成很大的数据库访问压力，数据库的瓶颈会直接成为系统的瓶颈。因此这里加上中间件Leaf，Leaf的主要作用是代理一次从数据库中批量获取一批ID供上层的服务消耗
对于递增的ID号需要做分段的设计，一般是把64bit的数据划分成几个区域
a）利用单点序列化
只在一台机器或者一个文件系统里面序列化，然后分发到所有的机器类似master-slave结构
参考文献
[1] http://robertgreiner.com/2014/08/cap-theorem-revisited/
[2] https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960128&idx=1&sn=8e0e409b10ab9db549432af461385314&chksm=bd2d069c8a5a8f8ab5cdee602d4062bbdbb25da290668515d36682afa854e374d2a5ff02004b&scene=21#wechat_redirect
[3] Leslie Lamport Time," Clocks, and the Ordering of Events in a Distributed System", ACM Press, July 1978
[4] 美团技术团队，https://tech.meituan.com/MT_Leaf.html
[5] https://cloud.tencent.com/developer/article/1154683