面试专题-6、分布式组件
1. 服务注册与发现
服务注册与发现-6、Nacos2. 网关
分布式专题-8、网关-GateWay3. 服务熔断降级限流
3.1. 服务雪崩
服务雪崩： 因服务提供者的不可用导致服务调用者的不可用, 并将不可用逐渐放大的过程，就叫服务雪崩效应
解决方式：
通过熔断机制，当一个服务挂了，被影响的服务能够及时熔断，使用 Fallback 数据保证流程在非关键服务不可用的情况下，仍然可以进行。
通过线程池和消息队列机制实现异步化，允许服务快速失败，当一个服务因为过慢而阻塞，被影响服务可以在超时后快速失败，不会影响整个调用链路。
3.2. 服务限流
是指在高并发请求下，为了保护系统，可以对访问服务的请求进行数量上的限制，从而防止系统不被大量请求压垮，在秒杀中，限流是非常重要的。
3.3. 服务熔断
当服务 A 调用的某个服务 B 不可用时，上游服务 A 为了保证自己不受影响，及时切断与服务 B 的通讯。以防服务雪崩。防止服务雪崩一种措施。
3.4. 服务降级
提前预想好另外一种兜底措施，可以进行后期补救。直到服务 B 恢复，再恢复和 B 服务的正常通讯。当被调用服务不可用时的一种兜底措施。
3.4.1. 哪些场景用到了限流、降级？怎么配的？
3.4.1.1. 服务降级的预案
在进行降级之前要对系统进行梳理，提前将一些 不重要 或 不紧急 的服务（弱依赖）或任务进行服务的 延迟使用 或 暂停使用。 （积分）
看看哪些服务是必须誓死保护，哪些系统是能够丢卒保帅；具体可以参考日志级别设置预案：
一般：有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
警告：有些服务在一段时间内成功率有波动（如在 95~100% 之间），可以自动降级或人工降级，并发送告警；
错误：可用率低于 90%，或者连接池被占用满了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
严重错误：因为特殊原因数据错误了，此时需要紧急人工降级
3.4.1.2. QPS 并发配置
- 测试会提供准确的数据；
- 自己算： 二八法则
计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
根据以上计算关系，我们来预估下单日访问量在 1000W 需要多大的 QPS 来支持：
通常情况下，80% 的访问量集中在 20% 的时间，算一下这 1000w pv 实际需要机器达到多少 qps 才能满足，
qps = (1000w * 0.8) / (24 * 3600 * 0.2)
qps = 462.9 - 根据压力测试的反馈，单台机子的 QPS 是多少，利用以上结果就可以算出需要几台机器或大致推算出需不需要使用缓存配置
方案一： 使用集群服务器 不使用缓存服务器
方案二： 使用集群服务器 同时使用缓存服务器 (推荐)
例子：
每秒可以处理的请求数 QPS（TPS）：每秒钟可以处理的请求或者事务的数量。
并发数： 系统同一时候处理的请求数量（事务数）
响应时间： 一般取平均响应时间
QPS（TPS）= 并发数/平均响应时间
并发数 = QPS平均响应时间
例子:
一个典型的上班签到系统，早上 8 点上班。7 点半到 8 点这 30 分钟的时间里用户会登录签到系统进行签到。公司员工为 1000
人，平均每一个员上登录签到系统的时长为 5 分钟。能够用以下的方法计算。
（1）QPS = 1000/(30×60) 事务/秒
（2）平均响应时间为 = 5×60 秒
（3）并发数= QPS 平均响应时间 = 1000/(30×60) ×(5×60)=166.7
再看如果老板要求实现多少并发数，在反推出机器需要多少 QPS，看是否集群配置。
3.5. Sentinal
服务治理-10、限流熔断降级(服务保护)-Sentinel4. 分布式事务
可以参考： 事务-2、分布式事务 ^lnql61
4.1. Seata 的实现原理 -AT2PC 变种⭐️🔴
❕ ^a3vjds
分布式事务： https://www.jianshu.com/p/044e95223a17 ⭐️🔴
在应用中 Seata 整体事务逻辑基于两阶段提交的模型，核心概念包含三个角色：
TC：事务协调者，即独立运行的 seata-server，用于接收事务注册，提交和回滚。
TM：事务发起者。用来告诉 TC 全局事务的开始，提交，回滚。
RM：事务资源，每一个 RM 都会作为一个分支事务注册在 TC。
AT(Auto Transaction) 模式
4.2. 执行流程
❕ ^14aw6x
假设运行：update product set name = ‘GTS’ where name = ‘TXC’; // id=1
4.2.1. TM 开启全局事务
TM 向 TC 申请开启一个全局事务，全局事务创建并生成一个全局唯一的 XID。
XID 在微服务调用链路的上下文中传播。
4.2.2. 第一阶段 - 各 RM 执行并提交分支事务
1. 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
2. 查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。 select * from product where name = 'TXC' 镜像前数据
3. 执行业务 SQL：更新这条记录的 name 为 ‘GTS’。
4. 查询后镜像：根据前镜像的结果，通过 主键 定位数据。select * from produc where name = 'TXC' 镜像后数据
5. RM 在同一个本地事务中执行业务 SQL 和 UNDO_LOG 数据的插入
把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
提交前，RM 向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的全局锁
如果申请不到，则说明有其他事务也在对这条记录进行操作，因此它会在一段时间内重试，重试失败则回滚本地事务，并向 TC 汇报本地事务执行失败。等待全局锁的情况如下图所示：
等不到全局锁回滚本地事务的情况，请看防止脏写的 3 种情况
6. RM 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。释放本地锁，但此时全局锁并没有释放，全局锁的释放取决于二阶段是提交命令还是回滚命令。
4.2.3. TM 发起全局决议
TM 将本地事务提交的结果上报给 TC。并向 TC 发起针对 XID 的全局提交或回滚决议。TC 根据所有的分支事务执行结果，向 RM 下发提交或回滚命令。
4.2.4. 第二阶段 - TM 决议后通知 TC 发起全局提交
TC 调度 XID 下管辖的全部分支事务完成提交请求
- RM 如果收到 TC 的提交命令，首先立即释放相关记录的全局锁 (其实锁是在 TC 端维护的)
- 然后把提交请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。异步队列中的提交请求真正执行时，只是删除相应 UNDO LOG 记录而已。
4.2.5. 第二阶段 - TM 决议后通知 TC 发起全局回滚
TC 调度 XID 下管辖的全部分支事务完成回滚请求
- 所有 RM 开启一个本地事务
- 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
- 数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改（出现脏写），转人工处理（Seata 因为无法感知这个脏写如何发生，此时只能打印日志和触发异常通知，告知用户需要人工介入） 。人工没有脏写就简单了：根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句
- 提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。
- 最后释放相关记录的全局锁
4.3. @GlobalTransactionScanner 原理
https://www.cnblogs.com/wxbty/p/10411190.html
4.4. Seata 的全局事务隔离级别⭐️🔴
❕ ^mm3ts9
脏读脏写的解决方案
https://seata.io/zh-cn/blog/seata-at-lock.html
4.4.1. 如何防止脏写
❕ ^qngn57
先来看一下使用 Seata AT 模式是怎么产生脏写的：
注：分支事务执行过程省略其它过程。
业务一开启全局事务，其中包含分支事务 A（修改 A）和分支事务 B（修改 B），业务二修改 A，其中业务一执行分支事务 A 先获取本地锁，业务二则等待业务一执行完分支事务 A 之后，获得本地锁修改 A 并入库，业务一在执行分支事务时发生异常了，由于分支事务 A 的数据被业务二修改，导致业务一的全局事务无法回滚。
如何防止脏写？
4.4.1.1. @GlobalTransactional
1、业务二执行时加 @GlobalTransactional 注解：
注：分支事务执行过程省略其它过程。
业务二在执行全局事务过程中，分支事务 A 提交前注册分支事务获取全局锁时，发现业务业务一全局锁还没执行完，因此业务二提交不了，抛异常回滚，所以不会发生脏写。
4.4.1.2. @GlobalLock
2、业务二执行时加 @GlobalLock 注解：
注：分支事务执行过程省略其它过程。
与 @GlobalTransactional 注解效果类似，只不过不需要开启全局事务，只在本地事务提交前，检查全局锁是否存在。
4.4.1.3. @GlobalLock + select for update
2、业务二执行时加 @GlobalLock 注解 + select for update 语句：
如果加了 select for update 语句，则会在 update 前检查全局锁是否存在，只有当全局锁释放之后，业务二才能开始执行 updateA 操作。
加 select for update 的作用是可以重试。
4.4.2. 如何防止脏读
Seata AT 模式的脏读是指在全局事务未提交前，被其它业务读到已提交的分支事务的数据，根本原因是 Seata 默认的全局事务是读未提交
那么怎么避免脏读现象呢？
业务二查询 A 时加 @GlobalLock 注解 + select for update 语句：
加 select for update 语句会在执行 SQL 前检查全局锁是否存在，只有当全局锁完成之后，才能继续执行 SQL，这样就防止了脏读。
4.4.3. select for update
Seata 由于一阶段 RM 自动提交本地事务的原因，默认隔离级别为 Read Uncommitted。如果希望隔离级别为 Read Committed，那么可以使用 SELECT...FOR UPDATE 语句。Seata 引擎重写了 SELECT...FOR UPDATE 语句执行逻辑，SELECT...FOR UPDATE 语句的执行会先申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT...FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的才返回。
除了能够检查是否有全局锁，加 select for update 还有个好处，就是可以重试。
出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。
4.5. 集中管理全局锁的考虑
全局锁是由 TC 也就是 server 来集中维护，而不是在数据库维护的。这样做有两点好处：
- 一方面：锁的释放非常快，尤其是在全局提交的情况下，收到全局提交的请求，锁马上就释放掉了，不需要与 RM 或数据库进行一轮交互。
- 另外一方面：因为锁不是数据库维护的，从数据库层面看，数据没有锁定。这也就是给极端情况下，业务 降级 提供了方便，事务协调器异常导致的一部分异常事务，不会 block 后面业务的继续进行。
5. 负载均衡
5.1. Ribbon 原理
分布式专题-5、负载均衡-Ribbon6. 远程服务调用
分布式专题-7、远程调用-Feign与OpenFeign7. SpringCloudAlibaba
尚硅谷 2020-3.2 第二季最新课程 SpringCloud H 版 +SpringCloud Alibaba 构成
8. 实战经验
9. 参考与感谢
9.1. 黑马程序员
❕ ^n93hnw
9.1.1. 视频
9.1.2. 资料
1 | |
1 | |
9.3. 网络笔记
分布式事务： https://www.jianshu.com/p/044e95223a17 ⭐️🔴
微信
支付宝
