分布式专题
- springcloud架构原理：eureka做注册中心，feign做动态代理，rabbin做负载均衡，进行http接口调用
- dubbo一般用zk做注册中心，springboot cloud一般用eureka，zk是强一致性，立刻通知所有节点修改，修改期间不可用，cp
eureka则是保留了可用性，每个eureka都会往其他节点同步，像注册表每隔30s检查一次，检查到改动立刻刷入writeonly缓存，读缓存则每隔30s检查一次，
发现改动再重新拉入缓存。发送端也是30s才会拉一次注册表。注册者每隔30s会发送心跳，eureka60s检查一次心跳，90s检查不到心跳就认为宕机
- 灰度发布：可以做个页面或者redis，阿波罗等，用网关的时候可以定时监听改动，做到动态路由和灰度发布（可以在准备灰度的机器上加个配置，再写个
比如10%比例路由到新改动机器上，如果开关关闭则正常均衡路由）
- 一般qps每秒几百，注册中心用4核8g的弄个两三台，每台扛个几百请求问题不大，如果服务实例就一二十，可以把请求优化到极致，比如拉取缓存，心跳发送都设置成1s，
网关一般用4核8g的部署个三四台也够了，数据库则最好用16核32g的物理机，每秒最高几千请求问题不大。服务实例最低部署个两台，防止挂了
- 一般服务初次启动时要优化ribbon，默认是服务第一次被请求初始化ribbon组件，比较耗时，容易超时，可以设置ribbon.eager-load-enabled=true 饥饿加载打开，网关也一样
ribbon可以设置超时时间，失败了就重试，再失败就重试下一个机器
- 接口幂等性，create类的操作可以加唯一索引，update类的可以在更新完后设置redis的key，重试的时候发现有这个key就做回滚操作
- 分布式事务
XA:两阶段提交，先问能不能成功，都能成功后主事务再去真正让各个系统执行。spring+jta就能实现。少用，缺点是一般不允许单个系统操作多个库
TCC：try先检测锁定资源，先comfirm，遇到问题就cancle取消。缺点就是跟业务耦合严重，但是强一致性，一般跟钱打交道的，就用tcc
本地消息表：比如A系统除了插入本地业务表，还要加个消息表，状态为待确认，B系统先插入消息表，再插入业务表，成功了就通知A，让他的消息变成成功
可靠消息最终一致性：可以基于rocketmq的事务，比如A发送消息给mq，B系统消费，消费失败就通知A重新发或者重新消费mq的消息
最大努力通知方案：比如A执行完本地事务就扔个消息到mq，B就基于最大努力通知服务，失败了重试，重试一定次数就丢弃
5：rocketmq 3.2.6之前有回调
