第6章 微服务下如何保证事务的一致性
CAP 原则
CAP原则是Consistency (一致性)、Availability (可用性) 和 Partition-tolerance (分区容错性)的缩写，它是分布式系统中的平衡理论。一致性要求所有节点每次读操作都能保证获取最新数据;可用性要求无论任何故障产生后都能保证服务仍然可用;分区容错性要求被分区的节点可以正常对外提供服务。事实上，任何系统只可同时满足其中两个，无法三者兼顾。
BASE 理论
针对一致性和可用性提出的方案，BASE 是 Basically Available (基本可用)、Soft-state (软状态)和Eventually Consistent (最终一致性) 的缩写，它是最终一致性的理论支撑。
分布式解决方案
- 强一致性：两阶段提交协议、三阶段提交协议。
- 最终一致性：可靠事件模式、补偿模式、TCC 模式
两阶段提交协议
XA 是一个分布式事物协议，它有两个角色：事务管理者和资源管理者。XA 协议通过两阶段提交协议保证强一致性
问题：事物管理者必须等待所有参与者的操作返回结果才能进行下一步
三阶段提交协议
一阶段预备，增加超时机制，提前发现无法执行操作的参与者；二阶段准备、提交。
问题：若参与者在超时场景默认提交成功，可能出现数据不一致性。
TCC 模式
将任务拆分为 Try Confirm Cancel 三个操作
第一阶段主业务服务调用全部的从业务服务的Try操作，并且事务管理器记录操作日志。第二阶段，当全部从业务服务都成功时，再执行Confirm操作，否则会执行Cancel逆操作进行回滚。
对于执行失败的事物，会有重试逻辑，注意接口的幂等性操作
补偿模式
重试机制实现数据最终一致性
定时校对，对异常数据进行补偿
可靠事件模式
引入消息队列，保证当前可靠事件投递并且消息队列确保事件传递至少一次
正反消息机制：
- 主业务将要发送的消息持久化到本地数据库，设置标志状态为待发送，然后将消息发送到消息队列
消息队列接收到消息之后，持久化到副本中，然后消息队列返回 ACK 给主业务
- 主业务根据消息队列响应结果，将数据库消息发送标记变更为 已发送 或者 结束
- 消息队列发送消息到从业务，根据从业务的 ACK 进行判断，若成功，从业务将会向消息队列发送一个完成的消息，将数据库已发送的消息状态改为 已完成
- 若消息队列一直发送失败，那么定时任务会重发数据库中的 已发送 的消息
第7章 百亿流量微服务网关的设计与实现
面向服务架构（Service Oriented Architecture，SOA），关注的是服务，服务最基本的业务功能单元由平台中立性的接口来定义。强调
微服务架构（MicroServices Architecture，MSA）
API 网关职能：请求接入、业务聚合、中介策略、统一管理
第9章 微服务数据抽取与统计
第10章 微服务双活体系建设
第11章 基于支付场景下的微服务改造与性能优化
最终一致性： MQ 缓存补偿；binlog 更新
故障分析：
- hprof 命令
- pidstat
第12章 遗留系统的微服务架构改造
Data Object 与数据库表一一对应
Data Transfer Object 远程调用对象，一定要序列话
Business Object 封装业务逻辑的对象
View Object 通常是请求处理层传输的对象
第13章 Service Mesh详解
第14章 微服务监控实战
开源 Application Performance Mnanagement 产品：Google Dapper、Twitter Zipkin、CAR、Pinpoint、Skywalking
数据采集
- java agent
传输
历史数据存储
监控报警通知
图表展示
若有收获，就点个赞吧
0 人点赞
