在集中式系统中，我们可以通过事务[1]来处理各种并发、故障带来的问题。但是一方面，集中式系统本身存在单点、无法水平扩展等局限性。另外一方面，有些应用本身就是分别部署在不同机器上的。因此我们引入了分布式系统。
分布式系统有一些典型的特点[2]：
- 分布性：部署在不同的空间
- 对等性：每台机器的地位都是一样的
- 并发性：并发使用资源
- 动态性：集群状态多变，节点会增加、减少，程序会渐进的变更
- 无全局时钟，容易发生故障
因为信息的传输存在物理上的延时，所以在分布式系统中，信息可能会出现不一致1：
- 考虑一个主从结构的数据库（如redis）。客户端a将数据先写入Master节点A中，数据通过异步的方式同步到节点B。如果在同步完成之前，客户端b访问了节点B，那么a和b看到的数据可能就不一样。如果a和b之间存在某种因果关系（比如a写入数据过后，通知b去查询），那么可能就会影响系统的正确性2。
- 还有一种情况是，客户端a将数据写入A过后，A宕机了，B节点升级为Master。那么数据就永远丢失了。
- 如果相关的两个客户端a和b，分别往节点A和B写入数据，那么他们写入的先后顺序可能不一致，也会导致与事实不符。
解决上面的问题的一个思路就是，每次写数据都往每个节点写，全部写成功才认为成功（并非完备的方法），但是如果这样设计，其中一个节点宕机，就会导致无法写入数据，又影响了可用性。并且引出了CAP原理[3]：一个分布式系统不可能同时满足一致性，可用性和分区容错性。
为了在一致性和可用性中作出平衡，又衍生出了BASE理论。
在很多场景中，我们对强一致性有依赖，哪怕要牺牲一定的可用性和吞吐，由此Paxos和raft[4]算法被先后提了出来。
1除了延时还有网络故障和三态（超时的情况下不知道请求是否送达）等问题。
2正确性：对于一个系统来说，我们希望能够基于一定的事实去预测程序的行为，则认为系统有正确性。
[1] 《数据库系统概论》高等教育出版社第五版
[2] 从Paxos到Zookeeper分布式一致性原理与实践
[3] Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services.
[4] https://ramcloud.atlassian.net/wiki/download/attachments/6586375/raft.pdf
