文接上篇。 在上篇里我们介绍了，SESSION一致，主从一致，双主一致，缓存DB一致的问题。 SESSION一致可以用SHARED DB,NGINX或者TOKEN来做。 主从一致，可以使得从库复制和主库写同步，或者引入CACHE还没同步先从主库CACHE拿。 双主一致，有不同的步长的主键，或者统一生成自增KEY的组件去分配数据的ID。随后通过异步扫BINLOG来同步彼此。最后缓存DB一致，我们采用先写DB再淘汰缓存来做。因为缓存失败的概率比DB低很多，几乎可认为不会失败。
5. 冗余表数据一致性
一、需求缘起
互联网很多业务场景的数据量很大，此时数据库架构要进行水平切分，水平切分会有一个patition key，通过patition key的查询能够直接定位到库，但是非patition key上的查询可能就需要扫描多个库了。
例如订单表，业务上对用户和商家都有订单查询需求：
Order(oid, info_detail)
T(buyer_id, seller_id, oid)
如果用buyer_id来分库，seller_id的查询就需要扫描多库。
如果用seller_id来分库，buyer_id的查询就需要扫描多库。
这类需求，为了做到高吞吐量低延时的查询，往往使用“数据冗余”的方式来实现，就是文章标题里说的“冗余表”：
T1(buyer_id, seller_id, oid)
T2(seller_id, buyer_id, oid)
同一个数据，冗余两份，一份以buyer_id来分库，满足买家的查询需求；
一份以seller_id来分库，满足卖家的查询需求。
二、冗余表的实现方案
【方法一：服务同步写】
顾名思义，由服务层同步写冗余数据，如上图1-4流程：
（1）业务方调用服务，新增数据
（2）服务先插入T1数据
（3）服务再插入T2数据
（4）服务返回业务方新增数据成功
优点：
（1）不复杂，服务层由单次写，变两次写
（2）数据一致性相对较高（因为双写成功才返回）
缺点：
（1）请求的处理时间增加（要插入次，时间加倍）
（2）数据仍可能不一致，例如第二步写入T1完成后服务重启，则数据不会写入T2
如果系统对处理时间比较敏感，引出常用的第二种方案
【方法二：服务异步写】
数据的双写并不再由服务来完成，服务层异步发出一个消息，通过消息总线发送给一个专门的数据复制服务来写入冗余数据，如上图1-6流程：
（1）业务方调用服务，新增数据
（2）服务先插入T1数据
（3）服务向消息总线发送一个异步消息（发出即可，不用等返回，通常很快就能完成）
（4）服务返回业务方新增数据成功
（5）消息总线将消息投递给数据同步中心
（6）数据同步中心插入T2数据
优点：
（1）请求处理时间短（只插入1次）
缺点：
（1）系统的复杂性增加了，多引入了一个组件（消息总线）和一个服务（专用的数据复制服务）
（2）因为返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）
（3）在消息总线丢失消息时，冗余表数据会不一致
如果想解除“数据冗余”对系统的耦合，引出常用的第三种方案
【方法三：线下异步写】
数据的双写不再由服务层来完成，而是由线下的一个服务或者任务来完成，如上图1-6流程：
（1）业务方调用服务，新增数据
（2）服务先插入T1数据
（3）服务返回业务方新增数据成功
（4）数据会被写入到数据库的log中
（5）线下服务或者任务读取数据库的log
（6）线下服务或者任务插入T2数据
优点：
（1）数据双写与业务完全解耦
（2）请求处理时间短（只插入1次）
缺点：
（1）返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）
（2）数据的一致性依赖于线下服务或者任务的可靠性
我的启发和思考
如果要极力压缩响应时间可以选用方案3，但是这个增加的复杂度不算低。一般对时间不敏感的话，还是方案1比较直观。如果一个插入成功另一个失败了，可以通过交给上游重试来达成 写恢复。
上述三种方案各有优缺点，但不管哪种方案，都会面临“究竟先写T1还是先写T2”的问题？这该怎么办呢？
三、究竟先写正表还是反表
对于一个不能保证事务性的操作，一定涉及“哪个任务先做，哪个任务后做”的问题，解决这个问题的方向是：
【如果出现不一致】，谁先做对业务的影响较小，就谁先执行。
以上文的订单生成业务为例，buyer和seller冗余表都需要插入数据：
T1(buyer_id, seller_id, oid)
T2(seller_id, buyer_id, oid)
用户下单时，如果“先插入buyer表T1，再插入seller冗余表T2”，当第一步成功、第二步失败时，出现的业务影响是“买家能看到自己的订单，卖家看不到推送的订单”
相反，如果“先插入seller表T2，再插入buyer冗余表T1”，当第一步成功、第二步失败时，出现的业务影响是“卖家能看到推送的订单，卖家看不到自己的订单”
由于这个生成订单的动作是买家发起的，买家如果看不到订单，会觉得非常奇怪，并且无法支付以推动订单状态的流转，此时即使卖家看到有人下单也是没有意义的。
因此，在此例中，应该先插入buyer表T1，再插入seller表T2。
however，记住结论：【****如果出现不一致】，谁先做对业务的影响较小，就谁先执行。
四、如何保证数据的一致性
从二节和第三节的讨论可以看到，不管哪种方案，因为两步操作不能保证原子性，总有出现数据不一致的可能，那如何解决呢？
【方法一：线下扫面正反冗余表全部数据】
如上图所示，线下启动一个离线的扫描工具，不停的比对正表T1和反表T2，如果发现数据不一致，就进行补偿修复。
优点：
（1）比较简单，开发代价小
（2）线上服务无需修改，修复工具与线上服务解耦
缺点：
（1）扫描效率低，会扫描大量的“已经能够保证一致”的数据
（2）由于扫描的数据量大，扫描一轮的时间比较长，即数据如果不一致，不一致的时间窗口比较长
有没有只扫描“可能存在不一致可能性”的数据，而不是每次扫描全部数据，以提高效率的优化方法呢？
【方法二：线下扫描增量数据】
每次只扫描增量的日志数据，就能够极大提高效率，缩短数据不一致的时间窗口，如上图1-4流程所示：
（1）写入正表T1
（2）第一步成功后，写入日志log1
（3）写入反表T2
（4）第二步成功后，写入日志log2
当然，我们还是需要一个离线的扫描工具，不停的比对日志log1和日志log2，如果发现数据不一致，就进行补偿修复
优点：
（1）虽比方法一复杂，但仍然是比较简单的
（2）数据扫描效率高，只扫描增量数据
缺点：
（1）线上服务略有修改（代价不高，多写了2条日志）
（2）虽然比方法一更实时，但时效性还是不高，不一致窗口取决于扫描的周期
有没有实时检测一致性并进行修复的方法呢？
【方法三：实时线上“消息对”检测】
这次不是写日志了，而是向消息总线发送消息，如上图1-4流程所示：
（1）写入正表T1
（2）第一步成功后，发送消息msg1
（3）写入反表T2
（4）第二步成功后，发送消息msg2
这次不是需要一个周期扫描的离线工具了，而是一个实时订阅消息的服务不停的收消息。
假设正常情况下，msg1和msg2的接收时间应该在3s以内，如果检测服务在收到msg1后没有收到msg2，就尝试检测数据的一致性，不一致时进行补偿修复
优点：
（1）效率高
（2）实时性高
缺点：
（1）方案比较复杂，上线引入了消息总线这个组件
（2）线下多了一个订阅总线的检测服务
however，技术方案本身就是一个投入产出比的折衷，可以根据业务对一致性的需求程度决定使用哪一种方法。我这边有过好友数据正反表的业务，使用的就是方法二。
我的启发和思考
方法1 会对扫描的数据不断增多而时间越来越长，基本是个很糟糕的方法。
方法2，可以选择也一般会这么做，是一种主动拉的修复模式
方法3，当然为了实时性，我们也可以换成推的修复模式。
6. 消息时序一致性
分布式系统中，很多业务场景都需要考虑消息投递的时序，例如：
（1）单聊消息投递，保证发送方发送顺序与接收方展现顺序一致
（2）群聊消息投递，保证所有接收方展现顺序一致
（3）充值支付消息，保证同一个用户发起的请求在服务端执行序列一致
消息时序是分布式系统架构设计中非常难的问题，ta为什么难，有什么常见优化实践，是本文要讨论的问题。
一、为什么时序难以保证，消息一致性难？
为什么分布式环境下，消息的时序难以保证，这边简要分析了几点原因：
【时钟不一致】
分布式环境下，有多个客户端、有web集群、service集群、db集群，他们都分布在不同的机器上，机器之间都是使用的本地时钟，而没有一个所谓的“全局时钟”，所以不能用“本地时间”来完全决定消息的时序。
【多客户端（发送方）】
多服务器不能用“本地时间”进行比较，假设只有一个接收方，能否用接收方本地时间表示时序呢？遗憾的是，由于多个客户端的存在，即使是一台服务器的本地时间，也无法表示“绝对时序”。
如上图，绝对时序上，APP1先发出msg1，APP2后发出msg2，都发往服务器web1，网络传输是不能保证msg1一定先于msg2到达的，所以即使以一台服务器web1的时间为准，也不能精准描述msg1与msg2的绝对时序。
【服务集群（多接收方）】
多发送方不能保证时序，假设只有一个发送方，能否用发送方的本地时间表示时序呢？遗憾的是，由于多个接收方的存在，无法用发送方的本地时间，表示“绝对时序”。
如上图，绝对时序上，web1先发出msg1，后发出msg2，由于网络传输及多接收方的存在，无法保证msg1先被接收到先被处理，故也无法保证msg1与msg2的处理时序。
【网络传输与多线程】
多发送方与多接收方都难以保证绝对时序，假设只有单一的发送方与单一的接收方，能否保证消息的绝对时序呢？结论是悲观的，由于网络传输与多线程的存在，仍然不行。
如上图，web1先发出msg1，后发出msg2，即使msg1先到达（网络传输其实还不能保证msg1先到达），由于多线程的存在，也不能保证msg1先被处理完。
【怎么保证绝对时序】
通过上面的分析，假设只有一个发送方，一个接收方，上下游连接只有一条连接池，通过阻塞的方式通讯，难道不能保证先发出的消息msg1先处理么？
回答：可以，但吞吐量会非常低，而且单发送方单接收方单连接池的假设不太成立，高并发高可用的架构不会允许这样的设计出现。
二、优化实践
【以客户端或者服务端的时序为准】
多客户端、多服务端导致“时序”的标准难以界定，需要一个标尺来衡量时序的先后顺序，可以根据业务场景，以客户端或者服务端的时间为准，例如：
（1）邮件展示顺序，其实是以客户端发送时间为准的，潜台词是，发送方只要将邮件协议里的时间调整为1970年或者2970年，就可以在接收方收到邮件后一直“置顶”或者“置底”
（2）秒杀活动时间判断，肯定得以服务器的时间为准，不可能让客户端修改本地时间，就能够提前秒杀
【服务端能够生成单调递增的id】
这个是毋庸置疑的，不展开讨论，例如利用单点写db的seq/auto_inc_id肯定能生成单调递增的id，只是说性能及扩展性会成为潜在瓶颈。对于严格时序的业务场景，可以利用服务器的单调递增id来保证时序。
【大部分业务能接受误差不大的趋势递增id】
消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求：
（1）同1s内发布的聊天消息时序乱了
（2）同1s内发布的帖子排序不对
（3）用1s内发起的秒杀，由于服务器多台之间时间有误差，落到A服务器的秒杀成功了，落到B服务器的秒杀还没开始，业务上也是可以接受的（用户感知不到）
所以，大部分业务，长时间趋势递增的时序就能够满足业务需求，非常短时间的时序误差一定程度上能够接受。
关于绝对递增id，趋势递增id的生成架构，详见文章《细聊分布式ID生成方法》，此处不展开。
【利用单点序列化，可以保证多机相同时序】
数据为了保证高可用，需要做到进行数据冗余，同一份数据存储在多个地方，怎么保证这些数据的修改消息是一致的呢？利用的就是“单点序列化”：
（1）先在一台机器上序列化操作
（2）再将操作序列分发到所有的机器，以保证多机的操作序列是一致的，最终数据是一致的
典型场景一：数据库主从同步
数据库的主从架构，上游分别发起了op1,op2,op3三个操作，主库master来序列化所有的SQL写操作op3,op1,op2，然后把相同的序列发送给从库slave执行，以保证所有数据库数据的一致性，就是利用“单点序列化”这个思路。
典型场景二：GFS中文件的一致性
GFS(Google File System)为了保证文件的可用性，一份文件要存储多份，在多个上游对同一个文件进行写操作时，也是由一个主chunk-server先序列化写操作，再将序列化后的操作发送给其他chunk-server，来保证冗余文件的数据一致性的。
【单对单聊天，怎么保证发送顺序与接收顺序一致】
单人聊天的需求，发送方A依次发出了msg1，msg2，msg3三个消息给接收方B，这三条消息能否保证显示时序的一致性（发送与显示的顺序一致）？
回答：
（1）如果利用服务器单点序列化时序，可能出现服务端收到消息的时序为msg3，msg1，msg2，与发出序列不一致
（2）业务上不需要全局消息一致，只需要对于同一个发送方A，ta发给B的消息时序一致就行，常见优化方案，在A往B发出的消息中，加上发送方A本地的一个绝对时序，来表示接收方B的展现时序
msg1{seq:10, receiver:B,msg:content1 }
msg2{seq:20, receiver:B,msg:content2 }
msg3{seq:30, receiver:B,msg:content3 }
潜在问题：如果接收方B先收到msg3，msg3会先展现，后收到msg1和msg2后，会展现在msg3的前面。
无论如何，是按照接收方收到时序展现，还是按照服务端收到的时序展现，还是按照发送方发送时序展现，是pm需要思考的点，技术上都能够实现（接收方按照发送时序展现是更合理的）。
总之，需要一杆标尺来衡量这个时序。
【群聊消息，怎么保证各接收方收到顺序一致】
群聊消息的需求，N个群友在一个群里聊，怎么保证所有群友收到的消息显示时序一致？
回答：
（1）不能再利用发送方的seq来保证时序，因为发送方不单点，时间也不一致
（2）可以利用服务器的单点做序列化
此时群聊的发送流程为：
（1）sender1发出msg1，sender2发出msg2
（2）msg1和msg2经过接入集群，服务集群
（3）service层到底层拿一个唯一seq，来确定接收方展示时序
（4）service拿到msg2的seq是20，msg1的seq是30
（5）通过投递服务讲消息给多个群友，群友即使接收到msg1和msg2的时间不同，但可以统一按照seq来展现
这个方法能实现，所有群友的消息展示时序相同。
缺点是，这个生成全局递增序列号的服务很容易成为系统瓶颈，还有没有进一步的优化方法呢？
思路：群消息其实也不用保证全局消息序列有序，而只要保证一个群内的消息有序即可，这样的话，“id串行化”就成了一个很好的思路。
这个方案中，service层不再需要去一个统一的后端拿全局seq，而是在service连接池层面做细小的改造，保证一个群的消息落在同一个service上，这个service就可以用本地seq来序列化同一个群的所有消息，保证所有群友看到消息的时序是相同的。
关于id串行化的细节，可详见《利用id串行化解决缓存与数据库一致性问题》，此处不展开。
三、总结
（1）分布式环境下，消息的有序性是很难的，原因多种多样：时钟不一致，多发送方，多接收方，多线程，网络传输不确定性等
（2）要“有序”，先得有衡量“有序”的标尺，可以是客户端标尺，可以是服务端标尺
（3）大部分业务能够接受大范围趋势有序，小范围误差；绝对有序的业务，可以借助服务器绝对时序的能力
（4）单点序列化，是一种常见的保证多机时序统一的方法，典型场景有db主从一致，gfs多文件一致
（5）单对单聊天，只需保证发出的时序与接收的时序一致，可以利用客户端seq
（6）群聊，只需保证所有接收方消息时序一致，需要利用服务端seq，方法有两种，一种单点绝对时序，另一种id串行化
我的思考和启发
- 首先消息时序的一致因为有多发送方，多接收方和时钟不同步的问题比较难。
- 我们采取小时段范围的乱序，而不追求绝对有序可以简化问题。
- 利用LAMPORT时间戳，也就是一个自增的ID来解决。
- 如果是单发送方，可以自己生成这个ID。
- 如果是多发送方，可以交给服务器生成。