分布式事务

2PC，典型的实现是MySQL的XA事务

准备阶段：事务管理器告知所有分支准备提交

提交阶段：事务管理器告知所有分支提交或回滚事务

缺点，长时间锁定资源，容易出现单点的问题

TCC

Try/Confirm/Cancel

需要自己实现2PC中的prepare/commit/rollback过程，相对于现成的2PC方案（MySQL的XA，和Seata的AT模式）需要自己实现三个过程，侵入性更强。

可靠消息最终一致性

要求使用该方案的服务保证如下：

本地事务与消息原子性 ，本地事务/消息发送 必须同时成功/失败 (RocketMQ实现了该要求)

消息接受可靠性

消息重复消费，保证幂等

该方案对业务入侵也是比较大的


程序设计的原则

S 单一职责原则

O 开闭原则

L 里氏替换原则

I 接口隔离原则 接口最小化

D 依赖倒置原则

迪米特法则 尽可能减小对外的控制权限

合成/聚合复用原则 尽可能组合而不是继承


Kafka 

消息丢失，重复

消息生产： ack参数配置为异步时，可能出现未同步，主分区挂掉的情况，消息丢失

消息消费： 高等级的API可能出现消息消费途中挂掉的问题，此时offset还是会提交，导致消息丢失，可用低等级的接口控制offset

kafka为什么会快 参考 其中mmap即kafka官方文档的PageCache

消息分区选择逻辑可参考： API 可指定分区，未指定分区，则根据key进行hash，没有key则用round-robin


限流方案：

限制单位时间调用量（滑动窗口）

限制并发量（信号量semaphore）

令牌桶

漏桶法 个人理解跟限制并发量比较接近


TODO

MySQL Explain

Redis 哨兵

Spring生命周期