【分布式】积累

分布式事务

分布式事务（2PC 3PC TCC 最终一致性）
一次给女朋友转账引发我对分布式事务的思考
分布式事务：深入理解什么是2PC、3PC及TCC协议
3pc 阶段二之中，参与者收到了preCommit，但如果协调者未收到ack，此时协调者会发送abort，但如果参与者也未收到3阶段的abort ，此时参与者会在超时后主动commit
这就造成数据不一致了

时钟

Lamport Clock

计算机的时钟（二）：Lamport逻辑时钟
分布式系统：Lamport 逻辑时钟 - 肖汉松的文章 - 知乎
意义在于，通过lamport逻辑时钟，每个进程在排序时，虽然无法保证时间顺序，但可以保证果一定在因的后面。

做分布式锁的核心在于，每个进程队列的顺序一定一致，因为由于逻辑时钟+进程序号的保证，保证了拓扑性质，即因一定在果前面，即资源请求必须按照请求发生的顺序进行授权。
即使释放过程中，由于分布式，可能有的进程会先释放锁，但只要保证释放时，工作已经完成就可以了，就不会发生不一致的情况。

混合逻辑时钟

计算机的时钟（五）：混合逻辑时钟

协议

Quorum

分布式系统理论之Quorum机制

Paxos算法

如何浅显易懂地解说 Paxos 的算法？ - GRAYLAMB的回答 - 知乎
分布式系列文章——Paxos算法原理与推导
Paxos算法详解
如何浅显易懂地解说 Paxos 的算法？ - 朱一聪的回答 - 知乎
情景1-3：为什么不行，我的理解是，从外界来看，按照要求，接受提案号更大的提案，那么结果是，P3先收到了P2的消息，P2的消息被接受了；P3又收到了P1的消息，P1的消息也被接受了。那么从外界来看，这个集群同时接受了两个消息，这违反了安全性“一旦v就某个值达成了一致，那么v不能对另一个值再次达成一致”。举个例子，我们可以假象P1和P2是两个有能力触发数值变更的客户端，最后这两个客户端都告知各自用户，您的提案已经被接受了，但实际上最终实际上P2客户端的用户被欺骗了。

从上到下依次阅读即可，Paxos确实难以理解。
Paxos面对的背景是，在一个集群里，每个节点都维护了一个变量V，并且这个集群里的某些节点会尝试修改V的值；而Paxos要解决的问题是，如何让这个集群里的每个节点针对V的取值达成一致，并且还能让外界知道自己达成一致的值是什么。这里的一致强调的是最终一致。举个例子，节点1期望将V改为a，而节点2期望将V改成b，并且节点之间可以相互通讯，那么通讯的时候需要交互什么信息，才能让这个集群里的所有机器的V达成一致，即所有机器都认可一个值，使得最终的取值都是一致的、相同的？
这里有几个角色：1. proposer：即提案者，他们可以提出提案，所谓提案就是他们期望将V改为a这类的请求；2. accepter：即接受者，他们可以响应提案者，告知提案者我接受或者不接受你的提案，并决定是否真正地完成V的修改，上文之中提到的“接受提案”，实际上指的就是完成了将V改成另一个值的操作；3. learner：学习者，只能flow提案去进行操作，无法相应proposal提案；

保持一致是一件很困难的事，因为一致的过程中会有很多博弈操作，上面的博客2的切入角度是：先给一个协议，然后举出一个场景，该协议在这个场景无法保证数据一致，然后修改协议，然后再举出一个异常场景，直到一个完美的协议，从而从浅到深地一点点推导出完整的paxos算法；

1. 情景1：多个proposer、一个Accepter

• 协议1：accepter接受第1个收到的提案（第几个其实都无所谓）。这很简单了，只有一个accepter，它接受任意一个proposal，都不会导致集群内V的不一致；
• 坏处：一个accepter还集群个屁

2. 情景2：多个proposer、多个Accepter

• 如果使用协议1：每个accepter都接受收到的第一个提案，那么由于不同节点可能延迟不同，导致每个accepter最终接受的值很可能就不一样，从而导致V各不相同；
• 补充规定：集群里总会出现多个proposal，那么最终哪个proposal会被接受呢？我们依照少数服从多数的规律，举个例子，如果提案1为V=a，提案2为V=b，那么如果此时提案1已经被大多数accepter接受了，那么最终的时候，V的取值应该是a；那么如何满足这个要求呢？其实还挺难的，举例来讲，如果有3个accepter，但accepter1和accepter2先收到了提案1，而accepter3先收到了提案2，那得用一种方式让accepter3拒绝提案2才行。
• 协议2：可以给每个proposal一个编号，协议要求accepter每次都接受最大编号的提案；
• 协议2的问题：上面说了；
• 协议2b：指的就是朱一聪的回答里的第三种情形，如果集群里有一个节点接受了提案1，使得v=a，那么proposer得能够保证，后续编号更大的提案，也得是v=a才行（即使该proposer之前已经提过其他的提案，例如提案10000v=z）

租约

Lease 机制和 Quorum 机制
租约与多数读写

Raft协议

全面理解Raft协议
也是分布式里数据一致性的协议
Raft协议详解
一文搞懂Raft算法
Raft 动画
In Search of an Understandable Consensus Algorithm

数据结构

LSM

LSM树详解
深入浅出分析LSM树（日志结构合并树）
相对于书里介绍的简化了很多-但意思差不多

一致性hash

图解一致性哈希算法
一致性哈希算法（consistent hashing）

分布式存储中间件

ZooKeeper

概念

zookeeper 持久节点和临时节点的区别

权限

zookeeper的ACL权限控制
ZooKeeper ACL权限控制
addauth操作指的是，让当前的上下文（或者说连接或者说session），认证某个用户，也就是说，让zookeeper服务端指的，当前的这个client的连接，拥有了这个用户的权限；
setacl里，auth模式就是给这个用户授权，然后密码就默认使用这个用户的密码；digest是授权时，同时指定账号密码，并且这个密码还是个加密后的。

命令行

【分布式】Zookeeper使用–命令行

java-api

ZooKeeper官方文档-Java客户端开发例子翻译