春职觉汉画2-1，4-1页的安排，节省纸张和时间应开它

并发指在同一时间内可以执行多个任务。并发编程含义比较广泛，包含多线程编程、多进程编程及分布式程序等。本章讲解的并发含义属于多线程编程。goroutine是由Go语言的运行时调度完成，而线程是由操作系统调度完成。使用者分配足够多的任务，系统能自动帮助使用者把任务分配到CPU上，让这些任务尽量并发运作。这种机制在Go语言中被称为goroutine。Go程序从main包的main()函数开始，在程序启动时，Go程序就会为main()函数创建一个默认的goroutine。调整并发的运行性能（DOMAXPROCS）传统逻辑中，开发者需要维护线程池中线程与CPU核心数量的对应关系。同样的，Go地中也可以通过runtime.GOMAXPROCS()函数做到，格式为：在常见的分布式系统中，总会发生诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）(也就是会发生异常的分布式系统)等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致。也可以理解成分布式系统中达成状态的一致性。Base理论的核心思想是最终一致性，即使无法做到强一致性（StrongConsistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual Consistency）。Quorum 机制在了解Paxos之前我们先了解一下「Quorum选举算法」 大家看到选举算法，是不是就联想到了zookeeper中的Leader选举？你的直觉是没有问题的。在各种一致性算法中都可以看到Quorum机制的身影，主要数学思想来源于抽屉原理，用一句话解释那就是，在N个副本中，一次更新成功的如果有W个，那么我在读取数据时是要从大于N－W个副本中读取，这样就能至少读到一个更新的数据了。和Quorum机制对应的是WARO，也就是WriteAllReadone，是一种简单的副本控制协议，当 Client 请求向某副本写数据时（更新数据），只有当所有的副本都更新成功之后，这次写操作才算成功，否则视为失败。WARO优先保证读服务，因为所有的副本更新成功，才能视为更新成功，从而保证了所有的副本一致，这样的话，只需要读任何一个副本上的数据即可。写服务的可用性较低，因为只要有一个副本更新失败，此次写操作就视为失败了。假设有 N 个副本，N－1 个都宕机了，剩下的那个副本仍能提供读服务；但是只要有一个副本宕机了，写服务就不会成功。WARO 牺牲了更新服务的可用性，最大程度地增强了读服务的可用性，而 Quorum 就是在更新服务和读服务之间进行的一个折衷。Quorum 定义Quorum的定义如下：假设有N个副本，更新操作wi在W个副本中更新成功之后，才认为此次更新操作wi成功，把这次成功提交的更新操作对应的数据叫做：“成功提交的数据”。对于读操作而言，至少需要读 R 个副本才能读到此次更新的数据，其中，W+R>N ，即 W 和 R 有重叠，一般，W+R=N+1。N = 存储数据副本的数量W = 更新成功所需的副本R = 一次数据对象读取要访问的副本的数量Quorum就是限定了一次需要读取至少N+1-w的副本数据,听起来有些抽象。举个例子，我们维护了10个副本，一次成功更新了三个，那么至少需要读取八个副本的数据，可以保证我们读到了最新的数据。Quorum 的应用Quorum机制无法保证强一致性，也就是无法实现任何时刻任何用户或节点都可以读到最近一次成功提交的副本数据。Quorum 机制的使用需要配合一个获取最新成功提交的版本号的 metadata 服务，这样可以确定最新已经成功提交的版本号，然后从已经读到的数据中就可以确认最新写入的数据。Quorum 是分布式系统中常用的一种机制，用来保证数据冗余和最终一致性的投票算法，在 Paxos、Raft 和 ZooKeeper 的 Zab 等算法中，都可以看到 Quorum 机制的应用。Paxos算法的相关概念在 Paxos 协议中，有三类节点角色，分别是 Proposer、Acceptor 和 Learner，另外还有一个 Client，作为产生议题者。 技术图片上述三类角色只是逻辑上的划分，在工作实践中，一个节点可以同时充当这三类角色。Proposer 提案者Proposer可以有多个，在流程开始时，Proposer提出议案，也就是value，所谓value，在工程中可以是任何操作，比如 “修改某个变量的值为某个新值”，Paxos协议中统一将这些操作抽象为value。不同的Proposer可以提出不同的甚至矛盾的value，比如某个Proposer提议“将变量X设置为1”，另一个 Proposer 提议 “将变量 X 设置为 2”，但对同一轮 Paxos 过程，最多只有一个 value 被批准。Acceptor 批准者在集群中，Acceptor 有 N 个，Acceptor 之间完全对等独立，Proposer 提出的 value 必须获得超过半数（N/2+1）的 Acceptor 批准后才能通过。Learner 学习者Learner 不参与选举，而是学习被批准的 value，在Paxos中，Learner主要参与相关的状态机同步流程。这里Leaner的流程就参考了Quorum议会机制，某个value需要获得W=N/2+1的Acceptor批准，Learner需要至少读取N/2+1个Accpetor，最多读取 N 个 Acceptor 的结果后，才能学习到一个通过的 value。举个例子：我有10个Accpetor，至少读取6个相同的value，最多读取10个相同的value。也就是选取票数最多的结果。Client 产生议题者Client 角色，作为产生议题者，实际不参与选举过程，比如发起修改请求的来源等。 Proposer 与 Acceptor 之间的交互Proposer与Acceptor之间的交互Paxos 中，proposer提交给Acceptor，由Acceptor达成一致选取最终的value，然后告诉Learner最终的value。Proposer 与 Acceptor 之间的交互主要有 4 类消息通信，如下图：