分布式系统原理( 三 ) _分布式系统

2.3.3 崩溃恢复所谓崩溃恢复，是指当leader崩溃（单点故障）后，重新选举leader并且数据保持一致性（数据同步）。

leader选举：
选举是通过投票来的，主要分为以下几个阶段，

发起投票：首轮投票，每个节点发出一个投票，先投票给自己，然后再把投票结果广播到集群中别的节点，其他机器。投票内容包含节点的myid（zookeeper安装时要设置的值，表示当前节点id）和zxid（事务id），比如ZK1的投票为(1, 0)，ZK2的投票为(2, 0)
验证投票：每个节点都投票给自己并且广播之后，那么节点就会收到别的节点的投票结果，在收到投票后可以验证投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器，
变更投票：验证完收到的投票结果后，处理投票，针对每一个投票，服务器都需要将别人的投票和自己的投票进行比较，规则如下 · 优先检查ZXID 。ZXID比较大的服务器优先作为Leader； · 如果ZXID相同，那么就比较myid 。myid较大的服务器作为Leader服务器；根据以上规则变更自己的投票，然后广播第二轮投票，还是同样的过程，先验证投票，然后变更投票，变更完成以后统计票仓（本轮投票过程中接收到的别的节点的投票信息）中，是否有超过半数的相同投票，如果有，则其就是新的leader，选举结束；如果没有，则继续发起投票，知道选出leader 。

文章插图

image.png
由上面规则可知，通常那台服务器上的数据越新（ZXID会越大），其成为Leader的可能性越大，也就越能够保证数据的恢复。如果ZXID相同，则SID越大机会越大。

数据同步：
上面的leader选举结束后，只有当新的leader和follower同步数据之后，才能对外提供服务。
同步分为以下几个阶段：

所有follower上报自己最后接收的事务的任期epoch（每个Proposal都包含了一个epoch值，用来代表当前的Leader 周期）；leader比较所有的任期，选取最大的epoch，加1后作为当前的任期E=E+1，并且将任期epoch广播给所有follower；follower将任期改为leader发过来的值之后，返回给leader当前follewer节点上的事务队列L；
leader从队列集合中选取任期最大的队列，如果有多个队列任期都是最大，则选取事务编号n最大的队列Lmax（通常就是leader节点自己的事务队列，因为选举leader时，就是选出的事务zxid最大的节点），并将其广播给各个follower，follower接收队列替换自己的事务队列，并且执行队列中的事务（执行过跳过，未执行执行），执行完以后反馈给leader 表明自己已经完成同步（追上来了），leader 收到过半反馈后，发送commit 消息；follower 接收到commit 消息后，提交事务；至此各个节点的数据达成一致，zookeeper恢复正常服务。

注意：在zk选举中，通过投票已经确认leader服务器是最大的zxid的节点了，所以同步过程没有那么复杂。同步阶段主要是利用 Leader 前一阶段获得的最新 Proposal 历史，同步集群中所有的副本。只有当超过半数的节点都同步完成，准 Leader 才会成为真正的 Leader 。Follower 只会处理 zxid 比自己 lastZxid 大的 Proposal 。
3、最终一致性分布式事务方案3.1 本地消息表本地消息表的核心思想是将分布式事务拆分成本地事务进行处理。
例如，在订单系统新增一条消息表，将新增订单和新增消息放到一个事务里完成，然后通过轮询的方式去查询消息表，将消息推送到 MQ，库存系统去消费 MQ 。

文章插图

image.png
执行流程：

订单系统，添加一条订单和一条消息，在一个事务里提交。
订单系统，使用定时任务轮询查询状态为未同步的消息表，发送到 MQ，如果发送失败，就重试发送。
库存系统，接收 MQ 消息，修改库存表，需要保证幂等操作。
如果修改成功，调用 RPC 接口修改订单系统消息表的状态为已完成或者直接删除这条消息。如果修改失败，可以不做处理，等待重试。

订单系统中的消息有可能由于业务问题会一直重复发送，所以为了避免这种情况可以记录一下发送次数，当达到次数限制之后报警，人工接入处理；库存系统需要保证幂等，避免同一条消息被多次消费造成数据一致。
本地消息表这种方案实现了最终一致性，需要在业务系统里增加消息表，业务逻辑中多一次插入的 DB 操作，所以性能会有损耗，而且最终一致性的间隔主要由定时任务的间隔时间决定。