咱们好，我是老三，不论今年金三银四怎样，面渣逆袭系列继续，这期咱们来看看分布式。
分布式理论
1. 说说CAP准则？
CAP准则又称CAP定理，指的是在一个分布式体系中，Consistency（共同性）、 Availability（可用性）、Partition tolerance（分区容错性）这3个根本需求，最多只能一起满意其间的2个。
| 选项 | 描述 |
|---|---|
| Consistency（共同性） | 指数据在多个副本之间能够坚持共同的特性（严厉的共同性） |
| Availability（可用性） | 指体系供给的服务必须一向处于可用的状况，每次恳求都能获取到非错的呼应（不确保获取的数据为最新数据） |
| Partition tolerance（分区容错性） | 分布式体系在遇到任何网络分区毛病的时分，仍然能够对外供给满意共同性和可用性的服务，除非整个网络环境都发生了毛病 |
2. 为什么CAP不行兼得呢？
首要关于分布式体系，分区是必定存在的，所谓分区指的是分布式体系或许出现的字区域网络不通，成为孤立区域的的状况。
那么分区容错性（P）就必须要满意，由于假如要牺牲分区容错性，就得把服务和资源放到一个机器，或许一个“同生共死”的集群，那就违背了分布式的初衷。
那么满意分区容错的根底上，能不能一起满意共同性和可用性？
假如现在有两个分区N1和N2，N1和N2分别有不同的分区存储D1和D2，以及不同的服务S1和S2。
- 在满意
共同性的时分，N1和N2的数据要求值相同的，D1=D2。 - 在满意
可用性的时分，不管拜访N1仍是N2，都能获取及时的呼应。
假如现在有这样的场景：
- 用户拜访了N1，修正了D1的数据。
- 用户再次拜访，恳求落在了N2。此刻D1和D2的数据不共同。
接下来：
- 确保
共同性：此刻D1和D2数据不共同，要确保共同性就不能回来不共同的数据，可用性无法确保。 - 确保
可用性：立即呼应，可用性得到了确保，可是此刻呼应的数据和D1不共同，共同性无法确保。
所以，能够看出，分区容错的前提下，共同性和可用性是对立的。
3. CAP对应的模型和运用？
CA without P
理论上抛弃P（分区容错性），则C（强共同性）和A（可用性）是能够确保的。实际上分区是不行避免的，严厉上CA指的是答应分区后各子体系依然坚持CA。
CA模型的常见运用：
- 集群数据库
- xFS文件体系
CP without A
抛弃A（可用），相当于每个恳求都需求在Server之间强共同，而P（分区）会导致同步时间无限延长，如此CP也是能够确保的。许多传统的数据库分布式业务都归于这种形式。
CP模型的常见运用：
- 分布式数据库
- 分布式锁
AP wihtout C
要高可用并答应分区，则需抛弃共同性。一旦分区发生，节点之间或许会失去联络，为了高可用，每个节点只能用本地数据供给服务，而这样会导致大局数据的不共同性。现在许多的NoSQL都归于此类。
AP模型常见运用：
- Web缓存
- DNS
举个咱们更了解的比方，像咱们了解的注册中心ZooKeeper、Eureka、Nacos中：
- ZooKeeper 确保的是 CP
- Eureka 确保的则是 AP
- Nacos 不仅支撑 CP 也支撑 AP
4. BASE理论了解吗？
BASE（Basically Available、Soft state、Eventual consistency）是依据CAP理论逐渐演化而来的，中心思维是即使不能到达强共同性（Strong consistency），也能够依据运用特色选用适当的办法来到达终究共同性（Eventual consistency）的作用。
BASE的首要意义：
- Basically Available（根本可用）
什么是根本可用呢？假定体系出现了不行预知的毛病，但仍是能用，仅仅相比较正常的体系而言，或许会有呼应时间上的损失，或许功用上的降级。
- Soft State（软状况）
什么是硬状况呢？要求多个节点的数据副本都是共同的，这是一种“硬状况”。
软状况也称为弱状况，相比较硬状况而言，答应体系中的数据存在中间状况，并认为该状况不影响体系的全体可用性，即答应体系在多个不同节点的数据副本存在数据延时。
- Eventually Consistent（终究共同性）
上面说了软状况，可是不应该一向都是软状况。在必定时间后，应该到达一个终究的状况，确保一切副本坚持数据共同性，从而到达数据的终究共同性。这个时间取决于网络延时、体系负载、数据仿制计划规划等等要素。
分布式锁
单体年代，能够直接用本地锁来完结对竞争资源的加锁，分布式环境下就要用到分布式锁了。
5. 有哪些分布式锁的完结计划呢？
常见的分布式锁完结计划有三种：MySQL分布式锁、ZooKepper分布式锁、Redis分布式锁。
5.1 MySQL分布式锁怎样完结呢？
用数据库完结分布式锁比较简略，便是创立一张锁表，数据库对字段作仅有性约束。
加锁的时分，在锁表中添加一条记载即可；开释锁的时分删去记载就行。
假如有并发恳求一起提交到数据库，数据库会确保只需一个恳求能够得到锁。
这种归于数据库 IO 操作，功率不高，并且频频操作会增大数据库的开支，因而这种办法在高并发、高功用的场景中用的不多。
5.2 ZooKeeper怎样完结分布式锁？
ZooKeeper也是常见分布式锁完结办法。
ZooKeeper的数据节点和文件目录相似，例如有一个lock节点，在此节点下树立子节点是能够确保先后顺序的，即使是两个进程一起恳求新建节点，也会依照先后顺序树立两个节点。
所以咱们能够用此特性完结分布式锁。以某个资源为目录，然后这个目录下面的节点便是咱们需求获取锁的客户端，每个服务在目录下创立节点，假如它的节点，序号在目录下最小，那么就获取到锁，不然等候。开释锁，便是删去服务创立的节点。
ZK实际上是一个比较重的分布式组件，实际上运用没那么多了，所以用ZK完结分布式锁，其实相对也比较少。
5.3 Redis怎样完结分布式锁？
Redis完结分布式锁，是当时运用最广泛的分布式锁完结办法。
Redis履行指令是单线程的，Redis完结分布式锁便是运用这个特性。
完结分布式锁最简略的一个指令：setNx(set if not exist)，假如不存在则更新：
setNx resourceName value
加锁了之后假如机器宕机，那我这个锁就无法开释，所以需求加入过期时间，并且过期时间需求和setNx同一个原子操作，在Redis2.8之前需求用lua脚本，可是redis2.8之后redis支撑nx和ex操作是同一原子操作。
set resourceName value ex 5 nx
- Redission
当然，一般出产中都是运用Redission客户端，非常杰出地封装了分布式锁的api，并且支撑RedLock。
分布式业务
6.什么是分布式业务?
分布式业务是相对本地业务而言的，关于本地业务，运用数据库本身的业务机制，就能够确保业务的ACID特性。
而在分布式环境下，会涉及到多个数据库。
分布式业务其实便是将对同一库业务的概念扩展到了对多个库的业务。目的是为了确保分布式体系中的数据共同性。
分布式业务处理的要害是：
- 需求记载业务在任何节点所做的一切动作；
- 业务进行的一切操作要么悉数提交，要么悉数回滚。
7.分布式业务有哪些常见的完结计划？
分布式常见的完结计划有 2PC、3PC、TCC、本地音讯表、MQ音讯业务、最大尽力告诉、SAGA业务 等等。
7.1 说说2PC两阶段提交？
提到2PC，就不得先说分布式业务中的 XA 协议。
在这个协议里，有三个人物：
- AP（Application） ：运用体系（服务）
- TM（Transaction Manager） ：业务办理器（大局业务办理）
- RM（Resource Manager） ：资源办理器（数据库）
XA协议选用两阶段提交办法来办理分布式业务。XA接口供给资源办理器与业务办理器之间进行通信的标准接口。
两阶段提交的思路能够归纳为： 参与者将操作胜败告诉和谐者，再由和谐者依据一切参与者的反馈状况决议各参与者是否要提交操作仍是回滚操作。
- 预备阶段：业务办理器要求每个涉及到业务的数据库预提交(precommit)此操作，并反映是否能够提交
- 提交阶段：业务和谐器要求每个数据库提交数据，或许回滚数据。
优点： 尽量确保了数据的强共同，完结本钱较低，在各大主流数据库都有自己完结，关于MySQL是从5.5开端支撑。
缺陷:
- 单点问题：业务办理器在整个流程中扮演的人物很要害，假如其宕机，比方在第一阶段现已完结，在第二阶段正预备提交的时分业务办理器宕机，资源办理器就会一向堵塞，导致数据库无法运用。
- 同步堵塞：在预备就绪之后，资源办理器中的资源一向处于堵塞，直到提交完结，开释资源。
- 数据不共同：两阶段提交协议虽然为分布式数据强共同性所规划，但仍然存在数据不共同性的或许，比方在第二阶段中，假定和谐者宣布了业务commit的告诉，可是由于网络问题该告诉仅被一部分参与者所收到并履行了commit操作，其他的参与者则由于没有收到告诉一向处于堵塞状况，这时分就发生了数据的不共同性。
7.2 3PC（三阶段提交）了解吗？
三阶段提交（3PC）是二阶段提交（2PC）的一种改善版本 ，为处理两阶段提交协议的单点毛病和同步堵塞问题。
三阶段提交有这么三个阶段：CanCommit，PreCommit，DoCommit三个阶段
-
CanCommit：预备阶段。和谐者向参与者发送commit恳求，参与者假如能够提交就回来Yes呼应，不然回来No呼应。
-
PreCommit：预提交阶段。和谐者依据参与者在预备阶段的呼应判别是否履行业务仍是中止业务，参与者履行完操作之后回来ACK呼应，一起开端等候终究指令。
-
DoCommit：提交阶段。和谐者依据参与者在预备阶段的呼应判别是否履行业务仍是中止业务：
- 假如一切参与者都回来正确的
ACK呼应，则提交业务 - 假如参与者有一个或多个参与者收到错误的
ACK呼应或许超时，则中止业务 - 假如参与者无法及时接纳到来自和谐者的提交或许中止业务恳求时，在等候超时之后，会继续进行业务提交
- 假如一切参与者都回来正确的
能够看出，三阶段提交处理的仅仅两阶段提交中单体毛病和同步堵塞的问题，由于加入了超时机制，这儿的超时的机制作用于 预提交阶段 和 提交阶段。假如等候 预提交恳求 超时，参与者直接回到预备阶段之前。假如比及提交恳求超时，那参与者就会提交业务了。
不管是2PC仍是3PC都不能确保分布式体系中的数据100%共同。
7.3 TCC了解吗？
TCC（Try Confirm Cancel） ，是两阶段提交的一个变种，针对每个操作，都需求有一个其对应的承认和吊销操作，当操作成功时调用承认操作，当操作失利时调用吊销操作，相似于二阶段提交，只不过是这儿的提交和回滚是针对业务上的，所以依据TCC完结的分布式业务也能够看做是对业务的一种补偿机制。
- Try：测验待履行的业务。订单体系将当时订单状况设置为付出中，库存体系校验当时剩下库存数量是否大于1，然后将可用库存数量设置为库存剩下数量-1，。
- Confirm：承认履行业务，假如Try阶段履行成功，接着履行Confirm 阶段，将订单状况修正为付出成功，库存剩下数量修正为可用库存数量。
- Cancel：吊销待履行的业务，假如Try阶段履行失利，履行Cancel 阶段，将订单状况修正为付出失利，可用库存数量修正为库存剩下数量。
TCC 是业务层面的分布式业务，确保终究共同性，不会一向持有资源的锁。
- 优点： 把数据库层的二阶段提交交给运用层来完结，规避了数据库的 2PC 功用低下问题
- 缺陷：TCC 的 Try、Confirm 和 Cancel 操作功用需业务供给，开发本钱高。TCC 对业务的侵入较大和业务紧耦合，需求依据特定的场景和业务逻辑来规划相应的操作
7.4 本地音讯表了解吗？
本地音讯表的中心思维是将分布式业务拆分本钱地业务进行处理。
例如，能够在订单库新增一个音讯表，将新增订单和新增音讯放到一个业务里完结，然后经过轮询的办法去查询音讯表，将音讯推送到MQ，库存服务去消费MQ。
履行流程：
- 订单服务，添加一条订单和一条音讯，在一个业务里提交
- 订单服务，运用定时任务轮询查询状况为未同步的音讯表，发送到MQ，假如发送失利，就重试发送
- 库存服务，接纳MQ音讯，修正库存表，需求确保幂等操作
- 假如修正成功，调用rpc接口修正订单体系音讯表的状况为已完结或许直接删去这条音讯
- 假如修正失利，能够不做处理，等候重试
订单服务中的音讯有或许由于业务问题会一向重复发送，所以为了避免这种状况能够记载一下发送次数，当到达次数约束之后报警，人工接入处理；库存服务需求确保幂等，避免同一条音讯被屡次消费构成数据不共同。
本地音讯表这种计划完结了终究共同性，需求在业务体系里添加音讯表，业务逻辑中多一次刺进的DB操作，所以功用会有损耗，并且终究共同性的距离首要有定时任务的距离时间决议
7.5 MQ音讯业务了解吗？
音讯业务的原理是将两个业务经过音讯中间件进行异步解耦。
订单服务履行自己的本地业务，并发送MQ音讯，库存服务接纳音讯，履行自己的本地业务，乍一看，如同跟本地音讯表的完结计划相似，仅仅省去 了对本地音讯表的操作和轮询发送MQ的操作，但实际上两种计划的完结是不相同的。
音讯业务必定要确保业务操作与音讯发送的共同性，假如业务操作成功，这条音讯也必定投递成功。
履行流程：
- 发送prepare音讯到音讯中间件
- 发送成功后，履行本地业务
- 假如业务履行成功，则commit，音讯中间件将音讯下发至消费端
- 假如业务履行失利，则回滚，音讯中间件将这条prepare音讯删去
- 消费端接纳到音讯进行消费，假如消费失利，则不断重试
音讯业务依赖于音讯中间件的业务音讯，例如咱们了解的RocketMQ就支撑业务音讯（半音讯），也便是只需收到发送方确定才会正常投递的音讯。
这种计划也是完结了终究共同性，比照本地音讯表完结计划，不需求再建音讯表，对功用的损耗和业务的入侵更小。
7.6 最大尽力告诉了解吗？
最大尽力告诉相比完结会简略一些，适用于一些对终究共同性实时性要求没那么高的业务，比方付出告诉，短信告诉。
以付出告诉为例，业务体系调用付出渠道进行付出，付出渠道进行付出，进行操作付出之后付出渠道会去同步告诉业务体系付出操作是否成功，假如不成功，会一向异步重试，可是会有一个最大告诉次数，假如超越这个次数后仍是告诉失利，就不再告诉，业务体系自行调用付出渠道供给一个查询接口，供业务体系进行查询付出操作是否成功。
履行流程：
- 业务体系调用付出渠道付出接口， 并在本地进行记载，付出状况为付出中
- 付出渠道进行付出操作之后，不管成功仍是失利，同步给业务体系一个成果告诉
- 假如告诉一向失利则依据重试规矩异步进行重试，到达最大告诉次数后，不再告诉
- 付出渠道供给查询订单付出操作成果接口
- 业务体系依据必定业务规矩去付出渠道查询付出成果
8.你们用什么？能说一下Seata吗？
咱们用比较常用的是Seata——自己去完结分布式业务调度仍是比较麻烦的。
Seata 的规划方针是对业务无侵入，因而它是从业务无侵入的两阶段提交（大局业务）着手，在传统的两阶段上进行改善，他把一个分布式业务了解成一个包括了若干分支业务的大局业务。而大局业务的职责是和谐它办理的分支业务达成共同性，要么一起成功提交，要么一起失利回滚。也便是一荣俱荣一损俱损~
Seata 中存在这么几种重要人物：
- TC（Transaction Coordinator） ：业务和谐者。办理大局的分支业务的状况，用于大局性业务的提交和回滚。
- TM（Transaction Manager） ：业务办理者。用于敞开、提交或回滚业务。
- RM（Resource Manager） ：资源办理器。用于分支业务上的资源办理，向 TC 注册分支业务，上报分支业务的状况，接纳 TC 的指令来提交或许回滚分支业务。
S’eata全体履行流程：
- 服务A中的 TM 向 TC 恳求敞开一个大局业务，TC 就会创立一个大局业务并回来一个仅有的 XID
- 服务A中的 RM 向 TC 注册分支业务，然后将这个分支业务归入 XID 对应的大局业务统辖中
- 服务A开端履行分支业务
- 服务A开端远程调用B服务，此刻 XID 会依据调用链传播
- 服务B中的 RM 也向 TC 注册分支业务，然后将这个分支业务归入 XID 对应的大局业务统辖中
- 服务B开端履行分支业务
- 大局业务调用处理完毕后，TM 会依据有误反常状况，向 TC 建议大局业务的提交或回滚
- TC 和谐其统辖之下的一切分支业务，决议是提交仍是回滚
分布式共同性算法
9.分布式算法paxos了解么 ？
Paxos 有点相似前面说的 2PC，3PC，但比这两种算法更加完善。在许多多大厂都得到了工程实践，比方阿里的 OceanBase 的 分布式数据库， Google 的 chubby 分布式锁 。
Paxos算法是什么？
Paxos 算法是 依据音讯传递 且具有 高效容错特性 的共同性算法，现在公认的处理 分布式共同性问题 最有用的算法之一。
Paxos算法的作业流程？
人物
在Paxos中有这么几个人物：
- Proposer（提议者） : 提议者提出提案，用于投票表决。
- Accecptor（承受者） : 对提案进行投票，并承受达成共同的提案。
- Learner（学习者） : 被告知投票的成果，承受达成共同的提案。
在实际中，一个节点能够一起充任不同人物。
提议者提出提案，提案=编号+value，能够表明为[M,V]，每个提案都有仅有编号，并且编号的巨细是趋势递加的。
算法流程
Paxos算法包括两个阶段，第一阶段Prepare(预备) 、第二阶段Accept(承受) 。
Prepare(预备)阶段
- 提议者提议一个新的提案 P[Mn,?]，然后向承受者的某个超越对折的子集成员发送编号为Mn的预备恳求
- 假如一个承受者收到一个编号为Mn的预备恳求，并且编号Mn大于它现已呼应的一切预备恳求的编号，那么它就会将它现已同意过的最大编号的提案作为呼应反馈给提议者，一起该承受者会许诺不会再同意任何编号小于Mn的提案。
总结一下，承受者在收到提案后，会给与提议者两个许诺与一个应对：
-
两个许诺：
- 许诺不会再承受提案号小于或等于 Mn 的 Prepare 恳求
- 许诺不会再承受提案号小于Mn 的 Accept 恳求
-
一个应对：
- 不违背曾经作出的许诺的前提下，回复现现已过的提案中提案号最大的那个提案所设定的值和提案号Mmax，假如这个值从来没有被任何提案设定过，则回来空值。假如不满意现已做出的许诺，即收到的提案号并不是决策节点收到过的最大的，那答应直接对此 Prepare 恳求不予理睬。
Accept(承受)阶段
- 假如提议者收到来自对折以上的承受者关于它宣布的编号为Mn的预备恳求的呼应，那么它就会发送一个针对[Mn,Vn]的承受恳求给承受者，注意Vn的值便是收到的呼应中编号最大的提案的值，假如呼应中不包括任何提案，那么它能够随意选定一个值。
- 假如承受者收到这个针对[Mn,Vn]提案的承受恳求，只需该承受者没有对编号大于Mn的预备恳求做出呼应，它就能够经过这个提案。
当提议者收到了大都承受者的承受应对后，洽谈完毕，共同决议构成，将构成的决议发送给一切学习节点进行学习。
所以Paxos算法的全体详细流程如下：
算法的流程模拟，能够查看参阅[13]。
Paxos算法有什么缺陷吗？怎样优化？
前面描述的能够称之为Basic Paxos 算法，在单提议者的前提下是没有问题的，可是假如有多个提议者针锋相对，那么就或许导致整个提议的过程进入了死循环。
Lamport 提出了 Multi Paxos 的算法思维。
Multi Paxos算法思维，简略说便是在多个提议者的状况下，选出一个Leader（领导者），由领导者作为仅有的提议者，这样就能够处理提议者抵触的问题。
10.说说Raft算法？
Raft算法是什么？
Raft 也是一个 共同性算法，和 Paxos 方针相同。但它还有另一个姓名 – 易于了解的共同性算法。Paxos 和 Raft 都是为了完结 共同性 发生的。这个过程如同推举相同，参选者 需求说服 大大都选民 (Server) 投票给他，一旦选定后就跟从其操作。Paxos 和 Raft 的区别在于推举的 详细过程 不同。
Raft算法的作业流程？
Raft算法的人物
Raft 协议将 Server 进程分为三种人物：
- Leader（领导者）
- Follower（跟从者）
- Candidate（提名人）
就像一个民主社会，领导者由跟从者投票选出。刚开端没有 领导者，一切集群中的 参与者 都是 跟从者。
那么首要敞开一轮大选。在大选期间 一切跟从者 都能参与竞选，这时一切跟从者的人物就变成了 提名人，民主投票选出首领后就开端了这届首领的任期，然后推举完毕，一切除 领导者 的 提名人 又变回 跟从者 遵守领导者领导。
这儿提到一个概念 「任期」，用术语 Term 表达。
三类人物的变迁图如下：
Leader推举过程
Raft 运用心跳（heartbeat）触发Leader推举。当Server启动时，初始化为Follower。Leader向一切Followers周期性发送heartbeat。假如Follower在推举超时时间内没有收到Leader的heartbeat，就会等候一段随机的时间后建议一次Leader推举。
Follower将其当时term加一然后转换为Candidate。它首要给自己投票并且给集群中的其他服务器发送 RequestVote RPC 。成果有以下三种状况：
- 赢得了大都（超越1/2）的选票，成功推举为Leader；
- 收到了Leader的音讯，表明有其它服务器现已抢先中选了Leader；
- 没有Server赢得大都的选票，Leader推举失利，等候推举时间超时（
Election Timeout）后建议下一次推举。
选出 Leader 后，Leader 经过 定时 向一切 Follower 发送 心跳信息 维持其统治。若 Follower 一段时间未收到 Leader 的 心跳，则认为 Leader 或许现已挂了，然后再次建议 推举 过程。
分布式规划
11.说说什么是幂等性？
什么是幂等性？
幂等性是一个数学概念，用在接口上：用在接口上就能够了解为：同一个接口，屡次宣布同一个恳求，恳求的成果是共同的。
简略说，便是屡次调用如一次。
什么是幂等性问题？
在体系的运行中，或许会出现这样的问题：
- 用户在填写某些
form表单时，保存按钮不小心快速点了两次，表中竟然发生了两条重复的数据，仅仅id不相同。 - 开发人员在项目中为了处理
接口超时问题，通常会引入了重试机制。第一次恳求接口超时了，恳求方没能及时获取回来成果（此刻有或许现已成功了），于是会对该恳求重试几回，这样也会发生重复的数据。 - mq顾客在读吊销息时，有时分会读取到
重复音讯，也会发生重复的数据。
这些都是常见的幂等性问题。
在分布式体系里，只需下游服务有写（保存、更新）的操作，都有或许会发生幂等性问题。
PS:幂等和防重有些不同，防重强调的避免数据重复，幂等强调的是屡次调用如一次，防重包括幂等。
怎样确保接口幂等性？
-
insert前先select
在保存数据的接口中，在
insert前，先依据requestId等字段先select一下数据。假如该数据已存在，则直接回来，假如不存在，才履行insert操作。 -
加仅有索引
加仅有索引是个非常简略但很有用的办法，假如重复刺进数据的话，就会抛出反常，为了确保幂等性，一般需求捕获这个反常。
假如是
java程序需求捕获：DuplicateKeyException反常，假如运用了spring结构还需求捕获：MySQLIntegrityConstraintViolationException反常。 -
加悲观锁
更新逻辑，比方更新用户账户余额，能够加悲观锁，把对运用户的哪一行数据锁住。同一时间只答应一个恳求获得锁，其他恳求则等候。
select * from user id=123 for update;这种办法有一个缺陷，获取不到锁的恳求一般只能报失利，比较难确保接口回来相同值。
-
加乐观锁
更新逻辑，也能够用乐观锁，功用更好。能够在表中添加一个
timestamp或许version字段，例如version:在更新前，先查询一下数据，将version也作为更新的条件，一起也更新version：
update user set amount=amount+100,version=version+1 where id=123 and version=1;更新成功后，version添加，重复更新恳求进来就无法更新了。
-
建防重表
有时分表中并非一切的场景都不答应发生重复的数据，只需某些特定场景才不答应。这时分，就能够运用防重表的办法。
例如音讯消费中，创立防重表，存储音讯的仅有ID，消费时先去查询是否现已消费，现已消费直接回来成功。
-
状况机
有些业务表是有状况的，比方订单表中有：1-下单、2-已付出、3-完结、4-吊销等状况，能够经过约束状况的活动来完结幂等。
-
分布式锁
直接在数据库上加锁的做法功用不够友爱，能够运用分布式锁的办法，现在最盛行的分布式锁完结是经过Redis，详细完结一般都是运用Redission结构。
-
token机制
恳求接口之前，需求先获取一个仅有的token，再带着这个token去完结业务操作，服务端依据这个token是否存在，来判别是否是重复的恳求。
分布式限流
12.你了解哪些限流算法？
- 计数器
计数器比较简略粗暴，比方咱们要约束1s能够经过的恳求数，完结的思路便是从第一个恳求进来开端计时，在接下来的1s内，每个恳求进来恳求数就+1，超越最大恳求数的恳求会被回绝，比及1s完毕后计数清零，重新开端计数。
这种办法有个很大的弊端：比方前10ms现现已过了最大的恳求数，那么后面的990ms的恳求只能回绝，这种现象叫做“突刺现象”。
- 漏桶算法
便是桶底出水的速度稳定，进水的速度或许快慢不一，可是当进水量大于出水量的时分，水会被装在桶里，不会直接被丢掉；可是桶也是有容量约束的，当桶装满水后溢出的部分仍是会被丢掉的。
算法完结：能够预备一个行列来保存暂时处理不了的恳求，然后经过一个线程池定时从行列中获取恳求来履行。
- 令牌桶算法
令牌桶便是出产拜访令牌的一个地方，出产的速度稳定，用户拜访的时分当桶中有令牌时就能够拜访，不然将触发限流。
完结计划：Guava RateLimiter限流
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 共同算法
[14].icyfenix.cn/distributio…
⭐️面渣逆袭系列：
- 面渣逆袭：Java根底五十三问
- 面渣逆袭：Java集合连环三十问
- 面渣逆袭：JVM经典五十问，这下面试稳了！
- 面渣逆袭：Java并发六十问
- 面渣逆袭：Spring三十五问，四万字+五十图详解！
- 面渣逆袭：二十二图、八千字、二十问，完全搞定MyBatis！
- 面渣逆袭：计算机网络六十二问，三万字图文详解！速收藏！
- 面试字节，被操作体系问挂了
- 面渣逆袭：RocketMQ二十三问
- 面渣逆袭：Redis连环五十二问！三万字+八十图详解！
- 面渣逆袭：MySQL六十六问，两万字+五十图详解！有点六！
