作者：韩健
资深分布式技术专家，拥有10余年技术研发和管理经验。曾就职于腾讯（前腾讯QQ后端基础设施技术负责人）和Intel，从事与大规模分布式系统和云计算相关的工作。
在大规模分布式系统领域有非常深厚的积累，擅长分布式、高性能、高并发、高可用的海量服务中间件的架构设计和开发，尤其是与大数据中间件相关的各种技术。在操作系统和计算机网络领域也有非常丰富的实践经验，对Linux内核、TCP/IP等技术有深入的理解。
热衷于技术分享，是FreeTSDB（业界第一个补齐了InfluxDB分布式能力的开源时序数据库）的发起人和核心贡献者。极客时间专栏作家，《分布式协议与算法实战》专栏作者，著有畅销书《InfluxDB原理与实战》。
维护有微信公众号influxdb-dev。　

技术审校：朱仪姣
腾讯资深架构师，腾讯监管业务研发负责人。对分布式设计、海量服务之道、高性能架构设计有深刻的理解和丰富的实战经验，主导了万亿级安全监测大数据分析平台的分布式架构设计和性能优化等项目。

序  Foreword

一晃两年多过去了，之前写稿的点点滴滴犹在昨天，忙碌、充实、快乐。比如，为了交付更高质量的技术内容，我总是会有很多想法，偶尔会周末通宵写稿，核对每句话、每个细节。

借着新书出版的这个机会，和大家聊聊我最近忙的一些事情和思考。

因为一直从事互联网后台、云计算的相关工作，我一直在关注着基础技术的演进和发展，尤其是与分布式、微服务、大数据相关的技术的发展，在我看来，我们现在正处于基础技术突破性发展的浪潮中。

首先，Serverless时代已来，相当一部分业务系统已经基于Serverless实现，这不仅降低了对项目人员的专业能力的要求，而且提高了整体的研发效能。如果大家还在犹豫Serverless（或FaaS）能否支撑起大系统，那么我这里简单举个具体案例证明。我之前负责的QQ后台的微服务能力就是由一个框架和几个API实现的，通过这几个API就支撑起QQ后台海量、复杂的系统，所以Serverless支撑大系统是没问题的。

其次，我觉得承载实时大数据中台基石能力的时序数据库只是一个过渡形态的产品。为什么这么说？与元数据不同，时序数据最大的需求不是存储，而是分析和洞察，但我们在实现分析和洞察时，对系统的查询性能要求极高。也就是说，大家常说的“时序数据的特点是多写少读、成本敏感”其实是不成立的，因“读”根本就不少，那么，以这个特点为目标来设计的系统也是满足不了实际场景的需求的。另外，站在分析和洞察的角度，底层应该是一个Serverless的技术底座，支持Metric（指标）、Log（日志）、Trace（追踪）、Meta data（元数据）等，而不是一个仅仅支持指标的时序数据库。也就是说，仅仅支持指标的时序数据库是无法有效支撑分析和洞察的。

然后，云计算的兴起令基础技术发生了很大的变化，而这些变化中最突出的就是“技术要具有成本优势”。

基于开源软件，我们很容易“堆砌”一套业务需要的功能。另外，基于大型互联网后台（比如QQ）的架构理念，我们也能支撑海量的服务和流量。也就是说，实现功能或支撑海量服务相关的软件和理念都已经很成熟，但功能背后的成本问题突出。

而成本就是钱，功能背后的成本问题是需要重视和解决的，比如，腾讯自研的KV存储相比Redis降低了数量级倍数的成本。另外，分布式技术本身就是适用于规模业务的，而且随着业务规模的增加，成本的痛点会更加突出。所以，我们在设计系统架构时，需要将成本作为一个权衡点考虑进去。

最后，临渊羡鱼，不如退而编码，让我们保持好奇心和创新精神，与时间做朋友，学习、成长，脚踏实地地实现自己的技术理想！

【理论篇】

第1章　拜占庭将军问题2
1.1　什么是拜占庭将军问题2
1.1.1　苏秦的困境3
1.1.2　二忠一叛难题3
1.2　口信消息，我们该如何处理呢5
1.3　如何解决n>(3f +1)的限制8
1.3.1　什么是签名消息8
1.3.2　签名消息型拜占庭问题之解10
1.4　拜占庭容错算法和非拜占庭容错算法，该如何选择呢16
1.5　本章小结17

