CAP准则又称CAP定理，指的是在一个分布式体系中，Consistency（共同性）、 Availability（可用性）、Partition tolerance（分区容错性）这3个根本需求，最多只能一同满意其间的2个。
CAP准则选项描绘Consistency（共同性）指数据在多个副本之间能够坚持共同的特性（严厉的共同性）Availability（可用性）指体系供给的服务有必要一向处于可用的状况，每次恳求都能获取到非错的呼应（不确保获取的数据为最新数据）Partition tolerance（分区容错性）分布式体系在遇到任何网络分区毛病的时分，仍然能够对外供给满意共同性和可用性的服务，除非整个网络环境都发生了毛病
首要关于分布式体系，分区是必定存在的，所谓分区指的是分布式体系或许呈现的字区域网络不通，成为孤立区域的的状况。
那么分区容错性（P）就有必要要满意，因为假定要献身分区容错性，就得把服务和资源放到一个机器，或许一个“同生共死”的集群，那就违反了分布式的初衷。
假定现在有两个分区N1和N2，N1和N2分别有不同的分区存储D1和D2，以及不同的服务S1和S2。
理论上抛弃P（分区容错性），则C（强共同性）和A（可用性）是能够确保的。实际上分区是不行避免的，严厉上CA指的是答应分区后各子体系仍然坚持CA。
抛弃A（可用），相当于每个恳求都需求在Server之间强共同，而P（分区）会导致同步时间无限延伸，如此CP也是能够确保的。许多传统的数据库分布式业务都归于这种形式。
要高可用并答应分区，则需抛弃共同性。一旦分区发生，节点之间或许会失掉联络，为了高可用，每个节点只能用本地数据供给服务，而这样会导致大局数据的不共同性。现在许多的NoSQL都归于此类。
举个咱们更了解的比方，像咱们了解的注册中心ZooKeeper、Eureka、Nacos中：
什么是根本可用呢？假定体系呈现了不行预知的毛病，但仍是能用，仅仅比较较正常的体系而言，或许会有呼应时间上的丢失，或许功能上的降级。
软状况也称为弱状况，比较较硬状况而言，答应体系中的数据存在中间状况，并以为该状况不影响体系的全体可用性，即答应体系在多个不同节点的数据副本存在数据延时。
上面说了软状况，可是不应该一向都是软状况。在必守时间后，应该抵达一个终究的状况，确保一切副本坚持数据共同性，然后到达数据的终究共同性。这个时间取决于网络延时、体系负载、数据仿制计划规划等等要素。
单体年代，能够直接用本地锁来完结对竞赛资源的加锁，分布式环境下就要用到分布式锁了。
常见的分布式锁完结计划有三种：MySQL分布式锁、ZooKepper分布式锁、Redis分布式锁。
用数据库完结分布式锁比较简略，便是创立一张锁表，数据库对字段作仅有性束缚。
这种归于数据库 IO 操作，功率不高，而且频频操作会增大数据库的开支，因而这种方法在高并发、高功能的场景顶用的不多。
ZooKeeper的数据节点和文件目录相似，例如有一个lock节点，在此节点下树立子节点是能够确保先后顺序的，即便是两个进程一同恳求新建节点，也会依照先后顺序树立两个节点。
所以咱们能够用此特性完结分布式锁。以某个资源为目录，然后这个目录下面的节点便是咱们需求获取锁的客户端，每个服务在目录下创立节点，假定它的节点，序号在目录下最小，那么就获取到锁，不然等候。开释锁，便是删去服务创立的节点。
ZK实际上是一个比较重的分布式组件，实际上运用没那么多了，所以用ZK完结分布式锁，其实相对也比较少。
完结分布式锁最简略的一个指令：setNx(set if not exist)，假定不存在则更新：
加锁了之后假定机器宕机，那我这个锁就无法开释，所以需求参加过期时间，而且过期时间需求和setNx同一个原子操作，在Redis2.8之前需求用lua脚本，可是redis2.8之后redis支撑nx和ex操作是同一原子操作。
当然，一般出产中都是运用Redission客户端，十分杰出地封装了分布式锁的api，而且支撑RedLock。
分布式业务是相对本地业务而言的，关于本地业务，运用数据库自身的业务机制，就能够确保业务的ACID特性。
分布式业务其实便是将对同一库业务的概念扩展到了对多个库的业务。意图是为了确保分布式体系中的数据共同性。
分布式常见的完结计划有2PC、3PC、TCC、本地音讯表、MQ音讯业务、最大尽力告诉、SAGA业务等等。
XA协议选用两阶段提交方法来办理分布式业务。XA接口供给资源办理器与业务办理器之间进行通讯的标准接口。
两阶段提交的思路能够归纳为：参加者将操作胜败告诉和谐者，再由和谐者依据一切参加者的反应状况抉择各参加者是否要提交操作仍是回滚操作。
长处：尽量确保了数据的强共同，完结本钱较低，在各大干流数据库都有自己完结，关于MySQL是从5.5开端支撑。
单点问题：业务办理器在整个流程中扮演的人物很要害，假定其宕机，比方在第一阶段现已完结，在第二阶段正预备提交的时分业务办理器宕机，资源办理器就会一向堵塞，导致数据库无法运用。
同步堵塞：在预备就绪之后，资源办理器中的资源一向处于堵塞，直到提交完结，开释资源。
数据不共同：两阶段提交协议尽管为分布式数据强共同性所规划，但仍然存在数据不共同性的或许，比方在第二阶段中，假定和谐者宣布了业务commit的告诉，可是因为网络问题该告诉仅被一部分参加者所收到并履行了commit操作，其他的参加者则因为没有收到告诉一向处于堵塞状况，这时分就发生了数据的不共同性。
三阶段提交（3PC）是二阶段提交（2PC）的一种改善版别 ，为处理两阶段提交协议的单点毛病和同步堵塞问题。
：预备阶段。和谐者向参加者发送commit恳求，参加者假定能够提交就回来Yes呼应，不然回来No呼应。
的呼应判别是否履行业务仍是中止业务，参加者履行完操作之后回来ACK呼应，一同开端等候终究指令。
假定参加者无法及时接纳到来自和谐者的提交或许中止业务恳求时，在等候超时之后，会继续进行业务提交
能够看出，三阶段提交处理的仅仅两阶段提交中单体毛病和同步堵塞的问题，因为参加了超时机制，这儿的超时的机制作用于预提交阶段和提交阶段。假定等候预提交恳求超时，参加者直接回到预备阶段之前。假定比及提交恳求超时，那参加者就会提交业务了。
TCC（Try Confirm Cancel），是两阶段提交的一个变种，针对每个操作，都需求有一个其对应的承认和吊销操作，当操作成功时调用承认操作，当操作失利时调用吊销操作，相似于二阶段提交，只不过是这儿的提交和回滚是针对业务上的，所以依据TCC完结的分布式业务也能够看做是对业务的一种补偿机制。
Try：测验待履行的业务。订单体系将当时订单状况设置为付出中，库存体系校验当时剩下库存数量是否大于1，然后将可用库存数量设置为库存剩下数量-1，。
Confirm：承认履行业务，假定Try阶段履行成功，接着履行Confirm 阶段，将订单状况修改为付出成功，库存剩下数量修改为可用库存数量。
Cancel：吊销待履行的业务，假定Try阶段履行失利，履行Cancel 阶段，将订单状况修改为付出失利，可用库存数量修改为库存剩下数量。
例如，能够在订单库新增一个音讯表，将新增订单和新增音讯放到一个业务里完结，然后经过轮询的方法去查询音讯表，将音讯推送到MQ，库存服务去消费MQ。
订单服务中的音讯有或许因为业务问题会一向重复发送，所以为了避免这种状况能够记载一下发送次数，当到达次数约束之后报警，人工接入处理；库存服务需求确保幂等，避免同一条音讯被屡次消费构成数据不共同。
本地音讯表这种计划完结了终究共同性，需求在业务体系里添加音讯表，业务逻辑中多一次刺进的DB操作，所以功能会有损耗，而且终究共同性的距离主要有守时使命的距离时间抉择
订单服务履行自己的本地业务，并发送MQ音讯，库存服务接纳音讯，履行自己的本地业务，乍一看，好像跟本地音讯表的完结计划相似，仅仅省去 了对本地音讯表的操作和轮询发送MQ的操作，但实际上两种计划的完结是不相同的。
音讯业务必定要确保业务操作与音讯发送的共同性，假定业务操作成功，这条音讯也必定投递成功。
音讯业务依赖于音讯中间件的业务音讯，例如咱们了解的RocketMQ就支撑业务音讯（半音讯），也便是只需收到发送方确认才会正常投递的音讯。
这种计划也是完结了终究共同性，比照本地音讯表完结计划，不需求再建音讯表，对功能的损耗和业务的侵略更小。
最大尽力告诉比较完结会简略一些，适用于一些对终究共同性实时性要求没那么高的业务，比方付出告诉，短信告诉。
以付出告诉为例，业务体系调用付出渠道进行付出，付出渠道进行付出，进行操作付出之后付出渠道会去同步告诉业务体系付出操作是否成功，假定不成功，会一向异步重试，可是会有一个最大告诉次数，假定超越这个次数后仍是告诉失利，就不再告诉，业务体系自行调用付出渠道供给一个查询接口，供业务体系进行查询付出操作是否成功。
咱们用比较常用的是Seata——自己去完结分布式业务调度仍是比较费事的。
Seata的规划方针是对业务无侵入，因而它是从业务无侵入的两阶段提交（大局业务）着手，在传统的两阶段上进行改善，他把一个分布式业务了解成一个包括了若干分支业务的大局业务。而大局业务的责任是和谐它办理的分支业务达到共同性，要么一同成功提交，要么一同失利回滚。也便是一荣俱荣一损俱损~
Paxos 有点相似前面说的 2PC，3PC，但比这两种算法愈加完善。在许多多大厂都得到了工程实践，比方阿里的 OceanBase 的分布式数据库， Google 的 chubby分布式锁。
Paxos 算法是依据音讯传递且具有高效容错特性的共同性算法，现在公认的处理分布式共同性问题最有用的算法之一。
提议者提出提案，提案=编号+value，能够表明为[M,V]，每个提案都有仅有编号，而且编号的巨细是趋势递加的。
提议者提议一个新的提案 P[Mn,?]，然后向承受者的某个超越对折的子集成员发送编号为Mn的预备恳求
假定一个承受者收到一个编号为Mn的预备恳求，而且编号Mn大于它现已呼应的一切预备恳求的编号，那么它就会将它现已同意过的最大编号的提案作为呼应反应给提议者，一同该承受者会许诺不会再同意任何编号小于Mn的提案。
不违反曾经作出的许诺的前提下，回复现现已过的提案中提案号最大的那个提案所设定的值和提案号Mmax，假定这个值从来没有被任何提案设定过，则回来空值。假定不满意现已做出的许诺，即收到的提案号并不是抉择计划节点收到过的最大的，那答应直接对此 Prepare 恳求不予理睬。
假定提议者收到来自对折以上的承受者关于它宣布的编号为Mn的预备恳求的呼应，那么它就会发送一个针对[Mn,Vn]的承受恳求给承受者，留意Vn的值便是收到的呼应中编号最大的提案的值，假定呼应中不包括任何提案，那么它能够随意选定一个值。
假定承受者收到这个针对[Mn,Vn]提案的承受恳求，只需该承受者没有对编号大于Mn的预备恳求做出呼应，它就能够经过这个提案。
当提议者收到了大都承受者的承受应对后，洽谈完毕，共同抉择构成，将构成的抉择发送给一切学习节点进行学习。
前面描绘的能够称之为Basic Paxos 算法，在单提议者的前提下是没有问题的，可是假定有多个提议者针锋相对，那么就或许导致整个提议的进程进入了死循环。
Multi Paxos算法思维，简略说便是在多个提议者的状况下，选出一个Leader（领导者），由领导者作为仅有的提议者，这样就能够处理提议者抵触的问题。
Raft 也是一个共同性算法，和 Paxos 方针相同。但它还有另一个姓名 -易于了解的共同性算法。Paxos 和 Raft 都是为了完结共同性发生的。这个进程好像推举相同，参选者需求压服大大都选民(Server) 投票给他，一旦选定后就跟从其操作。Paxos 和 Raft 的差异在于推举的详细进程不同。
就像一个民主社会，领导者由跟从者投票选出。刚开端没有领导者，一切集群中的参加者都是跟从者。
那么首要敞开一轮大选。在大选期间一切跟从者都能参加竞选，这时一切跟从者的人物就变成了提名人，民主投票选出首领后就开端了这届首领的任期，然后推举完毕，一切除领导者的提名人又变回跟从者遵守领导者领导。
Follower将其当时term加一然后转换为Candidate。它首要给自己投票而且给集群中的其他服务器发送 RequestVote RPC 。成果有以下三种状况：
选出 Leader 后，Leader 经过定时向一切 Follower 发送心跳信息保持其控制。若 Follower 一段时间未收到 Leader 的心跳，则以为 Leader 或许现已挂了，然后再次建议推举进程。
幂等性是一个数学概念，用在接口上：用在接口上就能够了解为：同一个接口，屡次宣布同一个恳求，恳求的成果是共同的。
用户在填写某些form表单时，保存按钮不小心快速点了两次，表中居然发生了两条重复的数据，仅仅id不相同。
开发人员在项目中为了处理接口超时问题，通常会引入了重试机制。第一次恳求接口超时了，恳求方没能及时获取回来成果（此刻有或许现已成功了），所以会对该恳求重试几回，这样也会发生重复的数据。
在分布式体系里，只需下流服务有写（保存、更新）的操作，都有或许会发生幂等性问题。
PS:幂等和防重有些不同，防重着重的避免数据重复，幂等着重的是屡次调用如一次，防重包括幂等。
在保存数据的接口中，在insert前，先依据requestId等字段先select一下数据。假定该数据已存在，则直接回来，假定不存在，才履行 insert操作。
加仅有索引是个十分简略但很有用的方法，假定重复刺进数据的话，就会抛出反常，为了确保幂等性，一般需求捕获这个反常。
更新逻辑，比方更新用户账户余额，能够加失望锁，把对运用户的哪一行数据锁住。同一时间只答应一个恳求取得锁，其他恳求则等候。
这种方法有一个缺陷，获取不到锁的恳求一般只能报失利，比较难确保接口回来相同值。
更新逻辑，也能够用达观锁，功能更好。能够在表中添加一个timestamp或许version字段，例如version:
在更新前，先查询一下数据，将version也作为更新的条件，一同也更新version：
有时分表中并非一切的场景都不答应发生重复的数据，只需某些特定场景才不答应。这时分，就能够运用防重表的方法。
例如音讯消费中，创立防重表，存储音讯的仅有ID，消费时先去查询是否现已消费，现已消费直接回来成功。
有些业务表是有状况的，比方订单表中有：1-下单、2-已付出、3-完结、4-吊销等状况，能够经过约束状况的活动来完结幂等。
直接在数据库上加锁的做法功能不行友爱，能够运用分布式锁的方法，现在最盛行的分布式锁完结是经过Redis，详细完结一般都是运用Redission结构。
恳求接口之前，需求先获取一个仅有的token，再带着这个token去完结业务操作，服务端依据这个token是否存在，来判别是否是重复的恳求。
计数器比较简略粗犷，比方咱们要约束1s能够经过的恳求数，完结的思路便是从第一个恳求进来开端计时，在接下来的1s内，每个恳求进来恳求数就+1，超越最大恳求数的恳求会被回绝，比及1s完毕后计数清零，重新开端计数。
这种方法有个很大的坏处：比方前10ms现现已过了最大的恳求数，那么后边的990ms的恳求只能回绝，这种现象叫做“突刺现象”。
便是桶底出水的速度稳定，进水的速度或许快慢纷歧，可是当进水量大于出水量的时分，水会被装在桶里，不会直接被丢掉；可是桶也是有容量约束的，当桶装满水后溢出的部分仍是会被丢掉的。
算法完结：能够预备一个行列来保存暂时处理不了的恳求，然后经过一个线程池定时从行列中获取恳求来履行。
令牌桶便是出产拜访令牌的一个当地，出产的速度稳定，用户拜访的时分当桶中有令牌时就能够拜访，不然将触发限流。
Guava RateLimiter是一个谷歌供给的限流，其依据令牌桶算法，比较适用于单实例的体系。
这一期的分布式面试题就整理到这儿了，主要是偏理论的一些问题，分布式其实是个很大的类型，比方分布式调用、分布式管理……
所以，这篇文章仅仅个开端，后边还会有分布式调用（RPC）、微服务相关的主题文章，敬请期待。
[1] . 《从Paxos到Zookeeper 分布式共同性原理与实践》[2]. 分布式理论(一) - CAP定理：[3]. 分布式理论(二) - BASE理论 ：[4]. 分布式理论(三) - 2PC协议：[5] . CAP和BASE理论了解么？能够结合实际事例说下不：[6] 从分布式业务处理到Seata运用，一梭子给你整理解了：[7]. 高并发下怎么确保接口的幂等性?：[8]. 分布式理论(三) - 2PC协议 ：[9]. 再有人问你分布式锁，这篇文章扔给他：[10]. 分布式理论(五) - 共同性算法Paxos ：[11]. 《分布式体系技能及其事例剖析》[12].不便是分布式业务，这下完全清楚了：[13].诸葛亮 VS 庞统，拿下 Paxos 共同算法：诸葛VS庞统，拿下Paxos?id=诸葛亮-vs-庞统，拿下-paxos-共同算法[14].