< div style = "color:#16b0ff;font-size:50px;font-weight: 900;text-shadow: 5px 5px 10px var(--theme-color);font-family: 'Comic Sans MS';" > Solution< / div >
< span style = "color:#16b0ff;font-size:20px;font-weight: 900;font-family: 'Comic Sans MS';" > Introduction</ span > ：收纳技术相关的 `幂等` 、`限流`、`降级`、`断路器`、`事务`、`缓存`、`分库分表` 等总结！
[TOC]
# 高可用设计
**什么是高可用？**
在定义什么是高可用，可以先定义下什么是不可用，一个网站的内容最终呈现在用户面前需要经过若干个环节，而其中只要任何一个环节出现了故障，都可能导致网站页面不可访问，这个也就是网站不可用的情况。
参考维基百科，看看维基怎么定义高可用：`系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一`。
这个难点或是重点在于“无中断”，要做到 7 x 24 小时无中断无异常的服务提供。
**为什么需要高可用？**
一套对外提供服务的系统是需要硬件， ， ， ， ， ， ， ， ， ， ， ，
**高可用的评价纬度**
在业界有一套比较出名的评定网站可用性的指标， ，
| 描述 | N个9 | 可用性级别 | 年度停机时间 |
| ------------------------ | ---- | ---------- | ------------ |
| 基本可用 | 2个9 | 99% | 87.6小时 |
| 较高可用 | 3个9 | 99% | 8.8小时 |
| 具备故障自动恢复能力可用 | 4个9 | 99.99% | 53分钟 |
| 极高可用 | 5个9 | 99.999% | 5分钟 |
一般互联网公司也是按照这个指标去界定可用性， ， ， ， ， ， ， ， ， ， ，
## 服务冗余
### 冗余策略
每一个访问可能都会有多个服务组成而成，每个机器每个服务都可能出现问题，所以第一个考虑到的就是每个服务必须不止一份可以是多份，所谓多份一致的服务就是服务的冗余，这里说的服务泛指了机器的服务，容器的服务，还有微服务本身的服务。
在机器服务层面需要考虑，各个机器间的冗余是否有在物理空间进行隔离冗余 ， ， ，
### 无状态化
服务的冗余会要求我们可以随时对服务进行扩容或者缩容， ， ， ，
例如，从我们的微服务架构来看，我们总共分水平划分了好几个层，正因为我们每个层都做到了无状态，所以在这个水平架构的扩张是非常的简单。假设，我们需要对网关进行扩容，我们只需要增加服务就可以，而不需要去考虑网关是否存储了一个额外的数据。
网关不保存任何的session数据， ， ， ， ， ， ，
这里仅仅是举了网关的例子，在微服务只基本所有的服务，都应该按照这种思路去做，如果服务中有状态，就应该把状态抽取出来，让更加擅长处理数据的组件来处理，而不是在微服务中去兼容有数据的状态。
## 数据存储高可用
之前上面说的服务冗余，可以简单的理解为计算的高可用，计算高可用只需要做到无状态既可简单的扩容缩容，但是对于需要存储数据的系统来说，数据本身就是有状态。
跟存储与计算相比，有一个本质的差别：`将数据从一台机器搬到另一台机器，需要经过线路进行传输`。
网络是不稳定的， ， ， ， ， ， ，
无论是正常情况下的传输延时，还是异常情况下的传输中断，都会导致系统的数据在某个时间点出现不一致，而数据的不一致又会导致业务出现问题，但是如果数据不做冗余，系统的高可用无法保证
> 所以，存储高可用的难点不在于怎么备份数据，而在于如何减少或者规避数据不一致对业务造成的影响
分布式领域中有一个著名的CAP定理， ， ， ， ， ， ， ， ，
存储高可用方案的本质是将数据复制到多个存储设备中，通过数据冗余的方式来现实高可用，其复杂度主要呈现在数据复制的延迟或中断导致数据的不一致性，我们在设计存储架构时必须考虑到一下几个方面：
- 数据怎么进行复制
- 架构中每个节点的职责是什么
- 数据复制出现延迟怎么处理
- 当架构中节点出现错误怎么保证高可用
### 数据主从复制
主从复制是最常见的也是最简单的存储高可用方案， ，
其架构的优点就是简单，主机复制写和读，而从机只负责读操作，在读并发高时候可用扩张从库的数量减低压力，主机出现故障，读操作也可以保证读业务的顺利进行。
缺点就是客户端必须感知主从关系的存在，将不同的操作发送给不同的机器进行处理，而且主从复制中，从机器负责读操作，可能因为主从复制时延大，出现数据不一致性的问题。
### 数据主从切换
刚说了主从切换存在两个问题： 1.主机故障写操作无法进行 2.需要人工将其中一台从机器升级为主机
为了解决这个两个问题，我们可以设计一套主从自动切换的方案，其中设计到对主机的状态检测，切换的决策，数据丢失和冲突的问题。
1.主机状态检测
需要多个检查点来检测主机的机器是否正常，进程是否存在，是否出现超时，是否写操作不可执行，读操作是否不可执行，将其进行汇总，交给切换决策
2.切换决策
确定切换的时间决策，什么情况下从机就应该升级为主机，是进程不存在，是写操作不可这行，连续检测多少失败次就进行切换。应该选择哪一个从节点升级为主节点，一般来说或应该选同步步骤最大的从节点来进行升级。切换是自动切换还是半自动切换，通过报警方式，让人工做一次确认。
3.数据丢失和数据冲突 数据写到主机， ， ， ，
还要考虑一个数据冲突的问题， ， ， ， ，
### 数据分片
上述的数据冗余可以通过数据的复制来进行解决，但是数据的扩张需要通过数据的分片来进行解决（如果在关系型数据库是分表）。
何为数据分片（ ， ， ， ） ， ， ，
HDFS ，
- 做数据分片，如何将数据映射到节点
- 数据分片的特征值，即按照数据中的哪一个属性（字段）来分片
- 数据分片的元数据的管理，如何保证元数据服务器的高性能、高可用，如果是一组服务器，如何保证强一致性
## 柔性化/异步化
### 异步化
在每一次调用，时间越长存在超时的风险就越大，逻辑越复杂执行的步骤越多存在失败的风险也就越大，如果在业务允许的情况下，用户调用只给用户必须要的结果，而不是需要同步的结果可以放在另外的地方异步去操作，这就减少了超时的风险也把复杂业务进行拆分减低复杂度。当然异步化的好处是非常多，例如削封解耦等等，这里只是从可用的角度出发。异步化大致有这三种的实现方式：
- 服务端接收到请求后，创建新的线程处理业务逻辑，服务端先回应答给客户端
- 服务端接收到请求后，服务端先回应答给客户端，再继续处理业务逻辑
- 服务端接收到请求后，服务端把信息保存在消息队列或者数据库，回应答给客户端，服务端业务处理进程再从消息队列或者数据库上读取信息处理业务逻辑
### 柔性化
什么是柔性化，想象一个场景，我们的系统会给每个下单的用户增加他们下单金额对应的积分，当一个用户下单完毕后，我们给他增加积分的服务出现了问题，这个时候，我们是要取消掉这个订单还是先让订单通过，积分的问题通过重新或者报警来处理呢？
所谓的柔性化， ， ，
怎么去做柔性化，更多其实是对业务的理解和判断，柔性化更多是一种思维，需要对业务场景有深入的了解。
在电商订单的场景中，下单，扣库存，支付是一定要执行的步骤，如果失败则订单失败，但是加积分，发货，售后是可以柔性处理，就算出错也可以通过日志报警让人工去检查，没必要为加积分损失整个下单的可用性
## 兜底/容错
兜底是可能我们经常谈论的是一种降级的方案，方案是用来实施，但是这里兜底可能更多是一种思想，更多的是一种预案，每个操作都可以犯错，我们也可以接受犯错，但是每个犯错我们都必须有一个兜底的预案，这个兜底的预案其实就是我们的容错或者说最大程度避免更大伤害的措施，实际上也是一个不断降级的过程。举个例子：
例如我们首页请求的用户个性化推荐商品的接口，发现推荐系统出错，我们不应该去扩大（直接把异常抛给用户）或保持调用接口的错误，而是应该兼容调用接口的错误，做到更加柔性化，这时候可以选择获取之前没有失败接口的缓存数据，如果没有则可以获取通用商品不用个性化推荐，如果也没有可以读取一些静态文字进行展示。
由于我们架构进行了分层， ， ， ， ， ， ， ， ， ： ， ：
商品的美元售价假设要用商品人民币售价/汇率，这个时候错误发生在低层的数据层，上一层如果直接进行除，肯定就抛出 java.lang.ArithmeticException: / by zero， ， ， ，
## 负载均衡
相信负载均衡这个话题基本已经深入每个做微服务开发或设计者的人心， ， ， ， ， ， ， ， ，
### Nginx负载均衡故障转移
**转移流程**
nginx 根据给定好的负载均衡算法进行调度， ， （ ） ， ， ， ，
**节点失效**
nginx默认判断节点失效是以connect refuse和timeout为标准， ， ，
**节点恢复**
当某个节点失败的次数大于max_fails时， ， ，
### ZK负载均衡故障转移
在使用ZK作为注册中心时， ， ， ，
使用zk作为负载均衡的协调器， ， ， ， ， ，
**幂等设计**
为何会牵出幂等设计的问题， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ，
## 服务限流降级熔断
先来讲讲微服务中限流/熔断的目的是什么， ， ， ， ， ，
限流跟高可用的关系是什么， ， ， ， ， ， ， ， ，
熔断跟高可用的关系是什么，上面说了微服务是一个错综复杂的调用链关系，假设 模块A 调用 模块B ， ， ， ， ， ， ， ， ， ，
## 服务治理
### 服务模块划分
服务模块与服务模块之间有着千丝万缕的关系，但服务模块在业务中各有权重，例如订单模块可能是一家电商公司的重中之重，如果出问题将会直接影响整个公司的营收，而一个后台的查询服务模块可能也重要，但它的重要等级绝对是没有像订单这么重要。所以，在做服务治理时，必须明确各个服务模块的重要等级，这样才能更好的做好监控，分配好资源。这个在各个公司有各个公司的一个标准，例如在电商公司，确定服务的级别可能会更加倾向对用用户请求数和营收相关的作为指标。
| 服务级别 | 服务模块 |
| -------- | ------------------------------------------------------ |
| 一级服务 | 支付系统 订单服务 商品服务 用户服务 发布系统 ... |
| 二级服务 | 消息服务 权限系统 CRM系统 积分系统 BI系统 评论系统 ... |
| 三级服务 | 后台日志系统 |
可能真正的划分要比这个更为复杂，必须根据具体业务去定，这个可以从平时服务模块的访问量和流量去预估，往往更重要的模块也会提供更多的资源，所以不仅要对技术架构了如指掌，还要对公司各种业务形态了然于心才可以。
服务分级不仅仅在故障界定起到重要主要，而且决定了服务监控的力度，服务监控在高可用中起到了一个保障的作用，它不仅可以保留服务奔溃的现场以等待日后复盘，更重要的是它可以起到一个先知，先行判断的角色，很多时候可以预先判断危险，防范于未然。
### 服务监控
服务监控是微服务治理的一个重要环节，监控系统的完善程度直接影响到我们微服务质量的好坏，我们的微服务在线上运行的时候有没有一套完善的监控体系能去了解到它的健康情况，对整个系统的可靠性和稳定性是非常重要，可靠性和稳定性是高可用的一个前提保证。
服务的监控更多是对于风险的预判，在出现不可用之间就提前的发现问题，如果系统获取监控报警系统能自我修复则可以将错误消灭在无形，如果系统发现报警无法自我修复则可以通知人员提早进行接入。
一个比较完善的微服务监控体系需要涉及到哪些层次，如下图，大致可以划分为五个层次的监控
**基础设施监控**
例如网络，交换机，路由器等低层设备，这些设备的可靠性稳定性就直接影响到上层服务应用的稳定性，所以需要对网络的流量，丢包情况，错包情况，连接数等等这些基础设施的核心指标进行监控。
**系统层监控**
涵盖了物理机， ， ， ， ， ，
**应用层监控**
例如对url访问的性能， ， ， ， ， ， ， ， ，
**业务监控**
比方说一个电商网站，需要关注它的用户登录情况，注册情况，下单情况，支付情况，这些直接影响到实际触发的业务交易情况，这个监控可以提供给运营和公司高管他们需需要关注的数据，直接可能对公司战略产生影响。
**端用户体验监控**
用户通过浏览器，客户端打开练到到我们的服务，那么在用户端用户的体验是怎么样，用户端的性能是怎么样，有没有产生错误，这些信息也是需要进行监控并记录下来，如果没有监控，有可能用户的因为某些原因出错或者性能问题造成体验非常的差，而我们并没有感知，这里面包括了，监控用户端的使用性能，返回码，在哪些城市地区他们的使用情况是怎么样，还有运营商的情况，包括电信，联通用户的连接情况。我们需要进一步去知道是否有哪些渠道哪些用户接入的时候存在着问题，包括我们还需要知道客户端使用的操作系统浏览器的版本。
## 解决方案
### 冷备
冷备， ， ， ， ，
- 简单
- 快速备份（相对于其他备份方式）
- 快速恢复。只需要将备份文件拷贝回工作目录即完成恢复过程（亦或者修改数据库的配置，直接将备份的目录修改为数据库工作目录）。更甚，通过两次`mv`命令就可瞬间完成恢复。
- 可以按照时间点恢复。比如，几天前发生的拼多多优惠券漏洞被人刷掉很多钱，可以根据前一个时间点进行还原，“挽回损失”。
以上的好处，对于以前的软件来说，是很好的方式。但是对于现如今的很多场景，已经不好用了，因为：
- 服务需要停机。n个9肯定无法做到了。然后， ， ， ，
- 数据丢失。如果不采取措施， ， ， ， ， ， ， ，
- 冷备是全量备份。全量备份会造成磁盘空间浪费， ， ， ， ， ， ，
如何权衡冷备的利弊，是每个业务需要考虑的。
### 双机热备
热备，和冷备比起来，主要的差别是不用停机，一边备份一边提供服务。但还原的时候还是需要停机的。由于我们讨论的是和存储相关的，所以不将共享磁盘的方式看作双机热备。
#### Active/Standby模式
相当于1主1从， ， ， ， ， ， ， ； ， ， ， ； ，
#### 双机互备
本质上还是Active/Standby， ， ， ， ， ， ， ， ， ， ，
其他的高可用方案还可以参考各类数据库的多种部署模式， ； ， ，
### 同城双活
前面讲到的几种方案， ， ， （ ， ）
同城双活其实和前文提到的双机热备没有本质的区别，只是“距离”更远了，基本上还是一样（同城专线网速还是很快的）。双机热备提供了灾备能力，双机互备避免了过多的资源浪费。
在程序代码的辅助下，有的业务还可以做到真正的双活，即同一个业务，双主，同时提供读写，只要处理好冲突的问题即可。需要注意的是，并不是所有的业务都能做到。
业界更多采用的是两地三中心的做法。远端的备份机房能更大的提供灾备能力，能更好的抵抗地震，恐袭等情况。双活的机器必须部署到同城，距离更远的城市作为灾备机房。灾备机房是不对外提供服务的，只作为备份使用，发生故障了才切流量到灾备机房；或者是只作为数据备份。原因主要在于：**距离太远，网络延迟太大**。
如上图， ， ， ； ， ； ， ， ， ， ， ， ， ， ， ， ，
上图是一种基于Master-Slave模式的两地三中心示意图。城市1中的两个机房作为1主1从， ， （ ）
### 异地双活
同城双活可以应对大部分的灾备情况， ， ， ， ， ， ，
所以大多数的互联网公司采用了异地双活的方案。
上图是一个简单的异地双活的示意图。流量经过LB后分发到两个城市的服务器集群中， ， ，
在这种方式下，由于异地网络问题，双向同步需要花费更多的时间。更长的同步时间将会导致更加严重的吞吐量下降，或者出现数据冲突的情况。吞吐量和冲突是两个对立的问题，你需要在其中进行权衡。例如，为了解决冲突，引入分布式锁/分布式事务； ， ， ； ， ，
对于一些无法接受最终一致性的业务，饿了么采用的是下图的方式：
> 对于个别一致性要求很高的应用， （ ） ， ， ， ， （ ） ，
>
> 《饿了么异地多活技术实现（一）总体介绍》
也就是说，在这个区域是不能进行双活的。采用主从而不是双写，自然解决了冲突的问题。
实际上， ， ， ， ， ， ，
### 异地多活
根据异地双活的思路， ， ， ， ， ， ， ，
回忆一下我们在解决网状网络拓扑的时候是怎么优化的？引入中间节点，将网状改为星状：
改造为上图后， ， （ ） ， ， ， ， ，
# 注册中心
注册中心主要是为分布式服务的**发布与发现**提供一层统一标准化的基础组件，便于使用者直接操作简单接口即可实现服务发布与发现功能。
## 服务注册
服务注册有两种形式：**客户端注册**和**代理注册**。
### 客户端注册
客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己。
这种方式缺点是注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。
### 代理注册
代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作。
这种方式的缺点是多引用了一个代理服务，并且代理服务要保持高可用状态。
## 服务发现
服务发现也分为客户端发现和代理发现。
### 客户端发现
客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后客户端根据**负载均衡**算法选择一个实例发起请求调用。
这种方式非常直接，客户端可以控制负载均衡算法。但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。
### 代理发现
代理发现是指新增一个路由服务负责服务发现获取可用的实例列表， ， ， ， ，
## 心跳机制
如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。如何实现摘机？业界比较常用的方式是通过心跳检测的方式实现，心跳检测有**主动**和**被动**两种方式。
### 被动检测
**被动检测**是指服务主动向注册中心发送心跳消息， ， ， ，
上图中服务A的实例2已经宕机不能主动给注册中心发送心跳消息，
### 主动检测
**主动检测**是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例。
## Dubbo注册中心
### 核心功能
针对使用者，主要关注注册中心的以下五个核心接口，通过以下五个核心接口，可以实现服务的动态发布、动态发现以及优雅下线等操作：
- **注册服务**：
- **注销服务**：从注册中心将服务提供者的地址进行摘除
- **订阅服务**：
- **退订服务**：取消向注册中心订阅的服务监听者
- **查找服务**：向注册中心查找指定的服务清单列表
### 生产特性
Zookeeper会有一些未知的问题出现， ， ， ：
- **自动重连**： ，
- **自动切换**： ，
- **自动清理**： ， （ ）
- **自动恢复**： ， （ ）
- **自动重试**：失败自动重试（注册、注销、订阅、退订、监听和取消监听失败，无限重试至成功为止）
- **自动缓存**： （ ）
## 业界方案
下面结合各个维度对比一下各组件：
| ** 方案** | ** 优点** | ** 缺点** | ** 访问协议** | ** 一致性算法** |
| :------------ | :----------------------------------------------------------- | :----------------------------------------------------------- | :----------- | :------------- |
| **Zookeeper** | 1.功能强大， ； ； ， ； ， ； （ ）
| **Consul** | 1.开箱即用， ； ； ； （ ）
| **Nacos** | 1.开箱即用， ， ； ， ； ， ； ， ，
| **Eureka** | | | HTTP | AP |
### Zookeeper
### Consul
Consul是HashiCorp公司推出的开源工， ，
**Consul有哪些优势？
- 服务注册发现：
- 健康检查： ， ，
- 多数据中心： ，
**Consul的架构图**
Consul 实现多数据中心依赖于gossip protocol协议。这样做的目的：
- 不需要使用服务器的地址来配置客户端；服务发现是自动完成的
- 健康检查故障的工作不是放在服务器上，而是分布式的
**Consul的使用场景**
Consul的应用场景包括**服务注册发现**、**服务隔离**、**服务配置**等。
- **服务注册发现场景**中consul作为注册中心， ， ，
- **服务隔离场景**中consul支持以服务为单位设置访问策略， ， ，
- **服务配置场景**中consul提供key-value数据存储功能， ， ，
### Nacos
# API网关
**API网关是什么？
API网关是随着微服务（ ） （ ） （ ） ， ， ， ， ，
**为什么要做API网关？
在没有API网关之前， ， ， ， ， ，
**Tomcat自身问题**
- **缓存太多**。Tomcat用了很多对象池技术， ，
- **内存copy**。Tomcat默认用堆内存， ， ， ，
- **Tomcat读body是阻塞的**。Tomcat的NIO模型和Reactor模型不一样，
- **Tomcat对链接重用的次数是有限制的**。默认是100次， ， ， ， ，
**Tomcat Buffer**
Tomcat buffer 的关系图如下：
通过上面的图， ，
## 基本功能
- **反向代理**： ，
- **动态发现**：加入后端微服务中心，实现动态发现后端服务实例
- **负载均衡**：根据后端服务的实例列表进行负载均衡分配
- **服务路由**：
## 功能设计
### API发布
使用API网关的控制面， ， ：
业务研发人员从创建API开始， ； ； ， ， ； ， ； ， ， ， ， ， ，
### 配置中心
API网关的配置中心存放API的相关配置信息——使用自定义的DSL（ ， ） ， ， ， ：
API配置的详细说明
- **Name、Group**：名字、所属分组
- **Request**：请求的域名、路径、参数等信息
- **Response**：
- **Filters、FilterConfigs**：
- **Invokers**：后端服务(RPC/HTTP/Function)的请求规则和编排信息
### API路由
API网关的数据面在感知到API配置后， ， ， ， ， ：
一种是不包含路径变量的直接映射的MAP结构。其中， ，
另外一种是包含路径变量的前缀树数据结构。通过前缀匹配的方式，先进行叶子节点精确查找，并将查找节点入栈处理，如果匹配不上，则将栈顶节点出栈，再将同级的变量节点入栈，如果仍然找不到，则继续回溯，直到找到（或没找到）路径节点并退出。
### 功能组件
当请求流量命中API请求路径进入服务端， ， ， ：
### 协议转换&服务调用
API调用的最后一步， ： ， ， ，
上图以调用后端RPC服务为例， ， ， ，
### 高性能设计
### 稳定性保障
提供了一些常规的稳定性保障手段，来保证自身和后端服务的可用性。如下图所示：
- **流量管控**：
- **请求缓存**：对于一些幂等的、查询频繁的、数据及时性不敏感的请求，业务研发人员可开启请求缓存功能
- **超时管理**： ， ， ，
- **熔断降级**：支持熔断降级功能，实时监控请求的统计信息，达到配置的失败阈值后，自动熔断，返回默认值
### 故障自愈
API网关服务端接入了弹性伸缩模块， ， ，
### 可迁移
对于一些已经在对外提供API的Web服务， ， ， ， ， ， ，
**解决方案**
API网关为业务研发人员提供了一个灰度SDK， ， ， ， ， ，
**灰度过程**
**灰度前**： ， ，
**灰度中**： ， ，
**灰度后**：
### 自动生成DSL
业务研发人员在实际使用网关管理平台时， ， ， ：
- 引入服务的接口包依赖
- 拿到服务参数类定义
- 编写Testcase生成JSON模板
- 填写参数映射规则
- 最后手工录入管理平台，
整个过程非常繁琐， ，
**解决方案**
那么能不能将服务参数DSL的生成过程给自动化呢？ ， ， ， ， ， ， ， ， ， ， ，
### API操作提效
**快速创建API**
API网关的核心能力是建立在API配置的基础上的， ， ， ， （ ） ， ，
**批量操作**
业务研发人员在API网关上， ， ， ， ， ， ， ： ， ，
**API导入导出**
API网关提供在不同研发环境相互导入导出API的能力， ， ， ，
### 自定义组件
API网关提供了丰富的系统组件完成鉴权、限流、监控能力， ， ， ， ，
### 服务编排
一般情况下， ， ， ， ， ，
服务编排的需求应运而生， ， ： （ ）
通过独立部署的方式提供服务编排能力， ， ， ， ， ， ， ：
## 流量治理
### API鉴权
请求安全是API网关非常重要的能力， ， ，
### 黑白名单
### 流量控制
### 熔断器
### 服务降级
### 流量调度
### 流量Copy
### 流量预热
### 集群隔离
API网关按业务线维度进行集群隔离， ：
### 请求隔离
服务节点维度， ， ， ， ， ， ， ：
### 灰度发布
API网关作为请求入口，
**灰度场景**
在灰度能力上， ， ， ：
灰度API自身逻辑时， ； ， ，
**灰度策略**
支持丰富的灰度策略，可以按照比例数灰度，也可以按照特定条件灰度。
## 监控告警
### 立体化监控
API网关提供360度的立体化监控， ， ：
| | 监控模块 | 主要功能 |
| :--- | :-------------- | :----------------------------------------------------------- |
| 1 | 统一监控Raptor | 实时上报请求调用信息、系统指标， （ ） （ ）
| 2 | 链路追踪Mtrace | 负责全链路参数透传、全链路追踪监控 |
| 3 | 日志监控Logscan | 监控本地日志异常关键字：
| 4 | 远程日志中心 | API请求日志、Debug日志、组件日志等可上报远程日志中心 |
| 5 | 健康检查Scanner | 对网关节点进行心跳检测和API状态检测，
### 多维度告警
有了全面的监控体系，自然少不了配套的告警机制，主要的告警能力包括：
| | 告警类型 | 触发时机 |
| :--- | :--------------- | :-------------------------------------------------- |
| 1 | 限流告警 | API请求达到限流规则阈值触发限流告警 |
| 2 | 请求失败告警 | 鉴权失败、请求超时、后端服务异常等触发请求失败告警 |
| 3 | 组件异常告警 | 自定义组件处理耗时长、失败率高告警 |
| 4 | API异常告警 | API发布失败、API检查异常时触发API异常告警 |
| 5 | 健康检查失败告警 | API心跳检查失败、网关节点不通时触发健康检查失败告警 |
## 关键设计
### 异步外调
基于Netty实现异步外调主要有两种方式可以实现：
- **方式一： ， （ ） ，
- **方式二： （ ）
方式一需要独立维护一个全局映射表，同时需要考虑请求超时和丢失的情况，否则会出现内存不断增长问题。
### 外调链接池化
使用Netty实现API网关外调微服务时， ， ， ：
- **初始化适当连接（过多过少都不适合）**
- **考虑连接能随流量增减而进行自动扩缩容**
- **取出的连接需要检查是否可用**
- **连接需要考虑双向心跳探测**
### 释放连接
http的链接是独占的， ， ， ， ：
- Connection:close
- 空闲超时，关闭链接
- 读超时关闭链接
- 写超时，关闭链接
- Fin，
- **写超时**： ， （ ）
### 对象池化设计
针对高并发系统， ， ， （ ， ） ，
### 上下文切换
整个网关没有涉及到IO操作， ，
- 防止开发写的代码有阻塞
- 业务逻辑打日志可能会比较多
在突发的情况下， ， ， ， （ ） ， ， ， ，
### 监控告警
**协议层**
- **攻击性请求**。只发头，不发/发部分body， ， ，
- **Line or Head or Body过大的请求**。采样落盘，还原现场，并报警
**应用层**
- **耗时监控**。有慢请求， ， ，
- **QPS监控和报警**
- **带宽监控和报警**。支持对请求和响应的行、头、body单独监控
- **响应码监控**。特别是400和404
- **链接监控**。对接入端的链接，以及和后端服务的链接，后端服务链接上待发送字节大小也都做了监控
- **失败请求监控**
- **流量抖动报警**。流量抖动要么是出了问题，要么就是出问题的前兆
## 解决方案
### Shepherd API网关
### Mashape Kong
**访问地址**：
### Soul
**访问地址**：
### Apiman
**访问地址**：
### Gravitee
**访问地址**：
### Tyk
**访问地址**：
### Traefik
**访问地址**：
Træfɪ
**功能特性**
- 它非常快
- 无需安装其他依赖，
- 支持 Rest API
- 多种后台支持：
- 后台监控, 可以监听后台变化进而自动化应用新的配置文件设置
- 配置文件热更新。无需重启进程
- 正常结束http连接
- 后端断路器
- 轮询，
- Rest Metrics
- 支持最小化官方docker 镜像
- 后台支持SSL
- 前台支持SSL（ ）
- 清爽的AngularJS前端页面
- 支持Websocket
- 支持HTTP/2
- 网络错误重试
- 支持Let’
- 高可用集群模式
### 小豹API网关
**访问地址**：
小豹API网关（ ） ， ： ，
### Others
- Orange：
- gateway：
# 服务编排
## DSL设计
为了实现服务编排， ， （ ）
## 架构设计
- Facade： ，
- Parser： ， ， ，
- Executor： ， ，
- DataProcessor： ， ，
- 组件插件化：对日志等功能实现可插拔，调用方可以自定义这些组件，即插即用
## 主要特点
主要特点如下：
- 采用去中心化设计思路， ，
- 服务编排支持并行和串行调用， ， ，
- 使用JSON DSL 描述整个工作蓝图，简单易学
- 支持JSONPath语法对服务返回的结果进行取值
- 支持内置函数和自定义指令（ ） ，
- 编排服务树可视化
# 服务降级
什么是服务降级？当服务器压力剧增的情况下，可以将一些**不重要**或**不紧急**服务**暂停使用**或**延迟使用**，从而释放服务器资源以保证核心服务的正常运作或高效运作。服务降级的设计架构图如下：
## 使用场景
服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 ** 不重要** 或 ** 不紧急** 的服务或任务进行服务的 ** 延迟使用** 或 ** 暂停使用**。
## 服务降级要考虑的问题
- 核心和非核心服务
- 是否支持降级，降级策略
- 业务放通的场景，策略
# 断路器
熔断机制是应对雪崩效应的一种微服务链路保护机制。当链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。服务断路器的设计架构图如下：
## 断路器状态
服务调用方为每一个调用服务 (调用路径) 维护一个状态机，在这个状态机中有`3`种状态：
- `CLOSED` ：默认状态。断路器观察到请求失败比例没有达到阈值，断路器认为被代理服务状态良好
- `OPEN` ：断路器观察到请求失败比例已经达到阈值，断路器认为被代理服务故障，打开开关，请求不再到达被代理的服务，而是快速失败
- `HALF OPEN` ：断路器打开后，为了能自动恢复对被代理服务的访问，会切换到半开放状态，去尝试请求被代理服务以查看服务是否已经故障恢复。如果成功，会转成`CLOSED`状态，否则转到`OPEN`状态
## 熔断策略
- **指定时间内失败率超过指定阈值**
- **指定时间内失败次数超过指定阈值**
- **可根据熔断等级，适当调整熔断超时时间**
## 恢复策略
- **指定时间内失败率低于指定阈值**
- **指定时间内失败次数低于指定阈值**
## 拒绝策略
- **直接抛出指定异常**
- **调用降级策略进行处理**
## 常见问题
使用断路器需要考虑一些问题：
- 针对不同的异常，定义不同的熔断后处理逻辑
- 设置熔断的时长，超过这个时长后切换到`HALF OPEN`进行重试
- 记录请求失败日志，供监控使用
- 主动重试，比如对于`connection timeout`造成的熔断，可以用异步线程进行网络检测，比如`telenet`，检测到网络畅通时切换到`HALF OPEN`进行重试
- 补偿接口，断路器可以提供补偿接口让运维人员手工关闭
- 重试时，可以使用之前失败的请求进行重试，但一定要注意业务上是否允许这样做
## 使用场景
- 服务故障或者升级时，让客户端快速失败
- 失败处理逻辑容易定义
- 响应耗时较长，客户端设置的`read timeout`会比较长，防止客户端大量重试请求导致的连接、线程资源不能释放
# 链路追踪
## ThreadContext
`NDC` （ ） （ ） ， （ ） ， ， ， ， ，
NDC和MDC的原理是用了java的ThreadLocal类。可以针对不同线程存储信息。但是今天在log4j2上使用时发现没有找到NDC和MDC。查找官方文档，
微服务架构中的链路追踪主要是用于快速定位故障点， ，
### NDC
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
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` 的使用方式如下：
```java
@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);
}
}
```
### ThreadContext
在 `log4j 2.x` 中，使用 `ThreadContext` 代替了 `MDC` 和 `NDC` ，使用方式如下：
```java
@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` ：
- `%X{key}` ：打印指定的信息
- `%x` ：打印堆栈中的所有信息
打印日志的格式案例如下：
```xml
< PatternLayout pattern = "%d{HH:mm:ss.SSS} [%t] %-5level %X{REQUEST_ID} %logger{36} - %msg%n" / >
```
## ThreadLocal
在全链路跟踪框架中， ， ，
### InheritableThreadLocal
`InheritableThreadLocal` 是 JDK 本身自带的一种线程传递解决方案。顾名思义，由当前线程创建的线程，将会继承当前线程里 ThreadLocal 保存的值。Thread内部为InheritableThreadLocal开辟了一个单独的ThreadLocalMap。在父线程创建一个子线程的时候， ，
### TransmittableThreadLocal
Transmittable ThreadLocal是阿里开源的库， ， ， ， ， ，
## Zipkin
Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。
### Zipkin基本架构
在服务运行的过程中会产生很多链路信息， ， ， ，
### Zipkin核心组件
Zipkin有四大核心组件
- **Collector**
一旦Collector采集线程获取到链路追踪数据， ， ，
- **Storage**
Zipkin Storage最初是为了在Cassandra上存储数据而构建的， ， ， ， ，
- **Query Service**
链路追踪数据被存储和索引之后，
- **Web UI**
Zipkin 提供了基本查询、搜索的web界面，
# 幂等机制
## 幂等场景
**场景一：前端重复提交**
用户注册，用户创建商品等操作，前端都会提交一些数据给后台服务，后台需要根据用户提交的数据在数据库中创建记录。如果用户不小心多点了几次，后端收到了好几次提交，这时就会在数据库中重复创建了多条记录。这就是接口没有幂等性带来的 bug。
**场景二：黑客拦截重放**
接口请求参数被黑客拦截，然后进行重放。
**场景三：接口超时重试**
对于给第三方调用的接口，有可能会因为网络原因而调用失败，这时，一般在设计的时候会对接口调用加上失败重试的机制。如果第一次调用已经执行了一半时，发生了网络异常。这时再次调用时就会因为脏数据的存在而出现调用异常。
**场景四：消息重复消费**
在使用消息中间件来处理消息队列，且手动 ack 确认消息被正常消费时。如果消费者突然断开连接，那么已经执行了一半的消息会重新放回队列。当消息被其他消费者重新消费时，如果没有幂等性，就会导致消息重复消费时结果异常，如数据库重复数据，数据库数据冲突，资源重复等。
## 解决方案
### Token机制实现
通过token机制实现接口的幂等性,这是一种比较通用性的实现方法。示意图如下：
具体流程步骤：
- 客户端会先发送一个请求去获取 token，
- 客户端第二次调用业务请求的时候必须携带这个 token
- 服务端会校验这个 token， ， ，
- 如果校验失败，说明 redis 中已经没有对应的 token， ，
注意：
- 对 redis 中是否存在 token 以及删除的代码逻辑建议用 Lua 脚本实现，保证原子性
- 全局唯一 ID 可以考虑用百度的 uid-generator、美团的 Leaf 去生成
**设计Token**
- 要申请，一次有效性，可以限流
- 使用删除操作来判断Token。删除成功代表校验通过
- 如果用 select+delete 来校验 Token， ， ，
- 设置短期过期时间，
### 基于MySQL实现
这种实现方式是利用 mysql 唯一索引的特性。示意图如下：
具体流程步骤：
- 建立一张去重表，其中某个字段需要建立唯一索引
- 客户端去请求服务端，服务端会将这次请求的一些信息插入这张去重表中
- 因为表中某个字段带有唯一索引，如果插入成功，证明表中没有这次请求的信息，则执行后续的业务逻辑
- 如果插入失败，则代表已经执行过当前请求，直接返回
### 基于Redis实现
这种实现方式是基于 SETNX 命令实现的 SETNX key value： ， ：
具体流程步骤：
- 客户端先请求服务端，会拿到一个能代表这次请求业务的唯一字段
- 将该字段以 SETNX 的方式存入 redis 中，并根据业务设置相应的超时时间
- 如果设置成功，证明这是第一次请求，则执行后续的业务逻辑
- 如果设置失败，则代表已经执行过当前请求，直接返回
### 基于业务参数实现
**第一阶段**： ， ： ， ，
**第二阶段**： ， ， ， ：
**第三阶段**： ， （ ） ， ， ， ，
```java
String KEY = "user_opt:U="+userId + "M=" + method + "P=" + reqParamMD5;
```
**第四阶段**： ， ： （ ） ， （ ） ， ， ， （ ）
**总结**
将业务参数（ ） （ ） ， ， ， ：
```java
String KEY = "前缀标识:U=" + < 用户唯一标识> + "M=" + < 接口唯一标识> + "P=" + < 业务参数MD5签名>;
```
# 分布式ID
分布式ID的两大核心需求：
- **全局唯一**
- **趋势有序**
- **高性能**
## UUID
基于 `UUID` 实现全球唯一的ID。用作订单号`UUID`这样的字符串没有丝毫的意义，看不出和订单相关的有用信息；而对于数据库来说用作业务`主键ID`，它不仅是太长还是字符串，存储性能差查询也很耗时，所以不推荐用作`分布式ID`。
**优点**
- 生成足够简单，本地生成无网络消耗，具有唯一性
**缺点**
- 无序的字符串，不具备趋势自增特性
- 没有具体的业务含义，看不出和订单相关的有用信息
- 长度过长16 字节128位， ， ， ， `UUID` 的无序性会导致数据位置频繁变动，严重影响性能
**适用场景**
- 可以用来生成如token令牌一类的场景， ， ，
- 可以用于无纯数字要求、无序自增、无可读性要求的场景
## 数据库自增ID
基于数据库的 `auto_increment` 自增ID完全可以充当 `分布式ID` 。当我们需要一个ID的时候， ， ， ， ， ：
```mysql
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');
```
**优点**
- 实现简单， ，
**缺点**
- DB单点存在宕机风险，
**适用场景**
- 小规模的，数据访问量小的业务场景
- 无高并发场景，插入记录可控的场景
## 数据库多主模式
单点数据库方式不可取， ， ， ，
**问题**： ， ？
**解决方案**：设置`起始值`和`自增步长`
MySQL_1 配置：
```mysql
set @@auto_increment_offset = 1; -- 起始值
set @@auto_increment_increment = 2; -- 步长
-- 自增ID分别为：
```
MySQL_2 配置：
```mysql
set @@auto_increment_offset = 2; -- 起始值
set @@auto_increment_increment = 2; -- 步长
-- 自增ID分别为：
```
那如果集群后的性能还是扛不住高并发咋办？ ：
从上图可以看出， ， ， ，
**优点**
- 解决DB单点问题
**缺点**
- 不利于后续扩容，而且实际上单个数据库自身压力还是大，依旧无法满足高并发场景
**适用场景**
- 数据量不大，数据库不需要扩容的场景
这种方案，除了难以适应大规模分布式和高并发的场景，普通的业务规模还是能够胜任的，所以这种方案还是值得积累。
## 数据库号段模式
号段模式是当下分布式ID生成器的主流实现方式之一， ， ， ， ， ：
```mysql
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 ：
step ：代表号段的长度
version ： ， ，
| id | biz_type | max_id | step | version |
| ---- | -------- | ------ | ---- | ------- |
| 1 | 101 | 1000 | 2000 | 0 |
等这批号段ID用完， ， ， ，
```mysql
update id_generator set max_id=max_id+${step}, version = version+1 where version=${version} and biz_type=${XXX}
```
由于多业务端可能同时操作，所以采用版本号`version`乐观锁方式更新，这种`分布式ID`生成方式不强依赖于数据库，不会频繁的访问数据库，对数据库的压力小很多。
## Redis模式
`Redis` 也同样可以实现，原理就是利用`redis`的 `incr` 命令实现ID的原子性自增。
```shell
# 初始化自增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重复的情况， ，
**优点**
- 有序递增，可读性强
- 能够满足一定性能
**缺点**
- 强依赖于Redis，
- 占用宽带，而且需要考虑网络延时等问题带来地性能冲击
**适用场景**
- 对性能要求不是太高， ， ， ， ， ，
Redis的方案其实可靠性有待考究， ， ，
## 雪花算法（ ）
雪花算法（ ） ， ，
`Snowflake` 生成的是Long类型的ID， ， ， ： （ ） `时间戳` （ ） `机器ID` （ ） `数据中心` （ ） `自增值` （ ） ，
- **第一个bit位（ ） ： ， ， ， ，
- **时间戳部分（ ） ） ， ； ， < < 41 ) / ( 1000L * 60 * 60 * 24 * 365 ) = 69 年
- **工作机器id（ ）
- **序列号部分（ ） ：
**优点**
- 每秒能够生成百万个不同的ID，
- 时间戳值在高位， ， ，
- 能够根据业务场景数据库节点布置灵活挑战bit位划分，
**缺点**
- **强依赖于机器时钟**， ， ， ， ， ，
**适用场景**
- 雪花算法有很明显的缺点就是时钟依赖， ， ，
## 百度（ ）
`uid-generator` 是基于`Snowflake`算法实现的，与原始的`snowflake`算法不同在于，`uid-generator`支持自`定义时间戳`、`工作机器ID`和 `序列号` 等各部分的位数，而且`uid-generator`中采用用户自定义`workId`的生成策略。
`uid-generator` 需要与数据库配合使用，需要新增一个`WORKER_NODE`表。当应用启动时会向数据库表中去插入一条数据， ，
**对于`uid-generator` ID组成结构**：
`workId` 占用了22个bit位， ， ， ，
## 美团（ ）
`Leaf` 同时支持号段模式和`snowflake`算法模式，可以切换使用。
### Leaf-segment数据库方案
在建一张表`leaf_alloc`：
```mysql
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机器上是1~1000的号段， ， ， ， ， ：
```mysql
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
```
**优点**
- Leaf服务可以很方便的线性扩展，
- ID号码是趋势递增的8byte的64位数字，
- 容灾性高： ， ，
- 可以自定义max_id的大小，
**缺点**
- ID号码不够随机， ，
- TP999数据波动大， ，
- DB宕机会造成整个系统不可用
**双buffer优化**
针对第二个缺点是因为在号段用完后才会出现，因此可以在消耗完前提前获取下一个号段，从而解决问题：
采用双buffer的方式， ， ， ， ， ：
- 每个biz-tag都有消费速度监控， （ ） ， ，
- 每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新
**Leaf高可用容灾**
对于第三点“DB可用性”问题， ， ，
### Leaf-snowflake方案
Leaf-segment方案可以生成趋势递增的ID， ， ， ， ， ， ， ， ， ， ：
- 启动Leaf-snowflake服务， ， （ ）
- 如果有注册过直接取回自己的workerID（ ） ，
- 如果没有注册过， ， ，
## 滴滴（ ）
`Tinyid` 是基于号段模式原理实现的与`Leaf`如出一辙， （ （ （
`Tinyid` 提供`http`和`tinyid-client`两种方式接入。
### Http方式接入
**第一步**：
```shell
git clone https://github.com/didi/tinyid.git
```
**第二步**：创建数据表
```mysql
-- 建表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， ，
`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');
```
**第三步**：配置数据库
```properties
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`后测试
```properties
# 获取分布式自增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
```
### Java客户端方式接入
**第一步**：引入依赖
```xml
< dependency >
< groupId > com.xiaoju.uemc.tinyid< / groupId >
< artifactId > tinyid-client< / artifactId >
< version > ${tinyid.version}< / version >
< / dependency >
```
**第二步**：配置文件
```properties
tinyid.server =localhost:9999
tinyid.token =0f673adf80504e2eaa552f5d791b644c
```
**第三步**：
```java
// 获取单个分布式自增ID
Long id = TinyId . nextId( " test " );
// 按需批量分布式自增ID
List< Long > ids = TinyId . nextId( " test " , 10 );
```
# 分布式锁
**何为分布式锁？**
- 当在分布式模型下，数据只有一份（或有限制），此时需要利用锁的技术控制某一时刻修改数据的进程数
- 用一个状态值表示锁，对锁的占用和释放通过状态值来标识
**分布式锁的特点**
- **互斥性**：和我们本地锁一样互斥性是最基本，但是分布式锁需要保证在不同节点的不同线程的互斥
- **可重入性**：同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁
- **锁超时**：和本地锁一样支持锁超时，防止死锁
- **高性能和高可用**：加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级
- **支持阻塞和非阻塞**： （ ）
- **支持公平锁和非公平锁（可选）**：公平锁的意思是按照请求加锁的顺序获得锁，非公平锁就相反是无序的
**三种方案对比**
- **从理解的难易程度角度（从低到高）**：数据库 > 缓存 > Zookeeper
- **从实现的复杂性角度（从低到高）**：
- **从性能角度（从高到低）**：缓存 > Zookeeper >= 数据库
- **从可靠性角度（从高到低）**：
## MySQL
### 基于唯一索引(`insert`)实现
**记录锁的乐观锁方案**。基于数据库的实现方式的核心思想是：在数据库中创建一个表，表中包含**方法名**等字段，并在**方法名字段上创建唯一索引**，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。
#### 优缺点
**优点**
- 实现简单、易于理解
**缺点**
- 没有线程唤醒，获取失败就被丢掉了
- 没有超时保护，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁
- 这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用
- 并发量大的时候请求量大，获取锁的间隔，如果较小会给系统和数据库造成压力
- 这把锁只能是非阻塞的， ， ， ，
- 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁，因为数据中数据已经存在了
- 这把锁是非公平锁，所有等待锁的线程凭运气去争夺锁
#### 实现方案
```mysql
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='锁定中的方法';
```
**① 获取锁**：想要执行某个方法，就使用这个方法名向表中插入数据
```mysql
INSERT INTO method_lock (lock_key, lock_timeout, remarks) VALUES ('methodName', '2021-07-19 18:20:00', '测试的methodName');
```
**② 释放锁**：释放锁的时候就删除记录
```mysql
DELETE FROM method_lock WHERE lock_key ='methodName';
```
#### 问题与解决
- 强依赖数据库可用性，是一个单点（部署双实例）
- 没有失效时间，一旦解锁失败，就会导致死锁（添加定时任务扫描表）
- 一旦插入失败就会直接报错， （ ， ）
- 是非重入锁，同一线程在没有释放锁之前无法再次获得该锁（添加字段记录机器和线程信息，查询时相同则直接分配）
- 非公平锁（建中间表记录等待锁的线程，根据创建时间排序后进行依次处理）
- 采用唯一索引冲突防重，在大并发情况下有可能会造成锁表现象（采用程序生产主键进行防重）
### 基于表字段版本号实现
**版本号对比更新的乐观锁方案**。一般是通过为数据库表添加一个 `version` 字段来实现读取出数据时，将此版本号一同读出。之后更新时，对此版本号加 `1` ，在更新过程中，会对版本号进行比较，如果是一致的，没有发生改变，则会成功执行本次操作；如果版本号不一致，则会更新失败。实际就是个`CAS`过程。
#### 优缺点
**缺点**
- 该方式使原本一次的update操作， ：
- 如果业务场景中的一次业务流程中，多个资源都需要用保证数据一致性，那么如果全部使用基于数据库资源表的乐观锁，就要让每个资源都有一张资源表，这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作，在高并发的要求下，对数据库连接的开销一定是无法忍受的
- 乐观锁机制往往基于系统中的数据存储逻辑，因此可能会造成脏数据被更新到数据库中
### 基于排他锁(`for update`)实现
**基于排它锁的悲观锁方案**。通过在select语句后增加`for update`来获取锁，数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁，我们可以认为获得排它锁的线程即可获得分布式锁。释放锁通过`connection.commit();`操作，提交事务来实现。
#### 优缺点
**优点**
- 实现简单、易于理解
**缺点**
- 排他锁会占用连接，产生连接爆满的问题
- 如果表不大，可能并不会使用行锁
- 同样存在单点问题、并发量问题
#### 实现方案
**建表脚本**
```mysql
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 = '锁定中的方法';
```
**加解锁操作**
```java
/**
* 加锁
*/
public boolean lock() {
// 开启事务
connection.setAutoCommit(false);
// 循环阻塞，等待获取锁
while (true) {
// 执行获取锁的sql
String sql = "select * from methodLock where lock_key = xxx for update";
// 创建prepareStatement对象，
ps = conn.prepareStatement(sql);
// 获取查询结果集
int result = ps.executeQuery();
// 结果非空，加锁成功
if (result != null) {
return true;
}
}
// 加锁失败
return false;
}
/**
* 解锁
*/
public void unlock() {
// 提交事务，解锁
connection.commit();
}
```
## Redis
### 锁的问题
#### 非原子操作
`加锁操作` 和后面的`设置超时时间`是分开的，并`非原子操作`。解决方案：
**方案一：
```java
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
```
在redis中还有`set`命令是原子操作，加锁和设置超时时间，一个命令就能轻松搞定。其中：
- `lockKey` ：锁的标识
- `requestId` ：
- `NX` ：只在键不存在时，才对键进行设置操作
- `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]);
```
#### 忘了释放锁
加锁之后，每次都要达到了超时时间才释放锁，不会有点不合理。如果不及时释放锁，会有很多问题。合理流程如下：
释放锁的伪代码如下：
```java
try{
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
} finally {
unlock(lockKey);
}
```
#### 释放了别人的锁
自己只能释放自己加的锁，不允许释放别人加的锁。
**方案一：
伪代码如下：
```java
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
```
#### 大量失败请求
在秒杀场景下， ？ ， ， ， ， （ ）
**解决方案：自旋锁**
在规定的时间， ， （ ， ， ） ， ， ， ， ，
```java
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;
```
#### 锁重入问题
假设需要获取一颗满足条件的菜单树。需要在接口中从根节点开始， ， ， ， ， ， ， ？
递归方法中加锁的伪代码（会出现异常）如下：
```java
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实现可重入锁**
伪代码如下：
```java
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();
}
}
```
#### 锁竞争问题
如果有大量需要写入数据的业务场景， ， ， ， ？
**读写锁**
读写锁的特点：
- **读与读是共享的，不互斥**
- **读与写互斥**
- **写与写互斥**
我们以redisson框架为例， ：
```java
RReadWriteLock readWriteLock = redisson.getReadWriteLock("readWriteLock");
RLock rLock = readWriteLock.readLock();
try {
rLock.lock();
//业务操作
} catch (Exception e) {
log.error(e);
} finally {
rLock.unlock();
}
```
写锁的伪代码如下：
```java
RReadWriteLock readWriteLock = redisson.getReadWriteLock("readWriteLock");
RLock rLock = readWriteLock.writeLock();
try {
rLock.lock();
//业务操作
} catch (InterruptedException e) {
log.error(e);
} finally {
rLock.unlock();
}
```
将读锁和写锁分开，最大的好处是提升读操作的性能，因为读和读之间是共享的，不存在互斥性。而我们的实际业务场景中，绝大多数数据操作都是读操作。所以，如果提升了读操作的性能，也就会提升整个锁的性能。
**锁分段**
此外，为了减小锁的粒度，比较常见的做法是将大锁：`分段`。
比如在秒杀扣库存的场景中， ， ， ， ，
为了提升系统性能， ， ： ，
在秒杀的过程中， ， ， ， ， ，
**注意**：将锁分段虽说可以提升系统的性能，但它也会让系统的复杂度提升不少。因为它需要引入额外的路由算法，跨段统计等功能。我们在实际业务场景中，需要综合考虑，不是说一定要将锁分段。
#### 锁超时问题
如果线程A加锁成功了， ， ，
**解决方案：自动续期**
自动续期的功能是获取锁之后开启一个定时任务， ， ， ， ， ，
我们可以使用`TimerTask`类，来实现自动续期的功能：
```java
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run(Timeout timeout) throws Exception {
//自动续期逻辑
}
}, 10000, TimeUnit.MILLISECONDS);
```
获取锁之后， ， ， ， ： ， ， ：
```lua
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
redis.call('pexpire', KEYS[1], ARGV[1]);
return 1;
end;
return 0;
```
**需要**： ， ， ， ， ，
#### 主从复制的问题
如果redis存在多个实例。比如： ， ，
比如锁A刚加锁成功master就挂了， ， ， ， ，
**解决方案：
RedissonRedLock解决问题的思路如下：
1. 需要搭建几套相互独立的redis环境，
2. 每套环境都有一个redisson node节点
3. 多个redisson node节点组成了RedissonRedLock
4. 环境包含：单机、主从、哨兵和集群模式，可以是一种或者多种混合
在这里我们以主从为例，架构图如下：
RedissonRedLock加锁过程如下：
1. 获取所有的redisson node节点信息， ， ，
2. 如果在N个节点当中， ，
3. 如果在N个节点当中， ，
4. 如果中途发现各个节点加锁的总耗时，大于等于设置的最大等待时间，则直接返回失败
从上面可以看出， ， ， ， ， ：
- 需要额外搭建多套环境，申请更多的资源，需要评估一下成本和性价比
- 如果有N个redisson node节点， ， ， ， ，
**场景选择**
在实际业务场景， ， ， ： （ ） （ ） （ ）
- 如果你的实际业务场景，更需要的是**保证数据一致性**，
比如： ， ， ，
- 如果你的实际业务场景，更需要的是**保证数据高可用性**。那么请使用AP类型的分布式锁
比如： ， ， ，
其实， ， ， ， ，
### LUA+SETNX+EXPIRE
先用`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脚本来保证原子性（ ） ， ：
```java
/**
* 使用Lua脚本，
*/
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脚本进行解锁操纵，
*/
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， ， ， ， ， ， ， ， ， ：
STW导致的锁过期问题， ：
- **方案一： 模拟CAS乐观锁的方式， （ ）
- **方案二：
客户端1加锁的锁key默认生存时间才30秒， ， ， ？ ！ ， ， ， ， ， ，
### SET-NX-EX
**方案**：
- `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` ，那么客户端获取锁失败，可以在稍后再重试
**① 加锁**：
```java
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`
**② 解锁**：
```java
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;
}
```
- luaScript 这个字符串是个lua脚本， ，
- jedis.eval(String,list,list);这个命令就是去执行lua脚本， ，
**③ 重试**
如果在业务中去拿锁如果没有拿到是应该阻塞着一直等待还是直接返回，这个问题其实可以写一个重试机制，根据重试次数和重试时间做一个循环去拿锁，当然这个重试的次数和时间设多少合适，是需要根据自身业务去衡量的。
```java
/**
* 重试机制
* @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
Redisson是一个在Redis的基础上实现的Java驻内存数据网格（ ） ， （ ） （ （ ） （ ） （ ） ，
**特性功能**
- 支持 Redis 单节点（ ） （ ） （ ） （ ）
- 程序接口调用方式采用异步执行和异步流执行两种方式
- 数据序列化，
- 单个集合数据分片， ，
- 提供多种分布式对象， ： ， ， ，
- 提供丰富的分布式集合， ： ， ， ， ， ， ，
- 分布式锁和同步器的实现， （ ） ， （ ） ， （ ） ， （ ） ， （ ） ， （ ）
- 提供先进的分布式服务， （ ） ， （ ） ， （ ） ， （ ） （ ）
**Watch dog**
总体的Redisson框架的分布式锁类型大致如下：
- **可重入锁**
- **公平锁**
- **联锁**
- **红锁**
- **读写锁**
- **信号量**
- **可过期信号量**
- **闭锁（/倒数闩）**
**实现方案**
添加依赖
```xml
<!-- 方式一： - java -->
< dependency >
< groupId > org.redisson< / groupId >
< artifactId > redisson< / artifactId >
< version > 3.11.4< / version >
< / dependency >
<!-- 方式二： - springboot -->
< dependency >
< groupId > org.redisson< / groupId >
< artifactId > redisson-spring-boot-starter< / artifactId >
< version > 3.11.4< / version >
< / dependency >
```
定义接口
```java
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);
}
```
实现分布式锁
```java
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实例上创建锁， ， ， ， ，
## Zookeeper
### Apache-Curator
如上借助于临时顺序节点， ， ， ：
- **InterProcessMutex**：就是公平锁的实现。可重入、独占锁
- **InterProcessSemaphoreMutex**：不可重入、独占锁
- **InterProcessReadWriteLock**：读写锁
- **InterProcessSemaphoreV2**：共享信号量
- **InterProcessMultiLock**：多重共享锁 （将多个锁作为单个实体管理的容器）
### 使用案例
```java
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));
}
}
```
# 分布式限流
当系统的处理能力不能应对外部请求的突增流量时，为了不让系统奔溃，必须采取限流的措施。
**限流目标**：
- 防止被突发流量冲垮
- 防止恶意请求和攻击
- 保证集群服务中心的健康稳定运行（流量整形）
- API经济的细粒度资源量（ ）
## 限流指标
目前主流的限流方法多采用 HPS 作为限流指标。
### TPS
**TPS（ ）
> 但是对实操性来说， ， ， ， ， ，
### HPS
**HPS（ ） （ ） 。是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和。 它一般和TPS成正比关系，
> 如果一个请求完成一笔事务， ， ，
### QPS
**QPS（ ） （ ） ， ， ，
> 如果后台只有一台服务器，那 HPS 和 QPS 是等同的。但是在分布式场景下，每个请求需要多个服务器配合完成响应。
## 限流方案
### 固定窗口计数器(Fixed Window)
固定窗口计数器(Fixed Window)算法的实现思路非常简单，维护一个固定单位时间内的计数器，如果检测到单位时间已经过去就重置计数器为零。计数限首先维护一个计数器，将单位时间段当做一个窗口，计数器记录这个窗口接收请求的次数。
- 当次数少于限流阀值，就允许访问，并且计数器+1
- 当次数大于限流阀值，就拒绝访问
- 当前的时间窗口过去之后，计数器清零
假设单位时间是1秒， ， ， ， ， ， ：
伪代码如下：
```java
/**
* 固定窗口时间算法
* @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;
}
```
**存在问题**
但是，这种算法有一个很明显的**临界问题**： ， ， ， ，
### 滑动窗口计数器(Sliding Window)
滑动窗口计数器(Sliding Window)算法限流解决固定窗口临界值的问题。它将单位时间周期分为n个小周期， ，
一张图解释滑动窗口算法，如下：
假设单位时间还是1s， ， （ ） ， ， ， ， ，
我们来看下滑动窗口是如何解决临界问题的？
假设我们1s内的限流阀值还是5个请求， （ ） ， ， ， ， ， ， ， ， ，
**TIPS:** 当滑动窗口的格子周期划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。
滑动窗口算法**伪代码实现**如下：
```java
/**
* 单位时间划分的小周期（ ， ， ）
*/
private int SUB_CYCLE = 10;
/**
* 每分钟限流请求数
*/
private int thresholdPerMin = 100;
/**
* 计数器, k-为当前窗口的开始时间值秒，
*/
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 个问题：
- 流量超过就必须抛弃或者走降级逻辑
- 对流量控制不够精细，不能限制集中在短时间内的流量，也不能削峰填谷
### 漏桶算法(Leaky Bucket)
如下图所示，水滴持续滴入漏桶中，底部定速流出。如果水滴滴入的速率大于流出的速率，当存水超过桶的大小的时候就会溢出。规则如下：
- 请求来了放入桶中
- 桶内请求量满了拒绝请求
- 服务定速从桶内拿请求处理
可以看到水滴对应的就是请求。它的特点就是**宽进严出**，无论请求多少，请求的速率有多大，都按照固定的速率流出，对应的就是服务按照固定的速率处理请求。面对突发请求，服务的处理速度和平时是一样的，这其实不是我们想要的，在面对突发流量我们希望在系统平稳的同时，提升用户体验即能更快的处理请求，而不是和正常流量一样，循规蹈矩的处理。而令牌桶在应对突击流量的时候，可以更加的“激进”。
漏桶算法伪代码实现如下：
```java
/**
* 每秒处理数（出水率）
*/
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;
}
```
### 令牌桶算法(Token Bucket)
令牌桶和漏桶的原理类似，不过漏桶是**定速地流出**，而令牌桶是**定速地往桶里塞入令牌**，然后请求只有拿到了令牌才能通过，之后再被服务器处理。当然令牌桶的大小也是有限制的，假设桶里的令牌满了之后，定速生成的令牌会丢弃。规则：
- 定速的往桶内放入令牌
- 令牌数量超过桶的限制，丢弃
- 请求来了先向桶内索要令牌，索要成功则通过被处理，反之拒绝
可以看出令牌桶在应对突发流量的时候，桶内假如有 100 个令牌，那么这 100 个令牌可以马上被取走，而不像漏桶那样匀速的消费。所以在**应对突发流量的时候令牌桶表现的更佳**。
令牌桶算法伪代码实现如下：
```java
/**
* 每秒处理数（放入令牌数量）
*/
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 有可能超过系统的承载。
```lua
-- 获取调用脚本时传入的第一个 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 参数，为某个限流指标的 key
- 通过 `ARGV[1]` 获取传入的 limit 参数，为限流值
- 通过 `ARGV[2]` 获取限流区间 ttl
- 通过 `redis.call` ，拿到 key 对应的值（默认为 0） ， `INCRBY` 增加 1， （ ， `TTL` ）
不过上面代码是有问题的，如果 key 之前存在且未设置 `TTL` ，那么限速逻辑就会永远生效了（触发 limit 值之后），使用时需要注意。
令牌桶算法也是 Guava 中使用的算法，同样采用计算的方式，将时间和 Token 数目联系起来：
```lua
-- 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] 返回的为秒，
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)
-- 添加令牌的时间间隔（ ）
-- 计算生产 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
-- 两种情况： < =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（ ） ，
return moment_available - now_micros
```
## Nginx限流
### 控制速率(limit_req_zone)
`ngx_http_limit_req_module` 模块提供限制请求处理速率能力，使用`漏桶算法(leaky bucket)`。使用`limit_req_zone` 和`limit_req`两个指令， ：
```nginx
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)超过限流策略后拒绝请求的响应状态码，
limit_req_status 555;
# 设置(http,server,location)限流策略后打印的日志级别：
limit_req_log_level warn;
# 设置(http,server,location)启动无过滤模式。启用后不会过滤请求， ，
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":"访问高峰期，请稍后再试"}';
}
}
```
- **key**：定义限流对象，`$binary_remote_addr` 表示基于 `remote_addr` 来做限流，`binary_` 的目的是压缩内存占用量
- **zone**：定义共享内存区来存储访问信息，`myRateLimit:10m` 表示一个大小为10M， ，
- **rate**：设置最大访问速率，`rate=10r/s` 表示每秒最多处理10个请求。Nginx 实际上以毫秒为粒度来跟踪请求信息，因此 10r/s 实际上是限制： ， ，
- **burst**：处理突发流量
- `burst=20` 表示若同时有21个请求到达， ， ， ， ，
- `burst=20 nodelay` 表示20个请求立马处理， ， ， ，
### 控制并发连接数(limit_conn_zone)
`ngx_http_limit_conn_module` 提供了限制连接数的能力，利用`limit_conn_zone`和`limit_conn`两个指令即可。下面是Nginx官方例子：
```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)超过限流策略后拒绝请求的响应状态码，
limit_conn_status 555;
# 设置(http,server,location)限流策略后打印的日志级别：
limit_conn_log_level warn;
# 设置(http,server,location)启动无过滤模式。启用后不会过滤请求， ，
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处理后，
### lua限流
**第一步**：安装说明
环境准备：
```shell
yum install -y gcc gcc-c++ readline-devel pcre-devel openssl-devel tcl perl
```
安装drizzle http://wiki.nginx.org/HttpDrizzleModule：
```shell
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：
```shell
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
```
**第二步**：
`/usr/local/openresty/nginx/conf/nginx.conf` ：
```nginx
# 添加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， ，
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;
}
}
```
**第三步**：
`/usr/local/lua_test/redis_test.lua` ：
```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` ：
```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
';
```
**第四步**：验证结果
```shell
$ 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所产生经济活动的总和， ，
**借贷机制**
针对两个连续的限流时间窗切换时， ， （ ，
# 分布式缓存
## 淘汰算法
### 最不经常使用算法(LFU)
这个缓存算法使用一个计数器来记录条目被访问的频率。通过使用LFU缓存算法， ，
### 最近最少使用算法(LRU)
这个缓存算法将最近使用的条目存放到靠近缓存顶部的位置。当一个新条目被访问时， ， ， ， ，
一个缓存被访问后，近期再被访问的可能性很大。可以记录每个缓存记录的最近访问时间，最近未被访问时间最长的数据会被首先淘汰。
优点：实现简单，能适应访问热点
缺点：对偶发的访问敏感，影响命中率
簿记开销：时间 `O(1)` ，空间 `O(N)`
### 自适应缓存替换算法(ARC)
在IBM Almaden研究中心开发， ， ，
### 先进先出算法(FIFO)
FIFO是英文First In First Out 的缩写， ， ， ， ， ， ，
越早进入缓存的数据，其不再被访问的可能性越大。因此在淘汰缓存时，应选择在内存中停留时间最长的缓存记录。使用队列即可实现该策略：
优点：实现简单，适合线性访问的场景
缺点：无法适应特定的访问热点，缓存的命中率差
簿记开销：时间 `O(1)` ，空间 `O(N)`
### 最近最常使用算法(MRU)
这个缓存算法最先移除最近最常使用的条目。一个MRU算法擅长处理一个条目越久，
## 更新策略
缓存更新的策略主要分为三种：
- **Cache Aside Pattern（ ）
- **Read/Write Through Pattern（ ）
- **Write Behind Caching Pattern（ ）
**缓存使用场景**
**分布式系统中要么通过2PC、3PC或Paxos协议保证强一致性， ， ，
**缓存场景分析**
- 对于读多写少的数据，请使用缓存
- 为了保持数据库和缓存的一致性，会导致系统吞吐量的下降
- 为了保持数据库和缓存的一致性，会导致业务代码逻辑复杂
- 缓存做不到绝对一致性，但可以做到最终一致性
- 对于需要保证缓存数据库数据一致的情况，请尽量考虑对一致性到底有多高要求，选定合适的方案，避免过度设计
### Cache Aside(旁路缓存)
`Cache Aside（ ） 是最广泛使用的缓存模式之一，如果能正确使用 `Cache Aside` 的话，能极大的提升应用性能，`Cache Aside`可用来读或写操作。`Cache Aside`的提出是为了尽可能地解决缓存与数据库的数据不一致问题。
#### Read Cache Aside
`Cache Aside` 的读请求流程如下：
- **读的时候，先读缓存，缓存命中的话，直接返回数据**
- **缓存没有命中的话，就去读数据库，从数据库取出数据，放入缓存后，同时返回响应**
#### Write Cache Aside
`Cache Aside` 的写请求流程如下：
- **更新的时候，先更新数据库，然后再删除缓存**
### Read/Write Through(读写穿透)
`Read/Write Through（ ） 模式中，服务端把缓存作为主要数据存储。应用程序跟数据库缓存交互，都是通过**抽象缓存层**完成的。
#### Read Through
`Read Through` 和 `Cache Aside` 很相似，不同点在于程序不需要再去管理从哪去读数据（缓存还是数据库）。相反它会直接从缓存中读数据，该场景下是缓存去决定从哪查询数据。当我们比较两者的时候这是一个优势因为它会让程序代码变得更简洁。`Read Through`的简要流程如下
- **从缓存读取数据，读到直接返回**
- **如果读取不到的话，从数据库加载，写入缓存后，再返回响应**
该模式只在 `Cache Aside` 之上进行了一层封装，它会让程序代码变得更简洁，同时也减少数据源上的负载。流程如下：
#### Write Through
`Write Through` 模式下的所有写操作都经过缓存，每次向缓存中写数据时，缓存会把数据持久化到对应的数据库中去，且这两个操作都在一个事务中完成。因此，只有两次都写成功才是最终写成功。用写延迟保证了数据一致性。当发生写请求时，也是由**缓存抽象层**完成数据源和缓存数据的更新，流程如下：
- **向缓存中写数据，并向数据库写数据**
- **使用事务保证一致性，两者都写成功才成功**
当使用 `Write Through ` 的时候一般都配合使用 `Read Through` 。`Write Through `适用情况有：
- **需要频繁读取相同数据**
- **不能忍受数据丢失（相对 `Write Behind` 而言）和数据不一致**
**`Write Through` 的潜在使用例子是银行系统。**
### Write Behind(异步写入)
`Write Behind（ ， ） 和 `Read/Write Through` 相似，都是由 `Cache Provider` 来负责缓存和数据库的读写。它们又有个很大的不同：`Read/Write Through` 是同步更新缓存和数据的，`Write Behind` 则是只更新缓存，不直接更新数据库，通过**批量异步**的方式来更新数据库。
这种方式下，缓存和数据库的一致性不强，**对一致性要求高的系统要谨慎使用**。但是它适合频繁写的场景， ， ，
- **优点**：是数据写入速度非常快，适用于频繁写的场景
- **缺点**：是缓存和数据库不是强一致性，对一致性要求高的系统慎用
## 数据一致性
一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。
- **强一致性**：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大
- **弱一致性**：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态
- **最终一致性**：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型
### 业务延时双删
先删除缓存，再更新数据库中如何避免脏数据？采用延时双删策略。
- **先删除缓存**
- **再写数据库**
- **休眠1秒后再次删除缓存**（
**① 读写分离架构**
读写架构中，先删除缓存，再更新数据库中如何避免脏数据？采用延时双删策略。
- **先淘汰缓存**
- **再写数据库**
- **休眠1秒后再次淘汰缓存**（
**② 延时双删导致吞吐量降低**
延时双删的方式同步淘汰策略导致了吞吐量降低如何解决？
- **将第二次删除作为异步**
### MQ重试机制
不管是**延时双删**还是**Cache-Aside的先操作数据库再删除缓存**，都可能会存在第二步的删除缓存失败，导致的数据不一致问题，可以引入**删除缓存重试机制**来解决。
流程如下：
- **更新数据库数据**
- **删除缓存中的数据，可此时缓存服务出现不可用情况，造成无法删除缓存数据**
- **当删除缓存数据失败时，将需要删除缓存的 Key 发送到消息队列 (MQ) 中**
- **应用自己消费需要删除缓存 Key 的消息**
- **应用接收到消息后，删除缓存，如果删除缓存确认 MQ 消息被消费，如果删除缓存失败，则让消息重新入队列，进行多次尝试删除缓存操作**
### biglog异步删除
重试删除缓存机制会造成好多**业务代码入侵**。其实还可以这样优化：通过数据库的**binlog来异步淘汰key**。
流程如下：
- **更新数据库数据**
- **MySQL将数据更新日志写入binlog中**
- **Canal订阅& 消费MySQL binlog，
- **调用应用删除缓存接口**
- **删除缓存数据**
- **Redis 不可用时，将更新数据的表名及 ID 发送到 MQ 中**
- **应用接收到消息后，删除缓存，如果删除缓存确认 MQ 消息被消费，如果删除缓存失败，则让消息重新入队列，进行多次尝试删除缓存操作，直到缓存删除成功为止**
## 策略选择
### 删除or更新
操作缓存的时候，到底是删除缓存呢，还是更新缓存？日常开发中，我们一般使用的就是`Cache-Aside`模式。有些小伙伴可能会问， `Cache-Aside` 在写入请求的时候，为什么是**删除缓存而不是更新缓存**呢？
我们在操作缓存的时候，到底应该删除缓存还是更新缓存呢？我们先来看个例子：
1. 线程A先发起一个写操作，
2. 线程B再发起一个写操作，
3. 由于网络等原因，
4. 线程A更新缓存
这时候， （ ） ， （ ） ，
- 如果你写入的缓存值，是经过复杂计算才得到的话。更新缓存频率高的话，就浪费性能啦
- 在写数据库场景多，读数据场景少的情况下，数据很多时候还没被读取到，又被更新了，这也浪费了性能呢(实际上，写多的场景，用缓存也不是很划算的)
### 双写顺序
双写的情况下，先操作数据库还是先操作缓存？`Cache-Aside` 缓存模式中，有些小伙伴还是会有疑问，在写请求过来的时候，为什么是**先操作数据库呢**？为什么**不先操作缓存**呢？比如一条数据同时存在数据库、缓存，现在你要更新此数据，不管先更新数据库，还是先更新缓存，这两种方式都有问题。
**方案一：先更新数据库，后更新缓存**
如下案例会造成数据不一致。
A先把数据库更新为 123， ， ， ， ， ， ， ， ， ，
**方案二：先更新缓存，再更新数据库**
如下案例也同样可能数据不一致。
缓存更新成功，数据为最新的，但数据库更新失败，回滚了，还是旧数据。还是非原子操作的原因。
**注意**：先操作数据库再操作缓存，不一样也会导致数据不一致嘛？它俩又不是原子性操作的。这个是**会的**，但是这种方式，一般因为删除缓存失败等原因，才会导致脏数据，这个概率就很低。接下来我们再来分析这种**删除缓存失败**的情况，**如何保证一致性**。
### 缓存更新
除了缓存服务器自带的缓存失效策略之外（ ） ， ：
- **LRU/LFU/FIFO**：都是属于当**缓存不够用**时采用的更新算法
适合内存空间有限，数据长期不变动，基本不存在数据一不致性业务。比如一些一经确定就不允许变更的信息。
- **超时剔除**：给缓存数据设置一个过期时间
适合于能够容忍一定时间内数据不一致性的业务，比如促销活动的描述文案。
- **主动更新**：如果数据源的数据有更新，则主动更新缓存
对于数据的一致性要求很高，比如交易系统，优惠劵的总张数。
常见数据更新方式有两大类，其余基本都是这两类的变种：
**方式一：先删缓存，再更新数据库**
这种做法是遇到数据更新， ， ， ：
- A请求需要更新数据， ，
- B请求来读取数据
- B请求看到缓存里没有， （ ）
- A请求更新DB
可以看到B请求将脏数据写入了缓存， ， （ ， ） ，
**方式二：先更新数据库，再删除缓存**
上图的右侧部分可以看到在A更新DB和删除缓存之间B请求会读取到老数据， ， ，
**删除缓存而非更新缓存原因**
上图可以看到我们用的是删除缓存，而不是更新缓存，原因如下图：
上图我用操作代替了删除或更新， ， ， ； ， ， ， ，
**缓存更新请求处理流程**
我们来一起看看完整的请求处理流程：
**注意**：不同颜色代表不同请求。
- 请求1更新DB
- 请求2查询同一个数据， ， ，
- 请求1删除缓存
- 请求3再来请求时缓存里没有， ，
- 后续的请求就会直接读取缓存了
## 缓存问题
### 缓存雪崩
当**大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机**时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是**缓存雪崩**的问题。
发生缓存雪崩的原因及解决方案：
**① 大量数据同时过期**
- **均匀设置过期时间**：给缓存数据的过期时间加上一个随机数
- **互斥锁**：加个互斥锁，保证同一时间内只有一个请求来构建缓存
- **二级缓存**：每一级缓存的失效时间都不同
- **队列控制**： ，
- **热点数据缓存永远不过期**
- **物理不过期**：
- **逻辑过期**： ， ，
**② Redis故障宕机**
- **服务熔断或请求限流机制**：启动服务熔断机制，暂停业务对缓存服务访问，直接返回错误；或启用限流机制
- **构建Redis缓存高可靠集群**：
- **开启Redis持久化机制**：一旦重启，能直接从磁盘上自动加载数据恢复内存中的数据
### 缓存击穿
如果缓存中的**某个热点数据过期**了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是**缓存击穿**的问题，如秒杀活动。
缓存击穿跟缓存雪崩很相似，可以认为缓存击穿是缓存雪崩的一个子集。应对缓存击穿可以采取以下两种方案：
- **互斥锁方案**：保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值
- **热点数据缓存永远不过期**
- **物理不过期**：
- **逻辑过期**： ， ，
### 缓存穿透
当用户访问的数据，**既不在缓存中，也不在数据库中**，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是**缓存穿透**的问题。
缓存穿透的发生一般有这两种情况：
- **业务误操作**：缓存中的数据和数据库中的数据都被误删除了，所以导致缓存和数据库中都没有数据
- **黑客恶意攻击**：故意大量访问某些读取不存在数据的业务
应对缓存穿透的方案，常见的方案有三种：
- **拦截非法请求**
- **布隆过滤器**：构造一个`BloomFilter`过滤器，初始化全量数据，当接到请求时，在`BloomFilter`中判断这个key是否存在， ， ，
- **缓存空对象**：
**布隆过滤器工作原理**
布隆过滤器由「**初始值都为 0 的位图数组**」和「 **N 个哈希函数** 」两部分组成。当我们在写入数据库数据时，在布隆过滤器里做个标记，这样下次查询数据是否在数据库时，只需要查询布隆过滤器，如果查询到数据没有被标记，说明不在数据库中。布隆过滤器会通过 3 个操作完成标记：
- 第一步：使用 N 个哈希函数分别对数据做哈希计算，得到 N 个哈希值
- 第二步：将第一步得到的 N 个哈希值对位图数组的长度取模，得到每个哈希值在位图数组的对应位置
- 第三步：将每个哈希值在位图数组的对应位置的值设置为 1
举个例子，假设有一个位图数组长度为 8，
## Hot Key
### 产生原因
- **用户消费的数据远大于生产的数据**（热卖商品、热点新闻、热点评论、明星直播）
在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。
- **请求分片集中，超过单 Server 的性能极限**
在服务端读数据进行访问时，往往会对数据进行分片切分，此过程中会在某一主机 Server 上对相应的 Key 进行访问，当访问超过 Server 极限时，就会导致热点 Key 问题的产生。
### 问题危害
当某一热点 Key 的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。如果热点过于集中，热点 Key 的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。当缓存服务崩溃后，此时再有请求产生，会缓存到后台 DB 上，
- **流量集中，达到物理网卡上限**
- **请求过多，缓存分片服务被打垮**
- **DB 击穿，引起业务雪崩**
### 发现热key
- 预估热key， ，
- 在客户端进行统计
- 可用Proxy，
- 利用redis自带命令， ，
- 利用流式计算引擎统计访问次数，
### 解决方案
通常的解决方案主要集中在对客户端和 Server 端进行相应的改造。
#### 读写分离
架构中各节点的作用如下：
- **SLB 层做负载均衡**
- **Proxy 层做读写分离自动路由**
- **Master 负责写请求**
- **ReadOnly 节点负责读请求**
- **Slave 节点和 Master 节点做高可用**
实际过程中 Client 将请求传到 SLB， ，
#### 热点数据
该方案通过主动发现热点并对其进行存储来解决热点 Key 的问题。首先 Client 也会访问 SLB， ，
- **Proxy 本地缓存热点，读能力可水平扩展**
- **DB 节点定时计算热点数据集合**
- **DB 反馈 Proxy 热点数据**
- **对客户端完全透明，不需做任何兼容**
### 热点key处理
#### 热点数据的读取
在热点 Key 的处理上主要分为写入跟读取两种形式，在数据写入过程当 SLB 收到数据 K1 并将其通过某一个 Proxy 写入一个 Redis， ， ， ，
#### 热点数据的发现
对于 db 上热点数据的发现，首先会在一个周期内对 Key 进行请求统计，在达到请求量级后会对热点 Key 进行热点定位，并将所有的热点 Key 放入一个小的 LRU 链表内，在通过 Proxy 请求进行访问时，若 Redis 发现待访点是一个热点， ，
- **基于统计阀值的热点统计**
- **基于统计周期的热点统计**
- **基于版本号实现的无需重置初值统计方法**
- **DB 计算同时具有对性能影响极其微小、内存占用极其微小等优点**
## Big Key
Big Key指数据量大的key， ， ， ， ，
### 常见场景
- 热门话题下的讨论
- 大V的粉丝列表
- 序列化后的图片
- 没有及时处理的垃圾数据
### 大Key影响
- 大key会大量占用内存，
- Reids性能下降，
- 在主动删除或过期删除时操作时间过长而引起服务阻塞
### 如何发现大Key
- redis-cli --bigkeys命令。可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。但如果Redis的key比较多，
- 获取生产Redis的rdb文件， ， ，
### 解决方案
优化big key的原则就是string减少字符串长度， ：
- string类型的big key， ， ， ，
- 设置一个阈值， ， ，
- 评估`大key`所占的比例，由于很多框架采用`池化技术`， ： ， ，
- 颗粒划分， ， ，
- 大key要设置合理的过期时间，
## 其它问题
### 缓存预热
缓存预热是指系统上线后， ， ， ， ， ， ， ， ，
**缓存预热思路**
- **数据量不大的时候**：工程启动的时候进行加载缓存动作
- **数据量大的时候**：设置一个定时任务脚本，进行缓存的刷新
- **数据量太大的时候**：优先保证热点数据进行提前加载到缓存
**预热解决方案**
- 直接写个缓存刷新页面，上线时手工操作下
- 数据量不大，可以在项目启动的时候自动进行加载
- 定时刷新缓存
**缓存加载策略**
- **使用时加载缓存**。当需要使用缓存数据时，就从数据库中查出，第一次查出后，接下来的请求都能从缓存中查询到数据
- **预加载缓存**。在项目启动的时候，预加载类似“国家信息、货币信息、用户信息，新闻信息”等不是经常变更的数据
### 缓存降级
缓存降级是指当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
**降级的最终目的是保证核心服务可用，即使是有损的**。而且有些服务是无法降级的（如加入购物车、结算）。
**分级降级预案：**
- **一般**：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级
- **警告**： （
- **错误**：
- **严重错误**：比如因为特殊原因数据错误了，此时需要紧急人工降级
### 热点数据
数据库里有2000W数据， ，
当 Redis 中的数据集上升到一定大小的时候，就需要实施数据淘汰策略，以保证 Redis 的内存不会被撑爆；那么如何保证 Redis 中的数据都是热点数据，需要先看看 Redis 有哪些数据淘汰策略。
**Redis 数据淘汰策略**
- volatile-lru： ，
- volatile-ttl： ，
- volatile-random： ，
- allkeys-lru： ，
- allkeys-random：
- no-eviction： ， ，
**到了4.0版本后，又增加以下两种淘汰策略：**
- volatile-lfu： ， （ ）
- allkeys-lfu： ，
**如何选择策略规则**
针对题目中的问题，还需要考虑数据的分布情况：
- 如果数据呈现幂律分布， ， ，
- 如果数据呈现平等分布， ，
# 消息队列
## 痛点问题
### 总耗时长
有些复杂业务系统， ， ，
这种同步接口调用的方式`总耗时比较长`，非常影响用户的体验，特别是在网络不稳定的情况下，极容易出现接口超时问题。
### 耦合性高
很多复杂的业务系统，一般都会拆分成多个子系统。我们在这里以用户下单为例，请求会先通过订单系统，然后分别调用：支付系统、库存系统、积分系统 和 物流系统。
系统之间`耦合性太高`，如果调用的任何一个子系统出现异常，整个请求都会异常，对系统的稳定性非常不利。
### 突发流量
有时候为了吸引用户，我们会搞一些活动，比如秒杀等。
如果用户少还好，不会影响系统的稳定性。但如果用户突增，一时间所有的请求都到数据库，可能会导致数据库无法承受这么大的压力，响应变慢或者直接挂掉。
对于这种 `突发流量` ，无法保证系统的稳定性。
## 功能特性
对于上面传统模式的三类问题，
### 异步
同步接口调用导致响应时间长的问题， ， ，
系统A作为消息的生产者， ， ，
### 解耦
子系统间耦合性太大的问题， ， ，
订单系统作为消息生产者， ， ， ， ， ，
### 消峰
由于突然出现的`突发流量`， ，
订单系统接收到用户请求之后， ， ， ， ， ， ， ，
## 引发问题
引入MQ后让我们子系统间耦合性降低了， ， ，
### 重复消息
重复消费问题可以说是MQ中普遍存在的问题， ？
- **消息生产者产生了重复的消息**
- **Kafka和RocketMQ的offset被回调了**
- **消息消费者确认失败**
- **消息消费者确认时超时了**
- **业务系统主动发起重试**
如果重复消息不做正确的处理，会对业务造成很大的影响，产生重复的数据，或者导致数据异常，比如会员系统多开通了一个月的会员。
### 数据一致性
很多时候， ， ： ， ， ， ，
如果下单和送积分在同一个事务中，要么同时成功，要么同时失败，是不会出现数据一致性问题的。但由于跨系统调用，为了性能考虑，一般不会使用强一致性的方案，而改成达成最终一致性即可。
### 消息丢失
同样消息丢失问题， ， ？
- **消息生产者发生消息时， ，
- **MQ服务器持久化时，
- **Kafka和RocketMQ的offset被回调时，
- **消息消费者刚读取消息， ， ，
导致消息丢失问题的原因挺多的，`生产者`、`MQ服务器`、`消费者` 都有可能产生问题，在这里就不一一列举了。最终的结果会导致消费者无法正确的处理消息，而导致数据不一致的情况。
### 消息顺序
有些业务数据是有状态的，比如订单有：下单、支付、完成、退货等状态，如果订单数据作为消息体，就会涉及顺序问题了。如果消费者收到同一个订单的两条消息，第一条消息的状态是下单，第二条消息的状态是支付，这是没问题的。但如果第一条消息的状态是支付，第二条消息的状态是下单就会有问题了，没有下单就先支付了？
消息顺序问题是一个非常棘手的问题，比如：
- `Kafka` 同一个`partition`中能保证顺序，但是不同的`partition`无法保证顺序
- `RabbitMQ` 的同一个`queue`能够保证顺序，但是如果多个消费者同一个`queue`也会有顺序问题
如果消费者使用多线程消费消息， ， ， ， ，
### 消息堆积
如果消息消费者读取消息的速度， ， ， ， ， ，
以下单开通会员为例，若消息出现堆积，会导致用户下单后，很久之后才能变成会员，这种情况肯定会引起大量用户投诉。
### 系统复杂度提升
这里说的系统复杂度和系统耦合性是不一样的， ： ， ， ， ， ，
MQ的机制需要： ， ， ： ， ， ， ， ， ，
## 解决引发问题
MQ是一种趋势， ， ？
### 重复消息问题
不管是由于生产者产生的重复消息， ， ， ， ， ， ， ， ， ， ：
- **在消费放使用messageId做唯一索引进行幂等处理**
- **在消费方根据业务唯一标识（如订单号、流水号）进行幂等处理 —— 推荐**
### 数据一致性问题
数据一致性分为强一致性、弱一致性和最终一致性。而MQ为了性能考虑使用的是`最终一致性`，那么必定会出现数据不一致的问题。这类问题大概率是因为消费者读取消息后，业务逻辑处理失败导致的，这时候可以增加`重试机制`。重试分为：`同步重试` 和 `异步重试` 。业务处理失败后，可以采用以下三种方式进行重试：
- **同步重试**
- 立即重试3-5次， ，
- **异步重试**
- 立刻写入`重试表`，
- 消费失败后，
有些消息量比较小的业务场景， ， ， ， ， ， ， ， ， ， ，
### 消息丢失问题
不管你是否承认有时候消息真的会丢， ，
为了解决这个问题，可以增加一张`消息发送表`， ， ， ， ， ， （ ） ， ，
这样不管是由于生产者、MQ服务器、还是消费者导致的消息丢失问题，
### 消息顺序问题
消息顺序问题是非常常见的问题，以`Kafka`消费订单消息为例。订单有：下单、支付、完成、退货等状态，这些状态是有先后顺序的，如果顺序错了会导致业务异常。解决这类问题之前，我们先确认一下，消费者是否真的需要知道中间状态，只知道最终状态行不行？
其实很多时候，只需要知道的是最终状态，这时可以把流程优化一下：
这种方式可以解决大部分的消息顺序问题。但如果真的有需要保证消息顺序的需求。订单号路由到不同的`partition`，同一个订单号的消息，每次到发到同一个`partition`。
### 消息堆积问题
如果消费者消费消息的速度小于生产者生产消息的速度，将会出现消息堆积问题。那么消息堆积问题该如何解决呢？这个要看消息是否需要保证顺序。如果不需要保证顺序，可以读取消息之后用多线程处理业务逻辑。
这样就能增加业务逻辑处理速度，解决消息堆积问题。但线程池的核心线程数和最大线程数需要合理配置，不然可能会浪费系统资源。如果需要保证顺序，可以读取消息之后，将消息按照一定规则分发到多个队列中，然后在队列中用单线程处理。
## 使用场景
其实MQ相关的内容还有很多， ：
### 延迟队列
延迟队列存储的对象肯定是对应的延时消息， ， ， ， ， ：
如电商中， ， ，
```java
Message msg = new Message("order", "订单001".getBytes());
// 延迟30分钟
msg.setDelayTimeLevel(16);
SendResult sendResult = producer.send(msg);
```
### 死信队列
当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。在消息队列 RocketMQ 中， （ ） ， （ ）
**死信消息**
- 不会再被消费者正常消费
- 有效期与正常消息相同，均为 3 天，
**死信队列**
- 一个死信队列对应一个 Group ID，
- 如果一个 Group ID 未产生死信消息，消息队列 RocketMQ 不会为其创建相应的死信队列
- 一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic
死信队列中的数据需要通过新订阅该topic进行消费。每个topic被消费后， ：
- **%RETRY%消费组名称**
- **%DLQ%消费组名称**
订单失效问题比较麻烦的地方就是如何能够实时获取失效的订单。对于这种问题一般有两种解决方案：
- **定时任务处理**
用户下订单后先生成订单信息， （ ） ， ，
- **延时任务处理**
当用户下订单后， ， ， ， ：
- **Java自带的DelayedQuene队列**
这是java本身提供的一种延时队列， ， ，
- **使用redis监听key的过期来实现**
当用户下订单后把订单信息设置为redis的key， ， ， （ ） ， ， ， ， ，
- **MQ死信队列实现**
### 事务问题
# 分布式事务
一般来讲， ， （ ） ， ， ， ， ， ， ， ， ， ， ， ，
**什么是分布式事务？**
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。一个大的操作由N多的小的操作共同完成。而这些小操作又分布在不同的服务上。针对于这些操作， ，
**TCC**和**可靠消息最终一致性方案**是在生产中最常用。一个要求强一致，一个要求最终一致。**TCC**用于强一致主要用于核心模块，例如交易/订单等。**最终一致方案**一般用于边缘模块例如库存， ， ，
## 分布式理论
### 事务一致性
**可靠程度**：强一致性 > 顺序一致性 > 因果一致性 > 最终一致性 > 弱一致性。
- **强一致性/线性一致性（ ）
- **顺序一致性（ ）
- **因果一致性（ ）
- **最终一致性（ ）
- **弱一致性（ ）
### ACID特性
`ACID` 注重一致性，是传统关系型数据库的设计思路。`ACID`是数据库（ ） ：
- **Atomicity（ ）
- **Consistency（ ）
- **Isolation（ ）
- **Durability（ ）
### CAP理论
`CAP` 理论的核心思想是任何基于网络的数据共享系统最多只能满足数据一致性（`Consistency`）、可用性（`Availability`）和网络分区容忍（`Partition Tolerance`）三个特性中的两个。
- **一致性（ ）
- **可用性（ ）
- **分区容错性（ ）
这三个特性只能满足其中两个，牺牲另一个。大部分系统也都是如此：
- **一般来说分布式集群都会保证P优先**。即集群部分节点坏死不影响整个集群的使用， ， ，
- **如果追求强一致性，那么势必会导致可用性下降**。比如在Master-Slave的场景中， ， ， ， ， ， ，
### BASE理论
`BASE` 关注高可用性。`BASE`理论是对`CAP`理论的延伸，核心思想是即使无法做到强一致性(`Strong Consistency`，
- **基本可用(Basically Available)**：指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用
- **软状态( Soft State)**：指允许系统存在中间状态，而该中间状态不会影响系统整体可用性
- **最终一致性( Eventual Consistency)**：指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果， ： ， ，
## 弱一致性算法
### Gossip协议
Gossip 协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。根据 Base 理论，如果你需要实现最终一致性，那么就可以通过 Gossip 协议实现这个目标。Gossip协议的核心一共是三块内容： （ ） （ ） （ ）
作为一种异步修复、实现最终一致性的协议，反熵在存储组件中应用广泛，比如 Dynamo、InfluxDB、Cassandra， ， ， ， ， ， ，
#### 直接邮寄（ ）
所谓直接邮寄，就是直接发送更新数据，当数据发送失败时，将数据缓存下来，然后重传。比如下图中，节点 A 直接将更新数据发送给了节点 B、D：
虽然直接邮寄实现起来比较容易，数据同步也很及时，但可能会因为缓存队列满了而丢数据。 也就是说，只采用直接邮寄是无法实现最终一致性的。
#### 反熵（ ）
熵， ， ， ， ， ， ， ， ， ， ，
**推方式**
推方式，就是将自己的所有副本数据，推给对方，修复对方副本中的熵：
**拉方式**
拉方式，就是拉取对方的所有副本数据，修复自己副本中的熵：
**推拉方式**
推拉方式，就是同时修复自己副本和对方副本中的熵：
虽然反熵很实用，但是执行反熵时，相关的节点都是已知的，而且节点数量不能太多，如果是一个动态变化或节点数比较多的分布式环境，反熵就不适用了。那么当你面临这个情况要怎样实现最终一致性呢？答案就是谣言传播。
#### 谣言传播（ ）
谣言传播，广泛地散播谣言，它指的是当一个节点有了新数据后，这个节点变成活跃状态，并周期性地联系其他节点向其发送新数据，直到所有的节点都存储了该新数据。比如下图中，节点 A 向节点 B、D 发送新数据，节点 B 收到新数据后，变成活跃节点，然后节点 B 向节点 C、D 发送新数据：
谣言传播非常具有传染性，它适合动态变化的分布式系统。
### Quorum NWR算法
CAP理论中的一致性一般指的是强一致性， ， ， ， ， ， ， ， ， ， ？ ， ，
**Quorum NWR三要素**
Quorum NWR 中有三个要素： ，
Quorum NWR 是非常实用的一个算法，能有效弥补 AP 型系统缺乏强一致性的痛点， ， ，
#### N（ ）
N 表示副本数， （ ） ， ， （ ， ） ， ， ，
在实现 Quorum NWR 的时候，我们需要实现自定义副本数的功能，比如，用户可以指定 DATA-1 具有 2 个副本，
#### W（ ）
W， （ ） ， ， ， ， ， ，
#### R（ ）
R， （ ） ， ， ， ， ， ，
N、W、R 值的不同组合，会产生不同的一致性效果，具体来说，有这么两种效果：
- 当 W + R > N 的时候，对于客户端来讲，整个系统能保证强一致性，一定能返回更新后的那份数据
- 当 W + R < = N 的时候，对于客户端来讲，整个系统只能保证最终一致性，可能会返回旧数据
我这里以DATA-2为例解释下， ， ， ， ， ， ， ； ， ， ， ，
### PBFT算法
我在《共识问题》一章中提到过， ： （ ， ） （ ， ） ， ， ， ， ： ， ， ， （ ） ， ？ ， ，
Raft 算法完全不适应有人作恶的场景， ， ， ，
此外， （ ） ，
#### oral message的问题
要理解PBFT算法， （ ） ？ ， ， （ ） ： ， ， ，
**PBFT算法流程**
PBFT 算法，通过签名（或消息认证码 MAC） ， ， ， （ ， ） ， ， ， ， ， ， （ ） ， ， （ ） ， ：
在PBFT算法中， ， ， ， （ ）
#### 预准备阶段
首先， （ ） ， ， （ ） ：
#### 准备阶段
B、C、D收到消息后 ， ， ， ， ， ，
所以， 接收到预准备消息之后， （ ） ， ， ：
#### 提交阶段
然后，当某个节点收到 2f 个包含相同指令的准备消息后， （ ） （
> 在这里， ： （ ） ？ ， ，
进入提交阶段后，各节点分别广播提交消息给其他节点，也就是告诉其他节点：“我已经准备好了，可以执行指令了”：
#### 响应
最后，当某个节点收到 2f + 1 个验证通过的提交消息后（其中 f 为叛徒数，包括自己），也就是说，大部分的节点们已经达成共识，这时可以执行指令了，那么该节点将执行客户端的指令，执行完毕后发送执行成功的消息给客户端。
最后，当客户端收到 f+1 个相同的响应（ ） ， ，
在PBFT算法中， ， ， ， ， ， （ ） ， ， ， ，
### PoW算法
谈起比特币， ？ ， ， ， ， ， （ ） ， ，
PoW算法， ， ， ， （ ） ， ，
#### 工作量证明
什么是工作量证明 (Proof Of Work，
那么，回到计算机世界，具体来说就是，客户端需要做一定难度的工作才能得出一个结果，验证方却很容易通过结果来检查出客户端是不是做了相应的工作。
比如小肖去Google面试， ， （ ） ， ， ：
**哈希运算**
既然工作量证明是通过指定的结果，来证明自己做过了一定量的工作。那么在区块链的 PoW 算法中需要做哪些工作呢？ （ ） ， ， ， ， （
```java
$ echo -n "tutuxiao" | sha256sum
bb2f0f297fe9d3b8669b6b4cec3bff99b9de596c46af2e4c4a504cfe1372dc52
```
那么我们如何通过哈希运算来证明工作量呢？
举个例子，我们给出的工作量要求是：基于一个基本的字符串（比如"tutuxiao"），在这个字符串后面添加一个整数值，然后对变更后的字符串进行 SHA256 哈希运算， （
```java
"tutuxiao0" => 01f28c5df06ef0a575fd0e529be9a6f73b1290794762de014ec84182081e118e
"tutuxiao1" => a2567c06fdb5775cb1e3ce17b72754cf146fcc6da75c8f1d87d7ab6a1b8c4523
...
"tutuxiao35022" =>
8afc85049a9e92fe0b6c98b02b27c09fb869fbfe273d0ab84ad8c5ac17b8627e
"tutuxiao35023" =>
0000ec5927ba10ea45a6822dcc205050ae74ae1ad2d9d41e978e1ec9762dc404
```
通过上面这个示例可以看到，工作量证明就是通过执行哈希运算，经过一段时间的计算后，得到符合条件的哈希值。在实际场景中，我们可以根据场景特点，制定不同的规则，比如，你可以试试分别运行多少次，才能找到恰好前 3 位和前 5 位为 0 的哈希值。
#### 区块链
区块链也是通过 SHA256 执行哈希运算， ， ，
- 区块头（ ） ： （ ） ，
- 区块体（ ） ： ，
在区块链中，给出的工作量要求是：对区块头执行 SHA256 哈希运算， ， ， （ ） ， ， ， ， ， ， ：
从上面这种工作量证明要求可以看出，算力越强，系统大概率会越先计算出这个哈希值。这也就意味着， 攻击者能挖掘一条比原链更长的攻击链，并将攻击链向全网广播。而按照约定，节点将接受更长的链，也就是攻击链，丢弃原链。就像下图的样子：
这样的话，按照比特币的区块链约定——“最长链胜出，其它节点在这条链基础上扩展”，那么如果坏人们掌握了 51% 的算力，就通过优势算力实现对最长链的争夺，也就是发起 51% 攻击， （ ）
即使攻击者只有 30% 的算力，他也有可能连续计算出多个区块的哈希值，挖掘出更长的攻击链，发动攻击； 另外，即使攻击者拥有 51% 的算力，他也有可能半天无法计算出一个区块的哈希值，也就是攻击失败。也就是说，能否计算出符合条件的哈希值，有一定的概率性，但长久来看，攻击者攻击成功的概率等同于攻击者算力的权重。
## 强一致性算法
**两阶段提交协议**
两阶段提交系统具有完全的C（ ） ， （ ） ， （ ）
首先，两阶段提交协议保证了副本间是完全一致的，这也是协议的设计目的。再者，协议在一个节点出现异常时，就无法更新数据，其服务可用性较低。最后，一旦协调者与参与者之间网络分化，无法提供服务。
**Paxos和Raft算法**
Paxos 协议和Raft算法都是强一致性协议。Paxos只有两种情况下服务不可用：
### Paxos协议
二阶段提交还是三阶段提交都无法很好的解决分布式的一致性问题， ， ， ， ，
**为什么在Paxos运行过程中， ？
- 如果半数以内的Acceptor失效时 还没确定最终的value， ， ，
- 如果半数以内的Acceptor失效时 已确定最终的value， ，
**如何产生唯一的编号呢？**
在《Paxos made simple》中提到的是让所有的Proposer都从不相交的数据集合中进行选择， ， ，
#### 核心思想
- 引入了多个Acceptor， ，
- Proposer用更大ProposalID来抢占临时的访问权， ，
- 保证一个N值， ，
- 新ProposalID的proposer比如认同前面提交的Value值，
**容错要求**
- 半数以内的Acceptor失效、任意数量的Proposer 失效，都能运行
- 一旦value值被确定， ， ，
#### 节点角色
Paxos 协议中，有三类节点:
- **Proposer（ ）
- Proposer 可以有多个， ， ，
- 不同的 Proposer 可以提出不同的甚至矛盾的 value， ， ，
- **Acceptor（ ）
- Acceptor 有 N 个，
- Acceptor 批准后才能通过。Acceptor 之间完全对等独立
- **Learner（ ）
- Learner 学习被批准的 value。所谓学习就是通过读取各个 Proposer 对 value 的选择结果，如果某个 value 被超过半数 Proposer 通过，则 Learner 学习到了这个 value
- 这里类似 Quorum 议会机制，某个 value 需要获得 W=N/2 + 1 的 Acceptor 批准， ，
#### 选举过程
- **Phase 1：
- **P1a：
Proposer 生成全局唯一且递增的ProposalID， ， ，
- **P1b：
Acceptor 收到 Prepare请求后，
- 如果是
- 在本地持久化 N，
- 回复请求， （ ， ）
- 做出承诺：
- 如果否，
- **Phase 2：
- **P2a：
经过一段时间后，
- 回复数量 > 一半的Acceptor数量， ， ，
- 回复数量 > 一半的Acceptor数量， ， ，
- 回复数量 ≤ 一半的Acceptor数量， ，
- **P2b：
Accpetor 收到 Accpet请求 后，判断：
- 收到的N >= Max_N (一般情况下是 等于)， ，
- 收到的N < Max_N ，则不回复或者回复提交失败
- **P2c：
经过一段时间后，
- 回复数量 > 一半的Acceptor数量， ， ，
- 回复数量 < = 一半的Acceptor数量， ，
- 收到一条提交失败的回复，则尝试更新生成更大的 ProposalID，
**最后，经过多轮投票后，达到的结果是：**
- 所有Proposer都 提交提案成功了，
- 过半数的 Acceptor都提交成功了，
#### 约束条件
Paxos 协议的几个约束：
- P1: 一个Acceptor必须接受(accept)第一次收到的提案
- P2a: 一旦一个具有value v的提案被批准(chosen)，
- P2b: 一旦一个具有value v的提案被批准(chosen)，那么以后任何 Proposer 提出的提案必须具有value v
- P2c: 如果一个编号为n的提案具有value v， ， ，
每轮 Paxos 协议分为准备阶段和批准阶段，在这两个阶段 Proposer 和 Acceptor 有各自的处理流程。Proposer与Acceptor之间的交互主要有4类消息通信， ：
这4类消息对应于paxos算法的两个阶段4个过程：
- Phase 1
- proposer向网络内超过半数的acceptor发送prepare消息
- acceptor正常情况下回复promise消息
- Phase 2
- 在有足够多acceptor回复promise消息时，
- 正常情况下acceptor回复accepted消息
### Raft协议
**三种角色**
**Raft是一个用于管理日志一致性的协议**。它将分布式一致性分解为多个子问题：**Leader选举（ ） （ ） （ ） （ ） ， ， （ ） （ ） （ ） ：
- **Leader（ ） ： ， ，
- **Follower（ ） ： ， ，
- **Candidate（ ） ：
三种状态的转换关系如下：
[](https://shuwoom.com/wp-content/uploads/2018/05/raft_change_user.png)
Raft要求系统在任意时刻最多只有一个Leader， （ ） ， ， ，
**Term（ ）
**Raft 算法将时间划分成为任意不同长度的任期（ ） （ ） ， ， ， ， ， ， ，
**RPC（ ）
**Raft 算法中服务器节点之间通信使用远程过程调用（ ） ， ：
- **RequestVote RPC**：候选人在选举期间发起
- **AppendEntries RPC**：领导人发起的一种心跳机制，复制日志也在该命令中完成
- **InstallSnapshot RPC**: 领导者使用该RPC来发送快照给太落后的追随者
#### 选举流程
**① Leader选举过程**
**Raft 使用心跳（ ） ， ， ， ， ， ， ：
- **赢得了多数的选票，
- 收到了Leader的消息，
- 没有服务器赢得多数的选票， ，
**② Leader选举的限制**
**在Raft协议中， ， ， ， ， ， ， ： ，
#### 日志复制
日志复制的目的是为了保证数据一致性。
- **日志复制的过程**
Leader选出后， （ ） ， ，
- 客户端的每一个请求都包含被复制状态机执行的指令
- leader把这个指令作为一条新的日志条目添加到日志中，
- 假如这条日志被安全的复制，领导人就应用这条日志到自己的状态机中，并返回给客户端
- 如果follower宕机或者运行缓慢或者丢包， ，
简而言之， ： ； ； ；
- **日志的组成**
日志由有序编号（ ） （ ） ， （ ）
上图显示，共有 8 条日志，提交了 7 条。提交的日志都将通过状态机持久化到磁盘中，防止宕机。
- **日志的一致性**
** ① 日志复制的两条保证**
- 如果不同日志中的两个条目有着**相同的索引和任期号，则它们所存储的命令是相同的**（ ：
- 如果不同日志中的两个条目有着**相同的索引和任期号，则它们之前的所有条目都是完全一样的**（原因：**每次 RPC 发送附加日志时**， **follower 发现和自己的日志不匹配，那么就拒绝接受这条日志** ，这个称之为**一致性检查**）
** ② 日志的不正常情况**
一般情况下， ， ， ：
下图阐述了一些Followers可能和新的Leader日志不同的情况。**一个Follower可能会丢失掉Leader上的一些条目， ，
** ③ 如何保证日志的正常复制**
Leader通过强制Followers复制它的日志来处理日志的不一致， ， ，
具体的操作是：**Leader会从后往前试**， ， （ ） ，
总结一下就是：**当 leader 和 follower 日志冲突的时候**，
#### 安全性
Raft增加了如下两条限制以保证安全性：
- 拥有**最新的已提交的log entry的Follower才有资格成为leader**
- **Leader只能推进commit index来提交当前term的已经复制到大多数服务器上的日志**， （ ）
#### 日志压缩
在实际的系统中，**不能让日志无限增长**，否则**系统重启时需要花很长的时间进行回放**， ， （ ） ，
**Snapshot中包含以下内容**：
- **日志元数据，最后一条已提交的 log entry的 log index和term**。这两个值在snapshot之后的第一条log entry的AppendEntries RPC的完整性检查的时候会被用上
- **系统当前状态**
当Leader要发给某个日志落后太多的Follower的log entry被丢弃， ， ， ， ，
#### 成员变更
- **常规处理成员变更存在的问题**
可能存在这样的一个时间点，两个不同的领导者在同一个任期里都可以被选举成功（双主问题），一个是通过旧的配置，一个通过新的配置。简而言之，成员变更存在的问题是增加或者减少的成员太多了，导致旧成员组和新成员组没有交集，因此出现了双主。
- **解决方案之一阶段成员变更**
Raft解决方法是每次成员变更只允许增加或删除一个成员（ ， ）
#### 常见问题
**问题1： ？
主要是分为leader选举、日志复制、日志压缩、成员变更等。
**问题2： ？
Raft发起选举的情况有如下几种：
- 刚启动时， ， ，
- 当leader挂掉后， ，
- 成员变更的时候会发起选举操作
**问题3： ？
**Raft确保新当选的Leader包含所有已提交（ ） ， ， ， ， ， ， ， ， ，
**问题4： ？
发生了网络分区或者网络通信故障，**使得Leader不能访问大多数Follwer了， ， ， ， ， ， ， ， ， （ ）
**问题5： ？
主要是通过日志复制实现数据一致性， ， ， ，
**问题6： ？
日志由有序编号（ ） ， （ ）
**问题7： ？
- Raft的leader有限制， ， ，
- Raft中Leader在每一个任期都有Term号
**问题8： ， ， ？
leader会通过RPC向follower发出日志复制， ， ，
**问题9： ？ ？ ？
在实际的系统中，**不能让日志无限增长**，否则**系统重启时需要花很长的时间进行回放**， ， （ ） ，
### ZAB协议
ZAB 协议全称Zookeeper Atomic Broadcast（ ） ，
ZAB 协议定义：**ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 `崩溃恢复` 和 `原子广播` 协议**。下面我们会重点讲这两个东西。基于该协议， `主备模式` 的系统架构来保持集群中各个副本之间`数据一致性`。具体如下图所示：
上图显示了 Zookeeper 如何处理集群中的数据。所有客户端写入数据都是写入到 主进程（称为 Leader） ， ， ） ，
那么复制过程又是如何的呢？复制过程类似 2PC，
#### 消息广播
ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 ** 二阶段提交过程**。对于客户端发送的写请求，全部由 Leader 接收， ， ）
**第一步**：将数据都复制到 Follwer 中
**第二步**：等待 Follwer 回应 Ack，
**第三步**：当超过半数成功回应，则执行 commit ，同时提交自己
通过以上 3 个步骤，就能够保持集群之间数据的一致性。实际上，在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，避免同步，实现异步解耦。还有一些细节：
- Leader 在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID， （ ） ，
- 在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞
- zookeeper集群中为保证任何所有进程能够有序的顺序执行，
- 实际上，这是一种简化版本的 2PC，
#### 崩溃恢复
当Leader崩溃， （ ： ） ：
- **ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交**
- **ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务**
所以，
#### 数据同步
当崩溃恢复之后， （ ） ， ，
**ZXID 生成**
在 ZAB 协议的事务编号 ZXID 设计中， ， ， ， ，
高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。同时，也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。基于这样的策略： ，
## 两阶段提交(2PC/XA)
**核心思路**
参与者将操作成功或失败结果通知协调者，再由协调者根据所有参与者反馈情况决定参与者是否要提交操作还是中止操作。
MySQL的事务就是通过**日志系统** 来完成两阶段提交的。两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，**由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交** 。
两阶段提交（ ， ） ：
- **第一阶段：预执行阶段(Prepare)**
- **第二阶段：确认阶段(Commit或Rollback)**
**伪代码**
```java
执行代码{
//一阶段
aStatus=参与者A.prepare()
bStatus=参与者B.prepare()
//二阶段
if aStatus and bStatus:
参与者A.commit()
参与者B.commit()
else:
参与者A.rollback()
参与者B.rollback()
}
```
**存在的问题**
- **同步阻塞**：整个消息链路是串行的，要等待响应结果，响应时间较长，不适合高并发的场景
- **单点故障**：一旦事务协调者出现故障，参与者会一直阻塞下去（第二阶段会导致所有参与者都处于锁定事务资源状态中）
- **数据不一致**： ， ， ，
### 预执行阶段(Prepare)
这个协议有 ** 两个角色** ， ， ：
- 协调者首先将命令 ** 写入日志**
- **发一个prepare命令** 给B和C节点这两个参与者
- B和C收到消息后， ，
- 将处理结果 ** 记录到日志** 系统
- 将结果 ** 返回** 给协调者
### 确认阶段(Commit/Rollback)
当A节点收到B和C参与者所有的确认消息后的执行流程如下：
- **判断** 所有协调者 ** 是否都可以提交**
- 如果可以则 ** 写入日志** 并且发起commit命令
- 在网络正常， ， ， （ ）
- 有一个不可以则 ** 写入日志** 并且发起rollback命令
- 第一阶段出现问题（比如数据逻辑问题），取消事务的提交
- 参与者收到协调者发起的命令，**执行命令**
- 将执行命令及结果 ** 写入日志**
- **返回结果** 给协调者
## 三阶段提交(3PC)
三阶段提交（ ， ） ，
- 第一阶段：
- 第二阶段：
- 第三阶段：
**伪代码**
```java
执行代码{
// 一阶段
参与者A.ping()
参与者B.ping()
// 二阶段
aStatus=参与者A.prepare().timeout(seconds).returnFalse()
bStatus=参与者B.prepare().timeout(seconds).returnFalse()
// 三阶段
if aStatus and bStatus:
参与者A.commit().timeout(seconds).returnFalse()
参与者B.commit().timeout(seconds).returnFalse()
else:
参与者A.rollback().timeout(seconds).returnFalse()
参与者B.rollback().timeout(seconds).returnFalse()
}
```
**改进后的效果**
- 在prepare前， ，
- 在prepare阶段，
- 数据不一致的问题，依旧没有解决，只是缓解了阻塞和单点问题
3PC针对2PC做了改进：
- **引入超时机制**： ，
- **在2PC的第一阶段和第二阶段中插入一个准备阶段**：保证了在最后提交阶段前确认各参与方是否可执行事务
### CanCommit阶段
协调者向参与者发送事务执行请求CanCommit， ，
### PreCommit阶段
协调者根据参与者反馈的结果来决定是否继续执行事务的PreCommit操作， ， ：
- 假如协调者收到参与者的反馈结果都是YES，
- **发送预提交请求**： ，
- **事务预提交**： ，
- **响应反馈**： ， ，
- 假如有任何一个参与者向协调者发送了NO响应， ， ，
- **发送中断请求**：协调者向所有参与者发送中断请求
- **中断事务**：参与者收到中断请求之后（或超时之后，仍未收到协调者的请求），执行事务中断操作
### DoCommit阶段
- **执行提交**
- **发送提交请求**： ，
- **事务提交**： ，
- **响应反馈**： ，
- **完成事务**： ，
- **中断事务**
- 在第二阶段中， ，
## 补偿机制(TCC)
**核心思想**：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。
两阶段提交（ ） （ ） ， ，
**伪代码：**
```java
执行代码{
//try阶段， ， ，
aStatus=参与者A.冻结资源().commit()
bStatus=参与者B.冻结资源().commit()
//Confirm阶段，
if aStatus and bStatus:
(参与者A.扣除资源().commit()).异步执行()
(参与者B.扣除资源().commit()).异步执行()
else:
//Cancel阶段，
(参与者A.解冻资源().commit()).异步执行()
(参与者B.解冻资源().commit()).异步执行()
}
```
**TCC优点：
TCC 事务机制相比于上面的2PC， ：
- **协调者单点**：由主业务方发起并完成这个业务活动。业务活动管理器（即业务微服务）也变成多点，引入集群
- **同步阻塞**：引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小
- **数据一致性**：有了补偿机制之后，由业务活动管理器控制一致性
**TCC缺点：
- **应用侵入性强**： ， `try` 、`confirm`、`cancel`三个接口
- **开发难度大**：代码开发量很大，为了要保证数据一致性 `confirm` 和 `cancel` 接口还必须实现幂等性
### Try阶段
这个阶段对各个服务的资源做检测以及对资源进行锁定或者预留。
### Confirm阶段
执行真正的业务操作， ， ， ，
### Cancel阶段
如果任何一个服务的业务方法执行出错， ， ， ， ，
### TCC案例场景
我们通过一个订单/库存的示例来理解。假设我们的分布式系统一共包含4个服务： ， ， ：
从正常流程看， ， ， ， ， （ ） ， ， ， ：
- **Try**：
- **Confirm**： ， ，
- **Cancel**： ， ，
> 注意： ，
**① Try阶段**
Try阶段一般用于锁定某个资源， ， ：
- 订单服务： ，
- 库存服务：先用一个冻结库存字段保存冻结库存数，而不是直接扣掉库存
- 积分服务：预增加会员积分
- 仓储服务： ，
**② Confirm阶段**
根据Try阶段的执行情况， ：
- **理想情况下， ，
- **部分服务Try执行失败，
Confirm阶段一般需要各个服务自己实现Confirm逻辑：
- 订单服务：
- 库存服务：将冻结库存数清零，同时扣减掉真正的库存
- 积分服务：将预增加积分清零，同时增加真实会员积分
- 仓储服务：修改销售出库单的状态为已创建-CREATED
> 注意： ， （ ， ， ） ， ， ，
**③ Cancel阶段**
如果Try阶段执行异常， ： ， ： ； ， ： ，
> 注意： ， ， ， ： ，
## 可靠消息方案(MQ)
**基于可靠消息方案**也称之为**最终一致性方案**，一般适用于**异步场景**的服务调用，是目前业务主流的分布式事务落地方案。
**实现原理：**
- 用mq消息异步传递子事务状态，
- 特点是由发起方决定是否回滚，也就是说只要发起者成功，后续的子事务基本都能成功。比如刷卡后，增加消费积分
**伪代码：**
```java
执行(事务主题, transId, 参与者){
name = 参与者.名称()
mq.setMsg(事务主题, transId, name, 'ping')
mStatus = 参与者.prepare();
mq.setMsg(事务主题, transId, name, 'prepare')
if mStatus:
excuted = 数据库是否提交(transId, name)
if not excuted:
参与者.commit()
mq.setMsg(事务主题, transId, name, 'commit')
else:
参与者.rollback()
mq.setMsg(事务主题, transId, name, 'rollback')
}
发起者A{
transId = getTransactionId()
执行(事务主题X, transId, 参与者A)
name = 参与者A.名称()
mq.订阅事件(事务主题X, name).触发函数(e){
transId = e.transacationId;
定时任务(事务主题X, transId, name)
if e.message == 'commit':
//启动下一个兄弟事务
mq.setMsg(事务主题X, transId, 参与者B名称, "wake up and work")
else if e.message == 'rollback':
mq.delMsg(事务主题X, transId)
}
}
参与者B{
name = 参与者B.名称()
mq.订阅事件(事务主题X, name).触发函数(e){
transId = e.transacationId;
定时任务(事务主题X, tranId,name)
if e.message == 'wake up and work':
执行(事务主题X, transId, 参与者B)
else if e.message == 'commit':
mq.delMsg(事务主题X, transId)
else if e.message == 'rollback':
//人工处理，因为一般都能执行成功
}
}
```
**优/缺点：**
- **优点**：消息数据独立存储，降低业务系统与消息系统间的耦合
- **缺点**：一次消息发送需要两次请求，业务服务需要提供消息状态查询的回调接口
### 方案一：本地消息表
基于本地消息表的分布式事务， ， ， ， ：
- **可靠消息服务**：存储消息，因为通常通过数据库存储，所以也叫本地消息表
- **生产者（上游服务）**：生产者是接口的调用方，生产消息
- **消费者（下游服务）**：消费者是接口的服务方，消费消息
**① 可靠消息服务**
可靠消息服务就是一个单独的服务，有自己的数据库，其主要作用就是存储消息（包含接口调用信息，全局唯一的消息编号），消息通常包含以下状态：
- **待确认**：上游服务发送待确认消息
- **已发送**：上游服务发送确认消息
- **已取消（终态**）：上游服务发送取消消息
- **已完成（终态）**：下游服务确认接口执行完成
**② 生产者**
服务调用方（ ） ， ， ， ：
- 生产者调用接口前， （ ， ） ， （ ） ，
- 生产者执行本地事务，本地事务执行成功并提交后，向可靠消息服务发送一条确认消息；如果本地执行失败，则向消息服务发送一条取消消息
- 可靠消息服务如果收到消息后， ， ； （ ， ）
> 注意：为了防止出现：生产者的本地事务执行成功，但是发送确认/取消消息超时的情况。可靠消息服务里一般会提供一个后台定时任务，不停的检查消息表中那些【待确认】的消息，然后回调生产者（上游服务）的一个接口，由生产者确认到底是取消这条消息，还是确认并发送这条消息。
通过上面这套机制，
**③ 消费者**
服务提供方（ ） ， ， ， ， ，
- **消费者消费消息失败，或者消费成功但执行本地事务失败**
针对这种情况， ， ， ， ， ， ，
- **如果消息重复投递，消费者接口逻辑需要实现幂等性，保证多次处理一个消息不会插入重复数据或造成业务数据混乱**
针对这种情况，消费者可以准备一张消息表，用于判重。消费者消费消息后，需要去本地消息表查看这条消息有没处理成功，如果处理成功直接返回成功
**总结**
这个方案的优点是简单，但最大的问题在于可靠消息服务是严重依赖于数据库的，即通过数据库的消息表来管理事务，不太适合并发量很高的场景。
### 方案二：消息中间件
许多开源的消息中间件都支持分布式事务， ， ， ， ， ：
**① prepare阶段**
- 生产者发送一个不完整的事务消息——HalfMsg到消息中间件， ， ，
- 生产者执行本地事务
> 注意： ， ，
**② 确认阶段**
- 如果生产者执行本地事务成功， （ ） ， ，
- 如果生产者执行本地事务失败， （ ） ，
> 消息中间件会定期去向生产者询问， ， ， ， ， ， ，
**③ ACK机制**
消费者消费完消息后， ， ， ， ， ， ，
### 应用案例
以一个电子商务支付系统的核心交易链路为示例，来更好的理解下可靠消息最终一致性方案。
**交易链路**
假设我们的系统的核心交易链路如下图。用户支付订单时， ， ， ， ：
上图中， ， ， ，
**事务执行**
接着， ， ， ：
- 当用户针对订单发起支付时， ， （ ， ， ）
- 然后， ， ，
- 如果订单接口服务收到链路失败的响应， ，
- 如果订单接口服务收到链路成功的响应， ， ，
- 仓储服务消费消息成功并执行完自身的逻辑后， ，
> 注意： ， ， ，
## 最大努力通知
最大努力通知的方案实现比较简单，适用于一些最终一致性要求较低的业务。执行流程：
- 系统 A 本地事务执行完之后，发送个消息到 MQ
- 这里会有个专门消费 MQ 的服务，这个服务会消费 MQ 并调用系统 B 的接口
- 要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B, 反复 N 次，最后还是不行就放弃
## Sagas事务模型
**原理:（消息）异步 + TCC（ ）
Saga事务模型又叫做长时间运行的事务。其核心思想是**「将长事务拆分为多个本地短事务」**， ， ，
**伪代码：**
```java
执行代码{
总事务开始()
new Thread(
aStatus = 参与者A.冻结资源().commit()
if aStatus:
参与者A.扣除资源().commit()
else
参与者A.解冻资源().commit()
).start()
new Thread(
bStatus = 参与者A.冻结资源().commit()
if bStatus:
参与者B.扣除资源().commit()
else:
参与者B.解冻资源().commit()
).start()
}
自行实现的定时任务{
if 全部参与者已完成事务:
if 全部扣除commit成功:
总事务成功()
else
已扣除资源退还()
总事务失败()
}
```
## Seate
Seata 是一款开源的分布式事务解决方案，
Seata主要分为以下三大模块：
- **TC (Transaction Coordinator) - 事务协调者**
维护全局和分支事务的状态，驱动全局事务提交或回滚。
- **TM (Transaction Manager) - 事务管理器**
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
- **RM (Resource Manager) - 资源管理器**
管理分支事务处理的资源， ，
> 注意：其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，
### AT模式
AT模式提供了无侵入自动补偿的事务模式， ，
**AT模式的前提：
- **基于支持本地 ACID事务的关系型数据库**
- **Java应用，
**整体机制**
- 第一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源
- 第二阶段
- 提交异步化，非常快速地完成
- 回滚通过一阶段的回滚日志进行反向补偿
### TCC模式
一个分布式的全局事务，整体是 ** 两阶段提交** 的模型。全局事务是由若干分支事务组成的，分支事务要满足 ** 两阶段提交** 的模型要求，即需要每个分支事务都具备自己的：
- 一阶段 prepare 行为
- 二阶段 commit 或 rollback 行为
根据两阶段行为模式的不同，我们将分支事务划分为：
- **Automatic (Branch) Transaction Mode**
- **Manual (Branch) Transaction Mode**
AT 模式基于 ** 支持本地 ACID 事务** 的 ** 关系型数据库**：
- 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录
- 二阶段 commit 行为：马上成功结束，**自动** 异步批量清理回滚日志
- 二阶段 rollback 行为：通过回滚日志，**自动** 生成补偿操作，完成数据回滚
TCC 模式，不依赖于底层数据资源的事务支持：
- 一阶段 prepare 行为：调用 ** 自定义** 的 prepare 逻辑
- 二阶段 commit 行为：调用 ** 自定义** 的 commit 逻辑
- 二阶段 rollback 行为：调用 ** 自定义** 的 rollback 逻辑
所谓 TCC 模式，是指支持把 ** 自定义** 的分支事务纳入到全局事务的管理中。
### Saga模式
Saga模式是SEATA提供的长事务解决方案， ， ， ，
**适用场景：**
- **业务流程长、业务流程多**
- **参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口**
**优势：**
- **一阶段提交本地事务，无锁，高性能**
- **事件驱动架构，参与者可异步执行，高吞吐**
- **补偿服务易于实现**
**缺点：**
- **不保证隔离性**
### XA模式
XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案，任何实现了 XA 协议的数据库都可以作为资源参与到分布式事务中，目前主流数据库，例如 MySql、Oracle、DB2、Oceanbase 等均支持 XA 协议。
XA 协议有一系列的指令， ； ， ；
在 XA 模式下，每一个 XA 事务都是一个事务参与者。分布式事务开启之后， ，
XA 模式下，用户只需关注自己的“业务 SQL”， ；
- **一阶段**
在 XA 模式的一阶段， ， （ ） ， ， ， （ ） ，
- **二阶段提交**
执行“xa commit”指令，
- **二阶段回滚**
执行“xa rollback”指令， ，
XA 模式下，用户只需关注“业务 SQL”， ，
### 性能优化
**优化一：同库模式**
通常一个 TM 会产生一笔主事务日志，一个 RM 会产生一条分支事务日志，每个分布式事务由一个 TM 和若干 RM 组成，一个分布式事务总共会有 1+N 条事务日志（
在默认情况下，分布式事务执行过程中客户端将事务日志发送给服务端，服务端再将事务日志存储至数据库中，一条事务日志的存储链路会有 2 次 TCP ，分别是“客户端到服务端”和“服务端到数据库”， 我们称这种模式为异库模式。
在异库模式下，分布式事务存储事务日志总共需要 2*（ ）
在事务执行过程中，客户端和服务端进行通信的目的是为了存储事务日志。如果客户端在存储事务日志时，绕过服务端直接将事务日志写入数据库（如上图“同库模式”所示），那么一笔事务日志的存储链路就由原来的 2 次 TCP 变成只需访问一次数据库便可，每条事务日志的存储减少了一次 TCP 通信，整个分布式事务就减少了 N+2 次 TCP 请求，分布式事务的性能大幅提升。**我们将客户端直接将事务日志存储至数据库的模式称为同库模式。**
**优化二：二阶段异步执行**
通常情况下，分布式事务发起方会依次执行一阶段和二阶段方法，然后结束分布式事务，返回结果。如果让分布式事务发起方执行完一阶段之后马上结束并返回结果，二阶段交由独立的线程或者进程异步执行，这样分布式事务的二阶段会晚几秒钟或者若干分钟执行，但事务的最终结果不会有任何改变。
二阶段异步执行之后，分布式事务的最终结果不会有任何影响，但是事务发起方要执行的内容减少一半（一阶段和二阶段都执行变成只执行一阶段），直观的用户感受是分布式事务的性能提升了 50%。
## 应用案例
### 订单库存案例
**电商经典模块**
**下单流程图**
**创建订单和扣件库存场景**
**分布式事务-技术方案**
#### 可靠消息方案
先说说MQ的分布式事务， ，
事务消息作为一种异步确保型事务， 将两个事务分支通过 MQ 进行异步解耦，
这个时候我们基本可以认为， ， ， ， ：
1. 查看商品详情（或购物车）
2. 计算商品价格和目前商品存在库存（生成订单详情）
3. 商品扣库存（调用商品库存服务）
4. 订单确认（生成有效订单）
订单创建完成后， ， ， ，
商品服务接受到orderCreate消息后就执行扣减库存的操作， ️ ， ， ， ， ：
- 如果扣减库存成功，将订单状态改为 “确认订单” ，下单成功
- 如果扣减库存失败，将订单状态改为 “失效订单” ，下单失败
这种模式将确认订单的流程变成异步化，**非常适合在高并发的使用**，但是，切记了，这个需要前端用户体验的一些改变，要配合产品来涉及流程。
上面使用MQ的方式确实是可以完成A和B操作， ， ， ， ， ， ， ， ，
#### TCC方案
TCC是服务化的二阶段变成模型， ， ， ， ， ，
- try阶段 try只是一个初步的操作， ， ，
- confirm阶段 confirm是在try阶段检查执行完毕后， ， ， ， ，
- cancel是取消执行， ， ，
接下来看看， ：
在try的时候， ， ， ， ， ， ， ， ：
在try的时候， ， ，
### 下单扣减库存
**传统模式**
**分库分表**
**Seata 优势**
实现分布式事务的方案比较多，常见的比如基于 `XA` 协议的 `2PC` 、`3PC`，基于业务层的 `TCC` ，还有应用消息队列 + 消息表实现的最终一致性方案，还有今天要说的 `Seata` 中间件，下边看看各个方案的优缺点。
#### 2PC
基于 XA 协议实现的分布式事务，
两阶段提交（`2PC`），对业务侵⼊很小，它最⼤的优势就是对使⽤⽅透明，用户可以像使⽤本地事务⼀样使⽤基于 XA 协议的分布式事务，能够严格保障事务 ACID 特性。
可 `2PC` 的缺点也是显而易见，它是一个强一致性的同步阻塞协议，事务执⾏过程中需要将所需资源全部锁定，也就是俗称的 `刚性事务` 。所以它比较适⽤于执⾏时间确定的短事务，整体性能比较差。
一旦事务协调者宕机或者发生网络抖动，会让参与者一直处于锁定资源的状态或者只有一部分参与者提交成功，导致数据的不一致。因此，在⾼并发性能⾄上的场景中，基于 XA 协议的分布式事务并不是最佳选择。
#### 3PC
三段提交（`3PC`）是二阶段提交（`2PC`）的一种改进版本 ，为解决两阶段提交协议的阻塞问题，上边提到两段提交，当协调者崩溃时，参与者不能做出最后的选择，就会一直保持阻塞锁定资源。
`2PC` 中只有协调者有超时机制，`3PC` 在协调者和参与者中都引入了超时机制，协调者出现故障后，参与者就不会一直阻塞。而且在第一阶段和第二阶段中又插入了一个准备阶段（如下图，看着有点啰嗦），保证了在最后提交阶段之前各参与节点的状态是一致的。
虽然 `3PC` 用超时机制，解决了协调者故障后参与者的阻塞问题，但与此同时却多了一次网络通信，性能上反而变得更差，也不太推荐。
#### TCC
所谓的 `TCC` 编程模式，也是两阶段提交的一个变种，不同的是 `TCC` 为在业务层编写代码实现的两阶段提交。`TCC` 分别指 `Try` 、`Confirm`、`Cancel` ，一个业务操作要对应的写这三个方法。
以下单扣库存为例，`Try` 阶段去占库存，`Confirm` 阶段则实际扣库存，如果库存扣减失败 `Cancel` 阶段进行回滚，释放库存。
TCC 不存在资源阻塞的问题，因为每个方法都直接进行事务的提交，一旦出现异常通过则 `Cancel` 来进行回滚补偿，这也就是常说的补偿性事务。
原本一个方法，现在却需要三个方法来支持，可以看到 TCC 对业务的侵入性很强，而且这种模式并不能很好地被复用，会导致开发量激增。还要考虑到网络波动等原因，为保证请求一定送达都会有重试机制，所以考虑到接口的幂等性。
#### 消息事务
消息事务（最终一致性）其实就是基于消息中间件的两阶段提交，将本地事务和发消息放在同一个事务里，保证本地操作和发送消息同时成功。下单扣库存原理图：
- 订单系统向 `MQ` 发送一条预备扣减库存消息， `MQ` 保存预备消息并返回成功 `ACK`
- 接收到预备消息执行成功 `ACK` ，订单系统执行本地下单操作，为防止消息发送成功而本地事务失败，订单系统会实现 `MQ` 的回调接口，其内不断的检查本地事务是否执行成功，如果失败则 `rollback` 回滚预备消息；成功则对消息进行最终 `commit` 提交。
- 库存系统消费扣减库存消息，执行本地事务，如果扣减失败，消息会重新投，一旦超出重试次数，则本地表持久化失败消息，并启动定时任务做补偿。
基于消息中间件的两阶段提交方案，通常用在高并发场景下使用，牺牲数据的强一致性换取性能的大幅提升，不过实现这种方式的成本和复杂度是比较高的，还要看实际业务情况。
#### Seata
`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` 字段。
```mysql
update user set name = '小富最帅' where name = '程序员内点事'
```
首先 Seata 的 `JDBC` 数据源代理通过对业务 SQL 解析，提取 SQL 的元数据，也就是得到 SQL 的类型（`UPDATE`），表（`user`），条件（`where name = '程序员内点事'`）等相关的信息。
先查询数据前镜像，根据解析得到的条件信息，生成查询语句，定位一条数据。
```mysql
select name from user where name = '程序员内点事'
```
紧接着执行业务 SQL，
```mysql
select name from user where id = 1
```
把业务数据在更新前后的数据镜像组织成回滚日志，将业务数据的更新和回滚日志在同一个本地事务中提交，分别插入到业务表和 `UNDO_LOG` 表中。
回滚记录数据格式如下：包括 `afterImage` 前镜像、`beforeImage` 后镜像、 `branchId` 分支事务ID、`xid` 全局事务ID
```json
{
"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。异步队列中会异步和批量地根据 `Branch ID` 查找并删除相应 `UNDO LOG` 回滚记录。
如果决议是全局回滚，过程比全局提交麻烦一点，`RM` 服务方收到 `TC` 全局协调者发来的回滚请求，通过 `XID` 和 `Branch ID` 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。
注意：这里删除回滚日志记录操作，一定是在本地业务事务执行之后
上边说了几种分布式事务各自的优缺点，下边实践一下分布式事务中间 Seata 感受一下。
### Seata 实践
Seata 是一个需独立部署的中间件，所以先搭 Seata Server， `seata-server-1.4.0` 版本为例，下载地址：`https://seata.io/en-us/blog/download.html`。解压后的文件我们只需要关心 `\seata\conf` 目录下的 `file.conf` 和 `registry.conf` 文件。
#### Seata Server
**file.conf**
`file.conf` 文件用于配置持久化事务日志的模式，目前提供 `file` 、`db`、`redis` 三种方式。
**注意**：在选择 `db` 方式后，需要在对应数据库创建 `globalTable` （持久化全局事务）、`branchTable`（持久化各提交分支的事务）、 `lockTable` （持久化各分支锁定资源事务）三张表。
```mysql
-- 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 Client
`Seata Server` 环境搭建完，接下来我们新建三个服务 `order-server` （下单服务）、`storage-server`（扣减库存服务）、`account-server`（账户金额服务），分别服务注册到 `eureka` 。
每个服务的大体核心配置如下：
```yaml
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` 扣账户余额服务， ， ， `@GlobalTransactional` 注解开启一个全局事务即可。
```java
@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：
}
```
前边说过 Seata AT 模式实现分布式事务，必须在相关的业务库中创建 `undo_log` 表来存数据回滚日志，表结构如下：
```mysql
-- 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';
```
#### 测试Seata
项目中的服务调用过程如下图：
启动各个服务后，我们直接请求下单接口看看效果，只要 `order` 订单表创建记录成功，`storage` 库存表 `used` 字段数量递增、`account` 余额表 `used` 字段数量递增则表示下单流程成功。
请求后正向流程是没问题的，数据和预想的一样
而且发现 `TM` 事务管理者 `order-server` 服务的控制台也打印出了两阶段提交的日志
那么再看看如果其中一个服务异常，会正常回滚呢？在 `account-server` 服务中模拟超时异常，看能否实现全局事务回滚。
发现数据全没执行成功，说明全局事务回滚也成功了
那看一下 `undo_log` 回滚记录表的变化情况，由于 `Seata` 删除回滚日志的速度很快，所以要想在表中看见回滚日志，必须要在某一个服务上打断点才看的更明显。
**总结**
上边简单介绍了 `2PC` 、`3PC`、`TCC`、`MQ`、`Seata` 这五种分布式事务解决方案，还详细的实践了 `Seata` 中间件。但不管我们选哪一种方案，在项目中应用都要谨慎再谨慎，除特定的数据强一致性场景外，能不用尽量就不要用，因为无论它们性能如何优越，一旦项目套上分布式事务，整体效率会几倍的下降，在高并发情况下弊端尤为明显。
# 分库分表
随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，优化迫在眉睫。原因在于关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到 **1000W** 或 **100G** 以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。解决上述问题通常有以下两种方案：
- **通过提升服务器硬件能力来提高数据处理能力，比如增加存储容量 、CPU 等，这种方案成本很高，并且如果瓶颈在 MySQL 本身那么提高硬件也是有很的**
- **把数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的**
**解决方案**
- **垂直分表：** 可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失
- **垂直分库：** 可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题
- **水平分库：** 可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题
- **水平分表：** 可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化
一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。
**拆分目的**
- **垂直拆分：业务数据解耦**
- **水平拆分：解决容量和性能压力**
**分库分表前的问题**
- 用户请求量太大
- 因为单服务器TPS， ，
- **解决方法**：分散请求到多个服务器上； 其实用户请求和执行一个sql查询是本质是一样的， ， ， ，
- 单库太大
- 单个数据库处理能力有限； ；
- **解决方法**：切分成更多更小的库
- 单表太大
- CRUD都成问题； ，
- **解决方法**：切分成多个数据集更小的表
## 垂直拆分
### 垂直分表
**垂直分表：将一个表按照字段分成多表，每个表存储其中一部分字段。**
我们拿网上商城举例：用户在浏览商品列表时，通常只会快速浏览商品名称、商品图片、商品价格等其他字段信息，这些字段数据访问频次较高。当只有对某商品感兴趣时才会查看该商品的详细描述。因此，商品信息中商品描述字段访问频次较低，且该字段存储占用空间较大，访问单个数据 IO 时间较长。
由于这两种数据的访问频次的不同，我们可以将商品信息表分成如下 2 张表：
**优化提升：**
1. 为了避免 IO 争抢并减少锁表的几率，查看详情的用户与商品信息浏览互不影响
2. 充分发挥热门数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累
**拆分原则：**
1. 把不常用的字段单独放在一张表
2. 把text，
3. 经常组合查询的列放在一张表中
### 垂直分库
**垂直分库：按照业务将表进行分类，分布到不同数据库上面，每个库可以放在不同服务器上，它的核心理念是专库专用。**
通过垂直分表性能得到了一定程度的提升， ， ， ， ， ，
继续拿商城举例： ， ，
**优化提升：**
1. 解决业务层面的耦合，业务清晰
2. 能对不同业务的数据进行分级管理、维护、监控、扩展等
3. 高并发场景下，
## 水平拆分
### 水平分库
**水平分库：把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。**
经过垂直分库后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，单库存储数据已经超出预估。单台服务器已经无法支撑。此时该如何优化？垂直拆分已达到极限，只能从水平维度拆分。
继续拿商城举例： ， ， ，
**优化提升：**
1. 解决了单库大数据，高并发的性能瓶颈
2. 提高了系统的稳定性及可用性
### 水平分表
**水平分表：在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。**
即便水平分库，随着业务的增长还是会出现单表数量大导致查询效率下降的问题。
按照水平分库的思路，我们可以对单表进行水平拆分：
**优化提升：**
1. 优化单一表数据量过大而产生的性能问题
2. 避免IO争抢并减少锁表的几率
### 切分规则
#### Hash取模
1. ** 优点**：经过 hash 取模之后，分到库和分到表中的数据，都是均衡的，所以，不会出现资源倾斜的问题
2. ** 缺点**： ， ， ，
#### Range划分
简单说，就是把数据划分范围，挨个存储，存满一个再存另一个。
1. ** 优点**：不需要数据迁移，后续数据即时增长很多也没问题
2. ** 缺点**：数据倾斜严重，比如上图，很长一段时间，都会只用到 1 个库，几个表
#### 一致性Hash
一致性 hash 环的节点一般按 2^32-1 来算，但是一般如果业务 ID 足够均衡，则可以降一些节点，如 4096 等等，
1. ** 优点**：更加均匀，并且在需要扩容时，数据迁移的量级更小，只需要迁移 1/N 的数据即可
2. ** 缺点**：路由算法要复杂，但是对于能得到的好处，这点复杂度就可以忽略了
#### 地理区域划分
比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。
#### 时间范围划分
按照时间切分， ， ， ，
## 面临问题
### 分布式事务问题
使用分布式事务中间件解决，具体是通过最终一致性还是强一致性分布式事务，看业务需求。
### 跨节点关联查询Join问题
切分之前， ， ， ， ， ：
- **全局表**
全局表，也可看做是 "**数据字典表**"， ， ， ** 这类表在每个数据库中都保存一份**。这些数据通常很少会进行修改，所以也不担心一致性的问题。
- **字段冗余**
** 利用空间换时间， ： ，
- **数据组装**
** 在系统层面，分两次查询**。第一次查询的结果集中找出关联数据id，
### 跨节点分页、排序函数问题
跨节点多库进行查询时， ， ， ； ， ， ，
### 全局主键避重问题
如果都用`主键自增`肯定不合理，如果用`UUID`那么无法做到根据主键排序，所以我们可以考虑通过`雪花ID`来作为数据库的主键， ：
### 数据迁移问题
采用`双写的方式`，修改代码，所有涉及到分库分表的表的增、删、改的代码，都要对新库进行增删改。同时，再有一个数据抽取服务，不断地从老库抽数据，往新库写，边写边按时间比较数据是不是最新的。
### 公共表
参数表、数据字典表等都是数据量较小，变动少的公共表，属于高频联合查询的依赖表。分库分表后，我们需要将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行。
## ShardingSphere
Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（ ）
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 | 任意 | 任意 |
| 性能 | 损耗低 | 损耗略高 | 损耗低 |
| 无中心化 | 是 | 否 | 是 |
| 静态入口 | 无 | 有 | 无 |
### ShardingSphere-JDBC
定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
- 适用于任何基于 JDBC 的 ORM 框架， ：
- 支持任何第三方的数据库连接池， ：
- 支持任意实现 JDBC 规范的数据库，目前支持 MySQL， ， ，
1. 引入 maven 依赖
```xml
< dependency >
< groupId > org.apache.shardingsphere< / groupId >
< artifactId > shardingsphere-jdbc-core< / artifactId >
< version > ${latest.release.version}< / version >
< / dependency >
```
2. 规则配置
ShardingSphere-JDBC 可以通过 `Java` ， ， `Spring Boot Starter` 这 4 种方式进行配置，开发者可根据场景选择适合的配置方式。 详情请参见[配置手册](https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-jdbc/configuration/)。
3. 创建数据源
通过 `ShardingSphereDataSourceFactory` 工厂和规则配置对象获取 `ShardingSphereDataSource` 。 该对象实现自 JDBC 的标准 DataSource 接口，可用于原生 JDBC 开发，或使用 JPA, MyBatis 等 ORM 类库。
```java
DataSource dataSource = ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, configurations, properties);
```
### ShardingSphere-Proxy
定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如：
- 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用
- 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端
1. 规则配置
- 编辑`%SHARDINGSPHERE_PROXY_HOME%/conf/config-xxx.yaml`。详情请参见[配置手册](https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/configuration/)
- 编辑`%SHARDINGSPHERE_PROXY_HOME%/conf/server.yaml`。详情请参见[配置手册](https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/configuration/)
2. 引入依赖
如果后端连接 PostgreSQL 数据库，不需要引入额外依赖。如果后端连接 MySQL 数据库，请下载 `mysql-connector-java-5.1.47.jar` ，并将其放入 `%SHARDINGSPHERE_PROXY_HOME%/lib` 目录。
3. 启动服务
- 使用默认配置项
```shell
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh
```
默认启动端口为 `3307` ，默认配置文件目录为：`%SHARDINGSPHERE_PROXY_HOME%/conf/`。
- 自定义端口和配置文件目录
```shell
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh ${proxy_port} ${proxy_conf_directory}
```
4. 使用ShardingSphere-Proxy
执行 MySQL 或 PostgreSQL的客户端命令直接操作 ShardingSphere-Proxy 即可。以 MySQL 举例：
```shell
mysql -u${proxy_username} -p${proxy_password} -h${proxy_host} -P${proxy_port}
```
### ShardingSphere-Sidecar(TODO)
定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。 通过无中心、零侵入的方案提供与数据库交互的啮合层，即 `Database Mesh` ，又可称数据库网格。
Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。 使用 Database Mesh， ， ，
1. 规则配置
编辑`%SHARDINGSPHERE_SCALING_HOME%/conf/server.yaml`。详情请参见[使用手册](https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-scaling/usage/)。
2. 引入依赖
如果后端连接 PostgreSQL 数据库，不需要引入额外依赖。如果后端连接 MySQL 数据库，请下载 `mysql-connector-java-5.1.47.jar` ，并将其放入 `%SHARDINGSPHERE_SCALING_HOME%/lib` 目录。
3. 启动服务
```shell
sh %SHARDINGSPHERE_SCALING_HOME%/bin/start.sh
```
4. 任务管理
通过相应的 HTTP 接口管理迁移任务。详情参见[使用手册](https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-scaling/usage/)。
### 混合架构
ShardingSphere-JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；
Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy， ， ，
**功能列表**
- 数据分片
- 分库 & 分表
- 读写分离
- 分片策略定制化
- 无中心化分布式主键
- 分布式事务
- 标准化事务接口
- XA 强一致事务
- 柔性事务
- 数据库治理
- 分布式治理
- 弹性伸缩
- 可视化链路追踪
- 数据加密
# 全链路压测
## 达达全链路压测探索与实战
### 业界全链路压测
达达原压测方案是: 搭建一套跟线上 1:1 的压测环境, 在这套环境中进行压测, 此方案技术难度低, 实现简单, 但弊端也明显: 人力及机器成本随着生产环境规模的变大而变大; 于是我们调研了业界主流的 【流量打标】方案, 该方案原理是: 在请求的流量(HTTP,RPC,MQ)上打标，所打的标示随着请求在各个服务之间流转, 从而使得压测流量与线上流量隔离，在数据隔离这块:
- DB 层: 使用 影子库/影子表 隔离数据
- Cache 层: 使用 影子缓存 隔离数据
- MQ 层: 使用 影子队列 隔离数据
但这个方案适用于中间件统一的场景;而达达内部使用了各种类型的中间件, 比如 ORM 就有 Mybatis, Hiberante, JPA, 版本也不一致; 并且存在大量异构程序, 有 Java 的, 有Python 的; 若要实现【流量打标】方案, 势必会有大量业务改造, 因此我们放弃此方案。
### 达达全链路压测
在分析自身架构特点后, 我们在 2019年一季度研发了基于【机器打标】的压测方案 (数据使用 影子DB& Redis& MQ 隔离)。
以下是实现此方案的流程:
- **机器抽象化**: 所有 DB& Redis& ES 机器抽象成一个一个节点; 节点信息如下图
- **机器信息注册到注册中心**: 所有节点信息注册到注册中心
- **服务接入链路治理SDK**: 所有服务接入 "链路治理SDK", "链路治理SDK" 具有根据链路路由请求的能力
节点信息说明:
- **cloud_name**: 资源名称, 全局唯一, 一个资源可包含多个节点, 比如 mysql_cluster001 就可以包含一个主节点, 多个从节点
- **node_name**: 节点名称, 全局唯一, 通常使用 host+port
- **host**: host 信息
- **port**: 端口信息
- **role**: 角色, w: 写节点, r: 读节点
- **dada_type**: 资源类别, 有 mysql, redis, es 等
- **data_link**: 链路类别, 有 benchmark(压测), base(生产)
方案中最重要的是 "链路治理SDK", 它的职责是: 根据链路类别路由请求流量; 如下图所示:
它的启动流程如下:
1. 注册服务节点信息
2. 根据本机的链路类别, 获取对应链路的存储节点信息
3. 根据存储节点信息, 建立起 DB,Redis, MQ 连接
最终线上环境, 在机器维度形成两条链路, 处理生产流量的生产链路和处理压测流量的压测链路。
**方案比较**
下图是对【流量打标】【机器打标】的比较, 两种方案都有优缺点, 达达从安全及系统改造成本出发, 最终选择了【机器打标】方案。
### 压测平台
原压测方案使用 jmeter 进行压测, jmeter 属于老牌压测工具, 稳定性高且支持分布式; 但在压测场景复杂时，使用不够灵活; 达达的压测多数为复杂场景压测, 所以放弃原方案, 转而基于 jmeter 内核开发自己的压测平台; 以下是压测平台的整体架构:
主要由以下几个核心模块构成:
- **前端服务**: 提供 压测任务填写, 压测任务启动/停止, 压测结果展示等功能。
- **压测任务解析器**: 主要负责压测任务的解析, 存储。
- **压测引擎**: 负责将压测任务调度到执行器上执行 (定时执行 & 立即执行)。
- **压测结果处理器**: 负责对压测接口返回值解析, 统计, 异常处理, 并生成报表。
新压测平台的优势在于: 具有可视化的操作界面, 压测结果实时动态产出; 研发人员在压测平台配置 "发压性能参数", "造数据脚本" 就能直接执行。
压测引擎在施压时, 对应压测结果 (TPS& 响应& 错误率) 会实时展示到前端界面。
### 全链路压测落地
整个全链路压测的落地分成: 压测前, 压测中, 压测后:
其中 ** 压测前** 有三个关键点: 压测链路梳理, 优化预案设定, 精细化压测模型。
#### 链路梳理
链路的梳理非常重要, 它决定着压测链路需要部署哪些服务, 压测时哪些服务需要被关注。
以前达达通过人肉的方式梳理链路, 但是这种方案效率低, 不准确, 工作量大, 且当生产环境链路变更时, 我们不能即时感知到; 后面引入 APM(PinPoint), APM 有梳理链路的功能。
但此方案还是没解决: "实时感知链路变更" 的问题; 为此我们在开发环境拉了条链路, 定时发请求以检测是否链路通畅; 若链路依赖有变化, 我们就能立刻知道。
#### 优化预案设定
俗话说: 不打无准备之战, 压测就是为了提前发现高负载时系统可能出现的性能隐患, 那如何解决性能隐患呢? 通常在压测之前我们会准备一些性能优化预案, 常用预案如下:
- **线程池/连接池 打满**: 扩容线程池大小(服务CPU未超过阈值时) / 扩容业务服务
- **Mysql 主从延迟**: Mysql BinLog 调优 -> 升级机器配置 -> 垂直拆库 -> 水平拆库
- **Redis 带宽打满**: 带宽自动扩容
- **MQ 消息堆积**: 扩容消费消息的服务方
因过去几年的业务的发展, 导致生产环境数据库单表单库的数据量一直在增长, 达达物流系统多次碰到 **Mysql 主从延迟** ; 目前最常用的优化方案是 "Mysql BinLog 调优", 此方案主要调优以下两个参数:
- **binlog_group_commit_sync_delay**: 表示事务提交后, 等待多少时间, binlog 再同步到磁盘, 默认0, 表示不等待(单位微秒)
- **binlog_group_commit_sync_no_delay_count**: 表示等待多少事务提交后, binlog 再同步到磁盘
但此调优方案也有弊端: 参数调优后, 接口响应会有一定提升(如下图); 所以调优时需考虑业务能否容忍接口响应的上升。
#### 精细化压测模型构建
随着业务的发展, 压测模型也在不断演进迭代中; 从一开始 "使用虚拟骑士, 单一按照接口TPS目标值压测" 到现在 "模拟生产活跃骑士, 引入时间& 空间因素 构建压测模型", 模型越发精准。模型分成两类:
- **数据模型**: 骑士数据, 商户数据, 订单数据。
- **流量模型**: 订单下发, 配送履约。
**数据模型**
把生产上活跃骑士& 商户& 订单导入影子库, 对这批数据进行清洗, 去除敏感信息(手机号, 地址信息等), 用这些数据进行压测; 此方案简单且能最真实的还原生产环境。
**流量模型**
业界常用 【流量回放】方案, 将大促时生产环境的流量存储下来, 然后在压测环境进行回放。
此方案适用于读接口的压测, 但是达达的业务场景复杂, 主流程接口多写少读; 所以直接使用此方案肯定不行。
鉴于不能直接使用【流量回放】, 达达选择了【人工构造流量】。影响构造流量真实性主要有两大因素: 时间, 空间。
**时间**
在时间上, 达达一天有三个高峰期: 早& 午& 晚高峰, 每个高峰期 各个接口处于不同状态:
- **早高峰**: 发单, 接单, 订单详情 的请求量处于高峰, 其他接口请求量一般。
- **午& 晚高峰**: 订单详情, 取货, 完成 的请求量处于高峰, 其他接口请求量一般。
所以压测时, 达达根据业务接口三个高峰期的特点, 设计两个压测场景(午高峰与晚高峰接口状态类似, 合并成一个压测场景), 进行压测。
**空间**
在空间上, 订单与骑士不均匀分布在各地, 有些区域人多单少, 有些区域人少单多, 而对系统影响最大的是人多单多的热点区域。
达达有个 ** 查看周围X公里订单** 的接口, 这个接口的性能跟 热点区域的个数, 每个热点区域内的单量, 每个热点区域内的运力 关系比较大; 为了搞清这几点, 我们分析大促时生产的流量, 根据 geohash 把全国划分成一个个正方形区域, 统计每个正方形区域内的订单及运力; 最后再在压测环境还原并放大。
然后就是 ** 压测中**, 主要有这几块: 接口验证, 压测预热, 压测实施, 性能指标观察, 性能问题记录。其中压测预热非常重要, 它决定了压测结果的准确性。
#### 压测预热
早期每次压测得到的接口响应都比生产环境慢一点, 后面发现: 生产环境的部分数据是热数据, 而压测环境全是冷数据, 这导致压测刚开始进行时, 接口响应偏高, 等过了一分钟后, 响应逐渐降低并趋于平稳; 后面引入压测预热, 使得压测环境的数据, 部分是热数据, 部分是冷数据, 以达到跟生产环境数据一致的效果。
最后就是 ** 压测后**; 压测后主要是: 压测报告的生成, 性能隐患定位与优化, 系统容量预估, 压测复盘。下面说一下压测复盘。
#### 压测复盘
每次的大促复盘, 都能找到下次压测优化的方向; 复盘中最重要的是: 比较 生产与压测环境的 接口TPS&响应,中间件核心指标; 通过这些数据的比较来验证并优化 压测模型。
#### 总结与收益
全链路压测从 2019年一季度立项, 已经历了 4次大促压测考验, 并且完成了目标; 而在全链路压测实施的过程中, 我们认为有三大关键:
- **流量的隔离**: 基于【流量打标】, 达达研发出【机器打标】的隔离方案, 使得压测流量与生产流量完全隔离。
- **数据的隔离**: 基于安全考虑, 达达选择 影子库, 影子缓存, 影子队列, 从而实现生产与压测数据的彻底隔离; 得益于这一点, 压测的实施在白天/晚上随时可进行。
- **精细化压测模型构建**: 压测模型是否跟生产环境相近, 直接影响了压测结果的准确性; 我们参考生产环境大促高峰期的流量, 从时间& 空间维度分析, 制作出与大促时相近的压测流量, 从而保证数据模型的真实性。
整个项目的收益也非常明显, 具体从以下两方面分别来看:
- **稳定性**: 目前连续两年大促, 全链路压测每次都能挖掘出10 多项性能隐患, 从而保障了大促的平稳度过。
- **效率**: 相比原先搭建一套独立压测环境的方案, 现在的方案在机器成本上降低 40%, 人效上提升 65%。
当然此方案还有待提升的点, 比如 成本问题; 目前从安全角度出发, 达达通过影子库/缓存实现数据的隔离, 但影子库相比影子表方案机器成本高, 那如何在 安全与成本之间找到平衡, 是压测优化的方向; 另外, 除了挖掘系统隐患点, 全链路压测能否给 "智能运力调度" "运力的合理配置" 提出更多建议, 这也是我们思考的。
# 配置中心
产品功能特点比较：
| 功能点 | Spring Cloud Config | Apollo | Nacos |
| ------------ | ------------------------------------------------------ | ----------------------------------------- | ------------------------------------ |
| 开源时间 | 2014.9 | 2016.5 | 2018.6 |
| 配置实时推送 | 支持（ ） （ ） （ ）
| 版本管理 | 支持（ ）
| 配置回滚 | 支持（ ）
| 灰度发布 | 支持 | 支持 | 待支持 |
| 权限管理 | 支持 | 支持 | 待支持 |
| 多集群 | 支持 | 支持 | 支持 |
| 多环境 | 支持 | 支持 | 支持 |
| 监听查询 | 支持 | 支持 | 支持 |
| 多语言 | 只支持java | Go、C++、java、Python、PHP、.net、OpenAPI | Python、Java、Node.js、OpenAPI |
| 单机部署 | Config-server+Git+Spring Cloud Bus（ ）
| 分布式部署 | Config-server+Git+MQ（ ） （ ） （ ）
| 配置格式校验 | 不支持 | 支持 | 支持 |
| 通信协议 | HTTP和AMQP | HTTP | HTTP |
| 数据一致性 | Git保证数据一致性， ，
| 单机读 | 7（ ）
| 单机写 | 5（ ）
| 3节点读 | 21（ ）
| 3节点写 | 5（ ）
| 文档 | 详细 | 详细 | 有待完善（ ）
## Apollo
## Nacos
## Spring Cloud Config
# 服务框架
## 注册中心
包括注册服务、订阅服务、服务变更通知、服务心跳发送等功能。Server端会在系统初始化时通过register模块注册服务， ，
### Redis
### Zookeeper
### Nacos
## 集群容错/高可用策略
### 失效切换(Failover Cluster)
失败自动切换，当出现失败，重试其它服务器。
### 快速失败(Failfast Cluster)
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
### 失败安全(Failsafe Cluster)
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
### 失败自动恢复(Failback Cluster)
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
### 并行调用(Forking Cluster)
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
### 广播调用(Broadcast Cluster)
广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
## 负载均衡
### Random LoadBalance
- **随机**，按权重设置随机概率。
- 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
### RoundRobin LoadBalance
- **轮询**，按公约后的权重设置轮询比率。
- 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
### LeastActive LoadBalance
- **最少活跃调用数**，相同活跃数的随机，活跃数指调用前后计数差。
- 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
### ConsistentHash LoadBalance
- **一致性 Hash**，相同参数的请求总是发到同一提供者。
- 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
## Filter
### AccessLogFilter
### AccessLimitFilter
### TraceFilter
### TimeoutFilter
用在provider侧， ，
### MonitorFilter
在consumer,provider侧将服务的耗时，
### CompatibleFilter
兼容适配器，能对结果返回值做一些类型转换，注入基本类型到装箱类型的互转，复合类型到序列化值的转换(依赖你配置的序列化类型)等。
### ExceptionFilter
在provider端， ， ， ，
## 服务路由
# 订单超时关闭
在电商、支付等领域， ， ， ， ， ， ； ？
**一般的做法有如下几种**
- 定时任务关闭订单
- rocketmq延迟队列
- rabbitmq死信队列
- 时间轮算法
- redis过期监听
参考文档：