第2章　CAP理论19
2.1　CAP理论：分布式系统的ph试纸，用它来测酸碱度20
2.1.1　CAP三指标20
2.1.2　CAP不可能三角24
2.1.3　如何使用CAP理论25
2.2　ACID理论：CAP的“酸”，追求一致性28
2.2.1　二阶段提交协议30
2.2.2　TCC32
2.3　BASE理论：CAP的“碱”，追求可用性35
2.3.1　实现基本可用的4板斧36
2.3.2　终一致性37
2.3.3　如何使用BASE理论39
2.4　本章小结40

【协议与算法篇】
第3章　Paxos算法44
3.1　Basic Paxos：如何在多个节点间确定某变量的值45
3.1.1　你需要了解的3种角色46
3.1.2　如何达成共识48
3.2　Multi-Paxos：Multi-Paxos不是一个算法，而是统称52
3.2.1　兰伯特关于Multi-Paxos的思考53
3.2.2　Chubby是如何实现Multi-Paxos算法的55
3.3　本章小结58

第4章　Raft算法59
4.1　Raft是如何选举领导者的60
4.1.1　有哪些成员身份60
4.1.2　选举领导者的过程61
4.1.3　选举过程四连问64
4.2　Raft是如何复制日志的68
4.2.1　如何理解日志68
4.2.2　如何复制日志69
4.2.3　如何实现日志的一致性71
4.3　Raft是如何解决成员变更问题的73
4.3.1　成员变更问题74
4.3.2　如何通过单节点变更解决成员变更问题75
4.4　Raft与一致性79
4.5　本章小结80

第5章　一致哈希算法82
5.1　使用哈希算法有什么问题83
5.2　如何使用一致哈希算法实现哈希寻址85
5.3　本章小结90

第6章　ZAB协议92
6.1　如何实现操作的顺序性93
6.1.1　为什么Multi-Paxos无法保证操作的顺序性93
6.1.2　ZAB协议是如何实现操作的顺序性的97
6.2　主节点崩溃了，怎么办101
6.2.1　ZAB协议是如何选举领导者的101
6.2.2　ZooKeeper是如何选举领导者的107
6.3　如何从故障中恢复111
6.3.1　ZAB集群如何从故障中恢复112
6.3.2　ZooKeeper如何从故障中恢复119
6.4　ZAB协议：如何处理读写请求125
6.4.1　ZooKeeper处理读写请求的原理126
6.4.2　ZooKeeper处理读写请求的代码实现127
6.5　ZAB协议与Raft算法134
6.6　本章小结136

第7章　Gossip协议137
7.1　Gossip的三板斧138
7.2　如何使用反熵实现终一致性141
7.3　本章小结144

第8章　Quorum NWR算法145
8.1　Quorum NWR的三要素146
8.2　如何实现Quorum NWR149
8.3　本章小结150

第9章　MySQL XA151
9.1　什么是XA规范152
9.2　如何通过MySQL XA实现分布式事务155
9.3　本章小结157

第10章　TCC158
10.1　什么是TCC159
10.2　如何通过TCC实现指令执行的原子性161
10.3　本章小结163

第11章　PBFT算法165
11.1　口信消息型拜占庭问题之解的局限166
11.2　PBFT算法是如何达成共识的167
11.3　如何替换作恶的主节点171
11.3.1　主节点作恶会出现什么问题171
11.3.2　如何替换作恶的主节点172
11.4　PBFT算法的局限、解决办法和应用176
11.5　本章小结177

第12章　PoW算法178
12.1　如何理解工作量证明179
12.2　区块链是如何实现PoW算法的181
12.3　本章小结183

【实战篇】
第13章　InfluxDB企业版一致性实现剖析186
13.1　什么是时序数据库186
13.2　如何实现META节点一致性188
13.3　如何实现DATA节点一致性188
13.3.1　自定义副本数188
13.3.2　Hinted-handoff189
13.3.3　反熵190
13.3.4　Quorum NWR191
13.4　本章小结192

第14章　Hashicorp Raft194
14.1　如何跨过理论和代码之间的鸿沟195
14.1.1　Hashicorp Raft如何实现领导者选举195
14.1.2　Hashicorp Raft如何复制日志201
14.2　如何以集群节点为中心使用API205
14.2.1　如何创建Raft节点205
14.2.2　如何增加集群节点208
14.2.3　如何移除集群节点209
14.2.4　如何查看集群节点状态210
14.3　本章小结211

第15章　基于Raft的分布式KV系统开发实战213
15.1　如何设计架构214
15.1.1　如何设计接入协议215
15.1.2　如何设计KV操作216
15.1.3　如何实现分布式集群218
15.2　如何实现代码220
15.2.1　如何实现接入协议220
15.2.2　如何实现KV操作222
15.2.3　如何实现分布式集群224
15.3　本章小结229