代码拉取完成，页面将自动刷新
同步操作将从 柠檬夕桐/lemon-guide 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
Introduction：收纳技术相关的 幂等、限流、降级、断路器、事务、缓存、分库分表 等总结！
[TOC]
什么是高可用？
在定义什么是高可用，可以先定义下什么是不可用，一个网站的内容最终呈现在用户面前需要经过若干个环节，而其中只要任何一个环节出现了故障，都可能导致网站页面不可访问，这个也就是网站不可用的情况。
参考维基百科，看看维基怎么定义高可用：系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。
这个难点或是重点在于“无中断”，要做到 7 x 24 小时无中断无异常的服务提供。
为什么需要高可用？
一套对外提供服务的系统是需要硬件，软件相结合，但是我们的软件会有bug，硬件会慢慢老化，网络总是不稳定，软件会越来越复杂和庞大，除了硬件软件在本质上无法做到“无中断”，外部环境也可能导致服务的中断，例如断电，地震，火灾，光纤被挖掘机挖断，这些影响的程度可能更大。
高可用的评价纬度
在业界有一套比较出名的评定网站可用性的指标，常用N个9来量化可用性，可以直接映射到网站正常运行时间的百分比上
| 描述 | N个9 | 可用性级别 | 年度停机时间 |
|---|---|---|---|
| 基本可用 | 2个9 | 99% | 87.6小时 |
| 较高可用 | 3个9 | 99% | 8.8小时 |
| 具备故障自动恢复能力可用 | 4个9 | 99.99% | 53分钟 |
| 极高可用 | 5个9 | 99.999% | 5分钟 |
一般互联网公司也是按照这个指标去界定可用性，不过在执行的过程中也碰到了一些问题，例如，有一些服务的升级或数据迁移明明可以在深夜停机或停服务进行，然而考虑到以后的报告要显示出我们的系统达到了多少个9的高可用，而放弃停服务这种简单的解决方案，例如停机2个小时，就永远也达不到4个9。然而在一些高并发的场合，例如在秒杀或拼团，虽然服务停止了几分钟，但是这个对整个公司业务的影响可能是非常重大的，分分钟丢失的订单可能是一个庞大的数量。所以N个9来量化可用性其实也得考虑业务的情况。
每一个访问可能都会有多个服务组成而成，每个机器每个服务都可能出现问题，所以第一个考虑到的就是每个服务必须不止一份可以是多份，所谓多份一致的服务就是服务的冗余，这里说的服务泛指了机器的服务，容器的服务，还有微服务本身的服务。
在机器服务层面需要考虑，各个机器间的冗余是否有在物理空间进行隔离冗余 ，例如是否所有机器是否有分别部署在不同机房，如果在同一个机房是否做到了部署在不同的机柜，如果是docker容器是否部署在分别不同的物理机上面。 采取的策略其实也还是根据服务的业务而定，所以需要对服务进行分级评分，从而采取不同的策略，不同的策略安全程度不同，伴随这的成本也是不同，安全等级更高的服务可能还不止考虑不同机房，还需要把各个机房所处的区域考虑进行，例如，两个机房不要处在同一个地震带上等等。
服务的冗余会要求我们可以随时对服务进行扩容或者缩容，有可能我们会从2台机器变成3台机器，想要对服务进行随时随地的扩缩容，就要求我们的服务是一个无状态化，所谓无状态化就是每个服务的服务内容和数据都是一致的。
例如，从我们的微服务架构来看，我们总共分水平划分了好几个层，正因为我们每个层都做到了无状态，所以在这个水平架构的扩张是非常的简单。假设，我们需要对网关进行扩容，我们只需要增加服务就可以，而不需要去考虑网关是否存储了一个额外的数据。
网关不保存任何的session数据，不提供会造成一致性的服务，将不一致的数据进行几种存储，借助更加擅长数据同步的中间件来完成。这个是目前主流的方案，服务本身尽可能提供逻辑的服务，将数据的一致性保证集中式处理，这样就可以把“状态”抽取出来，让网关保持一个“无状态”
这里仅仅是举了网关的例子，在微服务只基本所有的服务，都应该按照这种思路去做，如果服务中有状态，就应该把状态抽取出来，让更加擅长处理数据的组件来处理，而不是在微服务中去兼容有数据的状态。
之前上面说的服务冗余，可以简单的理解为计算的高可用，计算高可用只需要做到无状态既可简单的扩容缩容，但是对于需要存储数据的系统来说，数据本身就是有状态。
跟存储与计算相比，有一个本质的差别：将数据从一台机器搬到另一台机器，需要经过线路进行传输。
网络是不稳定的，特别是跨机房的网络，ping的延时可能是几十几百毫秒，虽然毫秒对于人来说几乎没有什么感觉，但是对于高可用系统来说，就是本质上的不同，这意味着整个系统在某个时间点上，数据肯定是不一致的。按照“数据+逻辑=业务”的公式来看，数据不一致，逻辑一致，最后的业务表现也会不一致。举个例子
无论是正常情况下的传输延时，还是异常情况下的传输中断，都会导致系统的数据在某个时间点出现不一致，而数据的不一致又会导致业务出现问题，但是如果数据不做冗余，系统的高可用无法保证
所以，存储高可用的难点不在于怎么备份数据，而在于如何减少或者规避数据不一致对业务造成的影响
分布式领域中有一个著名的CAP定理，从理论上论证了存储高可用的复杂度，也就是说，存储高可用不可能同时满足“一致性，可用性，分区容错性”，最多只能满足2个，其中分区容错在分布式中是必须的，就意味着，我们在做架构设计时必须结合业务对一致性和可用性进行取舍。
存储高可用方案的本质是将数据复制到多个存储设备中，通过数据冗余的方式来现实高可用，其复杂度主要呈现在数据复制的延迟或中断导致数据的不一致性，我们在设计存储架构时必须考虑到一下几个方面：
主从复制是最常见的也是最简单的存储高可用方案，例如Mysql，redis等等
其架构的优点就是简单，主机复制写和读，而从机只负责读操作，在读并发高时候可用扩张从库的数量减低压力，主机出现故障，读操作也可以保证读业务的顺利进行。
缺点就是客户端必须感知主从关系的存在，将不同的操作发送给不同的机器进行处理，而且主从复制中，从机器负责读操作，可能因为主从复制时延大，出现数据不一致性的问题。
刚说了主从切换存在两个问题： 1.主机故障写操作无法进行 2.需要人工将其中一台从机器升级为主机
为了解决这个两个问题，我们可以设计一套主从自动切换的方案，其中设计到对主机的状态检测，切换的决策，数据丢失和冲突的问题。
1.主机状态检测
需要多个检查点来检测主机的机器是否正常，进程是否存在，是否出现超时，是否写操作不可执行，读操作是否不可执行，将其进行汇总，交给切换决策
2.切换决策
确定切换的时间决策，什么情况下从机就应该升级为主机，是进程不存在，是写操作不可这行，连续检测多少失败次就进行切换。应该选择哪一个从节点升级为主节点，一般来说或应该选同步步骤最大的从节点来进行升级。切换是自动切换还是半自动切换，通过报警方式，让人工做一次确认。
3.数据丢失和数据冲突 数据写到主机，还没有复制到从机主机就挂了，这个时候怎么处理，这个也得考虑业务的方式，是要确保CP或AP
还要考虑一个数据冲突的问题，这个问题在mysql中大部分是由自增主键引起，就算不考虑自增主键会引起数据冲突的问题，其实自增主键还要引起很多的问题，这里不细说，避免使用自增主键。
上述的数据冗余可以通过数据的复制来进行解决，但是数据的扩张需要通过数据的分片来进行解决（如果在关系型数据库是分表）。
何为数据分片（segment，fragment， shard， partition），就是按照一定的规则，将数据集划分成相互独立、正交的数据子集，然后将数据子集分布到不同的节点上。
HDFS ， mongoDB 的sharding 模式也基本是基于这种分片的模式去实现，我们在设计分片主要考虑到的点是：
在每一次调用，时间越长存在超时的风险就越大，逻辑越复杂执行的步骤越多存在失败的风险也就越大，如果在业务允许的情况下，用户调用只给用户必须要的结果，而不是需要同步的结果可以放在另外的地方异步去操作，这就减少了超时的风险也把复杂业务进行拆分减低复杂度。当然异步化的好处是非常多，例如削封解耦等等，这里只是从可用的角度出发。异步化大致有这三种的实现方式：
什么是柔性化，想象一个场景，我们的系统会给每个下单的用户增加他们下单金额对应的积分，当一个用户下单完毕后，我们给他增加积分的服务出现了问题，这个时候，我们是要取消掉这个订单还是先让订单通过，积分的问题通过重新或者报警来处理呢？
所谓的柔性化，就是在我们业务中允许的情况下，做不到给予用户百分百可用的通过降级的手段给到用户尽可能多的服务，而不是非得每次都交出去要么100分或0分的答卷。
怎么去做柔性化，更多其实是对业务的理解和判断，柔性化更多是一种思维，需要对业务场景有深入的了解。
在电商订单的场景中，下单，扣库存，支付是一定要执行的步骤，如果失败则订单失败，但是加积分，发货，售后是可以柔性处理，就算出错也可以通过日志报警让人工去检查，没必要为加积分损失整个下单的可用性
兜底是可能我们经常谈论的是一种降级的方案，方案是用来实施，但是这里兜底可能更多是一种思想，更多的是一种预案，每个操作都可以犯错，我们也可以接受犯错，但是每个犯错我们都必须有一个兜底的预案，这个兜底的预案其实就是我们的容错或者说最大程度避免更大伤害的措施，实际上也是一个不断降级的过程。举个例子：
例如我们首页请求的用户个性化推荐商品的接口，发现推荐系统出错，我们不应该去扩大（直接把异常抛给用户）或保持调用接口的错误，而是应该兼容调用接口的错误，做到更加柔性化，这时候可以选择获取之前没有失败接口的缓存数据，如果没有则可以获取通用商品不用个性化推荐，如果也没有可以读取一些静态文字进行展示。
由于我们架构进行了分层，分成APP，网关，业务逻辑层，数据访问层等等，在组织结构也进行了划分，与之对应的是前端组，后端业务逻辑组，甚至有中台组等等。既然有代码和人员架构的划分层级，那么每一层都必须有这样的思想：包容下一层的错误，为上一层提供尽可能无措的服务。举个例子：
商品的美元售价假设要用商品人民币售价/汇率，这个时候错误发生在低层的数据层，上一层如果直接进行除，肯定就抛出 java.lang.ArithmeticException: / by zero，本着我们对任何一层调用服务都不可信的原则，应该对其进行容错处理，不能让异常扩散，更要保证我们这一层对上一次尽可能的作出最大努力确定的服务。
相信负载均衡这个话题基本已经深入每个做微服务开发或设计者的人心，负载均衡的实现有硬件和软件，硬件有F5，A10等机器，软件有LVS，nginx，HAProxy等等，负载均衡的算法有 random ， RoundRobin ， ConsistentHash等等。
转移流程
nginx 根据给定好的负载均衡算法进行调度，当请求到tomcat1，nginx发现tomcat1出现连接错误（节点失效），nginx会根据一定的机制将tomcat1从调用的负载列表中清除，在下一次请求，nginx不会分配请求到有问题的tomcat1上面，会将请求转移到其他的tomcat之上。
节点失效
nginx默认判断节点失效是以connect refuse和timeout为标准，在对某个节点进行fails累加，当fails大于max_fails时，该节点失效。
节点恢复
当某个节点失败的次数大于max_fails时，但不超过fail_timeout,nginx将不在对该节点进行探测，直到超过失效时间或者所有的节点都失效，nginx会对节点进行重新探测。
在使用ZK作为注册中心时，故障的发现是由Zk去进行发现，业务逻辑层通过watch的心跳机制将自己注册到zk上，网关对zk进行订阅就可以知道有多少可以调用的列表。当业务逻辑层在重启或者被关闭时就会跟zk断了心跳，zk会更新可调用列表。
使用zk作为负载均衡的协调器，最大的问题是zk对于服务是否可用是基于pingpong的方式，只要服务心跳存在，zk就认为服务是处在于可用状态，但是服务如果处在于假死的状态，zk是无从得知的。这个时候，业务逻辑服务是否真正可用只能够由网关知道。
幂等设计
为何会牵出幂等设计的问题，主要是因为负载均衡的failover策略，就是对失败的服务会进行重试，一般来说，如果是读操作的服务，重复执行也不会出问题，但想象一下，如果是一个创建订单减库存的操作，第一次调用也tomcat1超时，再重新调用了tomcat2，这个时候我们都不能确认超时调用的tomcat1是否真的被调用，有可能根本就调用不成功，有可能已经调用成功但是因为某些原因返回超时而已，所以，很大程度这个接口会被调用2次。如果我们没有保证幂等性，就有可能一个订单导致了减少2次的库存。所谓的幂等性，就是得保证在同一个业务中，一个接口被调用了多次，其导致的结果都是一样的。
先来讲讲微服务中限流/熔断的目的是什么，微服务后，系统分布式部署，系统之间通过rpc框架通信，整个系统发生故障的概率随着系统规模的增长而增长，一个小的故障经过链路的传递放大，有可能会造成更大的故障。
限流跟高可用的关系是什么，假定我们的系统最多只能承受500个人的并发访问，但整个时候突然增加到1000个人进来，一下子就把整个系统给压垮了，本来还有500个人能享受到我们系统的服务，突然间变成了所有人都无法得到服务，与其让1000人都不法得到服务，不如就让500个人得到服务，拒绝掉另外500个人。限流是对访问的隔离，是保证了部门系统承受范围内用户的可用性。
熔断跟高可用的关系是什么，上面说了微服务是一个错综复杂的调用链关系，假设 模块A 调用 模块B ， 模块B 又调用了 模块C ， 模块C 调用了 模块D，这个时候，模块D 出了问题出现严重的时延，这个时候，整个调用链就会被 模块D 给拖垮，A 等B，B等C，C等D，而且A B C D的资源被锁死得不到释放，如果流量大的话还容易引起雪崩。熔断，主动丢弃 模块D 的调用，并在功能上作出一些降级才能保证到我们系统的健壮性。 熔断是对模块的隔离，是保证了最大功能的可用性。
服务模块与服务模块之间有着千丝万缕的关系，但服务模块在业务中各有权重，例如订单模块可能是一家电商公司的重中之重，如果出问题将会直接影响整个公司的营收，而一个后台的查询服务模块可能也重要，但它的重要等级绝对是没有像订单这么重要。所以，在做服务治理时，必须明确各个服务模块的重要等级，这样才能更好的做好监控，分配好资源。这个在各个公司有各个公司的一个标准，例如在电商公司，确定服务的级别可能会更加倾向对用用户请求数和营收相关的作为指标。
| 服务级别 | 服务模块 |
|---|---|
| 一级服务 | 支付系统 订单服务 商品服务 用户服务 发布系统 ... |
| 二级服务 | 消息服务 权限系统 CRM系统 积分系统 BI系统 评论系统 ... |
| 三级服务 | 后台日志系统 |
可能真正的划分要比这个更为复杂，必须根据具体业务去定，这个可以从平时服务模块的访问量和流量去预估，往往更重要的模块也会提供更多的资源，所以不仅要对技术架构了如指掌，还要对公司各种业务形态了然于心才可以。
服务分级不仅仅在故障界定起到重要主要，而且决定了服务监控的力度，服务监控在高可用中起到了一个保障的作用，它不仅可以保留服务奔溃的现场以等待日后复盘，更重要的是它可以起到一个先知，先行判断的角色，很多时候可以预先判断危险，防范于未然。
服务监控是微服务治理的一个重要环节，监控系统的完善程度直接影响到我们微服务质量的好坏，我们的微服务在线上运行的时候有没有一套完善的监控体系能去了解到它的健康情况，对整个系统的可靠性和稳定性是非常重要，可靠性和稳定性是高可用的一个前提保证。
服务的监控更多是对于风险的预判，在出现不可用之间就提前的发现问题，如果系统获取监控报警系统能自我修复则可以将错误消灭在无形，如果系统发现报警无法自我修复则可以通知人员提早进行接入。
一个比较完善的微服务监控体系需要涉及到哪些层次，如下图，大致可以划分为五个层次的监控
基础设施监控
例如网络，交换机，路由器等低层设备，这些设备的可靠性稳定性就直接影响到上层服务应用的稳定性，所以需要对网络的流量，丢包情况，错包情况，连接数等等这些基础设施的核心指标进行监控。
系统层监控
涵盖了物理机，虚拟机，操作系统这些都是属于系统级别监控的方面，对几个核心指标监控，如cpu使用率，内存占用率，磁盘IO和网络带宽情况。
应用层监控
例如对url访问的性能，访问的调用数，访问的延迟，还有对服务提供性能进行监控，服务的错误率，对sql也需要进行监控，查看是否有慢sql，对与cache来说，需要监控缓存的命中率和性能，每个服务的响应时间和qps等等。
业务监控
比方说一个电商网站，需要关注它的用户登录情况，注册情况，下单情况，支付情况，这些直接影响到实际触发的业务交易情况，这个监控可以提供给运营和公司高管他们需需要关注的数据，直接可能对公司战略产生影响。
端用户体验监控
用户通过浏览器，客户端打开练到到我们的服务，那么在用户端用户的体验是怎么样，用户端的性能是怎么样，有没有产生错误，这些信息也是需要进行监控并记录下来，如果没有监控，有可能用户的因为某些原因出错或者性能问题造成体验非常的差，而我们并没有感知，这里面包括了，监控用户端的使用性能，返回码，在哪些城市地区他们的使用情况是怎么样，还有运营商的情况，包括电信，联通用户的连接情况。我们需要进一步去知道是否有哪些渠道哪些用户接入的时候存在着问题，包括我们还需要知道客户端使用的操作系统浏览器的版本。
冷备，通过停止数据库对外服务的能力，通过文件拷贝的方式将数据快速进行备份归档的操作方式。简而言之，冷备，就是复制粘贴，在linux上通过cp命令就可以很快完成。可以通过人为操作，或者定时脚本进行。有如下好处：
mv命令就可瞬间完成恢复。以上的好处，对于以前的软件来说，是很好的方式。但是对于现如今的很多场景，已经不好用了，因为：
如何权衡冷备的利弊，是每个业务需要考虑的。
热备，和冷备比起来，主要的差别是不用停机，一边备份一边提供服务。但还原的时候还是需要停机的。由于我们讨论的是和存储相关的，所以不将共享磁盘的方式看作双机热备。
相当于1主1从，主节点对外提供服务，从节点作为backup。通过一些手段将数据从主节点同步到从节点，当故障发生时，将从节点设置为工作节点。数据同步的方式可以是偏软件层面，也可以是偏硬件层面的。偏软件层面的，比如mysql的master/slave方式，通过同步binlog的方式；sqlserver的订阅复制方式。偏硬件层面，通过扇区和磁盘的拦截等镜像技术，将数据拷贝到另外的磁盘。偏硬件的方式，也被叫做数据级灾备；偏软件的，被叫做应用级灾备。后文谈得更多的是应用级灾备。
本质上还是Active/Standby，只是互为主从而已。双机互备并不能工作于同一个业务，只是在服务器角度来看，更好的压榨了可用的资源。比如，两个业务分别有库A和B，通过两个机器P和Q进行部署。那么对于A业务，P主Q从，对于B业务，Q主P从。整体上看起来是两个机器互为主备。这种架构下，读写分离是很好的，单写多读，减少冲突又提高了效率。
其他的高可用方案还可以参考各类数据库的多种部署模式，比如mysql的主从、双主多从、MHA；redis的主从，哨兵，cluster等等。
前面讲到的几种方案，基本都是在一个局域网内进行的。业务发展到后面，有了同城多活的方案。和前面比起来，不信任的粒度从机器转为了机房。这种方案可以解决某个IDC机房整体挂掉的情况（停电，断网等）。
同城双活其实和前文提到的双机热备没有本质的区别，只是“距离”更远了，基本上还是一样（同城专线网速还是很快的）。双机热备提供了灾备能力，双机互备避免了过多的资源浪费。
在程序代码的辅助下，有的业务还可以做到真正的双活，即同一个业务，双主，同时提供读写，只要处理好冲突的问题即可。需要注意的是，并不是所有的业务都能做到。
业界更多采用的是两地三中心的做法。远端的备份机房能更大的提供灾备能力，能更好的抵抗地震，恐袭等情况。双活的机器必须部署到同城，距离更远的城市作为灾备机房。灾备机房是不对外提供服务的，只作为备份使用，发生故障了才切流量到灾备机房；或者是只作为数据备份。原因主要在于：距离太远，网络延迟太大。
如上图，用户流量通过负载均衡，将服务A的流量发送到IDC1，服务器集A；将服务B的流量发送到IDC2，服务器B；同时，服务器集a和b分别从A和B进行同城专线的数据同步，并且通过长距离的异地专线往IDC3进行同步。当任何一个IDC当机时，将所有流量切到同城的另一个IDC机房，完成了failover。当城市1发生大面积故障时，比如发生地震导致IDC1和2同时停止工作，则数据在IDC3得以保全。同时，如果负载均衡仍然有效，也可以将流量全部转发到IDC3中。不过，此时IDC3机房的距离非常远，网络延迟变得很严重，通常用户的体验的会受到严重影响的。
上图是一种基于Master-Slave模式的两地三中心示意图。城市1中的两个机房作为1主1从，异地机房作为从。也可以采用同城双主+keepalived+vip的方式，或者MHA的方式进行failover。但城市2不能（最好不要）被选择为Master。
同城双活可以应对大部分的灾备情况，但是碰到大面积停电，或者自然灾害的时候，服务依然会中断。对上面的两地三中心进行改造，在异地也部署前端入口节点和应用，在城市1停止服务后将流量切到城市2，可以在降低用户体验的情况下，进行降级。但用户的体验下降程度非常大。
所以大多数的互联网公司采用了异地双活的方案。
上图是一个简单的异地双活的示意图。流量经过LB后分发到两个城市的服务器集群中，服务器集群只连接本地的数据库集群，只有当本地的所有数据库集群均不能访问，才failover到异地的数据库集群中。
在这种方式下，由于异地网络问题，双向同步需要花费更多的时间。更长的同步时间将会导致更加严重的吞吐量下降，或者出现数据冲突的情况。吞吐量和冲突是两个对立的问题，你需要在其中进行权衡。例如，为了解决冲突，引入分布式锁/分布式事务；为了解决达到更高的吞吐量，利用中间状态、错误重试等手段，达到最终一致性；降低冲突，将数据进行恰当的sharding，尽可能在一个节点中完成整个事务。
对于一些无法接受最终一致性的业务，饿了么采用的是下图的方式：
对于个别一致性要求很高的应用，我们提供了一种强一致的方案（Global Zone），Globa Zone是一种跨机房的读写分离机制，所有的写操作被定向到一个 Master 机房进行，以保证一致性，读操作可以在每个机房的 Slave库执行，也可以 bind 到 Master 机房进行，这一切都基于我们的数据库访问层（DAL）完成，业务基本无感知。
《饿了么异地多活技术实现（一）总体介绍》
也就是说，在这个区域是不能进行双活的。采用主从而不是双写，自然解决了冲突的问题。
实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。
根据异地双活的思路，我们可以画出异地多活的一种示意图。每个节点的出度和入度都是4，在这种情况下，任何节点下线都不会对业务有影响。但是，考虑到距离的问题，一次写操作将带来更大的时间开销。时间开销除了影响用户体验以外，还带来了更多的数据冲突。在严重的数据冲突下，使用分布式锁的代价也更大。这将导致系统的复杂度上升，吞吐量下降。所以上图的方案是无法使用的。
回忆一下我们在解决网状网络拓扑的时候是怎么优化的？引入中间节点，将网状改为星状：
改造为上图后，每个城市下线都不会对数据造成影响。对于原有请求城市的流量，会被重新LoadBalance到新的节点（最好是LB到最近的城市）。为了解决数据安全的问题，我们只需要针对中心节点进行处理即可。但是这样，对于中心城市的要求，比其他城市会更高。比如恢复速度，备份完整性等，这里暂时不展开。我们先假定中心是完全安全的。
注册中心主要是为分布式服务的发布与发现提供一层统一标准化的基础组件，便于使用者直接操作简单接口即可实现服务发布与发现功能。
服务注册有两种形式：客户端注册和代理注册。
客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己。
这种方式缺点是注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。
代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作。
这种方式的缺点是多引用了一个代理服务，并且代理服务要保持高可用状态。
服务发现也分为客户端发现和代理发现。
客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用。
这种方式非常直接，客户端可以控制负载均衡算法。但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。
代理发现是指新增一个路由服务负责服务发现获取可用的实例列表，服务消费者如果需要调用服务A的一个实例可以直接将请求发往路由服务，路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可，如果发现实例不可用，路由服务还可以自行重试，服务消费者完全不用感知。
如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。如何实现摘机？业界比较常用的方式是通过心跳检测的方式实现，心跳检测有主动和被动两种方式。
被动检测是指服务主动向注册中心发送心跳消息，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。
上图中服务A的实例2已经宕机不能主动给注册中心发送心跳消息，15秒之后注册就会将实例2移除掉。
主动检测是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例。
针对使用者，主要关注注册中心的以下五个核心接口，通过以下五个核心接口，可以实现服务的动态发布、动态发现以及优雅下线等操作：
Zookeeper会有一些未知的问题出现，所以需要生产特性来应对各种可能出现的问题，从而提升产品的质量。该类功能针对使用者一般情况是没办法直接感受到，但其发挥的作用就是保障产品的高质量服务：
下面结合各个维度对比一下各组件：
| 方案 | 优点 | 缺点 | 访问协议 | 一致性算法 |
|---|---|---|---|---|
| Zookeeper | 1.功能强大，不仅仅只是服务发现；2.提供watcher机制可以实时获取服务提供者的状态；3.广泛使用，dubbo等微服务框架已支持 | 1.没有健康检查；2.需要在服务中引入sdk，集成复杂度高；3.不支持多数据中心 | TCP | Paxos（CP） |
| Consul | 1.开箱即用，方便集成；2.带健康检查；3.支持多数据中心；4.提供web管理界面 | 不能实时获取服务变换通知 | HTTP/DNS | Raft（CP） |
| Nacos | 1.开箱即用，适用于dubbo，spring cloud等；2.AP模型，数据最终一致性；3.注册中心，配置中心二合一(二合一也不一定是优点)，提供控制台管理；4.纯国产，各种有中文文档，久经双十一考验 | 刚刚开源不久，社区热度不够，依然存在bug | HTTP/DNS | CP+AP |
| Eureka | HTTP | AP |
Consul是HashiCorp公司推出的开源工，使用Go语言开发，具有开箱即可部署方便的特点。Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。
Consul有哪些优势？
Consul的架构图
Consul 实现多数据中心依赖于gossip protocol协议。这样做的目的：
Consul的使用场景
Consul的应用场景包括服务注册发现、服务隔离、服务配置等。
服务注册发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check
服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密
服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息
API网关是什么？
API网关是随着微服务（Microservice）概念兴起的一种架构模式。原本一个庞大的单体应用（All in one）业务系统被拆分成许多微服务（Microservice）系统进行独立的维护和部署，服务拆分带来的变化是API的规模成倍增长，API的管理难度也在日益增加，使用API网关发布和管理API逐渐成为一种趋势。一般来说，API网关是运行于外部请求与内部服务之间的一个流量入口，实现对外部请求的协议转换、鉴权、流控、参数校验、监控等通用功能。
为什么要做API网关？
在没有API网关之前，业务研发人员如果要将内部服务输出为对外的HTTP API接口。通常要搭建一个Web应用，用于完成基础的鉴权、限流、监控日志、参数校验、协议转换等工作，同时需要维护代码逻辑、基础组件的升级，研发效率相对比较低。此外，每个Web应用都需要维护机器、配置、数据库等，资源利用率也非常差。
Tomcat自身问题
缓存太多。Tomcat用了很多对象池技术，内存有限的情况下，流量一高很容易触发gc
内存copy。Tomcat默认用堆内存，所以数据需要读到堆内，而后端服务是Netty，有堆外内存，需要通过数次copy
Tomcat读body是阻塞的。Tomcat的NIO模型和Reactor模型不一样，读body是Block的
Tomcat对链接重用的次数是有限制的。默认是100次，当达到100次后，Tomcat会通过在响应头里添加Connection:close，让客户端关闭该链接，否则如果再用该链接发送的话，会出现400
Tomcat Buffer
Tomcat buffer 的关系图如下：
通过上面的图，我们可以看出，Tomcat 对外封装的很好，内部默认的情况下会有三次 copy。
使用API网关的控制面，业务研发人员可以轻松的完成API的全生命周期管理，如下图所示：
业务研发人员从创建API开始，完成参数录入、DSL脚本生成；接着可以通过文档和MOCK功能进行API测试；API测试完成后，为了保证上线稳定性，管理平台提供了发布审批、灰度上线、版本回滚等一系列安全保证措施；API运行期间会监控API的调用失败情况、记录请求日志，一旦发现异常及时发出告警；最后，对于不再使用的API进行下线操作后，会回收API所占用的各类资源并等待重新启用。整个生命周期，全部通过配置化、流程化的方式，由业务研发人员全自助管理，上手时间基本在10分钟以内，极大地提升了研发效率。
API网关的配置中心存放API的相关配置信息——使用自定义的DSL（Domain-Specific Language，领域专用语言）来描述，用于向API网关的数据面下发API的路由、规则、组件等配置变更。配置中心的设计上使用统一配置管理服务和本地缓存结合的方式，实现动态配置，不停机发布。API的配置如下图所示：
API配置的详细说明
API网关的数据面在感知到API配置后，会在内存中建立请求路径与API配置的路由信息。通常HTTP请求路径上，会包含一些路径变量，考虑到性能问题，没有采用正则匹配的方式，而是设计了两种数据结构来存储。如下图所示：
一种是不包含路径变量的直接映射的MAP结构。其中，Key就是完整的域名和路径信息，Value是具体的API配置。
另外一种是包含路径变量的前缀树数据结构。通过前缀匹配的方式，先进行叶子节点精确查找，并将查找节点入栈处理，如果匹配不上，则将栈顶节点出栈，再将同级的变量节点入栈，如果仍然找不到，则继续回溯，直到找到（或没找到）路径节点并退出。
当请求流量命中API请求路径进入服务端，具体处理逻辑由DSL中配置的一系列功能组件完成。网关提供了丰富的功能组件集成，包括链路追踪、实时监控、访问日志、参数校验、鉴权、限流、熔断降级、灰度分流等，如下图所示：
API调用的最后一步，就是协议转换以及服务调用了。网关需要完成的工作包括：获取HTTP请求参数、Context本地参数，拼装后端服务参数，完成HTTP协议到后端服务的协议转换，调用后端服务获取响应结果并转换为HTTP响应结果。
上图以调用后端RPC服务为例，通过JsonPath表达式获取HTTP请求不同部位的参数值，替换RPC请求参数相应部位的Value，生成服务参数DSL，最后借助RPC泛化调用完成本次服务调用。
提供了一些常规的稳定性保障手段，来保证自身和后端服务的可用性。如下图所示：
API网关服务端接入了弹性伸缩模块，可根据CPU等指标进行快速扩容、缩容。除此之外，还支持快速摘除问题节点，以及更细粒度的问题组件摘除。
对于一些已经在对外提供API的Web服务，业务研发人员为了减少运维成本和后续的研发提效，考虑将其迁移到API网关。对于一些非核心API，可以考虑使用灰度发布功能直接迁移。但是对于一些核心API，上面的灰度发布功能是机器级别的，粒度较大，不够灵活，不能很好的支持灰度验证过程。
解决方案
API网关为业务研发人员提供了一个灰度SDK，接入SDK的Web服务，可在识别灰度流量后转发到API网关进行验证。灰度哪些API、灰度百分比可以在API网关管理端动态调节，实时生效，业务研发人员还可以通过SPI的方式自定义灰度策略。灰度验证通过后，再把API迁移到API网关，保障迁移过程的稳定性。
灰度过程
灰度前：在API网关管理平台创建API分组，域名配置为目前使用的域名。在Oceanus上，原域名规则不变。
灰度中：在API网关管理平台开启灰度功能，灰度SDK将灰度流量转发到网关服务，进行验证。
灰度后：通过灰度流量验证API网关上的API配置符合预期后再迁移。
业务研发人员在实际使用网关管理平台时，我们尽量通过图形化的页面配置来减轻DSL的编写负担。但服务参数转换的DSL配置，仍然需要业务研发人员手工编写。一般来说，生成服务参数DSL的流程是：
整个过程非常繁琐，且容易出错。如果需要录入的API多达几十上百个，全部由业务研发人员手工录入的效率是非常低下的。
解决方案
那么能不能将服务参数DSL的生成过程给自动化呢？ 答案是可以的，业务RD只需在网关录入API文档信息，然后录入服务的Appkey、服务名、方法名信息，API网关管理端会从最新发布的服务框架控制台获取到服务参数的JSON Schema信息，JSON Schema定义了服务参数的类型和结构信息，管理端可根据这些信息，自动生成服务参数的JSON Mock数据。结合API文档的信息，自动替换参数名相同的Value值。 这套DSL自动生成方案，使用过程中对业务透明、标准化，业务方只需升级最新版本服务框架即可使用，极大提升研发效率，目前受到业务研发人员的广泛好评。
快速创建API
API网关的核心能力是建立在API配置的基础上的，但提供强大功能的同时带来了较高的复杂性，不少业务研发人员吐槽API配置太繁琐，学习成本高。快速创建API的功能应运而生，业务研发人员只需要提供少量的信息就可以创建API。快速创建API的功能当前分为4种类型（后端RPC服务API、后端HTTP服务API、SSO CallBack API、Nest API），未来会根据业务应用场景的不同，提供更多的快速创建API类型。
批量操作
业务研发人员在API网关上，需要管理非常多的业务分组，每个业务分组，最多可以有200个API配置，多个API可能有很多相同的配置，如组件配置，错误码配置和跨域配置的。每个API对于相同的配置都要配置一遍，操作重复度很高。因此API网关支持批量操作多个API：勾选多个API后，通过【批量操作】功能可一次性完成多个API配置更新，降低业务重复配置的操作成本。
API导入导出
API网关提供在不同研发环境相互导入导出API的能力，业务研发人员在线下测试完成后，只需要使用API导入导出功能，即可将配置导出到线上生产环境，避免重复配置。
API网关提供了丰富的系统组件完成鉴权、限流、监控能力，能够满足大部分的业务需求。但仍有一些特殊的业务需求，如自定义验签、自定义结果处理等。API网关通过提供加载自定义组件能力，支持业务完成一些自定义逻辑的扩展。下图是自定义组件实现的一个实例。getName中填写自定义组件申请时的名称，invoke方法中实现自定义组件的业务逻辑，如继续执行、进行页面跳转、直接返回结果、抛出异常等。
一般情况下，网关上配置的一个API对应后端一个RPC或者HTTP服务。如果调用端有聚合和编排后端服务的需求，那么有多少后端服务，就必须发起多少次HTTP的请求调用。由此就会带来一些问题，调用端的HTTP请求次数过多，效率低，在调用端聚合服务的逻辑过重。
服务编排的需求应运而生，服务编排是对既有服务进行编排调用，同时对获取的数据进行处理。主要应用在数据聚合场景：一次HTTP请求返回的数据需要调用多个或多次服务（RPC或HTTP）才能获取到完整的结果。
通过独立部署的方式提供服务编排能力，API网关与服务编排服务之间通过RPC进行调用。这样可以解耦API网关与服务编排服务，避免因服务编排能力影响集群上的其他服务，同时多一次RPC调用并不会有明显耗时增加。使用上对业务研发人员也是透明的，非常方便，业务研发人员在管理端配置好服务编排的API，通过配置中心同时下发到API网关服务端和服务编排服务上，即可开始使用服务编排能力。整体的交互架构图如下：
请求安全是API网关非常重要的能力，集成了丰富的安全相关的系统组件，包括有基础的请求签名、SSO单点登录、基于SSO鉴权的UAC/UPM访问控制、用户鉴权Passport、商家鉴权EPassport、商家权益鉴权、反爬等等。业务研发人员只需要简单配置，即可使用。
API网关按业务线维度进行集群隔离，也支持重要业务独立部署。如下图所示：
服务节点维度，API网关支持请求的快慢线程池隔离。快慢线程池隔离主要用于一些使用了同步阻塞组件的API，例如SSO鉴权、自定义鉴权等，可能导致长时间阻塞共享业务线程池。快慢隔离的原理是统计API请求的处理时间，将请求处理耗时较长，超过容忍阈值的API请求隔离到慢线程池，避免影响其他正常API的调用。除此之外，也支持业务研发人员配置自定义线程池进行隔离。具体的线程隔离模型如下图所示：
API网关作为请求入口，往往肩负着请求流量灰度验证的重任。
灰度场景
在灰度能力上，支持灰度API自身逻辑，也支持灰度下游服务，也可以同时灰度API自身逻辑和下游服务。如下图所示：
灰度API自身逻辑时，通过将流量分流到不同的API版本实现灰度能力；灰度下游服务时，通过给流量打标，分流到指定的下游灰度单元中。
灰度策略
支持丰富的灰度策略，可以按照比例数灰度，也可以按照特定条件灰度。
API网关提供360度的立体化监控，从业务指标、机器指标、JVM指标提供7x24小时的专业守护，如下表：
| 监控模块 | 主要功能 | |
|---|---|---|
| 1 | 统一监控Raptor | 实时上报请求调用信息、系统指标，负责应用层（JVM）监控、系统层（CPU、IO、网络）监控 |
| 2 | 链路追踪Mtrace | 负责全链路参数透传、全链路追踪监控 |
| 3 | 日志监控Logscan | 监控本地日志异常关键字：如5xx状态码、空指针异常等 |
| 4 | 远程日志中心 | API请求日志、Debug日志、组件日志等可上报远程日志中心 |
| 5 | 健康检查Scanner | 对网关节点进行心跳检测和API状态检测，及时发现异常节点和异常API |
有了全面的监控体系，自然少不了配套的告警机制，主要的告警能力包括：
| 告警类型 | 触发时机 | |
|---|---|---|
| 1 | 限流告警 | API请求达到限流规则阈值触发限流告警 |
| 2 | 请求失败告警 | 鉴权失败、请求超时、后端服务异常等触发请求失败告警 |
| 3 | 组件异常告警 | 自定义组件处理耗时长、失败率高告警 |
| 4 | API异常告警 | API发布失败、API检查异常时触发API异常告警 |
| 5 | 健康检查失败告警 | API心跳检查失败、网关节点不通时触发健康检查失败告警 |
基于Netty实现异步外调主要有两种方式可以实现：
方式一需要独立维护一个全局映射表，同时需要考虑请求超时和丢失的情况，否则会出现内存不断增长问题。
使用Netty实现API网关外调微服务时，因建立连接需要极度消耗资源，所以需要考虑将外调的链接进行池化管理，设计时需要注意以下几点：
http的链接是独占的，所以在释放的时候要特别小心，一定要等服务端响应完了才能释放，还有就是链接关闭的处理也要小心，总结如下几点：
Connection:close
空闲超时，关闭链接
读超时关闭链接
写超时，关闭链接
Fin，Reset
写超时：writeAndFlush包含Netty的encode时间和从队列里把请求发出去即flush的时间。因此后端超时开始需要在真正flush成功后开始计时，这样才最接近服务端超时时间（还有网络往返时间和内核协议栈处理时间）
针对高并发系统，频繁创建对象不仅有分配内存开销，还对gc会造成压力。因此在实现时，会对频繁使用的对象（如线程池的任务task，StringBuffer等）进行重写，减少频繁的申请内存的开销。
整个网关没有涉及到IO操作，但在IO编解码和业务逻辑都用了异步，是有两个原因
在突发的情况下，但是我们在push线程时，支持用Netty的IO线程替代，这里做的工作比较少，这里由异步修改为同步后（通过修改配置调整），CPU的上下文切换减少20%，进而提高了整体的吞吐量，就是不能为了异步而异步，Zuul2的设计类似。
协议层
应用层
访问地址：https://github.com/Kong/kong
访问地址：https://github.com/Dromara/soul
访问地址：https://apiman.gitbooks.io/apiman-user-guide/user-guide/gateway/policies.html
访问地址：https://docs.gravitee.io/apim_policies_latency.html
访问地址：https://tyk.io/docs
访问地址：https://traefik.cn
Træfɪk 是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。
功能特性
小豹API网关（企业级API网关），统一解决：认证、鉴权、安全、流量管控、缓存、服务路由，协议转换、服务编排、熔断、灰度发布、监控报警等。
为了实现服务编排，需要定义一个数据结构来描述服务之间的依赖关系、调用顺序、调用服务的入参和出参等等。之后对获取的结果进行处理，也需要在这个数据结构中具体描述对什么样的数据进行怎么样的处理等等。所以需要定义一套DSL（领域特定语言）来描述整个服务编排的蓝图。
主要特点如下：
什么是服务降级？当服务器压力剧增的情况下，可以将一些不重要或不紧急服务暂停使用或延迟使用，从而释放服务器资源以保证核心服务的正常运作或高效运作。服务降级的设计架构图如下：
服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。
熔断机制是应对雪崩效应的一种微服务链路保护机制。当链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。服务断路器的设计架构图如下：
服务调用方为每一个调用服务 (调用路径) 维护一个状态机，在这个状态机中有3种状态：
CLOSED：默认状态。断路器观察到请求失败比例没有达到阈值，断路器认为被代理服务状态良好OPEN：断路器观察到请求失败比例已经达到阈值，断路器认为被代理服务故障，打开开关，请求不再到达被代理的服务，而是快速失败HALF OPEN：断路器打开后，为了能自动恢复对被代理服务的访问，会切换到半开放状态，去尝试请求被代理服务以查看服务是否已经故障恢复。如果成功，会转成CLOSED状态，否则转到OPEN状态使用断路器需要考虑一些问题：
HALF OPEN进行重试connection timeout造成的熔断，可以用异步线程进行网络检测，比如telenet，检测到网络畅通时切换到HALF OPEN进行重试read timeout会比较长，防止客户端大量重试请求导致的连接、线程资源不能释放
NDC（Nested Diagnostic Context）和MDC（Mapped Diagnostic Context）是log4j种非常有用的两个类，它们用于存储应用程序的上下文信息（Context Infomation），从而便于在log中使用这些上下文信息。NDC采用了一个类似栈的机制来push和pop上下文信息，每一个线程都独立地储存上下文信息。比如说一个servlet就可以针对每一个request创建对应的NDC，储存客户端地址等等信息。MDC和NDC非常相似，所不同的是MDC内部使用了类似map的机制来存储信息，上下文信息也是每个线程独立地储存，所不同的是信息都是以它们的key值存储在”map”中。
NDC和MDC的原理是用了java的ThreadLocal类。可以针对不同线程存储信息。但是今天在log4j2上使用时发现没有找到NDC和MDC。查找官方文档，原来是换成了ThreadContext。
微服务架构中的链路追踪主要是用于快速定位故障点，使用MDC方式来将每一笔交易产生的所有日志都添加上请求ID，从而只需要该ID即可将整个架构中的所有有关日志收集至一出进行分析定位具体问题。
NDC采用栈的机制存储上下文，线程独立的，子线程会从父线程拷贝上下文。其调用方法以下：
开始调用
NDC.push(message);
删除栈顶消息
NDC.pop();
清除所有的消息，必须在线程退出前显示的调用，不然会致使内存溢出。
NDC.remove();
输出模板，注意是小写的 [%x]
log4j.appender.stdout.layout.ConversionPattern=[%d{yyyy-MM-dd HH:mm:ssS}] [%x] : %m%n
MDC采用Map的方式存储上下文，线程独立的，子线程会从父线程拷贝上下文。其调用方法以下：
保存信息到上下文
MDC.put(key, value);
从上下文获取设置的信息
MDC.get(key);
清楚上下文中指定的key的信息
MDC.remove(key);
清除全部
clear();
输出模板，注意是大写 [%X{key}]
log4j.appender.consoleAppender.layout.ConversionPattern = %-4r [%t] %5p %c %x - %m - %X{key}%n
在 log4j 1.x 中 MDC 的使用方式如下：
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
try {
// 填充数据
MDC.put(Contents.REQUEST_ID, UUID.randomUUID().toString());
chain.doFilter(request, response);
} finally {
// 请求结束时清除数据，否则会造成内存泄露问题
MDC.remove(Contents.REQUEST_ID);
}
}
在 log4j 2.x 中，使用 ThreadContext 代替了 MDC 和 NDC，使用方式如下：
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
try {
// 填充数据
ThreadContext.put(Contents.REQUEST_ID, UUID.randomUUID().toString());
chain.doFilter(request, response);
} finally {
// 请求结束时清除数据，否则会造成内存泄露问题
ThreadContext.remove(Contents.REQUEST_ID);
}
}
%X ：打印Map中的所有信息%X{key} ：打印指定的信息%x ：打印堆栈中的所有信息打印日志的格式案例如下：
<PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %X{REQUEST_ID} %logger{36} - %msg%n" />
在全链路跟踪框架中，Trace信息的传递功能是基于ThreadLocal的。但实际业务中可能会使用异步调用，这样就会丢失Trace信息，破坏了链路的完整性。
InheritableThreadLocal 是 JDK 本身自带的一种线程传递解决方案。顾名思义，由当前线程创建的线程，将会继承当前线程里 ThreadLocal 保存的值。Thread内部为InheritableThreadLocal开辟了一个单独的ThreadLocalMap。在父线程创建一个子线程的时候，会检查这个ThreadLocalMap是否为空，不为空则会浅拷贝给子线程的ThreadLocalMap。
Transmittable ThreadLocal是阿里开源的库，继承了InheritableThreadLocal，优化了在使用线程池等会池化复用线程的情况下传递ThreadLocal的使用。简单来说，有个专门的TtlRunnable和TtlCallable包装类，用于读取原Thread的ThreadLocal对象及值并存于Runnable/Callable中，在执行run或者call方法的时候再将存于Runnable/Callable中的ThreadLocal对象和值读取出来，存入调用run或者call的线程中。
Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。
在服务运行的过程中会产生很多链路信息，产生数据的地方可以称之为Reporter。将链路信息通过多种传输方式如HTTP，RPC，kafka消息队列等发送到Zipkin的采集器，Zipkin处理后最终将链路信息保存到存储器中。运维人员通过UI界面调用接口即可查询调用链信息。
Zipkin有四大核心组件
Collector
一旦Collector采集线程获取到链路追踪数据，Zipkin就会对其进行验证、存储和索引，并调用存储接口保存数据，以便进行查找。
Storage
Zipkin Storage最初是为了在Cassandra上存储数据而构建的，因为Cassandra是可伸缩的，具有灵活的模式，并且在Twitter中大量使用。除了Cassandra，还支持支持ElasticSearch和MySQL存储，后续可能会提供第三方扩展。
Query Service
链路追踪数据被存储和索引之后，webui 可以调用query service查询任意数据帮助运维人员快速定位线上问题。query service提供了简单的json api来查找和检索数据。
Web UI
Zipkin 提供了基本查询、搜索的web界面，运维人员可以根据具体的调用链信息快速识别线上问题。
场景一：前端重复提交
用户注册，用户创建商品等操作，前端都会提交一些数据给后台服务，后台需要根据用户提交的数据在数据库中创建记录。如果用户不小心多点了几次，后端收到了好几次提交，这时就会在数据库中重复创建了多条记录。这就是接口没有幂等性带来的 bug。
场景二：黑客拦截重放
接口请求参数被黑客拦截，然后进行重放。
场景三：接口超时重试
对于给第三方调用的接口，有可能会因为网络原因而调用失败，这时，一般在设计的时候会对接口调用加上失败重试的机制。如果第一次调用已经执行了一半时，发生了网络异常。这时再次调用时就会因为脏数据的存在而出现调用异常。
场景四：消息重复消费
在使用消息中间件来处理消息队列，且手动 ack 确认消息被正常消费时。如果消费者突然断开连接，那么已经执行了一半的消息会重新放回队列。当消息被其他消费者重新消费时，如果没有幂等性，就会导致消息重复消费时结果异常，如数据库重复数据，数据库数据冲突，资源重复等。
通过token机制实现接口的幂等性,这是一种比较通用性的实现方法。示意图如下：
具体流程步骤：
注意：
设计Token
这种实现方式是利用 mysql 唯一索引的特性。示意图如下：
具体流程步骤：
这种实现方式是基于 SETNX 命令实现的 SETNX key value：将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作。该命令在设置成功时返回 1，设置失败时返回 0。示意图如下：
具体流程步骤：
第一阶段：只要客户端请求有唯一的请求编号，那么就能借用Redis做这个去重：只要这个唯一请求编号在Redis存在，证明处理过，那么就认为是重复的。
第二阶段：但很多的场景下，请求并不会带这样的唯一编号。先考虑简单的场景，假设请求参数只有一个字段reqParam，我们可以利用以下标识去判断这个请求是否重复：用户ID:接口名:请求参数 。
第三阶段：但我们的接口通常不是这么简单，参数通常是一个JSON。假设我们把请求参数（JSON）按KEY做升序排序，排序后拼成一个字符串作为KEY值，但这可能非常的长，所以可以考虑对这个字符串求一个MD5作为参数的摘要，以这个摘要去取代reqParam的位置。
String KEY = "user_opt:U="+userId + "M=" + method + "P=" + reqParamMD5;
第四阶段：上面的问题其实已经是一个很不错的解决方案了，但是实际投入使用的时候可能发现有些问题：某些请求用户短时间内重复的点击了（例如1000毫秒发送了三次请求），但绕过了上面的去重判断（不同的KEY值）。原因是这些请求参数的字段里面，是带时间字段的，这个字段标记用户请求的时间，服务端可以借此丢弃掉一些老的请求（例如5秒前）。
总结
将业务参数（Query+Body）按KEY（排除时间字段和经纬度字段）做升序排序，排序后将按Query方式逐一拼接成参数字符串，然后将这个字符串进行MD5摘要计算，然后使用以下规则进行KEY值计算：
String KEY = "前缀标识:U=" + <用户唯一标识> + "M=" + <接口唯一标识> + "P=" + <业务参数MD5签名>;
分布式ID的两大核心需求：
基于 UUID 实现全球唯一的ID。用作订单号UUID这样的字符串没有丝毫的意义，看不出和订单相关的有用信息；而对于数据库来说用作业务主键ID，它不仅是太长还是字符串，存储性能差查询也很耗时，所以不推荐用作分布式ID。
优点
缺点
UUID 的无序性会导致数据位置频繁变动，严重影响性能适用场景
基于数据库的 auto_increment 自增ID完全可以充当 分布式ID 。当我们需要一个ID的时候，向表中插入一条记录返回主键ID，但这种方式有一个比较致命的缺点，访问量激增时MySQL本身就是系统的瓶颈，用它来实现分布式服务风险比较大，不推荐。相关SQL如下：
CREATE DATABASE `SEQ_ID`;
CREATE TABLE SEQID.SEQUENCE_ID (
id bigint(20) unsigned NOT NULL auto_increment,
value char(10) NOT NULL default '',
PRIMARY KEY (id),
) ENGINE=MyISAM;
insert into SEQUENCE_ID(value) VALUES ('values');
优点
缺点
适用场景
单点数据库方式不可取，那对上述的方式做一些高可用优化，换成主从模式集群。一个主节点挂掉没法用，那就做双主模式集群，也就是两个Mysql实例都能单独的生产自增ID。
问题：如果两个MySQL实例的自增ID都从1开始，会生成重复的ID怎么办？
解决方案：设置起始值和自增步长
MySQL_1 配置：
set @@auto_increment_offset = 1; -- 起始值
set @@auto_increment_increment = 2; -- 步长
-- 自增ID分别为：1、3、5、7、9 ......
MySQL_2 配置：
set @@auto_increment_offset = 2; -- 起始值
set @@auto_increment_increment = 2; -- 步长
-- 自增ID分别为：2、4、6、8、10 ......
那如果集群后的性能还是扛不住高并发咋办？则进行MySQL扩容增加节点：
从上图可以看出，水平扩展的数据库集群，有利于解决数据库单点压力的问题，同时为了ID生成特性，将自增步长按照机器数量来设置。增加第三台MySQL实例需要人工修改一、二两台MySQL实例的起始值和步长，把第三台机器的ID起始生成位置设定在比现有最大自增ID的位置远一些，但必须在一、二两台MySQL实例ID还没有增长到第三台MySQL实例的起始ID值的时候，否则自增ID就要出现重复了，必要时可能还需要停机修改。
优点
缺点
适用场景
这种方案，除了难以适应大规模分布式和高并发的场景，普通的业务规模还是能够胜任的，所以这种方案还是值得积累。
号段模式是当下分布式ID生成器的主流实现方式之一，可以理解为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，具体的业务服务将本号段，生成1~1000的自增ID并加载到内存。表结构如下：
CREATE TABLE id_generator (
id int(10) NOT NULL,
max_id bigint(20) NOT NULL COMMENT '当前最大id',
step int(20) NOT NULL COMMENT '号段的步长',
biz_type int(20) NOT NULL COMMENT '业务类型',
version int(20) NOT NULL COMMENT '版本号',
PRIMARY KEY (`id`)
)
biz_type ：代表不同业务类型
max_id ：当前最大的可用id
step ：代表号段的长度
version ：是一个乐观锁，每次都更新version，保证并发时数据的正确性
| id | biz_type | max_id | step | version |
|---|---|---|---|---|
| 1 | 101 | 1000 | 2000 | 0 |
等这批号段ID用完，再次向数据库申请新号段，对max_id字段做一次update操作，update max_id= max_id + step，update成功则说明新号段获取成功，新的号段范围是(max_id ,max_id +step]。
update id_generator set max_id=max_id+${step}, version = version+1 where version=${version} and biz_type=${XXX}
由于多业务端可能同时操作，所以采用版本号version乐观锁方式更新，这种分布式ID生成方式不强依赖于数据库，不会频繁的访问数据库，对数据库的压力小很多。
Redis也同样可以实现，原理就是利用redis的 incr命令实现ID的原子性自增。
# 初始化自增ID为1
127.0.0.1:6379> set seq_id 1
OK
# 增加1，并返回递增后的数值
127.0.0.1:6379> incr seq_id
(integer) 2
用redis实现需要注意一点，要考虑到redis持久化的问题。redis有两种持久化方式RDB和AOF：
RDB：会定时打一个快照进行持久化，假如连续自增但redis没及时持久化，而这会redis挂掉了，重启redis后会出现ID重复的情况AOF：会对每条写命令进行持久化，即使Redis挂掉了也不会出现ID重复的情况，但由于incr命令的特殊性，会导致Redis重启恢复的数据时间过长优点
缺点
适用场景
Redis的方案其实可靠性有待考究，毕竟依赖于网络，延时故障或者宕机都可能导致服务不可用，这种风险是不得不考虑在系统设计内的。
雪花算法（Snowflake）是Twitter公司内部分布式项目采用的ID生成算法，开源后广受国内大厂的好评，在该算法影响下各大公司相继开发出各具特色的分布式生成器。
Snowflake生成的是Long类型的ID，一个Long类型占8个字节，每个字节占8比特，也就是说一个Long类型占64个比特。Snowflake ID组成结构：正数位（占1比特）+ 时间戳（占41比特）+ 机器ID（占5比特）+ 数据中心（占5比特）+ 自增值（占12比特），总共64比特组成的一个Long类型。
workId，这个可以灵活配置，机房或者机器号组合都可以优点
缺点
适用场景
uid-generator是基于Snowflake算法实现的，与原始的snowflake算法不同在于，uid-generator支持自定义时间戳、工作机器ID和 序列号 等各部分的位数，而且uid-generator中采用用户自定义workId的生成策略。
uid-generator需要与数据库配合使用，需要新增一个WORKER_NODE表。当应用启动时会向数据库表中去插入一条数据，插入成功后返回的自增ID就是该机器的workId数据由host，port组成。
对于uid-generator ID组成结构：
workId占用了22个bit位，时间占用了28个bit位，序列化占用了13个bit位。这里的时间单位是秒，而不是毫秒，workId也不一样，而且同一应用每次重启就会消费一个workId。
Leaf同时支持号段模式和snowflake算法模式，可以切换使用。
在建一张表leaf_alloc：
DROP TABLE IF EXISTS `leaf_alloc`;
CREATE TABLE `leaf_alloc` (
`biz_tag` varchar(128) NOT NULL DEFAULT '' COMMENT '业务key',
`max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '当前已经分配了的最大id',
`step` int(11) NOT NULL COMMENT '初始步长，也是动态调整的最小步长',
`description` varchar(256) DEFAULT NULL COMMENT '业务key的描述',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '数据库维护的更新时间',
PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;
test_tag在第一台Leaf机器上是11000的号段，当这个号段用完时，会去加载另一个长度为step=1000的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是30014000。同时数据库对应的biz_tag这条数据的max_id会从3000被更新成4000，更新号段的SQL语句如下：
Begin
UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
Commit
优点
缺点
双buffer优化
针对第二个缺点是因为在号段用完后才会出现，因此可以在消耗完前提前获取下一个号段，从而解决问题：
采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复：
Leaf高可用容灾
对于第三点“DB可用性”问题，采用一主两从的方式，同时分机房部署，Master和Slave之间采用半同步方式同步数据。
Leaf-segment方案可以生成趋势递增的ID，同时ID号是可计算的，不适用于订单ID生成场景，比如竞对在两天中午12点分别下单，通过订单id号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，我们提供了 Leaf-snowflake方案。Leaf-snowflake方案完全沿用snowflake方案的bit位设计，即是“1+41+10+12”的方式组装ID号。对于workerID的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf服务规模较大，动手配置成本太高。所以使用Zookeeper持久顺序节点的特性自动对snowflake节点配置wokerID。Leaf-snowflake是按照下面几个步骤启动的：
Tinyid是基于号段模式原理实现的与Leaf如出一辙，每个服务获取一个号段（1000,2000]、（2000,3000]、（3000,4000]
Tinyid提供http和tinyid-client两种方式接入。
第一步：导入Tinyid源码
git clone https://github.com/didi/tinyid.git
第二步：创建数据表
-- 建表SQL
CREATE TABLE `tiny_id_info` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '业务类型，唯一',
`begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '开始id，仅记录初始值，无其他含义。初始化时begin_id和max_id应相同',
`max_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '当前最大id',
`step` int(11) DEFAULT '0' COMMENT '步长',
`delta` int(11) NOT NULL DEFAULT '1' COMMENT '每次id增量',
`remainder` int(11) NOT NULL DEFAULT '0' COMMENT '余数',
`create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间',
`update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间',
`version` bigint(20) NOT NULL DEFAULT '0' COMMENT '版本号',
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_biz_type` (`biz_type`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'id信息表';
CREATE TABLE `tiny_id_token` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
`token` varchar(255) NOT NULL DEFAULT '' COMMENT 'token',
`biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '此token可访问的业务类型标识',
`remark` varchar(255) NOT NULL DEFAULT '' COMMENT '备注',
`create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间',
`update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'token信息表';
-- 添加tiny_id_info
INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`) VALUES (1, 'test', 1, 1, 100000, 1, 0, '2018-07-21 23:52:58', '2018-07-22 23:19:27', 1);
INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`) VALUES(2, 'test_odd', 1, 1, 100000, 2, 1, '2018-07-21 23:52:58', '2018-07-23 00:39:24', 3);
-- 添加tiny_id_token
INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`) VALUES(1, '0f673adf80504e2eaa552f5d791b644c', 'test', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');
INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`) VALUES(2, '0f673adf80504e2eaa552f5d791b644c', 'test_odd', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');
第三步：配置数据库
datasource.tinyid.names=primary
datasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.primary.url=jdbc:mysql://ip:port/databaseName?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.primary.username=root
datasource.tinyid.primary.password=123456
第四步：启动tinyid-server后测试
# 获取分布式自增ID
http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'
返回结果: 3
# 批量获取分布式自增ID
http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'
返回结果: 4,5,6,7,8,9,10,11,12,13
第一步：引入依赖
<dependency>
<groupId>com.xiaoju.uemc.tinyid</groupId>
<artifactId>tinyid-client</artifactId>
<version>${tinyid.version}</version>
</dependency>
第二步：配置文件
tinyid.server =localhost:9999
tinyid.token =0f673adf80504e2eaa552f5d791b644c
第三步：test 、tinyid.token是在数据库表中预先插入数据，test 是具体业务类型，tinyid.token表示可访问的业务类型
// 获取单个分布式自增ID
Long id = TinyId . nextId( " test " );
// 按需批量分布式自增ID
List< Long > ids = TinyId . nextId( " test " , 10 );
何为分布式锁？
分布式锁的特点
三种方案对比
insert)实现记录锁的乐观锁方案。基于数据库的实现方式的核心思想是：在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。
优点
缺点
DROP TABLE IF EXISTS `method_lock`;
CREATE TABLE `method_lock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
`lock_key` varchar(64) NOT NULL DEFAULT '' COMMENT '锁的键值',
`lock_timeout` datetime NOT NULL DEFAULT NOW() COMMENT '锁的超时时间',
`remarks` varchar(255) NOT NULL COMMENT '备注信息',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uidx_lock_key` (`lock_key`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';
① 获取锁：想要执行某个方法，就使用这个方法名向表中插入数据
INSERT INTO method_lock (lock_key, lock_timeout, remarks) VALUES ('methodName', '2021-07-19 18:20:00', '测试的methodName');
② 释放锁：释放锁的时候就删除记录
DELETE FROM method_lock WHERE lock_key ='methodName';
版本号对比更新的乐观锁方案。一般是通过为数据库表添加一个 version 字段来实现读取出数据时，将此版本号一同读出。之后更新时，对此版本号加 1，在更新过程中，会对版本号进行比较，如果是一致的，没有发生改变，则会成功执行本次操作；如果版本号不一致，则会更新失败。实际就是个CAS过程。
缺点
for update)实现基于排它锁的悲观锁方案。通过在select语句后增加for update来获取锁，数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁，我们可以认为获得排它锁的线程即可获得分布式锁。释放锁通过connection.commit();操作，提交事务来实现。
优点
缺点
建表脚本
CREATE TABLE `methodLock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
`lock_key` varchar(64) NOT NULL DEFAULT '' COMMENT '锁的键值',
`lock_timeout` datetime NOT NULL DEFAULT NOW() COMMENT '锁的超时时间',
`remarks` varchar(255) NOT NULL COMMENT '备注信息',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY ( `id` ),
UNIQUE KEY `uidx_lock_key` ( `lock_key ` ) USING BTREE
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '锁定中的方法';
加解锁操作
/**
* 加锁
*/
public boolean lock() {
// 开启事务
connection.setAutoCommit(false);
// 循环阻塞，等待获取锁
while (true) {
// 执行获取锁的sql
String sql = "select * from methodLock where lock_key = xxx for update";
// 创建prepareStatement对象，用于执行SQL
ps = conn.prepareStatement(sql);
// 获取查询结果集
int result = ps.executeQuery();
// 结果非空，加锁成功
if (result != null) {
return true;
}
}
// 加锁失败
return false;
}
/**
* 解锁
*/
public void unlock() {
// 提交事务，解锁
connection.commit();
}
加锁操作和后面的设置超时时间是分开的，并非原子操作。解决方案：
方案一：set命令
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
在redis中还有set命令是原子操作，加锁和设置超时时间，一个命令就能轻松搞定。其中：
lockKey：锁的标识requestId：请求idNX：只在键不存在时，才对键进行设置操作PX：设置键的过期时间为 millisecond 毫秒expireTime：过期时方案二：LUA脚本
if (redis.call('exists', KEYS[1]) == 0) then
redis.call('hset', KEYS[1], ARGV[2], 1);
redis.call('pexpire', KEYS[1], ARGV[1]);
return nil;
end
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1)
redis.call('hincrby', KEYS[1], ARGV[2], 1);
redis.call('pexpire', KEYS[1], ARGV[1]);
return nil;
end
return redis.call('pttl', KEYS[1]);
加锁之后，每次都要达到了超时时间才释放锁，不会有点不合理。如果不及时释放锁，会有很多问题。合理流程如下：
释放锁的伪代码如下：
try{
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
} finally {
unlock(lockKey);
}
自己只能释放自己加的锁，不允许释放别人加的锁。
方案一：requestId方案
伪代码如下：
if (jedis.get(lockKey).equals(requestId)) {
jedis.del(lockKey);
return true;
}
return false;
方案二：LUA脚本方案
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
end
在秒杀场景下，会有什么问题？每1万个同时请求，有1个成功。再1万个同时请求，有1个成功。如此下去，直到库存不足。这就变成均匀分布的秒杀了，跟我们想象中的不一样（应该是谁先来谁得到）。
解决方案：自旋锁
在规定的时间，比如500毫秒内，自旋不断尝试加锁（说白了，就是在死循环中，不断尝试加锁），如果成功则直接返回。如果失败，则休眠50毫秒，再发起新一轮的尝试。如果到了超时时间，还未加锁成功，则直接返回失败。
try {
Long start = System.currentTimeMillis();
while(true) {
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
// 创建订单
createOrder();
return true;
}
long time = System.currentTimeMillis() - start;
if (time>=timeout) {
return false;
}
try {
Thread.sleep(50);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
} finally{
unlock(lockKey,requestId);
}
return false;
假设需要获取一颗满足条件的菜单树。需要在接口中从根节点开始，递归遍历出所有满足条件的子节点，然后组装成一颗菜单树。在后台系统中运营同学可以动态添加、修改和删除菜单。为了保证在并发的情况下，每次都可能获取最新的数据，这里可以加redis分布式锁。在递归方法中递归遍历多次，每次都是加的同一把锁。递归第一层当然是可以加锁成功的，但递归第二层、第三层...第N层，不就会加锁失败了？
递归方法中加锁的伪代码（会出现异常）如下：
private int expireTime = 1000;
public void fun(int level,String lockKey,String requestId){
try{
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
if(level<=10){
this.fun(++level,lockKey,requestId);
} else {
return;
}
}
return;
} finally {
unlock(lockKey,requestId);
}
}
基于Redisson实现可重入锁
伪代码如下：
private int expireTime = 1000;
public void run(String lockKey) {
RLock lock = redisson.getLock(lockKey);
this.fun(lock,1);
}
public void fun(RLock lock,int level){
try{
lock.lock(5, TimeUnit.SECONDS);
if(level<=10){
this.fun(lock,++level);
} else {
return;
}
} finally {
lock.unlock();
}
}
如果有大量需要写入数据的业务场景，使用普通的redis分布式锁是没有问题的。但如果有些业务场景，写入的操作比较少，反而有大量读取的操作。这样直接使用普通的redis分布式锁，会不会有点浪费性能？
读写锁
读写锁的特点：
我们以redisson框架为例，它内部已经实现了读写锁的功能。读锁的伪代码如下：
RReadWriteLock readWriteLock = redisson.getReadWriteLock("readWriteLock");
RLock rLock = readWriteLock.readLock();
try {
rLock.lock();
//业务操作
} catch (Exception e) {
log.error(e);
} finally {
rLock.unlock();
}
写锁的伪代码如下：
RReadWriteLock readWriteLock = redisson.getReadWriteLock("readWriteLock");
RLock rLock = readWriteLock.writeLock();
try {
rLock.lock();
//业务操作
} catch (InterruptedException e) {
log.error(e);
} finally {
rLock.unlock();
}
将读锁和写锁分开，最大的好处是提升读操作的性能，因为读和读之间是共享的，不存在互斥性。而我们的实际业务场景中，绝大多数数据操作都是读操作。所以，如果提升了读操作的性能，也就会提升整个锁的性能。
锁分段
此外，为了减小锁的粒度，比较常见的做法是将大锁：分段。
比如在秒杀扣库存的场景中，现在的库存中有2000个商品，用户可以秒杀。为了防止出现超卖的情况，通常情况下，可以对库存加锁。如果有1W的用户竞争同一把锁，显然系统吞吐量会非常低。
为了提升系统性能，我们可以将库存分段，比如：分为100段，这样每段就有20个商品可以参与秒杀。
在秒杀的过程中，先把用户id获取hash值，然后除以100取模。模为1的用户访问第1段库存，模为2的用户访问第2段库存，模为3的用户访问第3段库存，后面以此类推，到最后模为100的用户访问第100段库存。
注意：将锁分段虽说可以提升系统的性能，但它也会让系统的复杂度提升不少。因为它需要引入额外的路由算法，跨段统计等功能。我们在实际业务场景中，需要综合考虑，不是说一定要将锁分段。
如果线程A加锁成功了，但是由于业务功能耗时时间很长，超过了设置的超时时间，这时候redis会自动释放线程A加的锁。
解决方案：自动续期
自动续期的功能是获取锁之后开启一个定时任务，每隔10秒判断一下锁是否存在，如果存在，则刷新过期时间。如果续期3次，也就是30秒之后，业务方法还是没有执行完，就不再续期了。
我们可以使用TimerTask类，来实现自动续期的功能：
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run(Timeout timeout) throws Exception {
//自动续期逻辑
}
}, 10000, TimeUnit.MILLISECONDS);
获取锁之后，自动开启一个定时任务，每隔10秒钟，自动刷新一次过期时间。这种机制在redisson框架中，有个比较霸气的名字：watch dog，即传说中的看门狗。当然自动续期功能，我们还是优先推荐使用lua脚本实现，比如：
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
redis.call('pexpire', KEYS[1], ARGV[1]);
return 1;
end;
return 0;
需要：在实现自动续期功能时，还需要设置一个总的过期时间，可以跟redisson保持一致，设置成30秒。如果业务代码到了这个总的过期时间，还没有执行完，就不再自动续期了。
如果redis存在多个实例。比如：做了主从或使用了哨兵模式，基于redis的分布式锁的功能，就会出现问题。
比如锁A刚加锁成功master就挂了，还没来得及同步到slave上。这样会导致新master节点中的锁A丢失了。后面，如果有新的线程，使用锁A加锁，依然可以成功，分布式锁失效了。
解决方案：RedissonRedLock
RedissonRedLock解决问题的思路如下：
在这里我们以主从为例，架构图如下：
RedissonRedLock加锁过程如下：
从上面可以看出，使用Redlock算法，确实能解决多实例场景中，假如master节点挂了，导致分布式锁失效的问题。但也引出了一些新问题，比如：
场景选择
在实际业务场景，尤其是高并发业务中，RedissonRedLock其实使用的并不多。在分布式环境中，CAP是绕不过去的：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
如果你的实际业务场景，更需要的是保证数据一致性，那么请使用CP类型的分布式锁
比如：zookeeper，它是基于磁盘的，性能可能没那么好，但数据一般不会丢
如果你的实际业务场景，更需要的是保证数据高可用性。那么请使用AP类型的分布式锁
比如：redis，它是基于内存的，性能比较好，但有丢失数据的风险
其实，在绝大多数分布式业务场景中，使用redis分布式锁就够了，真的别太较真。因为数据不一致问题，可以通过最终一致性方案解决。但如果系统不可用了，对用户来说是暴击一万点伤害。
先用setnx来抢锁，如果抢到之后，再用expire给锁设置一个过期时间，防止锁忘记了释放。
setnx(key, value)
setnx 的含义就是 SET if Not Exists，该方法是原子的。如果 key 不存在，则设置当前 key 为 value 成功，返回 1；如果当前 key 已经存在，则设置当前 key 失败，返回 0。
expire(key, seconds)
expire 设置过期时间，要注意的是 setnx 命令不能设置 key 的超时时间，只能通过 expire() 来对 key 设置。
使用Lua脚本(SETNX+EXPIRE)
可以使用Lua脚本来保证原子性（包含setnx和expire两条指令），加解锁代码如下：
/**
* 使用Lua脚本，脚本中使用setnex+expire命令进行加锁操作
*/
public boolean lock(Jedis jedis, String key, String uniqueId, int seconds) {
String luaScript = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
"redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";
Object result = jedis.eval(luaScript, Collections.singletonList(key),
Arrays.asList(uniqueId, String.valueOf(seconds)));
return result.equals(1L);
}
/**
* 使用Lua脚本进行解锁操纵，解锁的时候验证value值
*/
public boolean unlock(Jedis jedis, String key, String value) {
String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then " +
"return redis.call('del',KEYS[1]) else return 0 end";
return jedis.eval(luaScript, Collections.singletonList(key), Collections.singletonList(value)).equals(1L);
}
STW
如果在写文件过程中，发生了 FullGC，并且其时间跨度较长， 超过了锁超时的时间， 那么分布式就自动释放了。在此过程中，client2 抢到锁，写了文件。client1 的FullGC完成后，也继续写文件，注意，此时 client1 的并没有占用锁，此时写入会导致文件数据错乱，发生线程安全问题。这就是STW导致的锁过期问题。STW导致的锁过期问题，如下图所示：
STW导致的锁过期问题，大概的解决方案有：
方案一： 模拟CAS乐观锁的方式，增加版本号（如下图中的token）
此方案如果要实现，需要调整业务逻辑，与之配合，所以会入侵代码。
方案二：watch dog自动延期机制
客户端1加锁的锁key默认生存时间才30秒，如果超过了30秒，客户端1还想一直持有这把锁，怎么办呢？简单！只要客户端1一旦加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，会每隔10秒检查一下，如果客户端1还持有锁key，那么就会不断的延长锁key的生存时间。Redission采用的就是这种方案， 此方案不会入侵业务代码。
方案：SET key value [EX seconds] [PX milliseconds] [NX|XX]
EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value
PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value
NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value
XX ：只在键已经存在时，才对键进行设置操作客户端执行以上的命令：
OK ，那么这个客户端获得锁NIL ，那么客户端获取锁失败，可以在稍后再重试① 加锁：使用redis命令 set key value NX EX max-lock-time 实现加锁
Jedis jedis = new Jedis("127.0.0.1", 6379);
private static final String SUCCESS = "OK";
/**
* 加锁操作
* @param key 锁标识
* @param value 客户端标识
* @param timeOut 过期时间
*/
public Boolean lock(String key,String value,Long timeOut){
String var1 = jedis.set(key,value,"NX","EX",timeOut);
if(LOCK_SUCCESS.equals(var1)){
return true;
}
return false;
}
jedis.set(key,value,"NX","EX",timeout)【保证加锁的原子操作】key是redis的key值作为锁的标识，value在作为客户端的标识，只有key-value都比配才有删除锁的权利【保证安全性】timeout设置过期时间保证不会出现死锁【避免死锁】NX：只有这个key不存才的时候才会进行操作，if not exists
EX：设置key的过期时间为秒，具体时间由第5个参数决定，过期时间设置的合理有效期需要根据业务具体决定，总的原则是任务执行time*3
② 解锁：使用redis命令 EVAL 实现解锁
Jedis jedis = new Jedis("127.0.0.1", 6379);
private static final String SUCCESS = "OK";
/**
* 加锁操作
* @param key 锁标识
* @param value 客户端标识
* @param timeOut 过期时间
*/
public Boolean lock(String key,String value,Long timeOut){
String var1 = jedis.set(key,value,"NX","EX",timeOut);
if(LOCK_SUCCESS.equals(var1)){
return true;
}
return false;
}
③ 重试
如果在业务中去拿锁如果没有拿到是应该阻塞着一直等待还是直接返回，这个问题其实可以写一个重试机制，根据重试次数和重试时间做一个循环去拿锁，当然这个重试的次数和时间设多少合适，是需要根据自身业务去衡量的。
/**
* 重试机制
* @param key 锁标识
* @param value 客户端标识
* @param timeOut 过期时间
* @param retry 重试次数
* @param sleepTime 重试间隔时间
* @return
*/
public Boolean lockRetry(String key,String value,Long timeOut,Integer retry,Long sleepTime){
Boolean flag = false;
try {
for (int i=0;i<retry;i++){
flag = lock(key,value,timeOut);
if(flag){
break;
}
Thread.sleep(sleepTime);
}
}catch (Exception e){
e.printStackTrace();
}
return flag;
}
Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还实现了可重入锁（Reentrant Lock）、公平锁（Fair Lock、联锁（MultiLock）、 红锁（RedLock）、 读写锁（ReadWriteLock）等，还提供了许多分布式服务。
特性功能
Watch dog
总体的Redisson框架的分布式锁类型大致如下：
实现方案
添加依赖
<!-- 方式一：redisson-java -->
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.11.4</version>
</dependency>
<!-- 方式二：redisson-springboot -->
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson-spring-boot-starter</artifactId>
<version>3.11.4</version>
</dependency>
定义接口
import org.redisson.api.RLock;
import java.util.concurrent.TimeUnit;
public interface DistributedLocker {
RLock lock(String lockKey);
RLock lock(String lockKey, int timeout);
RLock lock(String lockKey, TimeUnit unit, int timeout);
boolean tryLock(String lockKey, TimeUnit unit, int waitTime, int leaseTime);
void unlock(String lockKey);
void unlock(RLock lock);
}
实现分布式锁
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import java.util.concurrent.TimeUnit;
public class RedissonDistributedLocker implements DistributedLocker{
private RedissonClient redissonClient;
@Override
public RLock lock(String lockKey) {
RLock lock = redissonClient.getLock(lockKey);
lock.lock();
return lock;
}
@Override
public RLock lock(String lockKey, int leaseTime) {
RLock lock = redissonClient.getLock(lockKey);
lock.lock(leaseTime, TimeUnit.SECONDS);
return lock;
}
@Override
public RLock lock(String lockKey, TimeUnit unit ,int timeout) {
RLock lock = redissonClient.getLock(lockKey);
lock.lock(timeout, unit);
return lock;
}
@Override
public boolean tryLock(String lockKey, TimeUnit unit, int waitTime, int leaseTime) {
RLock lock = redissonClient.getLock(lockKey);
try {
return lock.tryLock(waitTime, leaseTime, unit);
} catch (InterruptedException e) {
return false;
}
}
@Override
public void unlock(String lockKey) {
RLock lock = redissonClient.getLock(lockKey);
lock.unlock();
}
@Override
public void unlock(RLock lock) {
lock.unlock();
}
public void setRedissonClient(RedissonClient redissonClient) {
this.redissonClient = redissonClient;
}
}
高可用的RedLock（红锁）原理
RedLock算法思想是不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁，n / 2 + 1，必须在大多数redis节点上都成功创建锁，才能算这个整体的RedLock加锁成功，避免说仅仅在一个redis实例上加锁而带来的问题。
如上借助于临时顺序节点，可以避免同时多个节点的并发竞争锁，缓解了服务端压力。这种实现方式所有加锁请求都进行排队加锁，是公平锁的具体实现。Apache-Curator中提供的常见锁有如下：
import java.util.Arrays;
import java.util.Collection;
import java.util.HashSet;
import java.util.Set;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessLock;
import org.apache.curator.framework.recipes.locks.InterProcessMultiLock;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock;
import org.apache.curator.framework.recipes.locks.InterProcessSemaphoreMutex;
import org.apache.curator.framework.recipes.locks.InterProcessSemaphoreV2;
import org.apache.curator.framework.recipes.locks.Lease;
import org.apache.curator.retry.ExponentialBackoffRetry;
import org.apache.curator.utils.CloseableUtils;
import org.junit.After;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
public class DistributedLockDemo {
// ZooKeeper 锁节点路径, 分布式锁的相关操作都是在这个节点上进行
private final String lockPath = "/distributed-lock";
// ZooKeeper 服务地址, 单机格式为:(127.0.0.1:2181),
// 集群格式为:(127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183)
private String connectString="127.0.0.1:2181";
// Curator 客户端重试策略
private RetryPolicy retry;
// Curator 客户端对象
private CuratorFramework client1;
// client2 用户模拟其他客户端
private CuratorFramework client2;
// 初始化资源
@Before
public void init() throws Exception {
// 重试策略
// 初始休眠时间为 1000ms, 最大重试次数为 3
retry = new ExponentialBackoffRetry(1000, 3);
// 创建一个客户端, 60000(ms)为 session 超时时间, 15000(ms)为链接超时时间
client1 = CuratorFrameworkFactory.newClient(connectString, 60000, 15000, retry);
client2 = CuratorFrameworkFactory.newClient(connectString, 60000, 15000, retry);
// 创建会话
client1.start();
client2.start();
}
// 释放资源
@After
public void close() {
CloseableUtils.closeQuietly(client1);
}
/**
* InterProcessMutex：可重入、独占锁
*/
@Test
public void sharedReentrantLock() throws Exception {
// 创建可重入锁
InterProcessMutex lock1 = new InterProcessMutex(client1, lockPath);
// lock2 用于模拟其他客户端
InterProcessMutex lock2 = new InterProcessMutex(client2, lockPath);
// lock1 获取锁
lock1.acquire();
try {
// lock1 第2次获取锁
lock1.acquire();
try {
// lock2 超时获取锁, 因为锁已经被 lock1 客户端占用, 所以lock2获取锁失败, 需要等 lock1 释放
Assert.assertFalse(lock2.acquire(2, TimeUnit.SECONDS));
} finally {
lock1.release();
}
} finally {
// 重入锁获取与释放需要一一对应, 如果获取 2 次, 释放 1 次, 那么该锁依然是被占用,
// 如果将下面这行代码注释, 那么会发现下面的 lock2
// 获取锁失败
lock1.release();
}
// 在 lock1 释放后, lock2 能够获取锁
Assert.assertTrue(lock2.acquire(2, TimeUnit.SECONDS));
lock2.release();
}
/**
* InterProcessSemaphoreMutex： 不可重入、独占锁
*/
@Test
public void sharedLock() throws Exception {
InterProcessSemaphoreMutex lock1 = new InterProcessSemaphoreMutex(client1, lockPath);
// lock2 用于模拟其他客户端
InterProcessSemaphoreMutex lock2 = new InterProcessSemaphoreMutex(client2, lockPath);
// 获取锁对象
lock1.acquire();
// 测试是否可以重入
// 因为锁已经被获取, 所以返回 false
Assert.assertFalse(lock1.acquire(2, TimeUnit.SECONDS));// lock1 返回是false
Assert.assertFalse(lock2.acquire(2, TimeUnit.SECONDS));// lock2 返回是false
// lock1 释放锁
lock1.release();
// lock2 尝试获取锁成功, 因为锁已经被释放
Assert.assertTrue(lock2.acquire(2, TimeUnit.SECONDS));// 返回是true
lock2.release();
System.out.println("测试结束");
}
/**
* InterProcessReadWriteLock：读写锁.
* 特点：读写锁、可重入
*/
@Test
public void sharedReentrantReadWriteLock() throws Exception {
// 创建读写锁对象, Curator 以公平锁的方式进行实现
InterProcessReadWriteLock lock1 = new InterProcessReadWriteLock(client1, lockPath);
// lock2 用于模拟其他客户端
InterProcessReadWriteLock lock2 = new InterProcessReadWriteLock(client2, lockPath);
// 使用 lock1 模拟读操作
// 使用 lock2 模拟写操作
// 获取读锁(使用 InterProcessMutex 实现, 所以是可以重入的)
final InterProcessLock readLock = lock1.readLock();
// 获取写锁(使用 InterProcessMutex 实现, 所以是可以重入的)
final InterProcessLock writeLock = lock2.writeLock();
/**
* 读写锁测试对象
*/
class ReadWriteLockTest {
// 测试数据变更字段
private Integer testData = 0;
private Set<Thread> threadSet = new HashSet<>();
// 写入数据
private void write() throws Exception {
writeLock.acquire();
try {
Thread.sleep(10);
testData++;
System.out.println("写入数据 \t" + testData);
} finally {
writeLock.release();
}
}
// 读取数据
private void read() throws Exception {
readLock.acquire();
try {
Thread.sleep(10);
System.out.println("读取数据 \t" + testData);
} finally {
readLock.release();
}
}
// 等待线程结束, 防止 test 方法调用完成后, 当前线程直接退出, 导致控制台无法输出信息
public void waitThread() throws InterruptedException {
for (Thread thread : threadSet) {
thread.join();
}
}
// 创建线程方法
private void createThread(final int type) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
try {
if (type == 1) {
write();
} else {
read();
}
} catch (Exception e) {
e.printStackTrace();
}
}
});
threadSet.add(thread);
thread.start();
}
// 测试方法
public void test() {
for (int i = 0; i < 5; i++) {
createThread(1);
}
for (int i = 0; i < 5; i++) {
createThread(2);
}
}
}
ReadWriteLockTest readWriteLockTest = new ReadWriteLockTest();
readWriteLockTest.test();
readWriteLockTest.waitThread();
}
/**
* InterProcessSemaphoreV2 共享信号量
*/
@Test
public void semaphore() throws Exception {
// 创建一个信号量, Curator 以公平锁的方式进行实现
InterProcessSemaphoreV2 semaphore1 = new InterProcessSemaphoreV2(client1, lockPath, 6);
// semaphore2 用于模拟其他客户端
InterProcessSemaphoreV2 semaphore2 = new InterProcessSemaphoreV2(client2, lockPath, 6);
// 获取一个许可
Lease lease1 = semaphore1.acquire();
Assert.assertNotNull(lease1);
// semaphore.getParticipantNodes() 会返回当前参与信号量的节点列表, 俩个客户端所获取的信息相同
Assert.assertEquals(semaphore1.getParticipantNodes(), semaphore2.getParticipantNodes());
// 超时获取一个许可
Lease lease2 = semaphore2.acquire(2, TimeUnit.SECONDS);
Assert.assertNotNull(lease2);
Assert.assertEquals(semaphore1.getParticipantNodes(), semaphore2.getParticipantNodes());
// 获取多个许可, 参数为许可数量
Collection<Lease> leases = semaphore1.acquire(2);
Assert.assertTrue(leases.size() == 2);
Assert.assertEquals(semaphore1.getParticipantNodes(), semaphore2.getParticipantNodes());
// 超时获取多个许可, 第一个参数为许可数量
Collection<Lease> leases2 = semaphore2.acquire(2, 2, TimeUnit.SECONDS);
Assert.assertTrue(leases2.size() == 2);
Assert.assertEquals(semaphore1.getParticipantNodes(), semaphore2.getParticipantNodes());
// 目前 semaphore 已经获取 3 个许可, semaphore2 也获取 3 个许可, 加起来为 6 个, 所以他们无法再进行许可获取
Assert.assertNull(semaphore1.acquire(2, TimeUnit.SECONDS));
Assert.assertNull(semaphore2.acquire(2, TimeUnit.SECONDS));
// 释放一个许可
semaphore1.returnLease(lease1);
semaphore2.returnLease(lease2);
// 释放多个许可
semaphore1.returnAll(leases);
semaphore2.returnAll(leases2);
}
/**
* InterProcessMutex ：可重入、独占锁
* InterProcessSemaphoreMutex ： 不可重入、独占锁
* InterProcessMultiLock： 多重共享锁（将多个锁作为单个实体管理的容器）
*/
@Test
public void multiLock() throws Exception {
InterProcessMutex mutex = new InterProcessMutex(client1, lockPath);
InterProcessSemaphoreMutex semaphoreMutex = new InterProcessSemaphoreMutex(client2, lockPath);
//将上面的两种锁入到其中
InterProcessMultiLock multiLock = new InterProcessMultiLock(Arrays.asList(mutex, semaphoreMutex));
// 获取参数集合中的所有锁
multiLock.acquire();
// 因为存在一个不可重入锁, 所以整个 multiLock 不可重入
Assert.assertFalse(multiLock.acquire(2, TimeUnit.SECONDS));
// mutex 是可重入锁, 所以可以继续获取锁
Assert.assertTrue(mutex.acquire(2, TimeUnit.SECONDS));
// semaphoreMutex 是不可重入锁, 所以获取锁失败
Assert.assertFalse(semaphoreMutex.acquire(2, TimeUnit.SECONDS));
// 释放参数集合中的所有锁
multiLock.release();
// interProcessLock2 中的锁已经释放, 所以可以获取
Assert.assertTrue(semaphoreMutex.acquire(2, TimeUnit.SECONDS));
}
}
当系统的处理能力不能应对外部请求的突增流量时，为了不让系统奔溃，必须采取限流的措施。
限流目标：
目前主流的限流方法多采用 HPS 作为限流指标。
TPS（Transactions Per Second）是指每秒事务数。一个事务是指事务内第一个请求发送到接收到最后一个请求的响应的过程，以此来计算使用的时间和完成的事务个数。
但是对实操性来说，按照事务来限流并不现实。在分布式系统中完成一笔事务需要多个系统的配合。比如我们在电商系统购物，需要订单、库存、账户、支付等多个服务配合完成，有的服务需要异步返回，这样完成一笔事务花费的时间可能会很长。如果按照TPS来进行限流，时间粒度可能会很大大，很难准确评估系统的响应性能。
HPS（Hits Per Second）指每秒点击次数（每秒钟服务端收到客户端的请求数量）。是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和。 它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。
如果一个请求完成一笔事务，那TPS和HPS是等同的。但在分布式场景下，完成一笔事务可能需要多次请求，所以TPS和HPS指标不能等同看待。
QPS（Queries Per Second）是指每秒查询率。是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然这个不够全面，不能描述增删改，所以不建议用QPS来作为系统性能指标。
如果后台只有一台服务器，那 HPS 和 QPS 是等同的。但是在分布式场景下，每个请求需要多个服务器配合完成响应。
固定窗口计数器(Fixed Window)算法的实现思路非常简单，维护一个固定单位时间内的计数器，如果检测到单位时间已经过去就重置计数器为零。计数限首先维护一个计数器，将单位时间段当做一个窗口，计数器记录这个窗口接收请求的次数。
假设单位时间是1秒，限流阀值为3。在单位时间1秒内，每来一个请求,计数器就加1，如果计数器累加的次数超过限流阀值3，后续的请求全部拒绝。等到1s结束后，计数器清0，重新开始计数。如下图：
伪代码如下：
/**
* 固定窗口时间算法
* @return
*/
boolean fixedWindowsTryAcquire() {
long currentTime = System.currentTimeMillis(); //获取系统当前时间
if (currentTime - lastRequestTime > windowUnit) { //检查是否在时间窗口内
counter = 0; // 计数器清0
lastRequestTime = currentTime; //开启新的时间窗口
}
if (counter < threshold) { // 小于阀值
counter++; //计数器加1
return true;
}
return false;
}
存在问题
但是，这种算法有一个很明显的临界问题：假设限流阀值为5个请求，单位时间窗口是1s,如果我们在单位时间内的前0.8-1s和1-1.2s，分别并发5个请求。虽然都没有超过阀值，但是如果算0.8-1.2s,则并发数高达10，已经超过单位时间1s不超过5阀值的定义啦。
滑动窗口计数器(Sliding Window)算法限流解决固定窗口临界值的问题。它将单位时间周期分为n个小周期，分别记录每个小周期内接口的访问次数，并且根据时间滑动删除过期的小周期。
一张图解释滑动窗口算法，如下：
假设单位时间还是1s，滑动窗口算法把它划分为5个小周期，也就是滑动窗口（单位时间）被划分为5个小格子。每格表示0.2s。每过0.2s，时间窗口就会往右滑动一格。然后呢，每个小周期，都有自己独立的计数器，如果请求是0.83s到达的，0.8~1.0s对应的计数器就会加1。
我们来看下滑动窗口是如何解决临界问题的？
假设我们1s内的限流阀值还是5个请求，0.81.0s内（比如0.9s的时候）来了5个请求，落在黄色格子里。时间过了1.0s这个点之后，又来5个请求，落在紫色格子里。如果是固定窗口算法，是不会被限流的，但是滑动窗口的话，每过一个小周期，它会右移一个小格。过了1.0s这个点后，会右移一小格，当前的单位时间段是0.21.2s，这个区域的请求已经超过限定的5了，已触发限流啦，实际上，紫色格子的请求都被拒绝啦。
TIPS: 当滑动窗口的格子周期划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。
滑动窗口算法伪代码实现如下：
/**
* 单位时间划分的小周期（单位时间是1分钟，10s一个小格子窗口，一共6个格子）
*/
private int SUB_CYCLE = 10;
/**
* 每分钟限流请求数
*/
private int thresholdPerMin = 100;
/**
* 计数器, k-为当前窗口的开始时间值秒，value为当前窗口的计数
*/
private final TreeMap<Long, Integer> counters = new TreeMap<>();
/**
* 滑动窗口时间算法实现
*/
boolean slidingWindowsTryAcquire() {
long currentWindowTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC) / SUB_CYCLE * SUB_CYCLE; //获取当前时间在哪个小周期窗口
int currentWindowNum = countCurrentWindow(currentWindowTime); //当前窗口总请求数
//超过阀值限流
if (currentWindowNum >= thresholdPerMin) {
return false;
}
//计数器+1
counters.get(currentWindowTime)++;
return true;
}
/**
* 统计当前窗口的请求数
*/
private int countCurrentWindow(long currentWindowTime) {
//计算窗口开始位置
long startTime = currentWindowTime - SUB_CYCLE* (60s/SUB_CYCLE-1);
int count = 0;
//遍历存储的计数器
Iterator<Map.Entry<Long, Integer>> iterator = counters.entrySet().iterator();
while (iterator.hasNext()) {
Map.Entry<Long, Integer> entry = iterator.next();
// 删除无效过期的子窗口计数器
if (entry.getKey() < startTime) {
iterator.remove();
} else {
//累加当前窗口的所有计数器之和
count =count + entry.getValue();
}
}
return count;
}
滑动窗口算法虽然解决了固定窗口的临界问题，但是一旦到达限流后，请求都会直接暴力被拒绝。这样我们会损失一部分请求，这其实对于产品来说，并不太友好。滑动时间窗口的优点是解决了流量计数器算法的缺陷，但是也有 2 个问题：
如下图所示，水滴持续滴入漏桶中，底部定速流出。如果水滴滴入的速率大于流出的速率，当存水超过桶的大小的时候就会溢出。规则如下：
可以看到水滴对应的就是请求。它的特点就是宽进严出，无论请求多少，请求的速率有多大，都按照固定的速率流出，对应的就是服务按照固定的速率处理请求。面对突发请求，服务的处理速度和平时是一样的，这其实不是我们想要的，在面对突发流量我们希望在系统平稳的同时，提升用户体验即能更快的处理请求，而不是和正常流量一样，循规蹈矩的处理。而令牌桶在应对突击流量的时候，可以更加的“激进”。
漏桶算法伪代码实现如下：
/**
* 每秒处理数（出水率）
*/
private long rate;
/**
* 当前剩余水量
*/
private long currentWater;
/**
* 最后刷新时间
*/
private long refreshTime;
/**
* 桶容量
*/
private long capacity;
/**
* 漏桶算法
* @return
*/
boolean leakybucketLimitTryAcquire() {
long currentTime = System.currentTimeMillis(); //获取系统当前时间
long outWater = (currentTime - refreshTime) / 1000 * rate; //流出的水量 =(当前时间-上次刷新时间)* 出水率
long currentWater = Math.max(0, currentWater - outWater); // 当前水量 = 之前的桶内水量-流出的水量
refreshTime = currentTime; // 刷新时间
// 当前剩余水量还是小于桶的容量，则请求放行
if (currentWater < capacity) {
currentWater++;
return true;
}
// 当前剩余水量大于等于桶的容量，限流
return false;
}
令牌桶和漏桶的原理类似，不过漏桶是定速地流出，而令牌桶是定速地往桶里塞入令牌，然后请求只有拿到了令牌才能通过，之后再被服务器处理。当然令牌桶的大小也是有限制的，假设桶里的令牌满了之后，定速生成的令牌会丢弃。规则：
可以看出令牌桶在应对突发流量的时候，桶内假如有 100 个令牌，那么这 100 个令牌可以马上被取走，而不像漏桶那样匀速的消费。所以在应对突发流量的时候令牌桶表现的更佳。
令牌桶算法伪代码实现如下：
/**
* 每秒处理数（放入令牌数量）
*/
private long putTokenRate;
/**
* 最后刷新时间
*/
private long refreshTime;
/**
* 令牌桶容量
*/
private long capacity;
/**
* 当前桶内令牌数
*/
private long currentToken = 0L;
/**
* 漏桶算法
* @return
*/
boolean tokenBucketTryAcquire() {
long currentTime = System.currentTimeMillis(); //获取系统当前时间
long generateToken = (currentTime - refreshTime) / 1000 * putTokenRate; //生成的令牌 =(当前时间-上次刷新时间)* 放入令牌速率
currentToken = Math.min(capacity, generateToken + currentToken); // 当前令牌数量 = 之前的桶内令牌数量+放入的令牌数量
refreshTime = currentTime; // 刷新时间
//桶里面还有令牌，请求正常处理
if (currentToken > 0) {
currentToken--; //令牌数量-1
return true;
}
return false;
}
计数器限流的核心是 INCRBY 和 EXPIRE 指令，测试用例在此，通常，计数器算法容易出现不平滑的情况，瞬间的 qps 有可能超过系统的承载。
-- 获取调用脚本时传入的第一个 key 值（用作限流的 key）
local key = KEYS[1]
-- 获取调用脚本时传入的第一个参数值（限流大小）
local limit = tonumber(ARGV[1])
-- 获取计数器的限速区间 TTL
local ttl = tonumber(ARGV[2])
-- 获取当前流量大小
local curentLimit = tonumber(redis.call('get', key) or "0")
-- 是否超出限流
if curentLimit + 1 > limit then
-- 返回 (拒绝)
return 0
else
-- 没有超出 value + 1
redis.call('INCRBY', key, 1)
-- 如果 key 中保存的并发计数为 0，说明当前是一个新的时间窗口，它的过期时间设置为窗口的过期时间
if (current_permits == 0) then
redis.call('EXPIRE', key, ttl)
end
-- 返回 (放行)
return 1
end
此段 Lua 脚本的逻辑很直观：
KEYS[1] 获取传入的 key 参数，为某个限流指标的 keyARGV[1] 获取传入的 limit 参数，为限流值ARGV[2] 获取限流区间 ttlredis.call，拿到 key 对应的值（默认为 0），接着与 limit 判断，如果超出表示该被限流；否则，使用 INCRBY 增加 1，未限流（需要处理初始化的情况，设置 TTL）不过上面代码是有问题的，如果 key 之前存在且未设置 TTL，那么限速逻辑就会永远生效了（触发 limit 值之后），使用时需要注意。
令牌桶算法也是 Guava 中使用的算法，同样采用计算的方式，将时间和 Token 数目联系起来：
-- key
local key = KEYS[1]
-- 最大存储的令牌数
local max_permits = tonumber(KEYS[2])
-- 每秒钟产生的令牌数
local permits_per_second = tonumber(KEYS[3])
-- 请求的令牌数
local required_permits = tonumber(ARGV[1])
-- 下次请求可以获取令牌的起始时间
local next_free_ticket_micros = tonumber(redis.call('hget', key, 'next_free_ticket_micros') or 0)
-- 当前时间
local time = redis.call('time')
-- time[1] 返回的为秒，time[2] 为 ms
local now_micros = tonumber(time[1]) * 1000000 + tonumber(time[2])
-- 查询获取令牌是否超时（传入参数，单位为 微秒）
if (ARGV[2] ~= nil) then
-- 获取令牌的超时时间
local timeout_micros = tonumber(ARGV[2])
local micros_to_wait = next_free_ticket_micros - now_micros
if (micros_to_wait> timeout_micros) then
return micros_to_wait
end
end
-- 当前存储的令牌数
local stored_permits = tonumber(redis.call('hget', key, 'stored_permits') or 0)
-- 添加令牌的时间间隔（1000000ms 为 1s）
-- 计算生产 1 个令牌需要多少微秒
local stable_interval_micros = 1000000 / permits_per_second
-- 补充令牌
if (now_micros> next_free_ticket_micros) then
local new_permits = (now_micros - next_free_ticket_micros) / stable_interval_micros
stored_permits = math.min(max_permits, stored_permits + new_permits)
-- 补充后，更新下次可以获取令牌的时间
next_free_ticket_micros = now_micros
end
-- 消耗令牌
local moment_available = next_free_ticket_micros
-- 两种情况：required_permits<=stored_permits 或者 required_permits>stored_permits
local stored_permits_to_spend = math.min(required_permits, stored_permits)
local fresh_permits = required_permits - stored_permits_to_spend;
-- 如果 fresh_permits>0，说明令牌桶的剩余数目不够了，需要等待一段时间
local wait_micros = fresh_permits * stable_interval_micros
-- Redis 提供了 redis.replicate_commands() 函数来实现这一功能，把发生数据变更的命令以事务的方式做持久化和主从复制，从而允许在 Lua 脚本内进行随机写入
redis.replicate_commands()
-- 存储剩余的令牌数：桶中剩余的数目 - 本次申请的数目
redis.call('hset', key, 'stored_permits', stored_permits - stored_permits_to_spend)
redis.call('hset', key, 'next_free_ticket_micros', next_free_ticket_micros + wait_micros)
redis.call('expire', key, 10)
-- 返回需要等待的时间长度
-- 返回为 0（moment_available==now_micros）表示桶中剩余的令牌足够，不需要等待
return moment_available - now_micros
ngx_http_limit_req_module 模块提供限制请求处理速率能力，使用漏桶算法(leaky bucket)。使用limit_req_zone 和limit_req两个指令，限制单个IP的请求处理速率。格式：limit_req_zone key zone rate
http {
limit_req_zone $binary_remote_addr zone=testRateLimit:10m rate=10r/s;
}
server {
location /test/ {
limit_req zone=testRateLimit burst=20 nodelay;
# 设置(http,server,location)超过限流策略后拒绝请求的响应状态码，默认503
limit_req_status 555;
# 设置(http,server,location)限流策略后打印的日志级别：info|notice|warn|error
limit_req_log_level warn;
# 设置(http,server,location)启动无过滤模式。启用后不会过滤请求，但仍会记录速率超量的日志，默认为off
limit_req_dry_run off;
proxy_pass http://my_upstream;
}
error_page 555 /555json;
location = /555json {
default_type application/json;
add_header Content-Type 'text/html; charset=utf-8';
return 200 '{"code": 666, "update":"访问高峰期，请稍后再试"}';
}
}
$binary_remote_addr 表示基于 remote_addr 来做限流，binary_ 的目的是压缩内存占用量myRateLimit:10m 表示一个大小为10M，名字为myRateLimit的内存区域。1M能存储16000 IP地址的访问信息，10M可以存储16W IP地址访问信息rate=10r/s 表示每秒最多处理10个请求。Nginx 实际上以毫秒为粒度来跟踪请求信息，因此 10r/s 实际上是限制：每100毫秒处理一个请求。即上一个请求处理完后，后续100毫秒内又有请求到达，将拒绝处理该请求burst=20 表示若同时有21个请求到达，Nginx 会处理第1个请求，剩余20个请求将放入队列，然后每隔100ms从队列中获取一个请求进行处理。若请求数大于21，将拒绝处理多余的请求，直接返回503burst=20 nodelay 表示20个请求立马处理，不能延迟。不过即使这20个突发请求立马处理结束，后续来请求也不会立马处理。burst=20 相当于缓存队列中占了20个坑，即使请求被处理，这20个位置这只能按100ms一个来释放ngx_http_limit_conn_module提供了限制连接数的能力，利用limit_conn_zone和limit_conn两个指令即可。下面是Nginx官方例子：
limit_conn_zone $binary_remote_addr zone=test:10m;
limit_conn_zone $server_name zone=demo:10m;
server {
# 表示限制单个IP同时最多持有10个连接
limit_conn test 10;
# 表示虚拟主机(server) 同时能处理并发连接的总数为100个
limit_conn demo 100;
# 设置(http,server,location)超过限流策略后拒绝请求的响应状态码，默认503
limit_conn_status 555;
# 设置(http,server,location)限流策略后打印的日志级别：info|notice|warn|error
limit_conn_log_level warn;
# 设置(http,server,location)启动无过滤模式。启用后不会过滤请求，但仍会记录速率超量的日志，默认为off
limit_conn_dry_run off;
error_page 555 /555json;
location = /555json {
default_type application/json;
add_header Content-Type 'text/html; charset=utf-8';
return 200 '{"code": 666, "update":"访问高峰期，请稍后再试"}';
}
}
注意：只有当 request header 被后端server处理后，这个连接才进行计数。
第一步：安装说明
环境准备：
yum install -y gcc gcc-c++ readline-devel pcre-devel openssl-devel tcl perl
安装drizzle http://wiki.nginx.org/HttpDrizzleModule：
cd /usr/local/src/
wget http://openresty.org/download/drizzle7-2011.07.21.tar.gz
tar xzvf drizzle-2011.07.21.tar.gz
cd drizzle-2011.07.21/
./configure --without-server
make libdrizzle-1.0
make install-libdrizzle-1.0
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
安装openresty：
wget http://openresty.org/download/ngx_openresty-1.7.2.1.tar.gz
tar xzvf ngx_openresty-1.7.2.1.tar.gz
cd ngx_openresty-1.7.2.1/
./configure --with-http_drizzle_module
gmake
gmake install
第二步：Nginx配置nginx.conf
/usr/local/openresty/nginx/conf/nginx.conf：
# 添加MySQL配置(drizzle)
upstream backend {
drizzle_server 127.0.0.1:3306 dbname=test user=root password=123456 protocol=mysql;
drizzle_keepalive max=200 overflow=ignore mode=single;
}
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
location /lua _test{
default_type text/plain;
content_by_lua 'ngx.say("hello, lua")';
}
location /lua_redis {
default_type text/plain;
content_by_lua_file /usr/local/lua_test/redis_test.lua;
}
location /lua_mysql {
default_type text/plain;
content_by_lua_file /usr/local/lua_test/mysql_test.lua;
}
location @cats-by-name {
set_unescape_uri $name $arg_name;
set_quote_sql_str $name;
drizzle_query 'select * from cats where name=$name';
drizzle_pass backend;
rds_json on;
}
location @cats-by-id {
set_quote_sql_str $id $arg_id;
drizzle_query 'select * from cats where id=$id';
drizzle_pass backend;
rds_json on;
}
location = /cats {
access_by_lua '
if ngx.var.arg_name then
return ngx.exec("@cats-by-name")
end
if ngx.var.arg_id then
return ngx.exec("@cats-by-id")
end
';
rds_json_ret 400 "expecting \\"name\\" or \\"id\\" query arguments";
}
# 通过url匹配出name，并编码防止注入，最后以json格式输出结果
location ~ '^/mysql/(.*)' {
set $name $1;
set_quote_sql_str $quote_name $name;
set $sql "SELECT * FROM cats WHERE name=$quote_name";
drizzle_query $sql;
drizzle_pass backend;
rds_json on;
}
# 查看MySQL服务状态
location /mysql-status {
drizzle_status;
}
}
第三步：lua测试脚本
/usr/local/lua_test/redis_test.lua：
local redis = require "resty.redis"
local cache = redis.new()
cache.connect(cache, '127.0.0.1', '6379')
local res = cache:get("foo")
if res==ngx.null then
ngx.say("This is Null")
return
end
ngx.say(res)
/usr/local/lua_test/mysql_test.lua：
local mysql = require "resty.mysql"
local db, err = mysql:new()
if not db then
ngx.say("failed to instantiate mysql: ", err)
return
end
db:set_timeout(1000) -- 1 sec
-- or connect to a unix domain socket file listened
-- by a mysql server:
-- local ok, err, errno, sqlstate =
-- db:connect{
-- path = "/path/to/mysql.sock",
-- database = "ngx_test",
-- user = "ngx_test",
-- password = "ngx_test" }
local ok, err, errno, sqlstate = db:connect{
host = "127.0.0.1",
port = 3306,
database = "test",
user = "root",
password = "123456",
max_packet_size = 1024 * 1024 }
if not ok then
ngx.say("failed to connect: ", err, ": ", errno, " ", sqlstate)
return
end
ngx.say("connected to mysql.")
local res, err, errno, sqlstate =
db:query("drop table if exists cats")
if not res then
ngx.say("bad result: ", err, ": ", errno, ": ", sqlstate, ".")
return
end
res, err, errno, sqlstate =
db:query("create table cats "
.. "(id serial primary key, "
.. "name varchar(5))")
if not res then
ngx.say("bad result: ", err, ": ", errno, ": ", sqlstate, ".")
return
end
ngx.say("table cats created.")
res, err, errno, sqlstate =
db:query("insert into cats (name) "
.. "values (\'Bob\'),(\'\'),(null)")
if not res then
ngx.say("bad result: ", err, ": ", errno, ": ", sqlstate, ".")
return
end
ngx.say(res.affected_rows, " rows inserted into table cats ",
"(last insert id: ", res.insert_id, ")")
-- run a select query, expected about 10 rows in
-- the result set:
res, err, errno, sqlstate =
db:query("select * from cats order by id asc", 10)
if not res then
ngx.say("bad result: ", err, ": ", errno, ": ", sqlstate, ".")
return
end
local cjson = require "cjson"
ngx.say("result: ", cjson.encode(res))
-- put it into the connection pool of size 100,
-- with 10 seconds max idle timeout
local ok, err = db:set_keepalive(10000, 100)
if not ok then
ngx.say("failed to set keepalive: ", err)
return
end
-- or just close the connection right away:
-- local ok, err = db:close()
-- if not ok then
-- ngx.say("failed to close: ", err)
-- return
-- end
';
第四步：验证结果
$ curl 'http://127.0.0.1/lua_test'
hello, lua
$ redis-cli set foo 'hello,lua-redis'
OK
$ curl 'http://127.0.0.1/lua_redis'
hello,lua-redis
$ curl 'http://127.0.0.1/lua_mysql'
connected to mysql.
table cats created.
3 rows inserted into table cats (last insert id: 1)
result: [{"name":"Bob","id":"1"},{"name":"","id":"2"},{"name":null,"id":"3"}]
$ curl 'http://127.0.0.1/cats'
{"errcode":400,"errstr":"expecting \\"name\\" or \\"id\\" query arguments"}
$ curl 'http://127.0.0.1/cats?name=bob'
[{"id":1,"name":"Bob"}]
$ curl 'http://127.0.0.1/cats?id=2'
[{"id":2,"name":""}]
$ curl 'http://127.0.0.1/mysql/bob'
[{"id":1,"name":"Bob"}]
$ curl 'http://127.0.0.1/mysql-status'
worker process: 32261
upstream backend
active connections: 0
connection pool capacity: 0
servers: 1
peers: 1
API经济
API经济是基于API所产生经济活动的总和，在当今发展阶段主要包括API业务，以及通过API进行的业务功能、性能等方面的商业交易。
借贷机制
针对两个连续的限流时间窗切换时，如果切换前的时间窗中的请求量已被使用完，则第一个时间窗可以向下一个时间窗预借一小部分的请求量（小于每个时间窗内的资源量，建议运行借贷20%以内的资源）来提前使用，如果该时间窗内预借的资源也消耗完，则触发限流拒绝措施；那么在第二个时间窗内则会少使用被借走的请求量。在预借请求量时，如果当前时间窗”已欠费“（即有被借走的量），则该时间窗不允许向下一个时间窗借贷资源。
这个缓存算法使用一个计数器来记录条目被访问的频率。通过使用LFU缓存算法，最低访问数的条目首先被移除。这个方法并不经常使用，因为它无法对一个拥有最初高访问率之后长时间没有被访问的条目缓存负责。
这个缓存算法将最近使用的条目存放到靠近缓存顶部的位置。当一个新条目被访问时，LRU将它放置到缓存的顶部。当缓存达到极限时，较早之前访问的条目将从缓存底部开始被移除。这里会使用到昂贵的算法，而且它需要记录“年龄位”来精确显示条目是何时被访问的。此外，当一个LRU缓存算法删除某个条目后，“年龄位”将随其他条目发生改变。
一个缓存被访问后，近期再被访问的可能性很大。可以记录每个缓存记录的最近访问时间，最近未被访问时间最长的数据会被首先淘汰。
优点：实现简单，能适应访问热点
缺点：对偶发的访问敏感，影响命中率
簿记开销：时间 O(1)，空间 O(N)
在IBM Almaden研究中心开发，这个缓存算法同时跟踪记录LFU和LRU，以及驱逐缓存条目，来获得可用缓存的最佳使用。
FIFO是英文First In First Out 的缩写，是一种先进先出的数据缓存器，他与普通存储器的区别是没有外部读写地址线，这样使用起来非常简单，但缺点就是只能顺序写入数据，顺序的读出数据，其数据地址由内部读写指针自动加1完成，不能像普通存储器那样可以由地址线决定读取或写入某个指定的地址。
越早进入缓存的数据，其不再被访问的可能性越大。因此在淘汰缓存时，应选择在内存中停留时间最长的缓存记录。使用队列即可实现该策略：
优点：实现简单，适合线性访问的场景
缺点：无法适应特定的访问热点，缓存的命中率差
簿记开销：时间 O(1)，空间 O(N)
这个缓存算法最先移除最近最常使用的条目。一个MRU算法擅长处理一个条目越久，越容易被访问的情况。
缓存更新的策略主要分为三种：
缓存使用场景
分布式系统中要么通过2PC、3PC或Paxos协议保证强一致性，要么就是拼命的降低并发时脏数据的概率。缓存系统适用的场景就是非强一致性的场景，所以它属于CAP中的AP，只能做到BASE理论中说的最终一致性。异构数据库本来就没办法强一致，我们只是尽可能减少不一致的时间窗口，达到最终一致性。同时结合设置过期时间的兜底方案。
缓存场景分析
Cache Aside（旁路缓存） 是最广泛使用的缓存模式之一，如果能正确使用 Cache Aside 的话，能极大的提升应用性能，Cache Aside可用来读或写操作。Cache Aside的提出是为了尽可能地解决缓存与数据库的数据不一致问题。
Cache Aside 的读请求流程如下：
Cache Aside 的写请求流程如下：
Read/Write Through（读写穿透） 模式中，服务端把缓存作为主要数据存储。应用程序跟数据库缓存交互，都是通过抽象缓存层完成的。
Read Through 和 Cache Aside 很相似，不同点在于程序不需要再去管理从哪去读数据（缓存还是数据库）。相反它会直接从缓存中读数据，该场景下是缓存去决定从哪查询数据。当我们比较两者的时候这是一个优势因为它会让程序代码变得更简洁。Read Through的简要流程如下
该模式只在 Cache Aside 之上进行了一层封装，它会让程序代码变得更简洁，同时也减少数据源上的负载。流程如下：
Write Through 模式下的所有写操作都经过缓存，每次向缓存中写数据时，缓存会把数据持久化到对应的数据库中去，且这两个操作都在一个事务中完成。因此，只有两次都写成功才是最终写成功。用写延迟保证了数据一致性。当发生写请求时，也是由缓存抽象层完成数据源和缓存数据的更新，流程如下：
当使用 Write Through 的时候一般都配合使用 Read Through。Write Through 适用情况有：
Write Behind 而言）和数据不一致Write Through 的潜在使用例子是银行系统。
Write Behind（异步写入，又叫Write Back） 和 Read/Write Through 相似，都是由 Cache Provider 来负责缓存和数据库的读写。它们又有个很大的不同：Read/Write Through 是同步更新缓存和数据的，Write Behind 则是只更新缓存，不直接更新数据库，通过批量异步的方式来更新数据库。
这种方式下，缓存和数据库的一致性不强，对一致性要求高的系统要谨慎使用。但是它适合频繁写的场景，MySQL的InnoDB Buffer Pool 机制就使用到这种模式。如上图，应用程序更新两个数据，Cache Provider 会立即写入缓存中，但是隔一段时间才会批量写入数据库中。优缺点如下：
一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。
先删除缓存，再更新数据库中如何避免脏数据？采用延时双删策略。
① 读写分离架构
读写架构中，先删除缓存，再更新数据库中如何避免脏数据？采用延时双删策略。
② 延时双删导致吞吐量降低
延时双删的方式同步淘汰策略导致了吞吐量降低如何解决？
不管是延时双删还是Cache-Aside的先操作数据库再删除缓存，都可能会存在第二步的删除缓存失败，导致的数据不一致问题，可以引入删除缓存重试机制来解决。
流程如下：
重试删除缓存机制会造成好多业务代码入侵。其实还可以这样优化：通过数据库的binlog来异步淘汰key。
流程如下：
操作缓存的时候，到底是删除缓存呢，还是更新缓存？日常开发中，我们一般使用的就是Cache-Aside模式。有些小伙伴可能会问， Cache-Aside在写入请求的时候，为什么是删除缓存而不是更新缓存呢？
我们在操作缓存的时候，到底应该删除缓存还是更新缓存呢？我们先来看个例子：
这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据不一致了，脏数据出现啦。如果是删除缓存取代更新缓存则不会出现这个脏数据问题。更新缓存相对于删除缓存，还有两点劣势：
双写的情况下，先操作数据库还是先操作缓存？Cache-Aside 缓存模式中，有些小伙伴还是会有疑问，在写请求过来的时候，为什么是先操作数据库呢？为什么不先操作缓存呢？比如一条数据同时存在数据库、缓存，现在你要更新此数据，不管先更新数据库，还是先更新缓存，这两种方式都有问题。
方案一：先更新数据库，后更新缓存
如下案例会造成数据不一致。
A先把数据库更新为 123，由于网络问题，更新缓存的动作慢了。这时，B 去更新数据库了，改为了 456，紧接着把缓存也更新为456。现在A更新缓存的请求到了，把缓存更新为了 123。那么这时数据就不一致了，数据库里是最新的 456，而缓存是 123，是旧数据。因为数据库更新、缓存更新这2个动作不是原子的，在高并发操作时，这2个动作直接会插入其他动作。
方案二：先更新缓存，再更新数据库
如下案例也同样可能数据不一致。
缓存更新成功，数据为最新的，但数据库更新失败，回滚了，还是旧数据。还是非原子操作的原因。
注意：先操作数据库再操作缓存，不一样也会导致数据不一致嘛？它俩又不是原子性操作的。这个是会的，但是这种方式，一般因为删除缓存失败等原因，才会导致脏数据，这个概率就很低。接下来我们再来分析这种删除缓存失败的情况，如何保证一致性。
除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），还可以根据具体的业务需求进行自定义的缓存淘汰。常见的更新策略如下：
LRU/LFU/FIFO：都是属于当缓存不够用时采用的更新算法
适合内存空间有限，数据长期不变动，基本不存在数据一不致性业务。比如一些一经确定就不允许变更的信息。
超时剔除：给缓存数据设置一个过期时间
适合于能够容忍一定时间内数据不一致性的业务，比如促销活动的描述文案。
主动更新：如果数据源的数据有更新，则主动更新缓存
对于数据的一致性要求很高，比如交易系统，优惠劵的总张数。
常见数据更新方式有两大类，其余基本都是这两类的变种：
方式一：先删缓存，再更新数据库
这种做法是遇到数据更新，我们先去删除缓存，然后再去更新DB，如左图。让我们来看一下整个操作的流程：
可以看到B请求将脏数据写入了缓存，如果这是一个读多写少的数据，可能脏数据会存在比较长的时间（要么有后续更新，要么等待缓存过期），这是业务上不能接受的。
方式二：先更新数据库，再删除缓存
上图的右侧部分可以看到在A更新DB和删除缓存之间B请求会读取到老数据，因为此时A操作还没有完成，并且这种读到老数据的时间是非常短的，可以满足数据最终一致性要求。
删除缓存而非更新缓存原因
上图可以看到我们用的是删除缓存，而不是更新缓存，原因如下图：
上图我用操作代替了删除或更新，当我们做删除操作时，A先删还是B先删没有关系，因为后续读取请求都会从DB加载出最新数据；但是当我们对缓存做的是更新操作时，就会对A先更新缓存还是B先更新缓存敏感了，如果A后更新，那么缓存里就又存在脏数据了，所以 go-zero 只使用删除缓存的方式。
缓存更新请求处理流程
我们来一起看看完整的请求处理流程：
注意：不同颜色代表不同请求。
当大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。
发生缓存雪崩的原因及解决方案：
① 大量数据同时过期
② Redis故障宕机
如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题，如秒杀活动。
缓存击穿跟缓存雪崩很相似，可以认为缓存击穿是缓存雪崩的一个子集。应对缓存击穿可以采取以下两种方案：
互斥锁方案：保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值
热点数据缓存永远不过期
当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。
缓存穿透的发生一般有这两种情况：
应对缓存穿透的方案，常见的方案有三种：
拦截非法请求
布隆过滤器：构造一个BloomFilter过滤器，初始化全量数据，当接到请求时，在BloomFilter中判断这个key是否存在，如果不存在，直接返回即可，无需再查询缓存和DB
缓存空对象：查存DB 时，如果数据不存在，预热一个特殊空值到缓存中。这样，后续查询都会命中缓存，但是要对特殊值，解析处理
布隆过滤器工作原理
布隆过滤器由「初始值都为 0 的位图数组」和「 N 个哈希函数」两部分组成。当我们在写入数据库数据时，在布隆过滤器里做个标记，这样下次查询数据是否在数据库时，只需要查询布隆过滤器，如果查询到数据没有被标记，说明不在数据库中。布隆过滤器会通过 3 个操作完成标记：
举个例子，假设有一个位图数组长度为 8，哈希函数 3 个的布隆过滤器：
用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）
在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。
请求分片集中，超过单 Server 的性能极限
在服务端读数据进行访问时，往往会对数据进行分片切分，此过程中会在某一主机 Server 上对相应的 Key 进行访问，当访问超过 Server 极限时，就会导致热点 Key 问题的产生。
当某一热点 Key 的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。如果热点过于集中，热点 Key 的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。当缓存服务崩溃后，此时再有请求产生，会缓存到后台 DB 上，由于DB 本身性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步导致雪崩现象，严重影响设备的性能。
通常的解决方案主要集中在对客户端和 Server 端进行相应的改造。
架构中各节点的作用如下：
实际过程中 Client 将请求传到 SLB，SLB 又将其分发至多个 Proxy 内，通过 Proxy 对请求的识别，将其进行分类发送。例如，将同为 Write 的请求发送到 Master 模块内，而将 Read 的请求发送至 ReadOnly 模块。而模块中的只读节点可以进一步扩充，从而有效解决热点读的问题。读写分离同时具有可以灵活扩容读热点能力、可以存储大量热点Key、对客户端友好等优点。
该方案通过主动发现热点并对其进行存储来解决热点 Key 的问题。首先 Client 也会访问 SLB，并且通过 SLB 将各种请求分发至 Proxy 中，Proxy 会按照基于路由的方式将请求转发至后端的 Redis 中。在热点 key 的解决上是采用在服务端增加缓存的方式进行。具体来说就是在 Proxy 上增加本地缓存，本地缓存采用 LRU 算法来缓存热点数据，后端 DB 节点增加热点数据计算模块来返回热点数据。Proxy 架构的主要有以下优点：
在热点 Key 的处理上主要分为写入跟读取两种形式，在数据写入过程当 SLB 收到数据 K1 并将其通过某一个 Proxy 写入一个 Redis，完成数据的写入。假若经过后端热点模块计算发现 K1 成为热点 key 后， Proxy 会将该热点进行缓存，当下次客户端再进行访问K1时，可以不经Redis。最后由于Proxy是可以水平扩充的，因此可以任意增强热点数据的访问能力。
对于 db 上热点数据的发现，首先会在一个周期内对 Key 进行请求统计，在达到请求量级后会对热点 Key 进行热点定位，并将所有的热点 Key 放入一个小的 LRU 链表内，在通过 Proxy 请求进行访问时，若 Redis 发现待访点是一个热点，就会进入一个反馈阶段，同时对该数据进行标记。DB 计算热点时，主要运用的方法和优势有：
Big Key指数据量大的key，由于其数据大小远大于其它key，导致经过分片之后，某个具体存储这个Big Key的实例内存使用量远大于其他实例，造成内存不足，拖累整个集群的使用。
优化big key的原则就是string减少字符串长度，而list、hash、set、zset等则减少成员数：
string类型的big key，尽量不要存入Redis中，可以使用文档型数据库MongoDB或缓存到CDN上。如果必须用Redis存储，最好单独存储，不要和其他的key一起存储
设置一个阈值，当value的长度超过阈值时，对内容启动压缩，降低kv的大小
评估大key所占的比例，由于很多框架采用池化技术，如：Memcache，可以预先分配大对象空间。真正业务请求时，直接拿来即用
颗粒划分，将大key拆分为多个小key，独立维护，成本会降低不少
大key要设置合理的过期时间，尽量不淘汰那些大key
缓存预热是指系统上线后，提前将相关的缓存数据加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。如果不进行预热，那么Redis初始状态数据为空，系统上线初期，对于高并发的流量，都会访问到数据库中， 对数据库造成流量的压力。
缓存预热思路
预热解决方案
缓存加载策略
缓存降级是指当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
分级降级预案：
有些复杂业务系统，一次用户请求可能会同步调用N个系统接口，需要等待所有的接口都返回了，才能真正的获取执行结果。
这种同步接口调用的方式总耗时比较长，非常影响用户的体验，特别是在网络不稳定的情况下，极容易出现接口超时问题。
很多复杂的业务系统，一般都会拆分成多个子系统。我们在这里以用户下单为例，请求会先通过订单系统，然后分别调用：支付系统、库存系统、积分系统 和 物流系统。
系统之间耦合性太高，如果调用的任何一个子系统出现异常，整个请求都会异常，对系统的稳定性非常不利。
有时候为了吸引用户，我们会搞一些活动，比如秒杀等。
如果用户少还好，不会影响系统的稳定性。但如果用户突增，一时间所有的请求都到数据库，可能会导致数据库无法承受这么大的压力，响应变慢或者直接挂掉。
对于这种 突发流量，无法保证系统的稳定性。
对于上面传统模式的三类问题，使用MQ就能轻松解决。
同步接口调用导致响应时间长的问题，使用MQ之后，将同步调用改成异步，能够显著减少系统响应时间。
系统A作为消息的生产者，在完成本职工作后，就能直接返回结果了。而无需等待消息消费者的返回，它们最终会独立完成所有的业务功能。这样能避免总耗时比较长，从而影响用户的体验的问题。
子系统间耦合性太大的问题，使用MQ之后，我们只需要依赖于MQ，避免了各个子系统间的强依赖问题。
订单系统作为消息生产者，保证它自己没有异常即可，不会受到支付系统等业务子系统的异常影响，并且各个消费者业务子系统之间，也互不影响。这样就把之前复杂的业务子系统的依赖关系，转换为只依赖于MQ的简单依赖，从而显著的降低了系统间的耦合度。
由于突然出现的突发流量，导致系统不稳定的问题。使用MQ后，能够起到消峰的作用。
订单系统接收到用户请求之后，将请求直接发送到MQ，然后订单消费者从MQ中消费消息，做写库操作。如果出现突发流量的情况，由于消费者的消费能力有限，会按照自己的节奏来消费消息，多的请求不处理，保留在MQ的队列中，不会对系统的稳定性造成影响。
引入MQ后让我们子系统间耦合性降低了，异步处理机制减少了系统的响应时间，同时能够有效的应对突发流量问题，提升系统的稳定性。但是引入MQ同时也会带来一些问题。
重复消费问题可以说是MQ中普遍存在的问题，不管你用哪种MQ都无法避免。有哪些场景会出现重复的消息呢？
如果重复消息不做正确的处理，会对业务造成很大的影响，产生重复的数据，或者导致数据异常，比如会员系统多开通了一个月的会员。
很多时候，如果MQ的消费者业务处理异常的话，就会出现数据一致性问题。比如：一个完整的业务流程是，下单成功之后，送100个积分。下单写库了，但是消息消费者在送积分的时候失败了，就会造成数据不一致的情况，即该业务流程的部分数据写库了，另外一部分没有写库。
如果下单和送积分在同一个事务中，要么同时成功，要么同时失败，是不会出现数据一致性问题的。但由于跨系统调用，为了性能考虑，一般不会使用强一致性的方案，而改成达成最终一致性即可。
同样消息丢失问题，也是MQ中普遍存在的问题，不管你用哪种MQ都无法避免。有哪些场景会出现消息丢失问题呢？
导致消息丢失问题的原因挺多的，生产者、MQ服务器、消费者 都有可能产生问题，在这里就不一一列举了。最终的结果会导致消费者无法正确的处理消息，而导致数据不一致的情况。
有些业务数据是有状态的，比如订单有：下单、支付、完成、退货等状态，如果订单数据作为消息体，就会涉及顺序问题了。如果消费者收到同一个订单的两条消息，第一条消息的状态是下单，第二条消息的状态是支付，这是没问题的。但如果第一条消息的状态是支付，第二条消息的状态是下单就会有问题了，没有下单就先支付了？
消息顺序问题是一个非常棘手的问题，比如：
Kafka同一个partition中能保证顺序，但是不同的partition无法保证顺序RabbitMQ的同一个queue能够保证顺序，但是如果多个消费者同一个queue也会有顺序问题如果消费者使用多线程消费消息，也无法保证顺序。如果消费消息时同一个订单的多条消息中，中间的一条消息出现异常情况，顺序将会被打乱。还有如果生产者发送到MQ中的路由规则，跟消费者不一样，也无法保证顺序。
如果消息消费者读取消息的速度，能够跟上消息生产者的节奏，那么整套MQ机制就能发挥最大作用。但是很多时候，由于某些批处理，或者其他原因，导致消息消费的速度小于生产的速度。这样会直接导致消息堆积问题，从而影响业务功能。
以下单开通会员为例，若消息出现堆积，会导致用户下单后，很久之后才能变成会员，这种情况肯定会引起大量用户投诉。
这里说的系统复杂度和系统耦合性是不一样的，比如以前只有：系统A、系统B和系统C 这三个系统，现在引入MQ之后，你除了需要关注前面三个系统之外，还需要关注MQ服务，需要关注的点越多，系统的复杂度越高。
MQ的机制需要：生产者、MQ服务器、消费者。有一定的学习成本，需要额外部署MQ服务器，而且有些MQ比如：RocketMQ，功能非常强大，用法有点复杂，如果使用不好，会出现很多问题。有些问题，不像接口调用那么容易排查，从而导致系统的复杂度提升了。
MQ是一种趋势，总体来说对我们的系统是利大于弊的，那么要如何解决这些问题呢？
不管是由于生产者产生的重复消息，还是由于消费者导致的重复消息，我们都可以在消费者中这个问题。这就要求消费者在做业务处理时，要做幂等设计。在这里推荐增加一张消费消息表，来解决MQ的这类问题。消费消息表中，使用messageId做唯一索引，在处理业务逻辑之前，先根据messageId查询一下该消息有没有处理过，如果已经处理过了则直接返回成功，如果没有处理过，则继续做业务处理。解决方案：
数据一致性分为强一致性、弱一致性和最终一致性。而MQ为了性能考虑使用的是最终一致性，那么必定会出现数据不一致的问题。这类问题大概率是因为消费者读取消息后，业务逻辑处理失败导致的，这时候可以增加重试机制。重试分为：同步重试 和 异步重试。业务处理失败后，可以采用以下三种方式进行重试：
记录表，人工处理。推荐消息量小的场景使用重试表，使用Job定时重试。推荐在消息量大的场景使用顺序要求不高的场景
有些消息量比较小的业务场景，可以采用同步重试，在消费消息时如果处理失败，立刻重试3-5次，如何还是失败，则写入到记录表中。但如果消息量比较大，则不建议使用这种方式，因为如果出现网络异常，可能会导致大量的消息不断重试，影响消息读取速度，造成消息堆积。而消息量比较大的业务场景，建议采用异步重试，在消费者处理失败之后，立刻写入重试表，有个job专门定时重试。还有一种做法是，如果消费失败，自己给同一个Topic发一条消息，在后面的某个时间点，自己又会消费到那条消息，起到了重试的效果。如果对消息顺序要求不高的场景，可以使用这种方式。
不管你是否承认有时候消息真的会丢，即使这种概率非常小，也会对业务有影响。生产者、MQ服务器、消费者都有可能会导致消息丢失的问题。
为了解决这个问题，可以增加一张消息发送表，当生产者发完消息之后，会往该表中写入一条数据，状态status标记为待确认。如果消费者读取消息之后，调用生产者的api更新该消息的status为已确认。有个Job，每隔一段时间检查一次消息发送表，如果5分钟（这个时间可以根据实际情况来定）后还有状态是待确认的消息，则认为该消息已经丢失了，重新发条消息。
这样不管是由于生产者、MQ服务器、还是消费者导致的消息丢失问题，job都会重新发消息。
消息顺序问题是非常常见的问题，以Kafka消费订单消息为例。订单有：下单、支付、完成、退货等状态，这些状态是有先后顺序的，如果顺序错了会导致业务异常。解决这类问题之前，我们先确认一下，消费者是否真的需要知道中间状态，只知道最终状态行不行？
其实很多时候，只需要知道的是最终状态，这时可以把流程优化一下：
这种方式可以解决大部分的消息顺序问题。但如果真的有需要保证消息顺序的需求。订单号路由到不同的partition，同一个订单号的消息，每次到发到同一个partition。
如果消费者消费消息的速度小于生产者生产消息的速度，将会出现消息堆积问题。那么消息堆积问题该如何解决呢？这个要看消息是否需要保证顺序。如果不需要保证顺序，可以读取消息之后用多线程处理业务逻辑。
这样就能增加业务逻辑处理速度，解决消息堆积问题。但线程池的核心线程数和最大线程数需要合理配置，不然可能会浪费系统资源。如果需要保证顺序，可以读取消息之后，将消息按照一定规则分发到多个队列中，然后在队列中用单线程处理。
其实MQ相关的内容还有很多，比如：延迟消息、私信队列、事务问题等等。
延迟队列存储的对象肯定是对应的延时消息，所谓”延时消息”是指当消息被发送以后，并不想让消费者立即拿到消息，而是等待指定时间后，消费者才拿到这个消息进行消费。开源RocketMQ 不支持任意时间自定义的延迟消息，仅支持内置预设值的延迟时间间隔的延迟消息。预设值的延迟时间间隔为：1s、 5s、 10s、 30s、 1m、 2m、 3m、 4m、 5m、 6m、 7m、 8m、 9m、 10m、 20m、 30m、 1h、 2h。
如电商中，提交一个订单就可以发送一个延时消息，30m后去检查这个订单的状态，如果还未付款就取消订单释放库存。
Message msg = new Message("order", "订单001".getBytes());
// 延迟30分钟
msg.setDelayTimeLevel(16);
SendResult sendResult = producer.send(msg);
当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。在消息队列 RocketMQ 中，这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。
死信消息
死信队列
死信队列中的数据需要通过新订阅该topic进行消费。每个topic被消费后，如果消费失败超过次数会进入重试队列、死信队列等。名称会以：
订单失效问题比较麻烦的地方就是如何能够实时获取失效的订单。对于这种问题一般有两种解决方案：
定时任务处理 用户下订单后先生成订单信息，然后将该订单加入到定时任务中（30分钟后执行），当到达指定时间后检查订单状态，如果未支付则标识该订单失效。定时去轮询数据库/缓存，看订单的状态。这种方式的问题很明显，当集群部署服务器的时候需要做分布式锁进行协调，而且实时性不高，对数据库会产生压力。
延时任务处理 当用户下订单后，将用户的订单的标识全部发送到延时队列中，30分钟后进去消费队列中被消费，消费时先检查该订单的状态，如果未支付则标识该订单失效。有以下几种延时任务处理方式：
Java自带的DelayedQuene队列 这是java本身提供的一种延时队列，如果项目业务复杂性不高可以考虑这种方式。它是使用jvm内存来实现的，停机会丢失数据，扩展性不强。
使用redis监听key的过期来实现 当用户下订单后把订单信息设置为redis的key，30分钟失效，程序编写监听redis的key失效，然后处理订单（我也尝试过这种方式）。这种方式最大的弊端就是只能监听一台redis的key失效，集群下将无法实现，也有人监听集群下的每个redis节点的key，但我认为这样做很不合适。如果项目业务复杂性不高，redis单机部署，就可以考虑这种方式。
MQ死信队列实现
什么是分布式事务？
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。一个大的操作由N多的小的操作共同完成。而这些小的操作又分布在不同的服务上。针对于这些操作，要么全部成功执行，要么全部不执行 。
TCC和可靠消息最终一致性方案是在生产中最常用。一个要求强一致，一个要求最终一致。TCC用于强一致主要用于核心模块，例如交易/订单等。最终一致方案一般用于边缘模块例如库存，通过mq去通知，保证最终一致性，也可以业务解耦。
可靠程度：强一致性 > 顺序一致性 > 因果一致性 > 最终一致性 > 弱一致性。
ACID注重一致性，是传统关系型数据库的设计思路。ACID是数据库（MySQL）事务正确执行所必须满足的四个特性：
Atomicity（原子性）：事务中的操作要么都做，要么都不做
Consistency（一致性）：系统必须始终处在强一致状态下
Isolation（隔离性）：一个事务的执行不能被其它事务所干扰
Durability（持久性）：一个已提交的事务对数据库中数据的改变是永久性的
CAP理论的核心思想是任何基于网络的数据共享系统最多只能满足数据一致性（Consistency）、可用性（Availability）和网络分区容忍（Partition Tolerance）三个特性中的两个。
一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否拥有同样的值
可用性（Availability）：在集群中一部分节点故障后，集群整体还能响应客户端的读写请求
分区容错性（Partition Tolerance）：系统中任意信息的丢失或失败不会影响系统的继续运作
这三个特性只能满足其中两个，牺牲另一个。大部分系统也都是如此：
BASE关注高可用性。BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性(Strong Consistency，CAP的一致性就是强一致性)，但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。BASE是分别代表：
基本可用(Basically Available)：指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用
软状态( Soft State)：指允许系统存在中间状态，而该中间状态不会影响系统整体可用性
最终一致性( Eventual Consistency)：指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
Gossip 协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。根据 Base 理论，如果你需要实现最终一致性，那么就可以通过 Gossip 协议实现这个目标。Gossip协议的核心一共是三块内容：直接邮寄（Direct Mail）、反熵（Anti-entropy）和谣言传播（RumRumor mongering）。
作为一种异步修复、实现最终一致性的协议，反熵在存储组件中应用广泛，比如 Dynamo、InfluxDB、Cassandra，在需要实现最终一致性时，如果节点都是已知的，一般优先考虑反熵。当集群节点是变化的，或者集群节点数比较多时，这时要采用谣言传播的方式，同步更新数据，实现最终一致。
所谓直接邮寄，就是直接发送更新数据，当数据发送失败时，将数据缓存下来，然后重传。比如下图中，节点 A 直接将更新数据发送给了节点 B、D：
虽然直接邮寄实现起来比较容易，数据同步也很及时，但可能会因为缓存队列满了而丢数据。 也就是说，只采用直接邮寄是无法实现最终一致性的。
熵，在物理学中是用来度量体系的混乱程度。所以，反熵就是要消除混乱，Gossip协议通过反熵来异步修复节点之间的数据差异，实现最终一致性。反熵的实现，一共有推、拉、推拉三种。 集群中的节点，每隔一段时间就会随机选择某个其他节点，然后交换自己的已有数据来消除两者之间的差异。但是正因为反熵需要节点间两两交换比对数据，所以执行反熵时的通讯成本会很高，不建议在实际场景中频繁执行反熵，应该通过引入Checksum等机制，降低需要对比的数据量和通讯次数。
推方式
推方式，就是将自己的所有副本数据，推给对方，修复对方副本中的熵：
拉方式
拉方式，就是拉取对方的所有副本数据，修复自己副本中的熵：
推拉方式
推拉方式，就是同时修复自己副本和对方副本中的熵：
虽然反熵很实用，但是执行反熵时，相关的节点都是已知的，而且节点数量不能太多，如果是一个动态变化或节点数比较多的分布式环境，反熵就不适用了。那么当你面临这个情况要怎样实现最终一致性呢？答案就是谣言传播。
谣言传播，广泛地散播谣言，它指的是当一个节点有了新数据后，这个节点变成活跃状态，并周期性地联系其他节点向其发送新数据，直到所有的节点都存储了该新数据。比如下图中，节点 A 向节点 B、D 发送新数据，节点 B 收到新数据后，变成活跃节点，然后节点 B 向节点 C、D 发送新数据：
谣言传播非常具有传染性，它适合动态变化的分布式系统。
CAP理论中的一致性一般指的是强一致性，也就是说写操作完成后，任何后续访问都能读到更新后的值。而BASE理论中的一致性指的是最终一致性，也就是说写操作完成后， 任何后续访问可能会读到旧数据，但是整个分布式系统的数据最终会达到一致。那么，如果我们的系统现在是最终一致性模型，也就是AP模型，突然有一天因为业务需要，要临时保证节点间的数据强一致性，有没有办法临时做这样的改造呢？一种办法是重新开发一套系统，但显然成本太高了。另一种办法就是本章要介绍的Quorum NWR算法。通过 Quorum NWR，我们可以自定义一致性级别。
Quorum NWR三要素
Quorum NWR 中有三个要素：N、W、R，它们是 Quorum NWR 的核心内容，我们就是通过组合这三个要素，实现自定义一致性级别的。
Quorum NWR 是非常实用的一个算法，能有效弥补 AP 型系统缺乏强一致性的痛点，给业务提供了按需选择一致性级别的灵活度。很多开源框架都利用Quorum NWR实现自定义一致性级别，比如Elasticsearch，就支持“any、one、quorum、all”4 种写一致性级别。
N 表示副本数，又叫做复制因子（Replication Factor）。也就是说，N 表示集群中同一份数据有多少个副本。 注意，副本数不等同于节点数。（如果读者对Elasticsearch或Kafka有了解，可以把副本理解成Replica Shard）。比如下图中， DATA-1 有 2 个副本，DATA-2 有 3 个副本，DATA-3 有 1 个副本：
在实现 Quorum NWR 的时候，我们需要实现自定义副本数的功能，比如，用户可以指定 DATA-1 具有 2 个副本，DATA-2 具有 3 个副本，就像上图中的样子。
W，又称写一致性级别（Write Consistency Level），表示对于客户端的一次写操作，只有成功完成 W 个副本的更新，才算写操作成功。以下图中的DATA-2为例，当它的W=2时，如果客户端对 DATA-2 执行写操作，必须完成它的2 个副本的更新，才算完成了写操作：
R，又称读一致性级别（Read Consistency Level），表示对于客户端的一次写操作，需要读 R 个副本，然后最终返回最新的那份数据。以下图中的DATA-2为例，当它的R=2时，如果客户端读取DATA-2的数据，需要读取它的2 个副本中的数据，然后返回最新的那份数据：
N、W、R 值的不同组合，会产生不同的一致性效果，具体来说，有这么两种效果：
我这里以DATA-2为例解释下，为什么W+R>N时，一定可以读到最新的数据。首先，DATA-2的N=3，W=2，R=2，那么当写数据时，必然有2个节点要写成功；此时再读数据，即使读到了一个没有写过的节点，由于要读2个节点的值，另一个必然是写成功的节点，所以最终返回给客户端的还是最新的数据。
我在《共识问题》一章中提到过，共识算法一共可以分为两大类：拜占庭容错算法（Byzantine Fault Tolerance，BFT）和故障容错算法（Crash Fault Tolerance，CFT）。Leslie Lamport在论文中提出的口信消息解决方案就属于BFT，需要考虑恶意节点的篡改、攻击等问题。但是，口信消息解决方案在现实场景中很难落地。比如，它并不关心这个共识的结果是什么，这会出现一种情况：现在适合进攻，但将军们达成的共识却是撤退。另外，实际场景中，我们往往需要就提议的一系列值（而不是单值）在拜占庭错误发生的时候，也能被达成共识。那应该怎么做呢？一种方案就是本文要讲解的PBFT算法。 PBFT算法，是一种能在实际场景中落地的BFT算法，它在区块链中应用广泛。
Raft 算法完全不适应有人作恶的场景，但PBFT 算法能容忍 (n - 1)/3 个恶意节点 (也可以是故障节点)。另外，相比 PoW 算法，PBFT 的优点是不消耗算力，所以在日常实践中，PBFT 比较适用于相对“可信”的场景中，比如联盟链。
此外，虽然PBFT 算法相比口信消息方案已经有了很大的优化，将消息复杂度从 O(n ^ (f + 1)) 降低为 O(n ^ 2)，能在实际场景中落地并解决共识问题，但 PBFT 还是需要比较多的消息，比如在 13 节点集群中（f 为 4），一次共识协商需要 237 个消息，所以决定了 PBFT 算法适用于中小型分布式系统。
要理解PBFT算法，首先必须要明白口信消息解决方案（A solution with oral message）到底存在哪些问题？这些问题都是后续众多BFT算法在努力改进和解决的，理解了这些问题，能帮助你更好地理解后来的拜占庭容错算法的思想（包括 PBFT 算法）。oral message方案存在一个致命的缺陷：当将军总数为n，叛将数为f时，算法需要递归协商 f+1 轮，消息复杂度为 O(n ^ (f + 1))，消息数量指数级暴增。你可以想象一下，如果叛将数为 64，消息数已经远远超过 int64 所能表示的了，这是无法想象的。
PBFT算法流程
PBFT 算法，通过签名（或消息认证码 MAC）约束恶意节点的行为，每个节点都可以通过验证消息签名确认消息的发送来源，一个节点无法伪造另外一个节点的消息。PBFT 算法采用了三阶段协议，基于大多数原则（2f + 1，f表示叛将数）实现共识。另外，与oral message不同的是，PBFT 算法实现的是一系列值的共识，而不是单值的共识。我们先来看看PBFT 算法的流程。为了方便演示，假设一共有A、B、C、D四个节点，那么根据Paxos算法的理论，最多允许存在一个恶意节点（(4-1)/3=1），我们假设B是恶意节点，现在客户端发起了一个提议值（进攻），希望被各节点达成共识：
在PBFT算法中，第一个接收到客户端请求的节点，将成为Leader节点，我们假设A节点首先接收了到请求。A接收到客户端请求之后，会执行三阶段协议（Three-phase protocol）。
首先，A进入预准备（Pre-prepare）阶段，构造包含作战指令的预准备消息，并广播给其他节点（B、C、D）：
B、C、D收到消息后 ， 不能确认自己接收到指令和其他人的是否相同。比如，D是叛徒，D收到了 2 个指令，然后他给A发送的是其中一个指令，给B、C发送的是另一个指令，这样就会出现无法一致行动的情况。
所以， 接收到预准备消息之后，B、C、D会进入准备（Prepare）阶段，并分别广播包含指令的准备消息给其他节点。这里我们假设叛徒D想通过不发送消息，来干扰共识协商：
然后，当某个节点收到 2f 个包含相同指令的准备消息后，会进入提交（Commit）阶段（这里的f 为叛徒数， 2f 包括自己）。
在这里，思考一个问题：这个时候节点（比如B）可以直接执行指令吗？答案还是不能，因为B不能确认A、C、D是否收到了 2f 个一致的包含相同指令的准备消息。也就是说，B这时无法确认A、C、D是否准备好了执行指令。
进入提交阶段后，各节点分别广播提交消息给其他节点，也就是告诉其他节点：“我已经准备好了，可以执行指令了”：
最后，当某个节点收到 2f + 1 个验证通过的提交消息后（其中 f 为叛徒数，包括自己），也就是说，大部分的节点们已经达成共识，这时可以执行指令了，那么该节点将执行客户端的指令，执行完毕后发送执行成功的消息给客户端。
最后，当客户端收到 f+1 个相同的响应（Reply）消息时，说明各个节点已经就指令达成了共识，并执行了指令。
在PBFT算法中，共识是否达成，客户端是会做判断的，如果客户端在指定时间内未收到请求对应的 f + 1 相同响应，就认为集群出故障了，共识未达成，客户端会重新发送请求。PBFT 算法通过视图变更（View Change）的方式，来处理主节点作恶，当发现主节点在作恶时，会以“轮流上岗”方式，推举新的主节点。
谈起比特币，大家至少都应该有所耳闻吧？比特币是基于区块链实现的，而区块链运行在Internet上，这就存在有人试图作恶的情况。之前提到的口信消息解决方案和PBFT算法，虽然能防止坏人作恶，但只能防止少数，也就是 (n-1)/3 个坏人 (其中 n 为节点数)。可由于很多区块链是在公网环境，可能有坏人不断增加节点数，轻松突破 (n - 1) / 3 的限制。解决上述问题的方法就是PoW算法。PoW算法通过工作量证明（Proof of Work）增加了坏人作恶的成本，以此防止坏人作恶。本章，我就来讲讲PoW算法的原理。
PoW算法，属于拜占庭容错算法中的一种，能容忍一定比例的作恶行为，所以它在相对开放的场景中应用广泛，比如公链、联盟链。而非拜占庭容错算法（比如 Raft）无法对作恶行为进行容错，主要用于封闭、绝对可信的场景中，比如私链、公司内网的 DevOps 环境。
什么是工作量证明 (Proof Of Work，简称PoW) ？你可以这么理解：就是一份证明，用来确认你做过一定量的工作。比如，你的大学毕业证书就是一份工作量证明，证明你通过 4 年的努力完成了相关课程的学习。
那么，回到计算机世界，具体来说就是，客户端需要做一定难度的工作才能得出一个结果，验证方却很容易通过结果来检查出客户端是不是做了相应的工作。
比如小肖去Google面试，说自己的编程能力很强，那么她需要做一定难度的工作（比如做个算法题）。根据做题结果，面试官可以判断她是否适合这个岗位。这就是一个现实版的工作量证明。具体的工作量证明过程，就像下图中的样子：
哈希运算
既然工作量证明是通过指定的结果，来证明自己做过了一定量的工作。那么在区块链的 PoW 算法中需要做哪些工作呢？答案是哈希运算。哈希运算的核心是哈希函数（Hash Function），也叫散列函数。就是说，你输入一个任意长度的字符串，哈希函数会计算出一个哈希值。比如，我们对任意长度字符串（比如"tutuxiao"）执行 SHA256 哈希运算，就会得到一个 32 字节的哈希值，就像下面的样子：
$ echo -n "tutuxiao" | sha256sum
bb2f0f297fe9d3b8669b6b4cec3bff99b9de596c46af2e4c4a504cfe1372dc52
那么我们如何通过哈希运算来证明工作量呢？
举个例子，我们给出的工作量要求是：基于一个基本的字符串（比如"tutuxiao"），在这个字符串后面添加一个整数值，然后对变更后的字符串进行 SHA256 哈希运算，如果运算后得到的哈希值（16 进制形式）是以"0000"开头的，就验证通过；为了达到这个工作量证明的目标，我们需要不停地递增整数值，对得到的新字符串进行 SHA256 哈希运算。按照这个规则，我们需要经过 35024 次计算，才能找到恰好前 4 位为 0 的哈希值：
"tutuxiao0" => 01f28c5df06ef0a575fd0e529be9a6f73b1290794762de014ec84182081e118e
"tutuxiao1" => a2567c06fdb5775cb1e3ce17b72754cf146fcc6da75c8f1d87d7ab6a1b8c4523
...
"tutuxiao35022" =>
8afc85049a9e92fe0b6c98b02b27c09fb869fbfe273d0ab84ad8c5ac17b8627e
"tutuxiao35023" =>
0000ec5927ba10ea45a6822dcc205050ae74ae1ad2d9d41e978e1ec9762dc404
通过上面这个示例可以看到，工作量证明就是通过执行哈希运算，经过一段时间的计算后，得到符合条件的哈希值。在实际场景中，我们可以根据场景特点，制定不同的规则，比如，你可以试试分别运行多少次，才能找到恰好前 3 位和前 5 位为 0 的哈希值。
区块链也是通过 SHA256 执行哈希运算，通过计算出符合指定条件的哈希值，来证明工作量的。因为在区块链中，PoW 算法是基于区块链中的区块信息来进行哈希运算的。区块链的区块，是由区块头、区块体 2 部分组成的：
在区块链中，给出的工作量要求是：对区块头执行 SHA256 哈希运算，得到的结果再执行一个哈希运算，计算出的哈希值，只有小于目标值（target），才是有效的。计算出符合条件的哈希值后，矿工就会把这个信息广播给集群中所有其他节点，其他节点验证通过后，会将这个区块加入到自己的区块链中，最终形成一串区块链，就像下图的样子：
从上面这种工作量证明要求可以看出，算力越强，系统大概率会越先计算出这个哈希值。这也就意味着， 攻击者能挖掘一条比原链更长的攻击链，并将攻击链向全网广播。而按照约定，节点将接受更长的链，也就是攻击链，丢弃原链。就像下图的样子：
这样的话，按照比特币的区块链约定——“最长链胜出，其它节点在这条链基础上扩展”，那么如果坏人们掌握了 51% 的算力，就通过优势算力实现对最长链的争夺，也就是发起 51% 攻击，实现双花（Double Spending）。
即使攻击者只有 30% 的算力，他也有可能连续计算出多个区块的哈希值，挖掘出更长的攻击链，发动攻击； 另外，即使攻击者拥有 51% 的算力，他也有可能半天无法计算出一个区块的哈希值，也就是攻击失败。也就是说，能否计算出符合条件的哈希值，有一定的概率性，但长久来看，攻击者攻击成功的概率等同于攻击者算力的权重。
两阶段提交协议
两阶段提交系统具有完全的C（一致性），很糟糕的A（可用性），很糟糕的P（容错性）。 首先，两阶段提交协议保证了副本间是完全一致的，这也是协议的设计目的。再者，协议在一个节点出现异常时，就无法更新数据，其服务可用性较低。最后，一旦协调者与参与者之间网络分化，无法提供服务。
Paxos和Raft算法
Paxos 协议和Raft算法都是强一致性协议。Paxos只有两种情况下服务不可用：一是超过半数的 Proposer 异常，二是出现活锁。前者可以通过增加 Proposer 的个数来 降低由于 Proposer 异常影响服务的概率，后者本身发生的概率就极低。最后，只要能与超过半数的 Proposer 通信就可以完成协议流程，协议本身具有较好的容忍网络分区的能力。
二阶段提交还是三阶段提交都无法很好的解决分布式的一致性问题，直到Paxos算法的提出，Paxos协议由Leslie Lamport最早在1990年提出，目前已经成为应用最广的分布式一致性算法。Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。
为什么在Paxos运行过程中，半数以内的Acceptor失效都能运行？
如何产生唯一的编号呢？ 在《Paxos made simple》中提到的是让所有的Proposer都从不相交的数据集合中进行选择，例如系统有5个Proposer，则可为每一个Proposer分配一个标识j(0~4)，则每一个proposer每次提出决议的编号可以为5*i + j(i可以用来表示提出议案的次数)。
容错要求
Paxos 协议中，有三类节点:
Proposer（提案者）
Acceptor（批准者）
Learner（学习者）
Learner 学习被批准的 value。所谓学习就是通过读取各个 Proposer 对 value 的选择结果，如果某个 value 被超过半数 Proposer 通过，则 Learner 学习到了这个 value
这里类似 Quorum 议会机制，某个 value 需要获得 W=N/2 + 1 的 Acceptor 批准，Learner 需要至少读取 N/2+1 个 Accpetor，至多读取 N 个 Acceptor 的结果后，能学习到一个通过的 value
Phase 1：准备阶段
P1a：Proposer 发送 Prepare请求
Proposer 生成全局唯一且递增的ProposalID，向 Paxos 集群的所有机器发送 Prepare请求，这里不携带value，只携带N即ProposalID
P1b：Acceptor 应答 Prepare
Acceptor 收到 Prepare请求后，判断收到的ProposalID是否比之前已响应的所有提案的N大。
如果是
如果否，则不回复或回复Error
Phase 2：选举阶段
最后，经过多轮投票后，达到的结果是：
Paxos 协议的几个约束：
每轮 Paxos 协议分为准备阶段和批准阶段，在这两个阶段 Proposer 和 Acceptor 有各自的处理流程。Proposer与Acceptor之间的交互主要有4类消息通信，如下图：
这4类消息对应于paxos算法的两个阶段4个过程：
三种角色
Raft是一个用于管理日志一致性的协议。它将分布式一致性分解为多个子问题：Leader选举（Leader election）、日志复制（Log replication）、安全性（Safety）、日志压缩（Log compaction）等。同时，Raft算法使用了更强的假设来减少了需要考虑的状态，使之变的易于理解和实现。Raft将系统中的角色分为领导者（Leader）、跟从者（Follower）和候选者（Candidate）：
三种状态的转换关系如下：
Raft要求系统在任意时刻最多只有一个Leader，正常工作期间只有Leader和Followers。Raft算法将时间分为一个个的任期（term），每一个term的开始都是Leader选举。在成功选举Leader之后，Leader会在整个term内管理整个集群。如果Leader选举失败，该term就会因为没有Leader而结束。
Term（任期）
Raft 算法将时间划分成为任意不同长度的任期（term）。任期用连续的数字进行表示。每一个任期的开始都是一次选举（election），一个或多个候选人会试图成为领导人。如果一个候选人赢得了选举，它就会在该任期的剩余时间担任领导人。在某些情况下，选票会被瓜分，有可能没有选出领导人，那么，将会开始另一个任期，并且立刻开始下一次选举。Raft 算法保证在给定的一个任期最多只有一个领导人。
RPC（通信）
Raft 算法中服务器节点之间通信使用远程过程调用（RPC），并且基本的一致性算法只需要两种类型的 RPC，为了在服务器之间传输快照增加了第三种 RPC。RPC有三种：
① Leader选举过程
Raft 使用心跳（heartbeat）触发Leader选举。当服务器启动时，初始化为Follower。Leader向所有Followers周期性发送heartbeat。如果Follower在选举超时时间内没有收到Leader的heartbeat，就会等待一段随机的时间后发起一次Leader选举。每一个follower都有一个时钟，是一个随机的值，表示的是follower等待成为leader的时间，谁的时钟先跑完，则发起leader选举。Follower将其当前term加一然后转换为Candidate。它首先给自己投票并且给集群中的其他服务器发送 RequestVote RPC。结果有以下三种情况：
② Leader选举的限制
在Raft协议中，所有的日志条目都只会从Leader节点往Follower节点写入，且Leader节点上的日志只会增加，绝对不会删除或者覆盖。这意味着Leader节点必须包含所有已经提交的日志，即能被选举为Leader的节点一定需要包含所有的已经提交的日志。因为日志只会从Leader向Follower传输，所以如果被选举出的Leader缺少已经Commit的日志，那么这些已经提交的日志就会丢失，显然这是不符合要求的。这就是Leader选举的限制：能被选举成为Leader的节点，一定包含了所有已经提交的日志条目。
日志复制的目的是为了保证数据一致性。
日志复制的过程
Leader选出后，就开始接收客户端的请求。Leader把请求作为日志条目（Log entries）加入到它的日志中，然后并行的向其他服务器发起 AppendEntries RPC复制日志条目。当这条日志被复制到大多数服务器上，Leader将这条日志应用到它的状态机并向客户端返回执行结果。
简而言之，leader选举的过程是：1、增加term号；2、给自己投票；3、重置选举超时计时器；4、发送请求投票的RPC给其它节点。
日志的组成
日志由有序编号（log index）的日志条目组成**。**每个日志条目包含它被创建时的任期号（term）和用于状态机执行的命令。如果一个日志条目被复制到大多数服务器上，就被认为可以提交（commit）了。
上图显示，共有 8 条日志，提交了 7 条。提交的日志都将通过状态机持久化到磁盘中，防止宕机。
日志的一致性
① 日志复制的两条保证
② 日志的不正常情况
一般情况下，Leader和Followers的日志保持一致，因此 AppendEntries 一致性检查通常不会失败。然而，Leader崩溃可能会导致日志不一致：旧的Leader可能没有完全复制完日志中的所有条目。
下图阐述了一些Followers可能和新的Leader日志不同的情况。一个Follower可能会丢失掉Leader上的一些条目，也有可能包含一些Leader没有的条目，也有可能两者都会发生。丢失的或者多出来的条目可能会持续多个任期。
③ 如何保证日志的正常复制
Leader通过强制Followers复制它的日志来处理日志的不一致，Followers上的不一致的日志会被Leader的日志覆盖。Leader为了使Followers的日志同自己的一致，Leader需要找到Followers同它的日志一致的地方，然后覆盖Followers在该位置之后的条目。
具体的操作是：Leader会从后往前试，每次AppendEntries失败后尝试前一个日志条目，直到成功找到每个Follower的日志一致位置点（基于上述的两条保证），然后向后逐条覆盖Followers在该位置之后的条目。
总结一下就是：当 leader 和 follower 日志冲突的时候，leader 将校验 follower 最后一条日志是否和 leader 匹配，如果不匹配，将递减查询，直到匹配，匹配后，删除冲突的日志。这样就实现了主从日志的一致性。
Raft增加了如下两条限制以保证安全性：
在实际的系统中，不能让日志无限增长，否则系统重启时需要花很长的时间进行回放，从而影响可用性。Raft采用对整个系统进行snapshot来解决，snapshot之前的日志都可以丢弃（以前的数据已经落盘了）。每个副本独立的对自己的系统状态进行snapshot，并且只能对已经提交的日志记录进行snapshot。
Snapshot中包含以下内容：
当Leader要发给某个日志落后太多的Follower的log entry被丢弃，Leader会将snapshot发给Follower。或者当新加进一台机器时，也会发送snapshot给它。发送snapshot使用InstalledSnapshot RPC。做snapshot既不要做的太频繁，否则消耗磁盘带宽， 也不要做的太不频繁，否则一旦节点重启需要回放大量日志，影响可用性。推荐当日志达到某个固定的大小做一次snapshot。做一次snapshot可能耗时过长，会影响正常日志同步。可以通过使用copy-on-write技术避免snapshot过程影响正常日志同步。
常规处理成员变更存在的问题
可能存在这样的一个时间点，两个不同的领导者在同一个任期里都可以被选举成功（双主问题），一个是通过旧的配置，一个通过新的配置。简而言之，成员变更存在的问题是增加或者减少的成员太多了，导致旧成员组和新成员组没有交集，因此出现了双主。
解决方案之一阶段成员变更
Raft解决方法是每次成员变更只允许增加或删除一个成员（如果要变更多个成员，连续变更多次）。
问题1：Raft分为哪几个部分？
主要是分为leader选举、日志复制、日志压缩、成员变更等。
问题2：Raft中任何节点都可以发起选举吗？
Raft发起选举的情况有如下几种：
问题3：Raft中选举中给候选人投票的前提？
Raft确保新当选的Leader包含所有已提交（集群中大多数成员中已提交）的日志条目。这个保证是在RequestVoteRPC阶段做的，candidate在发送RequestVoteRPC时，会带上自己的last log entry的term_id和index，follower在接收到RequestVoteRPC消息时，如果发现自己的日志比RPC中的更新，就拒绝投票。日志比较的原则是，如果本地的最后一条log entry的term id更大，则更新，如果term id一样大，则日志更多的更大(index更大)。
问题4：Raft网络分区下的数据一致性怎么解决？
发生了网络分区或者网络通信故障，使得Leader不能访问大多数Follwer了，那么Leader只能正常更新它能访问的那些Follower，而大多数的Follower因为没有了Leader，他们重新选出一个Leader，然后这个 Leader来接受客户端的请求，如果客户端要求其添加新的日志，这个新的Leader会通知大多数Follower。如果这时网络故障修复 了，那么原先的Leader就变成Follower，在失联阶段这个老Leader的任何更新都不能算commit，都回滚，接受新的Leader的新的更新（递减查询匹配日志）。
问题5：Raft数据一致性如何实现？
主要是通过日志复制实现数据一致性，leader将请求指令作为一条新的日志条目添加到日志中，然后发起RPC 给所有的follower，进行日志复制，进而同步数据。
问题6：Raft的日志有什么特点？
日志由有序编号（log index）的日志条目组成，每个日志条目包含它被创建时的任期号（term）和用于状态机执行的命令。
问题7：Raft和Paxos的区别和优缺点？
问题8：Raft里面怎么保证数据被commit，leader宕机了会怎样，之前的没提交的数据会怎样？
leader会通过RPC向follower发出日志复制，等待所有的follower复制完成，这个过程是阻塞的**。**老的leader里面没提交的数据会回滚，然后同步新leader的数据。
问题9：Raft日志压缩是怎么实现的？增加或删除节点呢？？
在实际的系统中，不能让日志无限增长，否则系统重启时需要花很长的时间进行回放，从而影响可用性。Raft采用对整个系统进行snapshot来解决，snapshot之前的日志都可以丢弃（以前的数据已经落盘了）**。**snapshot里面主要记录的是日志元数据，即最后一条已提交的 log entry的 log index和term。
ZAB 协议全称Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议。
ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。下面我们会重点讲这两个东西。基于该协议，Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间数据一致性。具体如下图所示：
上图显示了 Zookeeper 如何处理集群中的数据。所有客户端写入数据都是写入到 主进程（称为 Leader）中，然后，由 Leader 复制到备份进程（称为 Follower）中。从而保证数据一致性。从设计上看，和 Raft 类似。
那么复制过程又是如何的呢？复制过程类似 2PC，ZAB 只需要 Follower 有一半以上返回 Ack 信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。
ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 二阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 Follwer）。整个广播流程分为 3 步骤：
第一步：将数据都复制到 Follwer 中
第二步：等待 Follwer 回应 Ack，最低超过半数即成功
第三步：当超过半数成功回应，则执行 commit ，同时提交自己
通过以上 3 个步骤，就能够保持集群之间数据的一致性。实际上，在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，避免同步，实现异步解耦。还有一些细节：
当Leader崩溃，即进入我们开头所说的崩溃恢复模式（崩溃即：Leader失去与过半Follwer的联系）。ZAB定义了2个原则：
所以，ZAB 设计了下面这样一个选举算法：**能够确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。**针对这个要求，如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群总所有机器编号（即 ZXID 最大）的事务，那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。而且这么做有一个好处是：可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。
当崩溃恢复之后，需要在正式工作之前（接收客户端请求），Leader 服务器首先确认事务是否都已经被过半的 Follwer 提交了，即是否完成了数据同步。目的是为了保持数据一致。当所有的 Follwer 服务器都成功同步之后，Leader 会将这些服务器加入到可用服务器列表中。
ZXID 生成
在 ZAB 协议的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字，其中低 32 位可以看作是一个简单的递增的计数器，针对客户端的每一个事务请求，Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。而高 32 位则代表了 Leader服务器上取出本地日志中最大事务Proposal的ZXID，并从该ZXID中解析出对应的epoch值，然后再对这个值加一。
高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。同时，也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。基于这样的策略：当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。
核心思路
参与者将操作成功或失败结果通知协调者，再由协调者根据所有参与者反馈情况决定参与者是否要提交操作还是中止操作。
熟悉MySQL的同学对两阶段提交应该颇为熟悉，MySQL的事务就是通过**「日志系统」** 来完成两阶段提交的。两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，「由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交」 。
这个协议有 「两个角色」 ，A节点是事务的协调者，B和C是事务的参与者。事务的提交分成两个阶段：
第二个阶段是 「决定阶段」
当A节点收到B和C参与者所有的确认消息后
当协调者和参与者同时出现故障时，两阶段提交无法保证事务的完整性。如果调者在发出commit消息之后宕机，而唯一接收到commit消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，因为没人知道事务是否已经被提交。
3PC针对2PC做了改进：
协调者向参与者发送事务执行请求CanCommit，参与者如果可以提交就返回YES响应，否则就返回NO响应。
协调者根据参与者反馈的结果来决定是否继续执行事务的PreCommit操作，根据协调者反馈的结果，有以下两种可能：
两阶段提交（2PC）和三阶段提交（3PC）并不适用于并发量大的业务场景。TCC事务机制相比于2PC、3PC，不会锁定整个资源，而是通过引入补偿机制，将资源转换为业务逻辑形式，锁的粒度变小。核心思想：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。TCC分为三个阶段：
TCC 事务机制相比于上面介绍的2PC，解决了其几个缺点：
总之，TCC 就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，并且很大程度的增加了业务代码的复杂度，因此，这种模式并不能很好地被复用。
TCC案例场景
TCC将一次事务操作分为三个阶段：Try、Confirm、Cancel，我们通过一个订单/库存的示例来理解。假设我们的分布式系统一共包含4个服务：订单服务、库存服务、积分服务、仓储服务，每个服务有自己的数据库，如下图：
从正常流程上讲，TCC仍是一个两阶段提交协议。但在执行出现问题的时候，有一定的自我修复能力，如果任何一个事务参与者出现了问题，协调者可以通过执行逆操作来取消之前的操作，达到最终的一致状态（比如冲正交易、查询交易）。从TCC的执行流程也可以看出，服务提供方需要提供额外的补偿逻辑，那么原来一个服务接口，引入TCC后可能要改造成3种逻辑：
注意：在设计TCC事务时，接口的Cancel和Confirm操作都必须满足幂等设计。
Try阶段一般用于锁定某个资源，设置一个预备状态或冻结部分数据。对于示例中的每一个服务，Try阶段所做的工作如下：
根据Try阶段的执行情况，Confirm分为两种情况：
Confirm阶段一般需要各个服务自己实现Confirm逻辑：
Confirm阶段的各个服务本身可能出现问题，这时候一般就需要TCC框架了（比如ByteTCC，tcc-transaction，himly），TCC事务框架一般会记录一些分布式事务的活动日志，保存事务运行的各个阶段和状态，从而保证整个分布式事务的最终一致性。
如果Try阶段执行异常，就会执行Cancel阶段。比如：对于订单服务，可以实现的一种Cancel逻辑就是：将订单的状态设置为“CANCELED”；对于库存服务，Cancel逻辑就是：将冻结库存扣减掉，加回到可销售库存里去。
许多公司为了简化TCC使用，通常会将一个服务的某个核心接口拆成两个，如库存服务的扣减库存接口，拆成两个子接口：①扣减接口 ②回滚扣减库存接口，由TCC框架来保证当某个接口执行失败后去执行对应的rollback接口。
该方案其实就是在分布式系统当中，把一个业务操作转换成一个消息，然后利用消息来实现事务的最终一致性。
比如从A账户向B账户转账的操作，当服务A从A账户扣除完金额后，通过消息中间件向服务B发一个消息，服务B收到这条消息后，进行B账户的金额增加操作。
可靠消息最终一致性方案一般有两种实现方式，原理其实是一样的：
可靠消息最终一致性方案，一般适用于异步的服务调用，比如支付成功后，调用积分服务进行积分累加、调用库存服务进行发货等等。总结一下，可靠消息最终一致性方案其实最基本的思想就两点：
可靠消息最终一致性方案是目前业务主流的分布式事务落地方案，其优缺点主要如下：
优点：消息数据独立存储，降低业务系统与消息系统间的耦合
缺点：一次消息发送需要两次请求，业务服务需要提供消息状态查询的回调接口
一般来讲，99%的分布式接口调用不需要做分布式事务，通过监控（邮件、短信告警）、记录日志，就可以事后快速定位问题，然后就是排查、出解决方案、修复数据。因为用分布式事务一定是有成本的，而且这个成本会比较高，特别是对于一些中小型公司。同时，引入分布式事务后，代码复杂度、开发周期会大幅上升，系统性能和吞吐量会大幅下跌，这就导致系统更加更加脆弱，更容易出bug。当然，如果有资源能够持续投入，分布式事务做好了的话，好处就是可以100%保证数据一致性不会出错。
基于本地消息表的分布式事务，是最简便的实现方式，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于eBay。我们来看下面这张图，基于本地消息服务的分布式事务分为三大部分：
可靠消息服务就是一个单独的服务，有自己的数据库，其主要作用就是存储消息（包含接口调用信息，全局唯一的消息编号），消息通常包含以下状态：
服务调用方（消息生产者）需要调用下游接口时，不直接通过RPC之类的方式调用，而是先生成一条消息，其主要步骤如下：
为了防止出现：生产者的本地事务执行成功，但是发送确认/取消消息超时的情况。可靠消息服务里一般会提供一个后台定时任务，不停的检查消息表中那些【待确认】的消息，然后回调生产者（上游服务）的一个接口，由生产者确认到底是取消这条消息，还是确认并发送这条消息。
通过上面这套机制，可以保证生产者对消息的100%可靠投递。
服务提供方（消息消费者），从MQ消费消息，然后执行本地事务。执行成功后，反过来通知可靠消息服务，说自己处理成功了，然后可靠消息服务就会把本地消息表中的消息状态置为最终状态【已完成】 。这里要注意两种情况：
总结
这个方案的优点是简单，但最大的问题在于可靠消息服务是严重依赖于数据库的，即通过数据库的消息表来管理事务，不太适合并发量很高的场景。
许多开源的消息中间件都支持分布式事务，比如RocketMQ、Kafka。其思想几乎是和本地消息表/服务实一样的，只不过是将可靠消息服务和MQ功能封装在一起，屏蔽了底层细节，从而更方便用户的使用。这种方案有时也叫做可靠消息最终一致性方案。以RocketMQ为例，消息的发送分成2个阶段：Prepare阶段和确认阶段。
注意：消费者无法立刻消费HalfMsg，生产者可以对HalfMsg进行Commit或者Rollback来终结事务。只有当Commit了HalfMsg后，消费者才能消费到这条消息。
消息中间件会定期去向生产者询问，是否可以Commit或者Rollback那些由于错误没有被终结的HalfMsg，以此来结束它们的生命周期，以达成事务最终的一致。之所以需要这个询问机制，是因为生产者可能提交完本地事务，还没来得及对HalfMsg进行Commit或者Rollback，就挂掉了，这样就会处于一种不一致状态。
消费者消费完消息后，可能因为自身异常，导致业务执行失败，此时就必须要能够重复消费消息。RocketMQ提供了ACK机制，即RocketMQ只有收到服务消费者的ack message后才认为消费成功。所以，服务消费者可以在自身业务员逻辑执行成功后，向RocketMQ发送ack message，保证消费逻辑执行成功。
我们最后以一个电子商务支付系统的核心交易链路为示例，来更好的理解下可靠消息最终一致性方案。
交易链路
假设我们的系统的核心交易链路如下图。用户支付订单时，首先调用订单服务的对外接口服务，然后开始核心交易链路的调用，依次经过订单业务服务、库存服务、积分服务，全部成功后再通过MQ异步调用仓储服务：
上图中，订单业务服务、库存服务、积分服务都是同步调用的，由于是核心链路，我们可以通过上一章中讲解的TCC分布式事务来保证分布式事务的一致性。而调用仓储服务可以异步执行，所以我们依赖RocketMQ来实现分布式事务。
事务执行
接着，我们来看下引入RocketMQ来实现分布式事务后，整个系统的业务执行流程发生了哪些变化，整个流程如下图：
注意，如果因为网络原因，导致RocketMQ始终没有收到订单接口服务对half-msg的commit或rollback消息，RocketMQ就会回调订单接口服务的某个接口，以查询该half-msg究竟是进行commit还是rollback。
最大努力通知的方案实现比较简单，适用于一些最终一致性要求较低的业务。执行流程：
Saga事务模型又叫做长时间运行的事务。其核心思想是**「将长事务拆分为多个本地短事务」，由Saga事务协调器协调，如果正常结束那就正常完成，如果「某个步骤失败，则根据相反顺序一次调用补偿操作」**。
XA和Seata区别
Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。
在 Seata 中，分布式事务的执行流程：
事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
Seata 会有 4 种分布式事务解决方案，分别是：AT 模式、TCC 模式、Saga 模式和 XA 模式。
2019年1月，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。
AT模式如何做到对业务的无侵入 ：
在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。
AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。
2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。
TCC 三个方法描述：
业务模型分 2 阶段设计：
用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。
以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完成的扣钱操作，拆成两阶段，实现成三个方法，并且保证一阶段 Try 成功的话 二阶段 Confirm 一定能成功。
如上图所示，Try 方法作为一阶段准备方法，需要做资源的检查和预留。在扣钱场景下，Try 要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结 A 账户的 转账资金。Try 方法执行之后，账号 A 余额虽然还是 100，但是其中 30 元已经被冻结了，不能被其他事务使用。
二阶段 Confirm 方法执行真正的扣钱操作。Confirm 会使用 Try 阶段冻结的资金，执行账号扣款。Confirm 方法执行之后，账号 A 在一阶段中冻结的 30 元已经被扣除，账号 A 余额变成 70 元 。
如果二阶段是回滚的话，就需要在 Cancel 方法内释放一阶段 Try 冻结的 30 元，使账号 A 的回到初始状态，100 元全部可用。
用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。
Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。
XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案，任何实现了 XA 协议的数据库都可以作为资源参与到分布式事务中，目前主流数据库，例如 MySql、Oracle、DB2、Oceanbase 等均支持 XA 协议。
XA 协议有一系列的指令，分别对应一阶段和二阶段操作。“xa start”和 “xa end”用于开启和结束XA 事务；“xa prepare” 用于预提交 XA 事务，对应一阶段准备；“xa commit”和“xa rollback”用于提交、回滚 XA 事务，对应二阶段提交和回滚。
在 XA 模式下，每一个 XA 事务都是一个事务参与者。分布式事务开启之后，首先在一阶段执行“xa start”、“业务 SQL”、“xa end”和 “xa prepare” 完成 XA 事务的执行和预提交；二阶段如果提交的话就执行 “xa commit”，如果是回滚则执行“xa rollback”。这样便能保证所有 XA 事务都提交或者都回滚。
XA 模式下，用户只需关注自己的“业务 SQL”，Seata 框架会自动生成一阶段、二阶段操作；XA 模式的实现如下：
在 XA 模式的一阶段，Seata 会拦截“业务 SQL”，在“业务 SQL”之前开启 XA 事务（“xa start”），然后执行“业务 SQL”，结束 XA 事务“xa end”，最后预提交 XA 事务（“xa prepare”），这样便完成 “业务 SQL”的准备操作。
执行“xa commit”指令，提交 XA 事务，此时“业务 SQL”才算真正的提交至数据库。
执行“xa rollback”指令，回滚 XA 事务，完成“业务 SQL”回滚，释放数据库锁资源。
XA 模式下，用户只需关注“业务 SQL”，Seata 会自动生成一阶段、二阶段提交和二阶段回滚操作。XA 模式和 AT 模式一样是一种对业务无侵入性的解决方案；但与 AT 模式不同的是，XA 模式将快照数据和行锁等通过 XA 指令委托给了数据库来完成，这样 XA 模式实现更加轻量化。
优化一：同库模式
通常一个 TM 会产生一笔主事务日志，一个 RM 会产生一条分支事务日志，每个分布式事务由一个 TM 和若干 RM 组成，一个分布式事务总共会有 1+N 条事务日志（N 为 RM 个数）。
在默认情况下，分布式事务执行过程中客户端将事务日志发送给服务端，服务端再将事务日志存储至数据库中，一条事务日志的存储链路会有 2 次 TCP ，分别是“客户端到服务端”和“服务端到数据库”， 我们称这种模式为异库模式。
在异库模式下，分布式事务存储事务日志总共需要 2*（1+N） 次左右的 TCP 通信。在 RM 数量较少的业务场景下，分布式事务性能还能接受，但有些业务场景下 RM 数量较多，此时事务内 TCP 数量也会增多，分布式事务性能急剧下降。
在事务执行过程中，客户端和服务端进行通信的目的是为了存储事务日志。如果客户端在存储事务日志时，绕过服务端直接将事务日志写入数据库（如上图“同库模式”所示），那么一笔事务日志的存储链路就由原来的 2 次 TCP 变成只需访问一次数据库便可，每条事务日志的存储减少了一次 TCP 通信，整个分布式事务就减少了 N+2 次 TCP 请求，分布式事务的性能大幅提升。我们将客户端直接将事务日志存储至数据库的模式称为同库模式。
优化二：二阶段异步执行
通常情况下，分布式事务发起方会依次执行一阶段和二阶段方法，然后结束分布式事务，返回结果。如果让分布式事务发起方执行完一阶段之后马上结束并返回结果，二阶段交由独立的线程或者进程异步执行，这样分布式事务的二阶段会晚几秒钟或者若干分钟执行，但事务的最终结果不会有任何改变。
二阶段异步执行之后，分布式事务的最终结果不会有任何影响，但是事务发起方要执行的内容减少一半（一阶段和二阶段都执行变成只执行一阶段），直观的用户感受是分布式事务的性能提升了 50%。
电商经典模块
下单流程图
创建订单和扣件库存场景
分布式事务-技术方案
先说说MQ的分布式事务，RocketMq在4.3版本已经正式宣布支持分布式事务，在选择Rokcetmq做分布式事务请务必选择4.3以上的版本。
事务消息作为一种异步确保型事务， 将两个事务分支通过 MQ 进行异步解耦，RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：
这个时候我们基本可以认为，只有MQ发送方自己的本地事务执行完毕，那么MQ的订阅方必定百分百能够接收到消息，我们再对下单减库存的步骤进行改造。这里涉及到一个异步化的改造，我们理一下如果是同步流程中的各个步骤：
订单创建完成后，发布一个事件“orderCreate” 到消息队列中，然后由MQ转发给订阅该消息的服务，因为是基于消息事务，我们可以认为订阅该消息的商品模块是百分百能收到这个消息的。
商品服务接受到orderCreate消息后就执行扣减库存的操作，注意⚠️，这里可能会有一些不可抗的因素导致扣减库存失败，无论成功或失败，商品服务都将发送一个扣减库存结果的消息“stroeReduce”到消息队列中，订单服务会订阅扣减库存的结果。订单服务收到消息后有两种可能：
这种模式将确认订单的流程变成异步化，非常适合在高并发的使用，但是，切记了，这个需要前端用户体验的一些改变，要配合产品来涉及流程。
上面使用MQ的方式确实是可以完成A和B操作，但是A和B并不是严格一致性，而是最终一致性，我们牺牲掉严格一致性，换来性能的提升，这种很适合在大促高并发场景总使用，但是如果B一直执行不成功，那么一致性也会被破坏，后续应该考虑到更多的兜底方案，方案越细系统就将越复杂。
TCC是服务化的二阶段变成模型，每个业务服务都必须实现 try，confirm，calcel三个方法，这三个方式可以对应到SQL事务中Lock，Commit，Rollback。
接下来看看，我们的下单扣减库存的流程怎么加入TCC：
在try的时候，会让库存服务预留n个库存给这个订单使用，让订单服务产生一个“未确认”订单，同时产生这两个预留的资源， 在confirm的时候，会使用在try预留的资源，在TCC事务机制中认为，如果在try阶段能正常预留的资源，那么在confirm一定能完整的提交：
在try的时候，有任务一方为执行失败，则会执行cancel的接口操作，将在try阶段预留的资源进行释放。
传统模式
分库分表
Seata 优势
实现分布式事务的方案比较多，常见的比如基于 XA 协议的 2PC、3PC，基于业务层的 TCC，还有应用消息队列 + 消息表实现的最终一致性方案，还有今天要说的 Seata 中间件，下边看看各个方案的优缺点。
基于 XA 协议实现的分布式事务，XA 协议中分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如 Oracle、MYSQL 这些数据库都实现了 XA 接口，而事务管理器则作为一个全局的调度者。
两阶段提交（2PC），对业务侵⼊很小，它最⼤的优势就是对使⽤⽅透明，用户可以像使⽤本地事务⼀样使⽤基于 XA 协议的分布式事务，能够严格保障事务 ACID 特性。
可 2PC的缺点也是显而易见，它是一个强一致性的同步阻塞协议，事务执⾏过程中需要将所需资源全部锁定，也就是俗称的 刚性事务。所以它比较适⽤于执⾏时间确定的短事务，整体性能比较差。
一旦事务协调者宕机或者发生网络抖动，会让参与者一直处于锁定资源的状态或者只有一部分参与者提交成功，导致数据的不一致。因此，在⾼并发性能⾄上的场景中，基于 XA 协议的分布式事务并不是最佳选择。
三段提交（3PC）是二阶段提交（2PC）的一种改进版本 ，为解决两阶段提交协议的阻塞问题，上边提到两段提交，当协调者崩溃时，参与者不能做出最后的选择，就会一直保持阻塞锁定资源。
2PC 中只有协调者有超时机制，3PC 在协调者和参与者中都引入了超时机制，协调者出现故障后，参与者就不会一直阻塞。而且在第一阶段和第二阶段中又插入了一个准备阶段（如下图，看着有点啰嗦），保证了在最后提交阶段之前各参与节点的状态是一致的。
虽然 3PC 用超时机制，解决了协调者故障后参与者的阻塞问题，但与此同时却多了一次网络通信，性能上反而变得更差，也不太推荐。
所谓的 TCC 编程模式，也是两阶段提交的一个变种，不同的是 TCC 为在业务层编写代码实现的两阶段提交。TCC 分别指 Try、Confirm、Cancel ，一个业务操作要对应的写这三个方法。
以下单扣库存为例，Try 阶段去占库存，Confirm 阶段则实际扣库存，如果库存扣减失败 Cancel 阶段进行回滚，释放库存。
TCC 不存在资源阻塞的问题，因为每个方法都直接进行事务的提交，一旦出现异常通过则 Cancel 来进行回滚补偿，这也就是常说的补偿性事务。
原本一个方法，现在却需要三个方法来支持，可以看到 TCC 对业务的侵入性很强，而且这种模式并不能很好地被复用，会导致开发量激增。还要考虑到网络波动等原因，为保证请求一定送达都会有重试机制，所以考虑到接口的幂等性。
消息事务（最终一致性）其实就是基于消息中间件的两阶段提交，将本地事务和发消息放在同一个事务里，保证本地操作和发送消息同时成功。下单扣库存原理图：
MQ 发送一条预备扣减库存消息， MQ 保存预备消息并返回成功 ACK
ACK，订单系统执行本地下单操作，为防止消息发送成功而本地事务失败，订单系统会实现 MQ 的回调接口，其内不断的检查本地事务是否执行成功，如果失败则 rollback 回滚预备消息；成功则对消息进行最终 commit 提交。基于消息中间件的两阶段提交方案，通常用在高并发场景下使用，牺牲数据的强一致性换取性能的大幅提升，不过实现这种方式的成本和复杂度是比较高的，还要看实际业务情况。
Seata 也是从两段提交演变而来的一种分布式事务解决方案，提供了 AT、TCC、SAGA 和 XA 等事务模式，这里重点介绍 AT模式。既然 Seata 是两段提交，那我们看看它在每个阶段都做了点啥？下边我们还以下单扣库存、扣余额举例。
先介绍 Seata 分布式事务的几种角色：
Transaction Coordinator(TC): 全局事务协调者，用来协调全局事务和各个分支事务（不同服务）的状态， 驱动全局事务和各个分支事务的回滚或提交Transaction Manager™: 事务管理者，业务层中用来开启/提交/回滚一个整体事务（在调用服务的方法中用注解开启事务）Resource Manager(RM): 资源管理者，一般指业务数据库代表了一个分支事务（Branch Transaction），管理分支事务与 TC 进行协调注册分支事务并且汇报分支事务的状态，驱动分支事务的提交或回滚Seata 实现分布式事务，设计了一个关键角色 UNDO_LOG （回滚日志记录表），我们在每个应用分布式事务的业务库中创建这张表，这个表的核心作用就是，将业务数据在更新前后的数据镜像组织成回滚日志，备份在 UNDO_LOG 表中，以便业务异常能随时回滚。
第一个阶段
比如：下边我们更新 user 表的 name 字段。
update user set name = '小富最帅' where name = '程序员内点事'
首先 Seata 的 JDBC 数据源代理通过对业务 SQL 解析，提取 SQL 的元数据，也就是得到 SQL 的类型（UPDATE），表（user），条件（where name = '程序员内点事'）等相关的信息。
先查询数据前镜像，根据解析得到的条件信息，生成查询语句，定位一条数据。
select name from user where name = '程序员内点事'
紧接着执行业务 SQL，根据前镜像数据主键查询出后镜像数据
select name from user where id = 1
把业务数据在更新前后的数据镜像组织成回滚日志，将业务数据的更新和回滚日志在同一个本地事务中提交，分别插入到业务表和 UNDO_LOG 表中。
回滚记录数据格式如下：包括 afterImage 前镜像、beforeImage 后镜像、 branchId 分支事务ID、xid 全局事务ID
{
"branchId":641789253,
"xid":"xid:xxx",
"undoItems":[
{
"afterImage":{
"rows":[
{
"fields":[
{
"name":"id",
"type":4,
"value":1
}
]
}
],
"tableName":"product"
},
"beforeImage":{
"rows":[
{
"fields":[
{
"name":"id",
"type":4,
"value":1
}
]
}
],
"tableName":"product"
},
"sqlType":"UPDATE"
}
]
}
这样就可以保证，任何提交的业务数据的更新一定有相应的回滚日志。
在本地事务提交前，各分支事务需向 全局事务协调者 TC 注册分支 ( Branch Id) ，为要修改的记录申请 全局锁 ，要为这条数据加锁，利用 SELECT FOR UPDATE 语句。而如果一直拿不到锁那就需要回滚本地事务。TM 开启事务后会生成全局唯一的 XID，会在各个调用的服务间进行传递。
有了这样的机制，本地事务分支（Branch Transaction）便可以在全局事务的第一阶段提交，并马上释放本地事务锁定的资源。相比于传统的 XA 事务在第二阶段释放资源，Seata 降低了锁范围提高效率，即使第二阶段发生异常需要回滚，也可以快速 从UNDO_LOG 表中找到对应回滚数据并反解析成 SQL 来达到回滚补偿。
最后本地事务提交，业务数据的更新和前面生成的 UNDO LOG 数据一并提交，并将本地事务提交的结果上报给全局事务协调者 TC。
第二个阶段
第二阶段是根据各分支的决议做提交或回滚：
如果决议是全局提交，此时各分支事务已提交并成功，这时 全局事务协调者（TC） 会向分支发送第二阶段的请求。收到 TC 的分支提交请求，该请求会被放入一个异步任务队列中，并马上返回提交成功结果给 TC。异步队列中会异步和批量地根据 Branch ID 查找并删除相应 UNDO LOG 回滚记录。
如果决议是全局回滚，过程比全局提交麻烦一点，RM 服务方收到 TC 全局协调者发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。
注意：这里删除回滚日志记录操作，一定是在本地业务事务执行之后
上边说了几种分布式事务各自的优缺点，下边实践一下分布式事务中间 Seata 感受一下。
Seata 是一个需独立部署的中间件，所以先搭 Seata Server，这里以最新的 seata-server-1.4.0 版本为例，下载地址：https://seata.io/en-us/blog/download.html。解压后的文件我们只需要关心 \seata\conf 目录下的 file.conf 和 registry.conf 文件。
file.conf
file.conf 文件用于配置持久化事务日志的模式，目前提供 file、db、redis 三种方式。
注意：在选择 db 方式后，需要在对应数据库创建 globalTable（持久化全局事务）、branchTable（持久化各提交分支的事务）、 lockTable（持久化各分支锁定资源事务）三张表。
-- the table to store GlobalSession data
-- 持久化全局事务
CREATE TABLE IF NOT EXISTS `global_table`
(
`xid` VARCHAR(128) NOT NULL,
`transaction_id` BIGINT,
`status` TINYINT NOT NULL,
`application_id` VARCHAR(32),
`transaction_service_group` VARCHAR(32),
`transaction_name` VARCHAR(128),
`timeout` INT,
`begin_time` BIGINT,
`application_data` VARCHAR(2000),
`gmt_create` DATETIME,
`gmt_modified` DATETIME,
PRIMARY KEY (`xid`),
KEY `idx_gmt_modified_status` (`gmt_modified`, `status`),
KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8;
-- the table to store BranchSession data
-- 持久化各提交分支的事务
CREATE TABLE IF NOT EXISTS `branch_table`
(
`branch_id` BIGINT NOT NULL,
`xid` VARCHAR(128) NOT NULL,
`transaction_id` BIGINT,
`resource_group_id` VARCHAR(32),
`resource_id` VARCHAR(256),
`branch_type` VARCHAR(8),
`status` TINYINT,
`client_id` VARCHAR(64),
`application_data` VARCHAR(2000),
`gmt_create` DATETIME(6),
`gmt_modified` DATETIME(6),
PRIMARY KEY (`branch_id`),
KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8;
-- the table to store lock data
-- 持久化每个分支锁表事务
CREATE TABLE IF NOT EXISTS `lock_table`
(
`row_key` VARCHAR(128) NOT NULL,
`xid` VARCHAR(96),
`transaction_id` BIGINT,
`branch_id` BIGINT NOT NULL,
`resource_id` VARCHAR(256),
`table_name` VARCHAR(32),
`pk` VARCHAR(36),
`gmt_create` DATETIME,
`gmt_modified` DATETIME,
PRIMARY KEY (`row_key`),
KEY `idx_branch_id` (`branch_id`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8;
registry.conf
registry.conf 文件设置 注册中心 和 配置中心：
目前注册中心支持 nacos 、eureka、redis、zk、consul、etcd3、sofa 七种，这里我使用的 eureka作为注册中心 ；配置中心支持 nacos 、apollo、zk、consul、etcd3 五种方式。
配置完以后在 \seata\bin 目录下启动 seata-server 即可，到这 Seata 的服务端就搭建好了。
Seata Server 环境搭建完，接下来我们新建三个服务 order-server（下单服务）、storage-server（扣减库存服务）、account-server（账户金额服务），分别服务注册到 eureka。
每个服务的大体核心配置如下：
spring:
application:
name: storage-server
cloud:
alibaba:
seata:
tx-service-group: my_test_tx_group
datasource:
driver-class-name: com.mysql.jdbc.Driver
url: jdbc:mysql://47.93.6.1:3306/seat-storage
username: root
password: root
# eureka 注册中心
eureka:
client:
serviceUrl:
defaultZone: http://${eureka.instance.hostname}:8761/eureka/
instance:
hostname: 47.93.6.5
prefer-ip-address: true
业务大致流程：用户发起下单请求，本地 order 订单服务创建订单记录，并通过 RPC 远程调用 storage 扣减库存服务和 account 扣账户余额服务，只有三个服务同时执行成功，才是一个完整的下单流程。如果某个服执行失败，则其他服务全部回滚。Seata 对业务代码的侵入性非常小，代码中使用只需用 @GlobalTransactional 注解开启一个全局事务即可。
@Override
@GlobalTransactional(name = "create-order", rollbackFor = Exception.class)
public void create(Order order) {
String xid = RootContext.getXID();
LOGGER.info("------->交易开始");
//本地方法
orderDao.create(order);
//远程方法 扣减库存
storageApi.decrease(order.getProductId(), order.getCount());
//远程方法 扣减账户余额
LOGGER.info("------->扣减账户开始order中");
accountApi.decrease(order.getUserId(), order.getMoney());
LOGGER.info("------->扣减账户结束order中");
LOGGER.info("------->交易结束");
LOGGER.info("全局事务 xid： {}", xid);
}
前边说过 Seata AT 模式实现分布式事务，必须在相关的业务库中创建 undo_log 表来存数据回滚日志，表结构如下：
-- for AT mode you must to init this sql for you business database. the seata server not need it.
CREATE TABLE IF NOT EXISTS `undo_log`
(
`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT 'increment id',
`branch_id` BIGINT(20) NOT NULL COMMENT 'branch transaction id',
`xid` VARCHAR(100) NOT NULL COMMENT 'global transaction id',
`context` VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
`rollback_info` LONGBLOB NOT NULL COMMENT 'rollback info',
`log_status` INT(11) NOT NULL COMMENT '0:normal status,1:defense status',
`log_created` DATETIME NOT NULL COMMENT 'create datetime',
`log_modified` DATETIME NOT NULL COMMENT 'modify datetime',
PRIMARY KEY (`id`),
UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB
AUTO_INCREMENT = 1
DEFAULT CHARSET = utf8 COMMENT ='AT transaction mode undo table';
项目中的服务调用过程如下图：
启动各个服务后，我们直接请求下单接口看看效果，只要 order 订单表创建记录成功，storage 库存表 used 字段数量递增、account 余额表 used 字段数量递增则表示下单流程成功。
请求后正向流程是没问题的，数据和预想的一样
而且发现 TM 事务管理者 order-server 服务的控制台也打印出了两阶段提交的日志
那么再看看如果其中一个服务异常，会正常回滚呢？在 account-server 服务中模拟超时异常，看能否实现全局事务回滚。
发现数据全没执行成功，说明全局事务回滚也成功了
那看一下 undo_log 回滚记录表的变化情况，由于 Seata 删除回滚日志的速度很快，所以要想在表中看见回滚日志，必须要在某一个服务上打断点才看的更明显。
总结
上边简单介绍了 2PC、3PC、TCC、MQ、Seata 这五种分布式事务解决方案，还详细的实践了 Seata 中间件。但不管我们选哪一种方案，在项目中应用都要谨慎再谨慎，除特定的数据强一致性场景外，能不用尽量就不要用，因为无论它们性能如何优越，一旦项目套上分布式事务，整体效率会几倍的下降，在高并发情况下弊端尤为明显。
随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，优化迫在眉睫。原因在于关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到 1000W 或 100G 以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。解决上述问题通常有以下两种方案：
通过提升服务器硬件能力来提高数据处理能力，比如增加存储容量 、CPU 等，这种方案成本很高，并且如果瓶颈在 MySQL 本身那么提高硬件也是有很的
把数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的
解决方案
垂直分表： 可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失
垂直分库： 可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题
水平分库： 可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题
水平分表： 可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化
一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。
拆分目的
垂直拆分：业务数据解耦
水平拆分：解决容量和性能压力
分库分表前的问题
用户请求量太大
单库太大
单表太大
垂直分表：将一个表按照字段分成多表，每个表存储其中一部分字段。
我们拿网上商城举例：用户在浏览商品列表时，通常只会快速浏览商品名称、商品图片、商品价格等其他字段信息，这些字段数据访问频次较高。当只有对某商品感兴趣时才会查看该商品的详细描述。因此，商品信息中商品描述字段访问频次较低，且该字段存储占用空间较大，访问单个数据 IO 时间较长。
由于这两种数据的访问频次的不同，我们可以将商品信息表分成如下 2 张表：
优化提升：
拆分原则：
垂直分库：按照业务将表进行分类，分布到不同数据库上面，每个库可以放在不同服务器上，它的核心理念是专库专用。
通过垂直分表性能得到了一定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终限制在一台服务器，库内垂直分表只解决了单一表数据量过大的问题，但没有将表分布到不同的服务器上，因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。
继续拿商城举例：一个商城系统通常都包含用户信息表和商品信息表，这两张表在业务上是独立的，因此我们可以将它们拆开分到2个不同的库中。
优化提升：
水平分库：把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。
经过垂直分库后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，单库存储数据已经超出预估。单台服务器已经无法支撑。此时该如何优化？垂直拆分已达到极限，只能从水平维度拆分。
继续拿商城举例：我们要查询某个商品信息时，需要分析这条商品信息的ID。如果ID为双数，将此操作映射至DB_1(商品库1)。如果店铺ID为单数，将操作映射至DB_2(商品库2)。此操作要访问数据库名称的表达式为DB_[商品信息ID % 2 + 1]。
优化提升：
水平分表：在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。
即便水平分库，随着业务的增长还是会出现单表数量大导致查询效率下降的问题。
按照水平分库的思路，我们可以对单表进行水平拆分：
优化提升：
简单说，就是把数据划分范围，挨个存储，存满一个再存另一个。
一致性 hash 环的节点一般按 2^32-1 来算，但是一般如果业务 ID 足够均衡，则可以降一些节点，如 4096 等等，4 个库的话，则均衡的分布在图上的位置，而数据通过 hash 计算，对应到外环的虚拟节点，然后归属于真实的库，对于表也可以同样处理。或者，直接把表节点部署在外环上，直接将数据归属于表。
比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。
按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。
使用分布式事务中间件解决，具体是通过最终一致性还是强一致性分布式事务，看业务需求。
切分之前，我们可以通过Join来完成。而切分之后，数据可能分布在不同的节点上，此时Join带来的问题就比较麻烦了，考虑到性能，尽量避免使用Join查询。解决这个问题的一些方法：
全局表
全局表，也可看做是 "数据字典表"，就是系统中所有模块都可能依赖的一些表，为了避免跨库Join查询，可以将 这类表在每个数据库中都保存一份。这些数据通常很少会进行修改，所以也不担心一致性的问题。
字段冗余
利用空间换时间，为了性能而避免join查询。例：订单表保存userId时候,也将userName冗余保存一份，这样查询订单详情时就不需要再去查询"买家user表"了。
数据组装
在系统层面，分两次查询。第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。
跨节点多库进行查询时，会出现Limit分页、Order by排序等问题。分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；当排序字段非分片字段时，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。
如果都用主键自增肯定不合理，如果用UUID那么无法做到根据主键排序，所以我们可以考虑通过雪花ID来作为数据库的主键，有关雪花ID可以参考我之前写的博客：静态内部类单例模式实现雪花算法。
采用双写的方式，修改代码，所有涉及到分库分表的表的增、删、改的代码，都要对新库进行增删改。同时，再有一个数据抽取服务，不断地从老库抽数据，往新库写，边写边按时间比较数据是不是最新的。
参数表、数据字典表等都是数据量较小，变动少的公共表，属于高频联合查询的依赖表。分库分表后，我们需要将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行。
Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。
Apache ShardingSphere 旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 关系型数据库当今依然占有巨大市场份额，是企业核心系统的基石，未来也难于撼动，我们更加注重在原有基础上提供增量，而非颠覆。
Apache ShardingSphere 5.x 版本开始致力于可插拔架构，项目的功能组件能够灵活的以可插拔的方式进行扩展。 目前，数据分片、读写分离、数据加密、影子库压测等功能，以及对 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持，均通过插件的方式织入项目。 开发者能够像使用积木一样定制属于自己的独特系统。Apache ShardingSphere 目前已提供数十个 SPI 作为系统的扩展点，而且仍在不断增加中。
| ShardingSphere-JDBC | ShardingSphere-Proxy | ShardingSphere-Sidecar | |
|---|---|---|---|
| 数据库 | 任意 | MySQL/PostgreSQL | MySQL/PostgreSQL |
| 连接消耗数 | 高 | 低 | 高 |
| 异构语言 | 仅 Java | 任意 | 任意 |
| 性能 | 损耗低 | 损耗略高 | 损耗低 |
| 无中心化 | 是 | 否 | 是 |
| 静态入口 | 无 | 有 | 无 |
定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
引入 maven 依赖
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-jdbc-core</artifactId>
<version>${latest.release.version}</version>
</dependency>
规则配置
ShardingSphere-JDBC 可以通过 Java，YAML，Spring 命名空间和 Spring Boot Starter 这 4 种方式进行配置，开发者可根据场景选择适合的配置方式。 详情请参见配置手册。
创建数据源
通过 ShardingSphereDataSourceFactory 工厂和规则配置对象获取 ShardingSphereDataSource。 该对象实现自 JDBC 的标准 DataSource 接口，可用于原生 JDBC 开发，或使用 JPA, MyBatis 等 ORM 类库。
DataSource dataSource = ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, configurations, properties);
定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如：MySQL Command Client, MySQL Workbench, Navicat 等)操作数据，对 DBA 更加友好。
规则配置
引入依赖
如果后端连接 PostgreSQL 数据库，不需要引入额外依赖。如果后端连接 MySQL 数据库，请下载 mysql-connector-java-5.1.47.jar，并将其放入 %SHARDINGSPHERE_PROXY_HOME%/lib 目录。
启动服务
使用默认配置项
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh
默认启动端口为 3307，默认配置文件目录为：%SHARDINGSPHERE_PROXY_HOME%/conf/。
自定义端口和配置文件目录
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh ${proxy_port} ${proxy_conf_directory}
使用ShardingSphere-Proxy
执行 MySQL 或 PostgreSQL的客户端命令直接操作 ShardingSphere-Proxy 即可。以 MySQL 举例：
mysql -u${proxy_username} -p${proxy_password} -h${proxy_host} -P${proxy_port}
定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。 通过无中心、零侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格。
Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。 使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。
规则配置
编辑%SHARDINGSPHERE_SCALING_HOME%/conf/server.yaml。详情请参见使用手册。
引入依赖
如果后端连接 PostgreSQL 数据库，不需要引入额外依赖。如果后端连接 MySQL 数据库，请下载 mysql-connector-java-5.1.47.jar，并将其放入 %SHARDINGSPHERE_SCALING_HOME%/lib 目录。
启动服务
sh %SHARDINGSPHERE_SCALING_HOME%/bin/start.sh
任务管理
通过相应的 HTTP 接口管理迁移任务。详情参见使用手册。
ShardingSphere-JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；ShardingSphere-Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。
Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，使得架构师更加自由地调整适合与当前业务的最佳系统架构。
功能列表
数据分片
分布式事务
数据库治理
达达原压测方案是: 搭建一套跟线上 1:1 的压测环境, 在这套环境中进行压测, 此方案技术难度低, 实现简单, 但弊端也明显: 人力及机器成本随着生产环境规模的变大而变大; 于是我们调研了业界主流的 【流量打标】方案, 该方案原理是: 在请求的流量(HTTP,RPC,MQ)上打标，所打的标示随着请求在各个服务之间流转, 从而使得压测流量与线上流量隔离，在数据隔离这块:
但这个方案适用于中间件统一的场景;而达达内部使用了各种类型的中间件, 比如 ORM 就有 Mybatis, Hiberante, JPA, 版本也不一致; 并且存在大量异构程序, 有 Java 的, 有Python 的; 若要实现【流量打标】方案, 势必会有大量业务改造, 因此我们放弃此方案。
在分析自身架构特点后, 我们在 2019年一季度研发了基于【机器打标】的压测方案 (数据使用 影子DB&Redis&MQ 隔离)。
以下是实现此方案的流程:
节点信息说明:
方案中最重要的是 "链路治理SDK", 它的职责是: 根据链路类别路由请求流量; 如下图所示:
它的启动流程如下:
最终线上环境, 在机器维度形成两条链路, 处理生产流量的生产链路和处理压测流量的压测链路。
方案比较
下图是对【流量打标】【机器打标】的比较, 两种方案都有优缺点, 达达从安全及系统改造成本出发, 最终选择了【机器打标】方案。
原压测方案使用 jmeter 进行压测, jmeter 属于老牌压测工具, 稳定性高且支持分布式; 但在压测场景复杂时，使用不够灵活; 达达的压测多数为复杂场景压测, 所以放弃原方案, 转而基于 jmeter 内核开发自己的压测平台; 以下是压测平台的整体架构:
主要由以下几个核心模块构成:
新压测平台的优势在于: 具有可视化的操作界面, 压测结果实时动态产出; 研发人员在压测平台配置 "发压性能参数", "造数据脚本" 就能直接执行。
压测引擎在施压时, 对应压测结果 (TPS&响应&错误率) 会实时展示到前端界面。
整个全链路压测的落地分成: 压测前, 压测中, 压测后:
其中 压测前 有三个关键点: 压测链路梳理, 优化预案设定, 精细化压测模型。
链路的梳理非常重要, 它决定着压测链路需要部署哪些服务, 压测时哪些服务需要被关注。
以前达达通过人肉的方式梳理链路, 但是这种方案效率低, 不准确, 工作量大, 且当生产环境链路变更时, 我们不能即时感知到; 后面引入 APM(PinPoint), APM 有梳理链路的功能。
但此方案还是没解决: "实时感知链路变更" 的问题; 为此我们在开发环境拉了条链路, 定时发请求以检测是否链路通畅; 若链路依赖有变化, 我们就能立刻知道。
俗话说: 不打无准备之战, 压测就是为了提前发现高负载时系统可能出现的性能隐患, 那如何解决性能隐患呢? 通常在压测之前我们会准备一些性能优化预案, 常用预案如下:
因过去几年的业务的发展, 导致生产环境数据库单表单库的数据量一直在增长, 达达物流系统多次碰到 Mysql 主从延迟 ; 目前最常用的优化方案是 "Mysql BinLog 调优", 此方案主要调优以下两个参数:
但此调优方案也有弊端: 参数调优后, 接口响应会有一定提升(如下图); 所以调优时需考虑业务能否容忍接口响应的上升。
随着业务的发展, 压测模型也在不断演进迭代中; 从一开始 "使用虚拟骑士, 单一按照接口TPS目标值压测" 到现在 "模拟生产活跃骑士, 引入时间&空间因素 构建压测模型", 模型越发精准。模型分成两类:
数据模型
把生产上活跃骑士&商户&订单导入影子库, 对这批数据进行清洗, 去除敏感信息(手机号, 地址信息等), 用这些数据进行压测; 此方案简单且能最真实的还原生产环境。
流量模型
业界常用 【流量回放】方案, 将大促时生产环境的流量存储下来, 然后在压测环境进行回放。
此方案适用于读接口的压测, 但是达达的业务场景复杂, 主流程接口多写少读; 所以直接使用此方案肯定不行。
鉴于不能直接使用【流量回放】, 达达选择了【人工构造流量】。影响构造流量真实性主要有两大因素: 时间, 空间。
时间
在时间上, 达达一天有三个高峰期: 早&午&晚高峰, 每个高峰期 各个接口处于不同状态:
所以压测时, 达达根据业务接口三个高峰期的特点, 设计两个压测场景(午高峰与晚高峰接口状态类似, 合并成一个压测场景), 进行压测。
空间
在空间上, 订单与骑士不均匀分布在各地, 有些区域人多单少, 有些区域人少单多, 而对系统影响最大的是人多单多的热点区域。
达达有个 查看周围X公里订单 的接口, 这个接口的性能跟 热点区域的个数, 每个热点区域内的单量, 每个热点区域内的运力 关系比较大; 为了搞清这几点, 我们分析大促时生产的流量, 根据 geohash 把全国划分成一个个正方形区域, 统计每个正方形区域内的订单及运力; 最后再在压测环境还原并放大。
然后就是 压测中, 主要有这几块: 接口验证, 压测预热, 压测实施, 性能指标观察, 性能问题记录。其中压测预热非常重要, 它决定了压测结果的准确性。
早期每次压测得到的接口响应都比生产环境慢一点, 后面发现: 生产环境的部分数据是热数据, 而压测环境全是冷数据, 这导致压测刚开始进行时, 接口响应偏高, 等过了一分钟后, 响应逐渐降低并趋于平稳; 后面引入压测预热, 使得压测环境的数据, 部分是热数据, 部分是冷数据, 以达到跟生产环境数据一致的效果。
最后就是 压测后; 压测后主要是: 压测报告的生成, 性能隐患定位与优化, 系统容量预估, 压测复盘。下面说一下压测复盘。
每次的大促复盘, 都能找到下次压测优化的方向; 复盘中最重要的是: 比较 生产与压测环境的 接口TPS&响应,中间件核心指标; 通过这些数据的比较来验证并优化 压测模型。
全链路压测从 2019年一季度立项, 已经历了 4次大促压测考验, 并且完成了目标; 而在全链路压测实施的过程中, 我们认为有三大关键:
整个项目的收益也非常明显, 具体从以下两方面分别来看:
当然此方案还有待提升的点, 比如 成本问题; 目前从安全角度出发, 达达通过影子库/缓存实现数据的隔离, 但影子库相比影子表方案机器成本高, 那如何在 安全与成本之间找到平衡, 是压测优化的方向; 另外, 除了挖掘系统隐患点, 全链路压测能否给 "智能运力调度" "运力的合理配置" 提出更多建议, 这也是我们思考的。
产品功能特点比较：
| 功能点 | Spring Cloud Config | Apollo | Nacos |
|---|---|---|---|
| 开源时间 | 2014.9 | 2016.5 | 2018.6 |
| 配置实时推送 | 支持（Spring Cloud Bus） | 支持（HTTP长轮询1S内） | 支持（HTTP长轮询1S内） |
| 版本管理 | 支持（Git） | 支持 | 支持 |
| 配置回滚 | 支持（Git） | 支持 | 支持 |
| 灰度发布 | 支持 | 支持 | 待支持 |
| 权限管理 | 支持 | 支持 | 待支持 |
| 多集群 | 支持 | 支持 | 支持 |
| 多环境 | 支持 | 支持 | 支持 |
| 监听查询 | 支持 | 支持 | 支持 |
| 多语言 | 只支持java | Go、C++、java、Python、PHP、.net、OpenAPI | Python、Java、Node.js、OpenAPI |
| 单机部署 | Config-server+Git+Spring Cloud Bus（支持配置实时推送） | Apollo-quikstart+MySQL | Nacos单节点 |
| 分布式部署 | Config-server+Git+MQ（部署复杂） | Config+Admin+Portal+MySQL（部署复杂） | Nacos+MySQL（部署简单） |
| 配置格式校验 | 不支持 | 支持 | 支持 |
| 通信协议 | HTTP和AMQP | HTTP | HTTP |
| 数据一致性 | Git保证数据一致性，Config-server从Git读数据 | 数据库模拟消息队列，Apollo定时读消息 | HTTP异步通知 |
| 单机读 | 7（限流所致） | 9000 | 15000 |
| 单机写 | 5（限流所致） | 1100 | 1800 |
| 3节点读 | 21（限流所致） | 27000 | 45000 |
| 3节点写 | 5（限流所致） | 3300 | 5600 |
| 文档 | 详细 | 详细 | 有待完善（目前只有java开发相关文档） |
包括注册服务、订阅服务、服务变更通知、服务心跳发送等功能。Server端会在系统初始化时通过register模块注册服务，Client端在系统初始化时会通过register模块订阅到具体提供服务的Server列表，当Server 列表发生变更时也由register模块通知Client。
失败自动切换，当出现失败，重试其它服务器。
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
用在provider侧，对超时的服务调用，打一个警告日志。
在consumer,provider侧将服务的耗时，并发数等送给监控服务。
兼容适配器，能对结果返回值做一些类型转换，注入基本类型到装箱类型的互转，复合类型到序列化值的转换(依赖你配置的序列化类型)等。
在provider端，对调用异常进行选择性进行包装。非受检异常直接抛出，jdk的异常直接抛出，异常类与接口类在一个jar包内的直接抛出，是服务接口方法自己声明的要throw的异常直接抛出。其余包装成受检异常放到RpcResult中返回。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。