应用缓存
缓存回收策略：空间／容量／时间
缓存回收算法：FIFO／LRU／LFU
Java堆／Java堆外／磁盘缓存
Guava／Ehcache／MapDB
缓存使用模式：Cache-Aside／Cache-As-SoR／CopyPattern
压测与预警
系统压测：<br> 压测方案：压测接口／并发量／压测策略／压测指标<br> 压测报告：机器负载／QPS／响应时间／成功率<br> 压测方式：线下／线上压测<br> 读写／仿真／引流／隔离集群／熔断压测<br> 单机／集群／离散／全链路压测
系统优化和容灾：<br> 单机调优<br> 架构优化／系统扩容<br> 跨机房容灾
应急预警：<br> 网络接入层：DNS／LVS／HaProxy<br> 应用接入层：Nginx／OpenResty<br> WEB应用层：Tomcat<br> 服务层：Dubbo<br> 数据层：Redis／DB
监控报警：<br> 服务监控／系统监控／JVM监控／接口监控<br> 报警策略：监控时间段／报警阀值／通知方式
扩容
单体应用垂直扩容
单体应用水平扩容
应用拆分
数据库拆分 水平／垂直拆分
使用sharding jdbc 分库分表／读写分离
数据异构
任务系统扩容Elastic-Job
队列
异步处理／系统解耦<br>数据同步／流量削峰
缓冲队列／任务队列／消息队列<br>请求队列／数据总线队列
Disruptor+Redies队列
基于Canal实现数据异构
分布式系统一致性
理论
酸碱平衡理论
ACID(酸) MVCC实现
A: Atomicity 原子性
C: Consistency 一致性
I: Isolation 隔离性
D: Durability 持久性
BASE(碱) <br>解决了CAP提出的<br>分布式系统的一致性<br>和可用性不可兼得的问题
BA: Basically Available 基本可用
S: Soft State 软状态,状态可以在一段时间内不同步
E: Eventually Consistent 最终一致性,在一定的时间窗口内达到即可
CAP 分布式系统
C: Consistency 一致性
A: Availablity 可用性
P: Partition tolerance 分区容忍性
DTS 分布式事务处理模型
模型角色
应用程序，参与者
事务管理器，协调者
资源管理器，参与者
通信资源管理器，参与者
两阶段提交
准备阶段
协调者向参与者发起指令，参与者评估自己的状态，如果评估指令可以完成，则写redo或undo日志(Write-AheadLog)的一种，然后锁定资源，执行操作，但是不提交。
提交阶段
如果每个参与者明确返回准备成功，协调者向参与者发起提交指令，参与者提交资源变更事务，释放资源。如果有一个参与者明确返回准备失败，则协调者向参与者发起终止指令，参与者取消已经变更的事务，执行undo日志，释放资源。
缺点
阻塞
每一次指令都必须明确收到响应才能进行下一步，否则阻塞，占用的资源一直锁定，不会释放。
单节点故障
如果协调者宕机，参与者没有协调者只会，则一直阻塞。尽管会有新的被选举出来的协调者，但如果协调者在发送一条提交指令后宕机，而提交指令仅被一个参与者接收，并且参与者接收后也宕机，则新的协调者无法处理这种情况。
脑裂
协调者发送提交指令，有的参与者接收到并执行了事务，有的参与者没有接收到事务就没执行事务，导致多个参与者之间的不一致。
三阶段提交
询问阶段
协调者询问参与者是否可以完成指令，协调者只需要回答是或者不是，不需要做真正的操作，这个阶段超时会导致终止
准备阶段
提交阶段
与两阶段的不同
增加了询问阶段，保证尽可能早的发现无法执行操作的指令
增加超时设置，一旦超时，协调者和参与者都会继续提交事务，默认成功。从概率统计的结果显示默认成功的正确性大。
保证最终一致性的模式
1. 查询模式
任何服务都需要提供一个查询执行操作状态的接口，服务使用方可以通过查询接口得知数据当前状态，然后做不同的处理。
注意事项
1. 每个服务操作都有一个唯一ID标识
2. 自我判断，单条还是批量查询，并做好吞吐量，熔断，隔离，限流等方案
2. 补偿模式
1. 自动恢复
2. 通知运营来操作，当然首先要有相应的功能
3. 技术运营，比如修改数据状态，修改代码上线等，尽量避免，不推荐❌
3. 异步确保模式
4. 定期校验模式
关键需要一个自始至终唯一的ID
5. 可靠消息模式
1. 消息的可靠发送
记录消息状态在DB，发送成功后标记为已发送。定时轮训未发送的消息发送出去。
2. 消息处理器的幂等性
6. 缓存一致性模式
读的顺序是先读缓存，后读数据库，写的顺序是献血数据库，后写缓存。
超时处理的模式
微服务的交互模式
1. 同步调用模式
使用场景: 实时性要求高，大规模，高并发的短小操作，不适合用于后段负载较高的场景。
超时解决方案
1. 两状态(成功/失败)同步接口
方案: 通过查询模式解决
2. 三状态(成功/失败/处理中)同步接口
方案: 最大努力将用户请求的操作处理成功
2. 接口异步调用模式
使用场景: 适用于非核心链路上的负载较高的处理环节，这个环节通常耗时较长，并对实时性要求不高。比如商品卖成功，需要给商户打钱，就可以采用接口异步调用模式。
超时解决方案
2. 异步调用内部超时
方案: 调用方查询补齐状态
3. 异步调用回调超时
方案: 开发子系统专门处理回调通知
3. 消息队列异步处理模式
使用场景: 上游不关心下游的处理结果，解耦，对流量可以起到消峰的功能，多应用与非核心链路上负载较高的处理环节中。
超时解决方案
1. 生产者发送消息超时
方案: 重复发送直到成功
2. 消费着消费超时
方案: 1. 消息可丢则消费了就不管了并发量高性能好 2. 持久化消息状态，记录状态，准确性高，不丢消息
4. 超时补偿原则
调用方补偿？被调用方补偿？
如果被调用方明确响应给调用方, 成功/超时或着其他状态. 如果调用方接收到成功，而被调用方内部调用其他服务失败了，则由被调用方补偿。反之调用方补偿。注意接口幂等性，发生超时等异常都算是没有明确的响应。
实践经验
1. 数据量小时通过单个数据库的ACID特性控制即可，或者使用强悍的硬件加上专业的关系型数据库(Oracle,DB2,MySQL)解决
2. 量稍微大些时，如果用Oracle,DB2或者硬件成本过高，采用廉价硬件运行MySQL进行水平伸缩和分片，将相关数据分到数据库的同一个片上，依然能通过数据库的ACID特性保证事务。
3. 如果业务规则限制，无法将相关数据分到同一个分片上，则需要实现最终一致性，记录事务的中间状态，若不一致则通过系统自动化，补偿机制修复。
技术评审提纲
现状
技术背景
架构描述
当前系统调用量的峰值，最小，最大请求响应时间
需求
性能需求
预估系统容量
预估系统调用量峰值，最小和最大值
方案描述
方案1
详细说明<br>对方案的具体描述可结合图来说明<br>从如下几个方面进行说明
数据架构
数据结构
数据分布
拆分策略
缓存策略
读写分离策略
查询策略
数据一致性策略
<ol><li>异常处理</li><li>容灾策略</li><li>灰度发布</li><li>上线方案</li><li>回滚方案</li></ol>
性能评估
给出方案的基准数据，并按照性能需求评估需要使用的资源数量
单机并发量
单机容量
单机吞吐量的峰值
按照预估的性能需求，预估资源数量，服务器，缓存，存储，队列等
方案对比
风险评估
标识所选方案的风险，提出此风险发生时的应对策略。。。例如上线失败快速回滚等
工作量评估
列出具体工作的安排时间，评估开发，测试细化任务的时间，形成可实施的任务计划列表
要求一定可以量化，如果事情预估可能问题较多，需要做好buffer
