知识点
- CAP
- 分布式事务
- 限流算法
- 限流方式
- 微服务和单体架构比较
- 断路器
- 注册中心的作用
- BASE理论
- 注册中心简单原理
- 配置中心简单原理
分布式
分布式的CAP原则
黑马Seata入门到实战教程，快速学习Seata分布式解决方案，XA模式 TCC模式 AT模式 Saga模式_哔哩哔哩_bilibili
（这个视频CAP理论讲得非常好）
- 一致性（Consistency） : 用户访问分布式系统中的任意节点，数据必须一致。（比如主从集群同步复制满足一致性，异步复制则是满足可用性）
- 可用性（Availability） : 用户访问集群中任意健康节点，必须得到及时响应（不是错误或者超时的响应）。
- 分区容错性（Partition Tolerance） : 因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。 （容错） 在这种情况下，整个系统也要对外提供服务。
分布式系统通过网络连接，一定会出现分区问题（P）。当分区出现时，C和A只能满足其中一个。
- CP模式：保证强一致性，不保证可用性。例如Seata的XA模式，各个分区事务等待所有事务成功后一起提交，保证一致性，但可用性降低了（前面的服务需要等待，不能立马提交事务） 。
- AP模式：保证可用性，不保证一致性（弱一致）。例如Seata的AT模式，各个分区事务可用先提交，若某个事务失败，之前的事务再回滚，保证可用但无法达到强一致性。
BASE理论
分布式微服务场景下如何保证数据一致性？（用友）
说分布式事务
分布式事务
01-03-分布式事务理论基础_哔哩哔哩_bilibili（详细讲解了）
什么是分布式事务？
分布式事务用于在分布式系统中保证不同节点之间的数据一致性。
分布式事务的解决方案
-
2PC两阶段提交（一种规范）
-
3PC
-
基于Seata的实现 (也是两阶段提交)
-
- XA模式（事务先不提交，强一致性）
- AT模式（事务可以先提交，最终一致性）
-
基于事务消息去实现（如rocketMQ的事务消息），有点像TCC模式（try，confirm，cancel）
Seata
Seata分布式事务组件基本组成部分
TC事务协调者，TM事务管理器，RM资源管理器，TC事务协调者
XA模式
分支事务先不提交，等待全部执行完之后一起提交
- 保证强一致性，忽略了可用性，性能较差。
- 依赖于数据库支持，因为需要卡在提交事务那里。
AT模式
分支事务可以先提交，如果最后TC判断有事务异常，那么全部回滚。
- 保证最终一致性和可用性，不保证强一致，所以性能好一点。
微服务
通用问题
微服务和相对于单体架构有什么优缺点？
优点：
- 低耦合，单一职责
- 项目开发，如果项目组的人员很庞大，方便分组开发，一个组开发一个服务。
- 数据库方面，各服务维护自己的库，有利于存储大量数据以及应对数据库并发请求。
缺点：
- 需要更多的资源，适合大公司。
- 系统更复杂了，维护更复杂。
- 需要考虑各个微服务分布式数据一致性等问题。
注册中心有什么用？
- 服务注册和发现
- 心跳机制检查服务监控状态
- 负载均衡？？？
SpringCloud alibaba组件
注册中心 nacos
配置中心 nacos
网关 gateaway
服务调用 feign
负载均衡 loadbalance组件
配置中心动态配置修改怎么实现的？
- 客户端长轮询
- 拉下来之后动态修改bean，构造一个新的bean（这中间很复杂），后续访问都访问这个新的Bean。
服务保护Sentinel（限流、隔离、熔断降级）
sentinel服务保护分为哪几种方式？
- 限流
- 线程隔离（就是给某个接口限制线程数，就算你这个接口并发高也不会影响其他接口的正常调用）
- 熔断/降级（通过断路器实现）
Sential的限流的几种方式？
- 直接拒绝（用滑动窗口拒绝，窗口内请求多了就拒绝嘛）
- 排队等待（漏桶，其实就是一个队列，在队列中等待，联想到MQ）
- 热点参数限流，热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。（LRU+令牌桶实现）
Sential限流的算法了解吗？（重要）
10-Sentinel与Gateway的限流对比，滑动窗口、令牌桶、漏桶_哔哩哔哩_bilibili（黑马这个比较详细）
面试官：Sentinel怎么实现限流的？一通问下来问麻了！！_哔哩哔哩_bilibili
这两篇文章介绍得很详细
滑动窗口：
- 优点：灵活，精确控制流量
- 缺点：无法处理突发流量（突发流量会被窗口限制住）
漏桶算法（请求加入队列，消费者恒定速率消费，类似于生产者消费者模式）：
- 优点：可以平滑流量（因为加了队列嘛）
- 缺点：
-
- 处理不灵活，不能快速处理突发流量，只能恒定速率消费。
- 可能会流量浪费。（当漏桶中空了）
令牌桶算法：恒定速率往桶中放入令牌，请求来了，就从桶中获取令牌，如果没有令牌的话，请求被拒绝
- 优点：可以灵活地处理突发和峰值流量（流量大时会有之前积累的令牌）。
- 缺点：存在透支消费 或者 累积令牌太多，导致放进来的峰值流量过多。
断路器了解吗，讲讲（云智）
22-Sentinel执行链路-DegradeSlot-断路器_哔哩哔哩_bilibili
微服务熔断的 断路器。有三个状态，close，open，half-open
- closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
- open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态持续一段时间后会进入half-open状态
- half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
-
- 请求成功：则切换到closed状态
- 请求失败：则切换到open状态
一致性哈希
应用场景
应用在 一个分布式的数据分片系统，一种负载均衡算法，使得某个key对应的节点是固定的。
一致性哈希是什么？
所以，一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上。
映射的结果值往顺时针的方向的找到第一个节点，就是存储该数据的节点。
一致性哈希解决了什么问题？
扩容缩容时过多数据迁移
一致性哈希算法就很好地解决了分布式系统在扩容或者缩容时，发生过多的数据迁移的问题。
在一致哈希算法中，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。
一致性哈希有什么问题？
数据分布不均匀的问题
一致性哈希算法并不保证节点能够在哈希环上分布均匀，这样就会带来一个问题，会有大量的请求集中在一个节点上。
所以，一致性哈希算法虽然减少了数据迁移量，但是存在节点分布不均匀的问题。
如何解决节点分布不均匀的问题？
增加虚拟节点
引入虚拟节点，对一个真实节点做多个副本。不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。
