问题范畴
工程开发中，认为系统中存在故障（fault），但不存在恶意（corrupt）节点，而区块链，特别是公开链是落地到物理世界中，涉及到人性和利益关系，不可避免的存在信任以及恶意攻击问题。
分布式一致性处理的是节点失效情况（即可能消息丢失或重复，但无错误消息）的共识达成（Consensus）问题，主要是Paxos算法及衍生的Raft算法。
CAP
分布式系统中的一致性也就是CAP中的C指的是线性一致性。引用wiki中对CAP的定义。
- Consistency: Every read receives the most recent write or an error
- Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write
- Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
CAP和ACID（事务的特点）。
以前，人们喜欢说鱼与熊掌不可兼得，这是二选一。
最近人们特别喜欢总结出事物的三种维度的属性，然后说三者不可兼得，这就是三选二。
不管是啥事物，只要把三选二的模板套上去，就给人一种很有洞察力的感觉。
BASE定理
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。 BASE其实是下面三个术语的缩写：
- 基本可用（Basically Available）
- 软状态（Soft state）
- 最终一致（Eventually consistent） 它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法
数据一致性
数据一致性模型 在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
对于一致性，可以分为从服务端和客户端两个不同的视角，即内部一致性和外部一致性。 没有全局时钟，绝对的内部一致性是没有意义的，一般来说，我们讨论的一致性都是外部一致性。外部一致性主要指的是多并发访问时更新过的数据如何获取的问题。
强一致性： 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。
弱一致性： 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。用户读到某一操作对系统特定数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。
最终一致性： 是弱一致性的一种特例。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。
最终一致性模型根据其提供的不同保证可以划分为更多的模型，包括因果一致性和读自写一致性等。
共识算法
共识算法分为两种：集中式共识算法，分布式共识算法。集中式共识算法中，存在中心节点，不够稳定，整个网络中存在两类结点；分布式共识算法，网络中每个结点都是等价的，是去中心化的。
- raft：便于理解的共识算法
- paxos
paxos算法是解决分布式一致性的基石。微信的phxpaxos和蚂蚁的oceanbase都是基于paxos实现。但paxos相对难以理解，同时论文中也没有给出工程化的标准实现。因此raft算法被提出，用更强的约束简化了具体实现，并给出了工程化实现的具体指导和常见优化选项。后续很多的分布式存储以raft算法为基础，常见的raft工程实现：etcd，tidb，byteraft，braft，sofa-raft。
面向agent编程
面向agent编程是一种并发性的编程范式。面向对象编程提出了对象的概念。但是对象依旧是需要有一个主线去调用。而agent则是一个完全自主的一个Class。
共识算法其实就是面向agent编程。
自组织：结点虽然相同，但是演化一段时间之后就能够形成不同的拓扑、不同的结点类型。例如在分布式共识算法中，每个结点都是等价的，但是他们会选择出一个leader来。