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