当数据库遇到分布式，你会怎么做？

我们知道分布式系统中，各个机器拥有相同的时钟(全局时钟)是不太可能的。1978年Lamport在一篇论文中提出了一种逻辑时间戳，来解决分布式系统中区分事件发生的时序问题。这篇论文是分布式系统领域被引用最多的论文之一。

Lamport时间戳就是两者的简单结合：时间戳/计数器 + 节点ID，规则如下：

每个事件对应一个Lamport时间戳，初始值为0

如果事件在节点内发生，本地进程中的时间戳加1

如果事件属于发送事件，本地进程中的时间戳加1并在消息中带上该时间戳

如果事件属于接收事件，本地进程中的时间戳 = Max(本地时间戳，消息中的时间戳) + 1

事件的顺序按照时间戳排序，时间戳相同则按照节点ID大小排序

上图，ABC节点的所有事件的全序关系如下：

Lamport时间戳背后的思想是：两个事件可以建立时序(因果)关系的前提是两个事件之间是否发生过信息传递。因此Lamport时间戳只保证因果关系(偏序)的正确性，不保证绝对时序的正确性。

全序广播

Lamport时间戳通过消息的传递来确定事件的时序关系，引出了全序广播(在节点间交换消息的协议)。全序广播需要满足两个安全属性：

可靠交付 (reliable delivery)，没有消息丢失：如果消息被传递到一个节点，它将传递到所有节点

全序交付(total ordered delivery)，消息以相同的顺序传递给每个节点

全序广播正是数据库复制所需要的：如果每个消息都代表一次数据库写入，且每个副本都按照相同的顺序处理相同的写入，那么副本相互保持一致(除了临时的复制延迟，可以将读操作也作为消息，来实现一致读)。这个原理被称为状态机复制(state machine replication)。

因为数据库的写入和读取操作都是通过消息交互达成一致，依据Lamport时间戳，所有的操作是全序的，因此可以实现线性一致性存储。

Raft协议

Raft是一种共识算法，旨在使其易于理解。 它在容错和性能上与Paxos等效。 不同之处在于它被分解为相对独立的子问题，并且干净地解决了实际系统所需的所有主要部分，实际将上面的 全序广播/状态机复制 的工程化。

Raft协议动画演示：thesecretlivesofdata.com/raft/

在Raft集群里，服务器可能会是这三种身份其中一个：领导(leader)、追随者(follower)，或是候选人(candidate)。在正常情况下只会有一个领导，其他都是追随者。而领导会负责所有外部的请求，如果不是领导的机器收到时，请求会被导到领袖。

Raft将问题拆成数个子问题分开解决：

领导选举(Leader Election)

日志复制(Log Replication)

集群成员变化 (Cluster membership changes)

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!