分布式问题-松哥资源

示例标题

熔断

个人感觉在语音上对熔断和降级的说明有些重合，或者不容易区分

当扇出链路的某个微服务不可用或者响应太长时，熔断(或者中断)该节点微服务的调用，快速返回错误的响应信息

熔断的目的是当A服务模块中的某块程序出现故障后为了不影响其他客户端的请求而做出的及时回应。

直接看例子

最底部的熔断方法和服务主体是跑在一起的

降级的目的是为了解决整体项目的压力，而牺牲掉某一服务模块而采取的措施。

也许这就是最能说明两者区别的区别

现在熔断的依赖包hystrix现在已经没人维护了，所以不推荐使用，个人更推荐使用**阿里巴巴的sentinel框架**

sentinel提供了熔断、流量整形等各种灵活功能

在管理后台可以定义目标、应用什么规则(策略)、触发后采取的措施

可以这样使用：

也可以：

nginx家族(nginx/openresty/kong)

之前尝试过nginx/openresty，但学习成本相对高，最后自己通过filter写了一套代码来达到目的
apisix

国内开源项目，已从apache毕业，很多大厂也在使用，具体还没使用过，有提供方便管理的界面，这个很吸引人

可以理解为是一个分布式文件系统，满足CAP中的CP，在进行leader选举的时候不满足A
基于内存，所以性能很高，非常使用读多写少的场景。
针对写多读少的场景，zk存在一些性能瓶颈，因为它要把数据同步到其他zk节点上
分为4种节点，每个节点存储的数据大小限制为1M
- 永久节点：即便zk宕机也还在，直到删除
- 永久顺序节点：
- 临时节点：和会话绑定，会话消失节点消失，只能是叶子节点，不能有子节点
- 临时顺序节点：除了临时节点的特性外，节点名称还具有顺序性
节点间通过zab协议保持数据同步
会有脑裂问题，也就是可能同时存在两个leader，但由于有过半机制，所以只能一个leader能提供写服务，所以也可以说没有脑裂问题。
节点有三种角色(raft协议也是三种角色)
- leader
- follower
- observer
为啥节点数最好奇数个，因为2n个节点和2n-1个节点的容忍度一样，比如4台最多宕机一台，3台也是最多宕机一台
zab协议，这个没去研究了，研究了下更简单易懂的raft协议

个人认为这个问题有点大，因为一个系统往往是由很多子系统或者组件构成，要整个系统高可用，那么冲请求进来到请求返回的整个链路都要高可用才行。
总的来说分几个层来说吧：

不同的存储又有不同的高可用

比如redis高可用方案，个人比较喜欢codis:
1. codis
2. redis本身的cluser方案，同时redis自身的各种设置，比如持久化规则，aof重写，内存淘汰策略等等
3. twitter的Twemproxy
mq的高可用，不同的mq又有不同的方案