del

极客时间专栏/geek/分布式协议与算法实战/理论篇/01 | 拜占庭将军问题：有叛徒的情况下，如何才能达成共识？.md

@@ -0,0 +1,145 @@
+<audio id="audio" title="01 | 拜占庭将军问题：有叛徒的情况下，如何才能达成共识？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/12/90/129c68b3904facbd8f64ac38164b7690.mp3"></audio>
+
+你好，我是韩健。
+
+在日常工作中，我常听到有人吐槽“没看懂拜占庭将军问题”“中文的文章看不懂，英文论文更看不下去”。想必你也跟他们一样，有类似的感受。
+
+在我看来，拜占庭将军问题（The Byzantine Generals Problem），它其实是借拜占庭将军的故事展现了分布式共识问题，还探讨和论证了解决的办法。而大多数人觉得它难理解，除了因为分布式共识问题比较复杂之外，还与莱斯利·兰伯特（Leslie Lamport）的讲述方式有关，他在一些细节上（比如，口信消息型拜占庭问题之解的算法过程上）没有说清楚。
+
+实际上，它是分布式领域最复杂的一个容错模型，一旦搞懂它，你就能掌握分布式共识问题的解决思路，还能更深刻地理解常用的共识算法，在设计分布式系统的时候，也能根据场景特点选择适合的算法，或者设计适合的算法了。而我把拜占庭将军的问题放到第一讲，主要是因为它很好地抽象了分布式系统面临的共识问题，理解了这个问题，会为你接下来的学习打下基础。
+
+那么接下来，我就以战国时期六国抗秦的故事为主线串联起整篇文章，让你读懂、学透。
+
+## 苏秦的困境
+
+战国时期，齐、楚、燕、韩、赵、魏、秦七雄并立，后来秦国的势力不断强大起来，成了东方六国的共同威胁。于是，这六个国家决定联合，全力抗秦，免得被秦国各个击破。一天，苏秦作为合纵长，挂六国相印，带着六国的军队叩关函谷，驻军在了秦国边境，为围攻秦国作准备。但是，因为各国军队分别驻扎在秦国边境的不同地方，所以军队之间只能通过信使互相联系，这时，苏秦面临了一个很严峻的问题：如何统一大家的作战计划？
+
+万一一些诸侯国在暗通秦国，发送误导性的作战信息，怎么办？如果信使被敌人截杀，甚至被敌人间谍替换，又该怎么办？这些都会导致自己的作战计划被扰乱，然后出现有的诸侯国在进攻，有的诸侯国在撤退的情况，而这时，秦国一定会趁机出兵，把他们逐一击破的。
+
+**所以，如何达成共识，制定统一的作战计划呢？苏秦他很愁。**
+
+这个故事，是拜占庭将军问题的一个简化表述，苏秦面临的就是典型的共识难题，也就是如何在可能有误导信息的情况下，采用合适的通讯机制，让多个将军达成共识，制定一致性的作战计划？
+
+你可以先停下来想想，这个问题难在哪儿？我们又是否有办法，帮助诸侯国们达成共识呢？
+
+## 二忠一叛的难题
+
+为了便于你理解和层层深入，我先假设只有3个国家要攻打秦国，这三个国家的三位将军，咱们简单点儿，分别叫齐、楚、燕。同时，又因为秦国很强大，所以只有半数以上的将军参与进攻，才能击败敌人（注意，这里是假设哈，你别较真），在这个期间，将军们彼此之间需要通过信使传递消息，然后协商一致之后，才能在同一时间点发动进攻。
+
+举个例子，有一天，这三位将军各自一脸严肃地讨论明天是进攻还是撤退，并让信使传递信息，按照“少数服从多数”的原则投票表决，两个人意见一致就可以了，比如：
+
+1. 齐根据侦查情况决定撤退；
+1. 楚和燕根据侦查信息，决定进攻。
+
+那么按照原则，齐也会进攻。最终，3支军队同时进攻，大败秦军。
+
+<img src="https://static001.geekbang.org/resource/image/0b/d2/0bf66342fa03d73cf4b62b7497939bd2.jpg" alt="">
+
+**可是，问题来了：** 一旦有人在暗通秦国，就会出现作战计划不一致的情况。比如齐向楚、燕分别发送了“撤退”的消息，燕向齐和楚发送了“进攻”的消息。**撤退：进攻=1:1，无论楚投进攻还是撤退，都会成为2:1，这个时候还是会形成一个一致性的作战方案。**
+
+但是，楚这个叛徒在暗中配合秦国，让信使向齐发送了“撤退”，向燕发送了“进攻”，那么：
+
+- 燕看到的是，撤退：进攻=1:2；
+- 齐看到的是，撤退：进攻=2:1。
+
+按照“少数服从多数”的原则，就会出现燕单独进攻秦军，当然，最后肯定是因为寡不敌众，被秦军给灭了。
+
+<img src="https://static001.geekbang.org/resource/image/b3/0b/b3f01caa021dae1cdf4051cceb6d3d0b.jpg" alt="">
+
+在这里，你可以看到，叛将楚通过发送误导信息，非常轻松地干扰了齐和燕的作战计划，导致这两位忠诚将军被秦军逐一击败。**这就是所说的二忠一叛难题。** 那么苏秦应该怎么解决这个问题呢？我们来帮苏秦出出主意。
+
+如果你觉得上面的逻辑有点绕的话，可以找张白纸，自己比划比划。
+
+## 苏秦该怎么办？
+
+#### 解决办法一：口信消息型拜占庭问题之解
+
+先来说说第一个解决办法。首先，三位将军都分拨一部分军队，由苏秦率领，苏秦参与作战计划讨论并执行作战指令。这样，3位将军的作战讨论，就变为了4位将军的作战讨论，这能够增加讨论中忠诚将军的数量。
+
+然后呢，4位将军还约定了，如果没有收到命令，就执行预设的默认命令，比如“撤退”。除此之外，还约定一些流程来发送作战信息、执行作战指令，比如，进行两轮作战信息协商。为什么要执行两轮呢？先卖个关子，你一会儿就知道了。
+
+**第一轮：**
+
+- 先发送作战信息的将军作为指挥官，其他的将军作为副官；
+- 指挥官将他的作战信息发送给每位副官；
+- 每位副官，将从指挥官处收到的作战信息，作为他的作战指令；如果没有收到作战信息，将把默认的“撤退”作为作战指令。
+
+**第二轮：**
+
+- 除了第一轮的指挥官外，剩余的3位将军将分别作为指挥官，向另外2位将军发送作战信息；
+- 然后，这3位将军按照“少数服从多数”，执行收到的作战指令。
+
+为了帮助你直观地理解苏秦的整个解决方案，我来演示一下作战信息协商过程。**而且，我会分别以忠诚将军和叛将先发送作战信息为例来演示，** 这样可以完整地演示叛将对作战计划干扰破坏的可能性。
+
+首先是3位忠诚的将军先发送作战信息的情况。
+
+为了演示方便，假设苏秦先发起作战信息，作战指令是“进攻”。那么在第一轮作战信息协商中，苏秦向齐、楚、燕发送作战指令“进攻”。
+
+<img src="https://static001.geekbang.org/resource/image/b6/01/b6143760b8095ba31fcfc97daf619d01.jpg" alt="">
+
+在第二轮作战信息协商中，齐、楚、燕分别作为指挥官，向另外2位发送作战信息“进攻”，因为楚已经叛变了，所以，为了干扰作战计划，他就对着干，发送“撤退”作战指令。
+
+<img src="https://static001.geekbang.org/resource/image/9c/50/9c47038ca1c39422040fa3f4b65a2950.jpg" alt="">
+
+最终，齐和燕收到的作战信息都是“进攻、进攻、撤退”，按照原则，齐和燕与苏秦一起执行作战指令“进攻”，实现了作战计划的一致性，保证了作战的胜利。
+
+那么，如果是叛徒楚先发送作战信息，干扰作战计划，结果会有所不同么？我们来具体看一看。在第一轮作战信息协商中，楚向苏秦发送作战指令“进攻”，向齐、燕发送作战指令“撤退”。
+
+<img src="https://static001.geekbang.org/resource/image/93/5f/93cda6d0a5646593826e6338d733825f.jpg" alt="">
+
+然后，在第二轮作战信息协商中，苏秦、齐、燕分别作为指挥官，向另外两位发送作战信息。
+
+<img src="https://static001.geekbang.org/resource/image/8f/14/8fdac1df9027711347f178bb9d3ccf14.jpg" alt="">
+
+最终，苏秦、齐和燕收到的作战信息都是“撤退、撤退、进攻”，按照原则，苏秦、齐和燕一起执行作战指令“撤退”，实现了作战计划的一致性。也就是说，无论叛将楚如何捣乱，苏秦、齐和燕，都执行一致的作战计划，保证作战的胜利。
+
+这个解决办法，其实是兰伯特在论文《[The Byzantine Generals Problem](https://www.microsoft.com/en-us/research/publication/byzantine-generals-problem/)》中提到的口信消息型拜占庭问题之解：**如果叛将人数为m，将军人数不能少于3m + 1 ，那么拜占庭将军问题就能解决了。** 不过，作者在论文中没有讲清楚一些细节，为了帮助你阅读和理解论文，在这里我补充一点：
+
+**这个算法有个前提**，也就是叛将人数m，或者说能容忍的叛将数m，是已知的。在这个算法中，叛将数m决定递归循环的次数（也就是说，叛将数m决定将军们要进行多少轮作战信息协商），即m+1轮（所以，你看，只有楚是叛变的，那么就进行了两轮）。你也可以从另外一个角度理解：n位将军，最多能容忍(n - 1) / 3位叛将。**关于这个公式，你只需要记住就好了，推导过程你可以参考论文。**
+
+不过，这个算法虽然能解决拜占庭将军问题，但它有一个限制：如果叛将人数为m，那么将军总人数必须不小于3m + 1。
+
+在二忠一叛的问题中，在存在1位叛将的情况下，必须增加1位将军，将3位将军协商共识，转换为4位将军协商共识，这样才能实现忠诚将军的一致性作战计划。那么有没有办法，在不增加将军人数的时候，直接解决二忠一叛的难题呢？
+
+#### 解决办法二：签名消息型拜占庭问题之解
+
+其实，苏秦还可以通过签名的方式，在不增加将军人数的情况下，解决二忠一叛的难题。首先，苏秦要通过印章、虎符等信物，实现这样几个特性：
+
+- 忠诚将军的签名无法伪造，而且对他签名消息的内容进行任何更改都会被发现；
+- 任何人都能验证将军签名的真伪。
+
+这时，如果忠诚的将军，比如齐先发起作战信息协商，一旦叛将小楚修改或伪造收到的作战信息，那么燕在接收到楚的作战信息的时候，会发现齐的作战信息被修改，楚已叛变，这时他将忽略来自楚的作战信息，最终执行齐发送的作战信息。
+
+<img src="https://static001.geekbang.org/resource/image/e9/05/e9c5ff8d9591f9a00adcfcfd4981cb05.jpg" alt="">
+
+如果叛变将军楚先发送误导的作战信息，那么，齐和燕将按照一定规则（比如取中间的指令）在排序后的所有已接收到的指令中（比如撤退、进攻）中选取一个指令，进行执行，最终执行一致的作战计划。
+
+<img src="https://static001.geekbang.org/resource/image/3a/2e/3a697c2ed35f4c446b6414770a5d392e.jpg" alt="">
+
+这个解决办法，是兰伯特在论文中提到的签名消息型拜占庭问题之解。而通过签名机制约束叛将的叛变行为，任何叛变行为都会被发现，也就会实现无论有多少忠诚的将军和多少叛将，忠诚的将军们总能达成一致的作战计划。
+
+我想，如果当时苏秦能够具备分布式系统设计的思维，掌握这几种算法，应该就不用担心作战计划被干扰了吧。
+
+## 内容小结
+
+本节课，为了帮助你理解拜占庭将军问题，我讲了苏秦协商作战的故事，现在让我们跳回现实世界，回到计算机世界的分布式场景中：
+
+- 故事里的各位将军，你可以理解为计算机节点；
+- 忠诚的将军，你可以理解为正常运行的计算机节点；
+- 叛变的将军，你可以理解为出现故障并会发送误导信息的计算机节点；
+- 信使被杀，可以理解为通讯故障、信息丢失；
+- 信使被间谍替换，可以理解为通讯被中间人攻击，攻击者在恶意伪造信息和劫持通讯。
+
+这样一来，你是不是就理解了计算机分布式场景中面临的问题，并且知道了解决的办法呢？
+
+那么我想强调的是，拜占庭将军问题描述的是最困难的，也是最复杂的一种分布式故障场景，除了存在故障行为，还存在恶意行为的一个场景。你要注意，在存在恶意节点行为的场景中（比如在数字货币的区块链技术中），必须使用拜占庭容错算法（Byzantine Fault Tolerance，BFT）。除了故事中提到两种算法，常用的拜占庭容错算法还有：PBFT算法，PoW算法（为了重点突出，这些内容我会在后面讲解）。
+
+而在计算机分布式系统中，最常用的是非拜占庭容错算法，即故障容错算法（Crash Fault Tolerance，CFT）。**CFT解决的是分布式的系统中存在故障，但不存在恶意节点的场景下的共识问题。** 也就是说，这个场景可能会丢失消息，或者有消息重复，但不存在错误消息，或者伪造消息的情况。常见的算法有Paxos算法、Raft算法、ZAB协议（这些内容我同样会在后面讲解）。
+
+那么，如何在实际场景选择合适的算法类型呢？答案是：如果能确定该环境中各节点是可信赖的，不存在篡改消息或者伪造消息等恶意行为（例如DevOps环境中的分布式路由寻址系统），推荐使用非拜占庭容错算法；反之，推荐使用拜占庭容错算法，例如在区块链中使用PoW算法。
+
+## 课堂思考
+
+文中我提了两类容错算法，分别是拜占庭容错算法和非拜占庭容错算法，那么在常见的分布式软件系统中，哪些场景必须要使用拜占庭容错算法呢？哪些场景使用非拜占庭容错算法就可以了呢？欢迎在留言区分享你的看法，与我一同讨论。
+
+最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

极客时间专栏/geek/分布式协议与算法实战/理论篇/02 | CAP理论：分布式系统的PH试纸，用它来测酸碱度.md

@@ -0,0 +1,148 @@
+<audio id="audio" title="02 | CAP理论：分布式系统的PH试纸，用它来测酸碱度" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1d/34/1d05c9912ee0ba691048ab868e40e734.mp3"></audio>
+
+你好，我是韩健。
+
+很多同学可能都有这样的感觉，每次要开发分布式系统的时候，就会遇到一个非常棘手的问题，那就是如何根据业务特点，为系统设计合适的分区容错一致性模型，以实现集群能力。这个问题棘手在当发生分区错误时，应该如何保障系统稳定运行，不影响业务。
+
+这和我之前经历的一件事比较像，当时，我负责自研InfluxDB系统的项目，接手这个项目后，**我遇到的第一个问题就是，如何为单机开源版的InfluxDB设计分区容错一致性模型。**因为InfluxDB有META和DATA两个节点，它们的功能和数据特点不同，所以我还需要考虑这两个逻辑单元的特点，然后分别设计分区容错一致性模型。
+
+那个时候，我想到了CAP理论，并且在CAP理论的帮助下，成功地解决了问题。讲到这儿，你可能会问了：为什么CAP理论可以解决这个问题呢？
+
+因为在我看来，CAP理论是一个很好的思考框架，它对分布式系统的特性做了高度抽象，比如抽象成了一致性、可用性和分区容错性，并对特性间的冲突（也就是CAP不可能三角）做了总结。一旦掌握它，你就像拥有了引路人，自然而然就能根据业务场景的特点进行权衡，设计出适合的分区容错一致性模型。
+
+那么问题来了：我说的一致性、可用性和分区容错性是什么呢？它们之间有什么关系？你又该如何使用CAP理论来思考和设计分区容错一致性模型呢？这些问题就是我们本节课所要讲的重点了。我建议你集中注意力，认真学习内容，并学以致用，把CAP理论应用到日常工作中。
+
+## CAP三指标
+
+我刚刚提到，CAP理论对分布式系统的特性做了高度抽象，形成了三个指标：
+
+- 一致性（Consistency）
+- 可用性（Availability）
+- 分区容错性（Partition Tolerance）
+
+一致性说的是客户端的每次读操作，不管访问哪个节点，要么读到的都是同一份最新写入的数据，要么读取失败。
+
+你可以把一致性看作是分布式系统，对访问自己的客户端的一种承诺：不管你访问哪个节点，要么我给你返回的都是绝对一致的最新写入的数据，要么你读取失败。你可以看到，一致性强调的是数据正确。
+
+为了帮你理解一致性这个指标，我给你举一个具体的例子。比如，2个节点的KV存储，原始的KV记录为“X = 1”。
+
+<img src="https://static001.geekbang.org/resource/image/5d/6d/5d666afe96731c95556ee7d5a1194d6d.jpg" alt="">
+
+紧接着，客户端向节点1发送写请求“SET X = 2”。
+
+<img src="https://static001.geekbang.org/resource/image/58/e7/58519857f8f6b3edf8ebe38d3c18ede7.jpg" alt="">
+
+如果节点1收到写请求后，只将节点1的X值更新为2，然后返回成功给客户端。
+
+<img src="https://static001.geekbang.org/resource/image/56/c4/56922def2471e194d3e5420ad006e1c4.jpg" alt="">
+
+那么，此时如果客户端访问节点2执行读操作，就无法读到最新写入的X值，这就不满足一致性了。<br>
+<img src="https://static001.geekbang.org/resource/image/31/1f/31b628027351e4b5a6ffb31cdcba431f.jpg" alt="">
+
+如果节点1收到写请求后，通过节点间的通讯，同时将节点1和节点2的X值都更新为2，然后返回成功给客户端。
+
+<img src="https://static001.geekbang.org/resource/image/89/51/890b9890584a4f17306da88fedea3451.jpg" alt="">
+
+那么在完成写请求后，不管客户端访问哪个节点，读取到的都是同一份最新写入的数据，这就叫一致性。
+
+<img src="https://static001.geekbang.org/resource/image/9b/c2/9bf9c133ad815219791f87799bee5cc2.jpg" alt="">
+
+一致性这个指标，描述的是分布式系统非常重要的一个特性，强调的是数据正确。也就是说，对客户端而言，每次读都能读取到最新写入的数据。
+
+不过集群毕竟不是单机，当发生分区故障的时候，有时不能仅仅因为节点间出现了通讯问题，无法响应最新写入的数据，之后在客户端查询数据时，就一直返回给客户端出错信息。这句话怎么理解呢？我来举个例子。
+
+业务集群中的一些关键系统，比如名字路由系统（基于Raft算法的强一致性系统），如果仅仅因为发生了分区故障，无法响应最新数据（比如不满足“大多数”，没有了领导者），为了不破坏一致性，那么客户端查询相关路由信息时，系统就一直返回给客户端出错信息，此时相关的业务都将因为获取不到指定路由信息而不可用、瘫痪，这可以说是灾难性的故障了。
+
+这个时候，我们就需要牺牲数据正确，每个节点使用本地数据来响应客户端请求，来保证服务可用，**这就是我要说的另外一个指标，可用性。**
+
+可用性说的是任何来自客户端的请求，不管访问哪个非故障节点，都能得到响应数据，但不保证是同一份最新数据。你也可以把可用性看作是分布式系统对访问本系统的客户端的另外一种承诺：我尽力给你返回数据，不会不响应你，但是我不保证每个节点给你的数据都是最新的。**这个指标强调的是服务可用，但不保证数据正确。**
+
+我还是用一个例子，帮助你理解一下。比如，用户可以选择向节点1或节点2 发起读操作，如果不管节点间的数据是否一致，只要节点服务器收到请求，就响应X的值，那么，2个节点的服务是满足可用性的。
+
+<img src="https://static001.geekbang.org/resource/image/b2/a4/b27f4ff771fa8e9b671f5864c96d9aa4.jpg" alt="">
+
+最后的分区容错性说的是，当节点间出现任意数量的消息丢失或高延迟的时候，系统仍然在继续工作。也就是说，分布式系统在告诉访问本系统的客户端：不管我的内部出现什么样的数据同步问题，我会一直运行。**这个指标，强调的是集群对分区故障的容错能力。**
+
+来看下面的图，当节点1和节点2通信出问题的时候，如果系统仍能继续工作，那么，2个节点是满足分区容错性的。
+
+<img src="https://static001.geekbang.org/resource/image/a6/65/a61a426bccbe27e48ca75db909ae8265.jpg" alt="">
+
+因为分布式系统与单机系统不同，它涉及到多节点间的通讯和交互，节点间的分区故障是必然发生的，**所以我要提醒你的是，在分布式系统中分区容错性是必须要考虑的。**
+
+现在你了解了一致性、可用性和分区容错性，那么你在设计分布式系统时，是选择一致性？还是可用性？还是分区容错性？还是都可以选择呢？这三个特性有什么冲突么？这些问题就与我接下来要讲的“CAP不可能三角”有关了。
+
+## CAP不可能三角
+
+CAP不可能三角说的是对于一个分布式系统而言，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）3个指标不可兼得，只能在3个指标中选择2个。
+
+<img src="https://static001.geekbang.org/resource/image/67/48/67aa4a0e56dcc8ad34bf1b0232f12748.jpg" alt="">
+
+CAP不能三角最初是埃里克·布鲁尔（Eric Brewer）基于自己的工程实践，提出的一个猜想，后被赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）证明，证明过程可以参考论文[《Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services》](https://dl.acm.org/citation.cfm?id=564601)，你记住结论就好了。不过，为了帮你阅读论文，我补充一点：
+
+**基于证明严谨性的考虑，赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）对指标的含义做了预设和限制，比如，将一致性限制为原子一致性。**
+
+说了这么多，那么CAP理论是怎么解决我在开篇提到的问题呢？或者说，你要如何使用CAP理论来思考和设计分区容错一致性模型呢？
+
+## 如何使用CAP理论
+
+我们都知道，只要有网络交互就一定会有延迟和数据丢失，而这种状况我们必须接受，还必须保证系统不能挂掉。所以就像我上面提到的，节点间的分区故障是必然发生的。也就是说，分区容错性（P）是前提，是必须要保证的。
+
+现在就只剩下一致性（C）和可用性（A）可以选择了：要么选择一致性，保证数据正确；要么选择可用性，保证服务可用。那么CP和AP的含义是什么呢？
+
+- 当选择了一致性（C）的时候，一定会读到最新的数据，不会读到旧数据，但如果因为消息丢失、延迟过高发生了网络分区，那么这个时候，当集群节点接收到来自客户端的读请求时，为了不破坏一致性，可能会因为无法响应最新数据，而返回出错信息。
+- 当选择了可用性（A）的时候，系统将始终处理客户端的查询，返回特定信息，如果发生了网络分区，一些节点将无法返回最新的特定信息，它们将返回自己当前的相对新的信息。
+
+**这里我想强调一点，大部分人对CAP理论有个误解，认为无论在什么情况下，分布式系统都只能在C和A中选择1个。**其实，在不存在网络分区的情况下，也就是分布式系统正常运行时（这也是系统在绝大部分时候所处的状态），就是说在不需要P时，C和A能够同时保证。只有当发生分区故障的时候，也就是说需要P时，才会在C和A之间做出选择。而且如果读操作会读到旧数据，影响到了系统运行或业务运行（也就是说会有负面的影响），推荐选择C，否则选A。
+
+那么我当时是怎么根据场景特点，进行CAP权衡，设计适合的分布式系统呢？为了便于你理解，我先来说说背景。
+
+开源版的InfluxDB，缺乏集群能力和可用性，而且，InfluxDB是由META节点和DATA节点2个逻辑单元组成，这2个节点的功能和数据特点不同，需要我们分别为它们设计分区容错一致性模型。
+
+<img src="https://static001.geekbang.org/resource/image/93/5d/9397c99a462d1dcb9ca69328ba34515d.jpg" alt="" title="InfluxDB程序的逻辑架构示意图">
+
+我具体是这么设计的：
+
+<li>
+**作为分布式系统，分区容错性是必须要实现的，**不能因为节点间出现了分区故障，而出现整个系统不工作的情况。
+</li>
+<li>
+考虑到META节点保存的是系统运行的关键元信息，比如数据库名、表名、保留策略信息等，所以必须实现一致性。也就是说，每次读，都要能读取到最新数据，这样才能避免因为查询不到指定的元信息，时序数据记录写入失败或者系统没办法正常运行。比如，创建了数据库telegraf之后，如果系统不能立刻读取到这条新的元信息，那么相关的时序数据记录，就会因为找不到指定数据库信息而写入失败，**所以，我选择CAP理论中的C和P，采用CP架构。**
+</li>
+<li>
+DATA节点保存的是具体的时序数据记录，比如一条记录CPU负载的时序数据，“cpu_usage,host=server01,location=cn-sz user=23.0,system=57.0”。虽然这些数据不是系统运行相关的元信息，但服务会被访问频繁，水平扩展、性能、可用性等是关键，**所以，我选择了CAP理论中的A和P，采用AP架构。**
+</li>
+
+你看，我用CAP理论进行思考，并分别设计了InfluxDB的META节点和DATA节点的分区容错一致性模型，而你也可以采用类似的思考方法，设计出符合自己业务场景的分区容错一致性模型。
+
+那么假设我当时没有受到CAP理论的影响，或者对CAP理论理解不深入，DATA节点不采用AP架构，而是直接使用了现在比较流行的共识算法，比如使用Raft算法，会有什么痛点呢？
+
+- 受限于Raft的强领导者模型。所有写请求都在领导者节点上处理，整个集群的写性能等于单机性能。这样会造成集群接入性能低下，无法支撑海量或大数据量的时序数据。
+- 受限于强领导者模型，以及Raft的节点和副本一一对应的限制，无法实现水平扩展，分布式集群扩展了读性能，但写性能并没有提升。这样会出现写性能低下，和因为架构上的限制，无法提升写性能的问题。
+
+关于Raft算法的一些细节（比如强领导模型），我会在07讲详细带你了解，这里你知道有这么回事儿就可以了。
+
+那么在这里，我也想考考你：如果META节点采用AP架构，会有什么痛点呢？你可以思考一下。
+
+## 内容小结
+
+本节课我主要带你了解了CAP理论，以及CAP理论的应用，我希望你明确的重点如下：
+
+<li>
+CA模型，在分布式系统中不存在。因为舍弃P，意味着舍弃分布式系统，就比如单机版关系型数据库MySQL，如果MySQL要考虑主备或集群部署时，它必须考虑P。
+</li>
+<li>
+CP模型，采用CP模型的分布式系统，舍弃了可用性，一定会读到最新数据，不会读到旧数据。一旦因为消息丢失、延迟过高发生了网络分区，就影响用户的体验和业务的可用性（比如基于Raft的强一致性系统，此时可能无法执行读操作和写操作）。典型的应用是Etcd，Consul和Hbase。
+</li>
+<li>
+AP模型，采用AP模型的分布式系统，舍弃了一致性，实现了服务的高可用。用户访问系统的时候，都能得到响应数据，不会出现响应错误，但会读到旧数据。典型应用就比如Cassandra和DynamoDB。
+</li>
+
+在多年的开发实践中，我一直喜欢埃里克·布鲁尔的猜想，不是因为它是CAP理论的本源，意义重大，而是因为它源自高可用、高扩展大型互联网系统的实践，强调在数据一致性（ACID）和服务可用性（BASE）之间权衡妥协。在我看来，CAP理论像PH试纸一样，可以用来度量分布式系统的酸碱值，帮助我们思考如何设计合适的酸碱度，在一致性和可用性之间进行妥协折中，设计出满足场景特点的分布式系统。关于酸（Acid）和碱（Base），我会在03和04讲带你了解。
+
+最后我想说的是，在当前分布式系统开发中，延迟是非常重要的一个指标，比如，在QQ后台的名字路由系统中，我们通过延迟评估服务可用性，进行负载均衡和容灾；再比如，在Hashicorp/Raft实现中，通过延迟评估领导者节点的服务可用性，以及决定是否发起领导者选举。所以，我希望你在分布式系统的开发中，也能意识到延迟的重要性，能通过延迟来衡量服务的可用性。
+
+## 课堂思考
+
+既然我提了CAP理论是一个很好的思考框架，能帮助我们思考，如何进行权衡，设计适合业务场景特性的分布式系统，那么你不妨思考一下，CP模型的KV存储和AP模型的KV存储，分别适合怎样的业务场景呢？欢迎在留言区分享你的看法，与我一同讨论。
+
+最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。

极客时间专栏/geek/分布式协议与算法实战/理论篇/03 | ACID理论：CAP的酸，追求一致性.md

@@ -0,0 +1,128 @@
+<audio id="audio" title="03 | ACID理论：CAP的酸，追求一致性" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/15/aa/155bbe97c390b62fcf9a008de2db76aa.mp3"></audio>
+
+你好，我是韩健。
+
+提到ACID，我想你并不陌生，很多同学也会觉得它容易理解，在单机上实现ACID也不难，比如可以通过锁、时间序列等机制保障操作的顺序执行，让系统实现ACID特性。但是，一说要实现分布式系统的ACID特性，很多同学就犯难了。那么问题来了，为什么分布式系统的ACID特性在实现上，比较难掌握呢？
+
+在我看来，ACID理论是对事务特性的抽象和总结，方便我们实现事务。你可以理解成：如果实现了操作的ACID特性，那么就实现了事务。而大多数人觉得比较难，是因为分布式系统涉及多个节点间的操作。加锁、时间序列等机制，只能保证单个节点上操作的ACID特性，无法保证节点间操作的ACID特性。
+
+那么怎么做才会让实现不那么难呢？答案是你要掌握分布式事务协议，比如二阶段提交协议和TCC（Try-Confirm-Cancel）。这也是我接下来重点和你分享的内容。
+
+不过在带你了解二阶段提交协议和TCC之前，咱们先继续看看苏秦的故事，看这回苏秦又遇到了什么事儿。
+
+最近呢，秦国按捺不住自己躁动的心，开始骚扰魏国边境，魏王头疼，向苏秦求助，苏秦认为“三晋一家亲”，建议魏王联合赵、韩一起对抗秦国。但是这三个国家实力都很弱，需要大家都同意联合，一致行动，如果有任何一方不方便行动，就取消整个计划。
+
+根据侦查情况，明天发动反攻胜算比较大。苏秦想协调赵、魏、韩，明天一起行动。**那么对苏秦来说，他面临的问题是，如何高效协同赵、魏、韩一起行动，并且保证当有一方不方便行动时，取消整个计划。**
+
+<img src="https://static001.geekbang.org/resource/image/09/55/0951213850cbf7a9f6db1d99511bd455.jpg" alt="">
+
+苏秦面对的这个新问题，就是典型的如何实现分布式事务的问题，**赵、魏、韩明天攻打秦国，这三个操作组成一个分布式事务，要么全部执行，要么全部不执行。**
+
+了解了这个问题之后，我们看看如何通过二阶段提交协议和TCC，来帮助苏秦解决这个难题。
+
+## 二阶段提交协议
+
+二阶段提交协议，顾名思义，就是通过二阶段的协商来完成一个提交操作，那么具体是怎么操作的呢？
+
+首先，苏秦发消息给赵，赵接收到消息后就扮演协调者（Coordinator）的身份，由赵联系魏和韩，发起二阶段提交：
+
+<img src="https://static001.geekbang.org/resource/image/c4/2b/c43a3bffad5dee2d4f465df3fc22c52b.jpg" alt="">
+
+赵发起二阶段提交后，先进入**提交请求阶段（又称投票阶段）。** 为了方便演示，我们先假设赵、魏、韩明天都能去攻打秦国：
+
+<img src="https://static001.geekbang.org/resource/image/72/af/72f1414c2d4f2e7a66b8dd246165a8af.jpg" alt="">
+
+也就是说，第一步，赵分别向魏、韩发送消息：“明天攻打秦国，方便吗？”
+
+第二步，赵、魏、韩，分别评估明天能否去攻打秦国，如果能，就预留时间并锁定，不再安排其他军事活动。
+
+第三步，赵得到全部的回复结果（包括他自己的评估结果），都是YES。
+
+赵收到所有回复后，进入**提交执行阶段（又称完成阶段），** 也就是具体执行操作了，大致步骤如下：
+
+<img src="https://static001.geekbang.org/resource/image/f5/dc/f5deb827fd03e10106ed6b6839f1d7dc.jpg" alt="">
+
+首先，赵按照“要么全部执行，要么放弃”的原则，统计投票结果，因为所有的回复结果都是YES，所以赵决定执行分布式事务，明天攻打秦国。
+
+然后，赵通知魏、韩：“明天攻打秦国。”
+
+接到通知之后，魏、韩执行事务，明天攻打秦国。
+
+最后，魏、韩将执行事务的结果返回给赵。
+
+这样一来，赵就将事务执行的结果（也就是赵、魏、韩明天一起攻打秦国），返回给苏秦，那么，这时苏秦就解决了问题，协调好了明天的作战计划。
+
+在这里，赵采用的方法就是二阶段提交协议。在这个协议中：
+
+- 你可以将“赵明天攻打秦国、魏明天攻打秦国、韩明天攻打秦国”，理解成一个分布式事务操作；
+- 将赵、魏、韩理解为分布式系统的三个节点，其中，赵是协调者（Coordinator），将苏秦理解为业务，也就是客户端；
+- 将消息理解为网络消息；
+- 将“明天能否攻打秦国，预留时间”，理解为评估事务中需要操作的对象和对象状态，是否准备好，能否提交新操作。
+
+需要注意的是，在第一个阶段，每个参与者投票表决事务是放弃还是提交。一旦参与者投票要求提交事务，那么就不允许放弃事务。也就是说，**在一个参与者投票要求提交事务之前，它必须保证能够执行提交协议中它自己那一部分，即使参与者出现故障或者中途被替换掉。** 这个特性，是我们需要在代码实现时保障的。
+
+还需要你注意的是，在第二个阶段，事务的每个参与者执行最终统一的决定，提交事务或者放弃事务。这个约定，是为了实现ACID中的原子性。
+
+[二阶段提交协议](https://courses.cs.washington.edu/courses/cse551/09au/papers/CSE550BHG-Ch7.pdf)最早是用来实现数据库的分布式事务的，不过现在最常用的协议是XA协议。这个协议是X/Open国际联盟基于二阶段提交协议提出的，也叫作X/Open Distributed Transaction Processing（DTP）模型，比如MySQL就是通过MySQL XA实现了分布式事务。
+
+但是不管是原始的二阶段提交协议，还是XA协议，都存在一些问题：
+
+- 在提交请求阶段，需要预留资源，在资源预留期间，其他人不能操作（比如，XA在第一阶段会将相关资源锁定）；
+- 数据库是独立的系统。
+
+因为上面这两点，我们无法根据业务特点弹性地调整锁的粒度，而这些都会影响数据库的并发性能。那用什么办法可以解决这些问题呢？答案就是TCC。
+
+## TCC（Try-Confirm-Cancel）
+
+TCC是Try（预留）、Confirm（确认）、Cancel（撤销） 3个操作的简称，它包含了预留、确认或撤销这2个阶段。那么你如何使用TCC协议，解决苏秦面临的问题呢？
+
+首先，我们先**进入到预留阶段**，大致的步骤如下：
+
+<img src="https://static001.geekbang.org/resource/image/84/e2/84a56f9ef977e4bc10424f34e59140e2.jpg" alt="">
+
+第一步，苏秦分别发送消息通知赵、魏、韩，让他们预留明天的时间和相关资源。然后苏秦实现确认操作（明天攻打秦国），和撤销操作（取消明天攻打秦国）。
+
+第二步，苏秦收到赵、魏、韩的预留答复，都是OK。
+
+如果预留阶段的执行都没有问题，就进入**确认阶段**，大致步骤如下：
+
+<img src="https://static001.geekbang.org/resource/image/28/db/28d109d73b31eb750912c55e795af1db.jpg" alt="">
+
+第一步，苏秦执行确认操作，通知赵、魏、韩明天攻打秦国。
+
+第二步，收到确认操作的响应，完成分布式事务。
+
+如果预留阶段执行出错，比如赵的一部分军队还在赶来的路上，无法出兵，那么就进入撤销**阶段**，大致步骤如下：
+
+<img src="https://static001.geekbang.org/resource/image/b1/8a/b10a640509628053bacb0897c741608a.jpg" alt="">
+
+第一步，苏秦执行撤销操作，通知赵、魏、韩取消明天攻打秦国的计划。
+
+第二步，收到撤销操作的响应。
+
+你看，在经过了预留和确认（或撤销）2阶段的协商，苏秦实现这个分布式事务：赵、魏、韩三国，要么明天一起进攻，要么明天都按兵不动。
+
+其实在我看来，TCC本质上是补偿事务，**它的核心思想是针对每个操作都要注册一个与其对应的确认操作和补偿操作（也就是撤销操作）。** 它是一个业务层面的协议，你也可以将TCC理解为编程模型，TCC的3个操作是需要在业务代码中编码实现的，为了实现一致性，确认操作和补偿操作必须是等幂的，因为这2个操作可能会失败重试。
+
+另外，TCC不依赖于数据库的事务，而是在业务中实现了分布式事务，这样能减轻数据库的压力，但对业务代码的入侵性也更强，实现的复杂度也更高。所以，我推荐在需要分布式事务能力时，优先考虑现成的事务型数据库（比如MySQL XA），当现有的事务型数据库不能满足业务的需求时，再考虑基于TCC实现分布式事务。
+
+## 内容小结
+
+本节课我主要带你了解了实现分布式系统ACID特性的方法，二阶段提交协议和TCC，我希望你明确这样几个重点。
+
+<li>
+二阶段提交协议，不仅仅是协议，也是一种非常经典的思想。二阶段提交在达成提交操作共识的算法中应用广泛，比如XA协议、TCC、Paxos、Raft等。我希望你不仅能理解二阶段提交协议，更能理解协议背后的二阶段提交的思想，当后续需要时，能灵活地根据二阶段提交思想，设计新的事务或一致性协议。
+</li>
+<li>
+幂等性，是指同一操作对同一系统的任意多次执行，所产生的影响均与一次执行的影响相同，不会因为多次执行而产生副作用。常见的实现方法有Token、索引等。它的本质是通过唯一标识，标记同一操作的方式，来消除多次执行的副作用。
+</li>
+
+另外，我想补充一下，三阶段提交协议，虽然针对二阶段提交协议的“协调者故障，参与者长期锁定资源”的痛点，通过引入了询问阶段和超时机制，来减少资源被长时间锁定的情况，不过这会导致集群各节点在正常运行的情况下，使用更多的消息进行协商，增加系统负载和响应延迟。也正是因为这些问题，三阶段提交协议很少被使用，所以，你只要知道有这么个协议就可以了，但如果你想继续研究，可以参考《[Concurrency Control and Recovery in Database Systems](https://courses.cs.washington.edu/courses/cse551/09au/papers/CSE550BHG-Ch7.pdf)》来学习。
+
+最后我想强调的是，你可以将ACID特性理解为CAP中一致性的边界，最强的一致性，也就是CAP的酸（Acid）。根据CAP理论，如果在分布式系统中实现了一致性，可用性必然受到影响。比如，如果出现一个节点故障，则整个分布式事务的执行都是失败的。实际上，绝大部分场景对一致性要求没那么高，短暂的不一致是能接受的，另外，也基于可用性和并发性能的考虑，**建议在开发实现分布式系统，如果不是必须，尽量不要实现事务，可以考虑采用最终一致性**。
+
+## 课堂思考
+
+既然我提了一些实现分布式事务的方法，比如二阶段提交协议、TCC等，那么你不妨思考一下，事务型分布式系统有哪些优点，哪些缺点呢？欢迎在留言区分享你的看法，与我一同讨论。
+
+最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

极客时间专栏/geek/分布式协议与算法实战/理论篇/04 | BASE理论：CAP的碱，追求可用性.md

@@ -0,0 +1,100 @@
+<audio id="audio" title="04 | BASE理论：CAP的碱，追求可用性" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e3/17/e3135226b8d39af5eb78735ec2234017.mp3"></audio>
+
+你好，我是韩健。
+
+很多同学可能喜欢使用事务型的分布式系统，或者是强一致性的分布式系统，因为使用起来很方便，不需要考虑太多，就像使用单机系统一样。但是学了CAP理论后，你肯定知道在分布式系统中要实现强一致性必然会影响可用性。比如，在采用两阶段提交协议的集群系统中，因为执行提交操作，需要所有节点确认和投票。
+
+所以，集群的可用性是每个节点可用性的乘积，比如，假设3个节点的集群，每个节点的可用性为99.9％，那么整个集群的可用性为99.7％，也就是说，每个月约宕机129.6分钟，**这是非常严重的问题。** 而解决可用性低的关键在于，根据实际场景，尽量采用可用性优先的AP模型。
+
+讲到这儿，可能会有一些同学“举手提问”：这也太难了，难道没有现成的库或者方案，来实现合适的AP模型？是的，的确没有。因为它是一个动态模型，是基于业务场景特点妥协折中后设计实现的。不过，你可以借助BASE理论帮助你达成目的。
+
+在我看来，BASE理论是CAP理论中的AP的延伸，是对互联网大规模分布式系统的实践总结，强调可用性。几乎所有的互联网后台分布式系统都有BASE的支持，这个理论很重要，地位也很高。一旦掌握它，你就能掌握绝大部分场景的分布式系统的架构技巧，设计出适合业务场景特点的、高可用性的分布式系统。
+
+而它的核心就是基本可用（Basically Available）和最终一致性（Eventually consistent）。也有人会提到软状态（Soft state），在我看来，软状态描述的是实现服务可用性的时候系统数据的一种过渡状态，也就是说不同节点间，数据副本存在短暂的不一致。你只需要知道软状态是一种过渡状态就可以了，我们不多说。
+
+那么基本可用以及最终一致性到底是什么呢？你又如何在实践中使用BASE理论提升系统的可用性呢？这些就是本节课的重点了，而我建议你集中注意力，认真学习本节课的内容，学以致用，将BASE理论应用到日常工作中。
+
+## 实现基本可用的4板斧
+
+在我看来，基本可用是说，当分布式系统在出现不可预知的故障时，允许损失部分功能的可用性，保障核心功能的可用性。就像弹簧一样，遇到外界的压迫，它不是折断，而是变形伸缩，不断适应外力，实现基本的可用。
+
+具体说的话，你可以把基本可用理解成，当系统节点出现大规模故障的时候，比如专线的光纤被挖断、突发流量导致系统过载（出现了突发事件，服务被大量访问），这个时候可以通过服务降级，牺牲部分功能的可用性，保障系统的核心功能可用。
+
+就拿12306订票系统基本可用的设计为例，这个订票系统在春运期间，因为开始售票后先到先得的缘故，会出现极其海量的请求峰值，如何处理这个问题呢？
+
+咱们可以在不同的时间，出售不同区域的票，将访问请求错开，削弱请求峰值。比如，在春运期间，深圳出发的火车票在8点开售，北京出发的火车票在9点开售。**这就是我们常说的流量削峰。**
+
+另外，你可能已经发现了，在春运期间，自己提交的购票请求，往往会在队列中排队等待处理，可能几分钟或十几分钟后，系统才开始处理，然后响应处理结果，**这就是你熟悉的延迟响应。** 你看，12306订票系统在出现超出系统处理能力的突发流量的情况下，会通过牺牲响应时间的可用性，保障核心功能的运行。
+
+而12306通过流量削峰和延迟响应，是不是就实现了基本的可用呢？现在它不会再像最初的时候那样，常常404了吧？
+
+再比如，你正负责一个互联网系统，突然出现了网络热点事件，好多用户涌进来，产生了海量的突发流量，系统过载了，大量图片因为网络超时无法显示。那么这个时候你可以通过哪些方法，保障系统的基本可用呢？
+
+**相信你马上就能想到体验降级，** 比如用小图片来替代原始图片，通过降低图片的清晰度和大小，提升系统的处理能力。
+
+**然后你还能想到过载保护，** 比如把接收到的请求放在指定的队列中排队处理，如果请求等待时间超时了（假设是100ms），这个时候直接拒绝超时请求；再比如队列满了之后，就清除队列中一定数量的排队请求，保护系统不过载，实现系统的基本可用。
+
+**你看，和12306的设计类似，只不过你负责的互联网系统是通过牺牲部分功能的可用性，保障核心功能的运行。**
+
+我说了这么多，主要是想强调：基本可用在本质上是一种妥协，也就是在出现节点故障或系统过载的时候，通过牺牲非核心功能的可用性，保障核心功能的稳定运行。
+
+我希望你能在后续的分布式系统的开发中，**不仅掌握流量削峰、延迟响应、体验降级、过载保护这4板斧**，更能理解这4板斧背后的妥协折中，从而灵活地处理不可预知的突发问题。
+
+带你了解了基本可用之后，我再来说说BASE理论中，另一个非常核心的内容：最终一致性。
+
+## 最终的一致
+
+在我看来，最终一致性是说，系统中所有的数据副本在经过一段时间的同步后，最终能够达到一个一致的状态。也就是说，在数据一致性上，存在一个短暂的延迟。
+
+几乎所有的互联网系统采用的都是最终一致性，只有在实在无法使用最终一致性，才使用强一致性或事务，比如，对于决定系统运行的敏感元数据，需要考虑采用强一致性，对于与钱有关的支付系统或金融系统的数据，需要考虑采用事务。
+
+你可以将强一致性理解为最终一致性的特例，也就是说，你可以把强一致性看作是不存在延迟的一致性。**在实践中，你也可以这样思考：** 如果业务的某功能无法容忍一致性的延迟（比如分布式锁对应的数据），需要实现的是强一致性；如果能容忍短暂的一致性的延迟（比如QQ状态数据），就可以考虑最终一致性。
+
+那么如何实现最终一致性呢？你首先要知道它以什么为准，因为这是实现最终一致性的关键。一般来说，在实际工程实践中有这样几种方式：
+
+- 以最新写入的数据为准，比如AP模型的KV存储采用的就是这种方式；
+- 以第一次写入的数据为准，如果你不希望存储的数据被更改，可以以它为准。
+
+那实现最终一致性的具体方式是什么呢？常用的有这样几种。
+
+- 读时修复：在读取数据时，检测数据的不一致，进行修复。比如Cassandra 的Read Repair实现，具体来说，在向Cassandra系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。
+- 写时修复：在写入数据，检测数据的不一致时，进行修复。比如Cassandra 的Hinted Handoff实现。具体来说，Cassandra集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性。
+- 异步修复：这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复（更多信息可以参考[11讲](https://time.geekbang.org/column/article/208182)的反熵）。
+
+在这里，我想强调的是因为写时修复不需要做数据一致性对比，性能消耗比较低，对系统运行影响也不大，所以我推荐你在实现最终一致性时优先实现这种方式。而读时修复和异步修复因为需要做数据的一致性对比，性能消耗比较多，在开发实际系统时，你要尽量优化一致性对比的算法，降低性能消耗，避免对系统运行造成影响。
+
+另外，我还想补充一点，在实现最终一致性的时候，**我推荐同时实现自定义写一致性级别（比如All、Quorum、One、Any，更多信息你可以看一下[12讲](https://time.geekbang.org/column/article/209130)），** 让用户可以自主选择相应的一致性级别，比如可以通过设置一致性级别为All，来实现强一致性。
+
+现在，想必你了解了BASE理论的核心内容了吧？不过这是理论层面上的，那么在实践中，该如何使用BASE理论的呢？
+
+## 如何使用BASE理论
+
+我以自研InfluxDB系统中DATA节点的集群实现为例，带你来使用BASE理论。咱们先来看看如何保障基本可用。
+
+DATA节点的核心功能是读和写，所以基本可用是指读和写的基本可用。那么我们可以通过分片和多副本，实现读和写的基本可用。也就是说，将同一业务的数据先分片，然后再以多份副本的形式分布在不同的节点上。比如下面这张图，这个3节点2副本的集群，除非超过一半的节点都故障了，否则是能保障所有数据的读写的。
+
+<img src="https://static001.geekbang.org/resource/image/ae/d6/ae5fd43f4c878d0acdc188e9889d29d6.jpg" alt="">
+
+那么如果实现最终一致性呢？就像我上文提到的样子，我们可以通过写时修复和异步修复实现最终一致性。另外，还实现自定义写一致性级别，支持All、Quorum、One、Any 4种写一致性级别，用户在写数据的时候，可以根据业务数据的特点，设置不同的写一致性级别。
+
+## 内容小结
+
+本节课我主要带你了解了BASE理论，以及BASE理论的应用，我希望你明确几个重点：
+
+<li>
+BASE理论是对CAP中一致性和可用性权衡的结果，它来源于对大规模互联网分布式系统实践的总结，是基于CAP定理逐步演化而来的。它的核心思想是，如果不是必须的话，不推荐实现事务或强一致性，鼓励可用性和性能优先，根据业务的场景特点，来实现非常弹性的基本可用，以及实现数据的最终一致性。
+</li>
+<li>
+BASE理论主张通过牺牲部分功能的可用性，实现整体的基本可用，也就是说，通过服务降级的方式，努力保障极端情况下的系统可用性。
+</li>
+<li>
+ACID理论是传统数据库常用的设计理念，追求强一致性模型。BASE理论支持的是大型分布式系统，通过牺牲强一致性获得高可用性。BASE理论在很大程度上，解决了事务型系统在性能、容错、可用性等方面痛点。另外我再多说一句，BASE理论在NoSQL中应用广泛，是NoSQL系统设计的事实上的理论支撑。
+</li>
+
+最后我强调一下，对于任何集群而言，不可预知的故障的最终后果，都是系统过载。如何设计过载保护，实现系统在过载时的基本可用，是开发和运营互联网后台的分布式系统的重中之重。那么我建议你，在开发实现分布式系统，要充分考虑如何实现基本可用。
+
+## 课堂思考
+
+我在文章中提了一些实现基本可用的方法，比如流量削峰、延迟响应、体验降级、过载保护等，那么你不妨思考一下，还有哪些方法可以用来实现基本可用呢？欢迎在留言区分享你的看法，与我一同讨论。
+
+最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

极客时间专栏/geek/分布式协议与算法实战/理论篇/加餐 | 拜占庭将军问题：如何基于签名消息实现作战计划的一致性？.md

@@ -0,0 +1,123 @@
+<audio id="audio" title="加餐  | 拜占庭将军问题：如何基于签名消息实现作战计划的一致性？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/33/00/33d67684c3c705efb685afbb1f600c00.mp3"></audio>
+
+你好，我是韩健。
+
+在[01讲](https://time.geekbang.org/column/article/195662)中，为了不啰嗦，让你举一反三地学习，我对签名消息型拜占庭问题之解，没有详细展开，而是聚焦在最核心的点“签名约束了叛徒的作恶行为”，但从留言来看，很多同学在理解签名和如何实现作战一致性上，还是遇到了问题。比如不理解如何实现作战计划的一致性。
+
+另外，考虑到签名消息是一些常用的拜占庭容错算法（比如PBFT）的实现基础，很重要，所以这节课我会对签名消息型拜占庭问题之解进行补充。在今天的内容中，除了具体讲解如何基于签名消息实现作战计划的一致性之外，我还会说一说什么是签名消息。希望在帮你掌握签名消息型拜占庭问题之解的同时，还帮你吃透相关的基础知识。
+
+当然，在学完01讲之后，相信你已经明白了，签名消息拜占庭问题之解，之所以能够容忍任意数量的叛徒，关键就在于通过消息的签名，约束了叛徒的作恶行为，也就是说，任何篡改和伪造忠将的消息的行为，都会被发现。
+
+既然签名消息这么重要，那么什么是签名消息呢？
+
+## 什么是签名消息？
+
+签名消息指的就是带有数字签名的消息，你可以这么理解“数字签名”：类似在纸质合同上进行签名来确认合同内容和证明身份。
+
+在这里我想说的是，数字签名既可以证实内容的完整性，又可以确认内容的来源，实现不可抵赖性（Non-Repudiation）。既然签名消息优点那么多，**那么如何实现签名消息呢？**
+
+你应该还记得密码学的学术CP（Bob和Alice）吧（不记得的话也没关系，你把他们当作2个人就可以了），今天Bob要给Alice发送一个消息，告诉她，“我已经到北京了”，但是Bob希望这个消息能被Alice完整地接收到，内容不能被篡改或者伪造，我们一起帮Bob和Alice想想办法，看看如何实现这个消息。
+
+首先，为了避免密钥泄露，我们推荐Bob和Alice使用非对称加密算法（比如RSA）。也就是说，加密和解密使用不同的秘钥，在这里，Bob持有需要安全保管的私钥，Alice持有公开的公钥。
+
+然后，Bob用哈希算法（比如MD5）对消息进行摘要，然后用私钥对摘要进行加密，生成数字签名（Signature），就像下图的样子：
+
+<img src="https://static001.geekbang.org/resource/image/8d/75/8d69065c69944b74d77592a2aa5ea075.jpg" alt="" title="图1">
+
+接着，Bob将加密摘要和消息一起发送给Alice：
+
+<img src="https://static001.geekbang.org/resource/image/92/e0/924cd677d20a1fa7dca41936fc1e5ee0.jpg" alt="" title="图2">
+
+接下来，当Alice接收到消息和加密摘要（Signature）后，她会用自己的公钥对加密摘要（Signature）进行解密，并对消息内容进行摘要（Degist-2），然后将新获取的摘要（Degist-2）和解密后的摘要（Degist-1）进行对比，如果2个摘要（Digest-1和Digest-2）一致，就说明消息是来自Bob的，并且是完整的，就像下图的样子：
+
+<img src="https://static001.geekbang.org/resource/image/fe/9d/fe974b9037e9ef4e85c227b5a867d39d.jpg" alt="" title="图3">
+
+你看，通过这种方法，Bob的消息就能被Alice完整接收到了，任何篡改和伪造Bob消息的行为，都会因为摘要不一致，而被发现。**而这个消息就是签名消息。**
+
+现在，你应该理解了什么是签名消息了吧？另外，关于在留言区提到的“为什么签名消息能约束叛将们的作恶行为？”，在这里，我再补充下，通过上面的Bob和Alice的故事，我们可以看到，在数字签名的约束下，叛将们是无法篡改和伪造忠将的消息的，因为任何篡改和伪造消息的行为都会被发现，也就是作恶的行为被约束了。也就是说，叛将这时能做“小”恶（比如，不响应消息，或者叛将们相互串通发送指定的消息）但他们无法篡改或伪造忠将的消息了。
+
+既然数字签名约束了叛将们的作恶行为，那么苏秦怎么做才能实现作战的一致性的呢？也就是忠将们执行一致的作战计划。
+
+## 如何实现作战计划的一致性？
+
+之前我已经提到了，苏秦可以通过签名消息的方式，不仅能在不增加将军人数的情况下，解决二忠一叛的难题，还能实现无论叛将数多少，忠诚的将军们始终能达成一致的作战计划。
+
+为了方便你理解，我以二忠二叛（更复杂的叛徒作恶模型，因为叛徒们可以相互勾结串通）为例具体演示一下，是怎样实现作战计划的一致性的：
+
+<img src="https://static001.geekbang.org/resource/image/25/f9/25bdee6e350e7d4f70401c649f40bef9.jpg" alt="" title="图4">
+
+需要你注意的是，4位将军约定了一些流程来发送作战信息、执行作战指令。
+
+**第一轮：**
+
+- 先发送作战指令的将军，作为指挥官，其他的将军作为副官。
+- 指挥官将他的签名的作战指令发送给每位副官。
+- 每位副官，将从指挥官处收到的新的作战指令（也就与之前收的作战指令不同），按照顺序（比如按照首字母字典排序）放到一个盒子里。
+
+**第二轮：**
+
+- 除了第一轮的指挥官外，剩余的3位将军将分别作为指挥官，在上一轮收到的作战指令上，加上自己的签名，并转发给其他将军。
+
+**第三轮：**
+
+- 除了第一、二轮的指挥官外，剩余的2位将军将分别作为指挥官，在上一轮收到的作战指令上，加上自己的签名，并转发给其他将军。
+
+最后，各位将军按照约定，比如使用盒子里最中间的那个指令来执行作战指令。（假设盒子中的指令为A、B、C，那中间的指令也就是第n /2个命令。其中，n为盒子里的指令数，指令从0开始编号，也就是B）。
+
+为了帮你直观地理解，如何基于签名消息实现忠将们作战计划的一致性，我来演示一下作战信息协商过程。**而且我会分别以忠将和叛将先发送作战信息为例来演示，**这样可以完整地演示叛将对作战计划干扰破坏的可能性。
+
+那么忠诚的将军先发送作战信息的情况是什么呢？
+
+为了演示方便，假设苏秦先发起带有签名的作战信息，作战指令是“进攻”。那么在第一轮作战信息协商中，苏秦向齐、楚、燕发送作战指令“进攻”。
+
+<img src="https://static001.geekbang.org/resource/image/66/be/66add595b082b18e3a6feaeb4b5e6ebe.jpg" alt="" title="图5">
+
+在第二轮作战信息协商中，齐、楚、燕分别作为指挥官，向另外2位发送作战信息“进攻”。可是楚、燕已经叛变了，**但在签名的约束下，他们无法篡改和伪造忠将的消息，**为了达到干扰作战计划的目的，他们俩一个选择发送消息，一个默不作声，不配合。
+
+<img src="https://static001.geekbang.org/resource/image/6b/d0/6b5878c8dce6279dabc8db92d666cfd0.jpg" alt="" title="图6">
+
+在第三轮作战信息协商中，齐、楚分别作为指挥官，将接收到的作战信息，附加上自己的签名，并转发给另外一位（这时的叛徒燕，还是默不作声，不配合）。
+
+<img src="https://static001.geekbang.org/resource/image/35/23/355f1a1453547731c9a1d05090eaa123.jpg" alt="" title="图7">
+
+最终，齐收到的作战信息都是“进攻”（它收到了苏秦和楚的），按照“执行盒子最中间的指令”的约定，齐会和苏秦一起执行作战指令“进攻”，实现忠将们作战计划的一致性。
+
+那么如果是叛徒楚先发送作战信息，干扰作战计划，结果会有所不同吗？我们来具体看一看。在第一轮作战信息协商中，楚向苏秦发送作战指令“进攻”，向齐、燕发送作战指令“撤退”。（当然还有其他的情况，这里只是选择了其中一种，其他的情况，你可以都推导着试试，看看结果是不是一样？）
+
+<img src="https://static001.geekbang.org/resource/image/d6/0b/d6e1997399d8e37177a4a1e98e31cb0b.jpg" alt="" title="图8">
+
+然后，在第二轮作战信息协商中，苏秦、齐、燕分别作为指挥官，将接收到的作战信息，附加上自己的签名，并转发给另外两位。
+
+<img src="https://static001.geekbang.org/resource/image/7e/2c/7e9066308ae3338a53c2e5561d43b22c.jpeg" alt="" title="图9">
+
+**为了达到干扰作战计划的目的，叛徒楚和燕相互勾结了。**比如，燕拿到了楚的私钥，也就是燕可以伪造楚的签名，这个时候，燕为了干扰作战计划，给苏秦发送作战指令“进攻”，给齐发送作战指令却是“撤退”。
+
+接着，在第三轮作战信息协商中，苏秦、齐、燕分别作为指挥官，将接收到的作战信息，附加上自己的签名，并转发给另外一位。
+
+<img src="https://static001.geekbang.org/resource/image/bd/e3/bd82590e3db9184067d455cf0d3a74e3.jpg" alt="" title="图10">
+
+最终，苏秦和齐收到的作战信息都是“撤退、进攻”，按照“执行盒子最中间的指令”的约定，苏秦、齐和燕一起执行作战指令“撤退”，实现了作战计划的一致性。也就是说，无论叛将楚和燕如何捣乱，苏秦和齐都能执行一致的作战计划，保证作战的胜利。
+
+另外在这里，我想补充一点，签名消息的拜占庭问题之解，也是需要进行m+1轮（其中m为叛将数，所以你看，只有楚、燕是叛变的，那么就进行了三轮协商）。你也可以从另外一个角度理解：n位将军，能容忍(n - 2) 位叛将（只有一位忠将没有意义，因为此时不需要达成共识了）。**关于这个公式，你只需要记住就好了，推导过程你可以参考论文。**
+
+最后，我想说的是，签名消息型拜占庭问题之解，解决的是忠将们如何就作战计划达成共识的问题，也就只要忠将们执行了一致的作战计划就可以了。但它不关心这个共识是什么，比如，在适合进攻的时候，忠将们可能执行的作战计划是撤退。也就是，这个算法比较理论化。
+
+关于理论化这一点，有的同学会想知道它如何去用，在我看来呢，这个算法解决的是共识的问题，没有与实际场景结合，是很难在实际场景中落地的。在实际场景中，你可以考虑后来的改进过后的拜占庭容错算法，比如PBFT算法。
+
+## 内容小结
+
+本节课我主要带你了解了什么签名消息，以及忠将们如何通过签名消息实现作战的一致性，我希望你明确这样几个重点：
+
+1.数字签名是基于非对称加密算法（比如RSA、DSA、DH）实现的，它能防止消息的内容被篡改和消息被伪造。
+
+2.签名消息约束了叛徒的作恶行为，比如，叛徒可以不响应，可以相互勾结串通，但叛徒无法篡改和伪造忠将的消息。
+
+3.需要你注意的是，签名消息拜占庭问题之解，虽然实现了忠将们作战计划的一致性，但它不关心达成共识的结果是什么。
+
+最后，我想说的是，签名消息、拜占庭将军问题的签名消息之解是非常经典的基础知识，影响和启发了后来的众多拜占庭容错算法（比如PBFT），理解了本讲的内容后，你能更好地理解其他的拜占庭容错算法，以及它们如何改进的？为什么要这么改进？比如，在PBFT中，基于性能的考虑，大部分场景的消息采用消息认证码（MAC），只有在视图变更（View Change）等少数场景中采用了数字签名。
+
+## 课堂思考
+
+我演示了在“二忠二叛”情况下，忠将们如何实现作战计划的一致性，那么你不妨推演下，在“二忠一叛”情况下，忠将们如何实现作战计划的一致性呢？欢迎在留言区分享你的看法，与我一同讨论。
+
+最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。