一、企业级数据库Sharding Sphere分库分表应用设计实战
数据扩展带来的问题
请求路由
分表规则
写入路由
查询路由
分页查询怎么解决：混合模式
1、Sharding Sphere
Sharding JDBC ：客户端集成 线上业务使用
Sharding-Proxy：代理模式 数据维护使用
| 对比项 | Sharding JDBC | Sharding-Proxy |
| 数据库 | 任意 | 单一 |
| 异构语言 | 仅JAVA | 任意 |
| 连接数 | 高 | 低 |
| 性能 | 损耗低 | 损耗高 |
| 去中心化 | 是 | 否 |
| 静态入口 | 无 | 有 |
分布式事务：业务规避
二、企业级分布式事务阿里巴巴Seata应用设计实战
分布式事务
强一致
一致性协议
两阶段提交2PC 事务协调者->事务参与者A->事务参与者B 事务协调者询问确认提交
三阶段提交3PC 事务协调者->事务参与者A->事务参与者B 事务协调者询问是否提交，确认完再通知提交
落地方案
XA规范（两阶段提交）
资源管理器-事务参与者
事务管理器-事务协调者
存在问题（XA10倍性能衰减）
写入加锁 存在异常锁数据
记录事务执行状态 不支持异地恢复
柔性事务（最终一致性）
TCC（Try-Confirm-Cancel）框架实现
尝试执行业务，预留资源
确认执行业务，使用Try阶段资源
取消执行业务，释放Try阶段预留的资源
SAGA模型
把一个分布式事务拆分为多个本地事务
本地事务都有相应的执行模块和补偿模块（需要补偿逻辑并且补偿接口要有幂等）
事务管理器负责在事务失败时调度执行补偿逻辑
事务消息（分布式事务的弱化）MQ消息 RocketMQ 2PC
简化了分布式事务模型
对业务更友好
XA>TCC、SAGA>事务消息
Seata分布式事务流程
TM向TC申请开启一个全局事务，TC创建全局事务后返回全局唯一的XID，XID会在全局事务的上下文中传播
RM向TX注册分支事务，该分支事务归属拥有相同XID的全局事务
TM向TX发起全局提交或回滚
TC调度XID下的分支事务完成提交或者回滚
Seata-AT
介绍：
一种无侵入的分布式事务解决方案，2PC的广义实现
源自阿里云GTS AT模式的开源版本
核心价值
低成本：编程模型不变，轻依赖不需要为分布式事务场景做特定设计
高性能：一阶段提交，不阻塞；连接释放，保证整个系统的吞吐
高可用：极端的异常情况下，可以暂时跳过异常事务，保证系统可用
核心设计
一阶段
拦截“业务SQL”
生成前镜像：用于异常回滚
生成后镜像
二阶段
TX向所有RM发起提交/回滚
执行流程
拦截“业务SQL”
解析SQL语义
提取表元数据
保存原镜像
执行业务SQL
保存新镜像
利用本地事务保证ACID
提交：清快照数据
回滚：
检查脏写：新镜像VS当前数据库数据
还原数据：根据前后镜像，生成逆向SQL
删除中间数据：删除前后镜像
前后镜像：操作前后 查询数据作为前后镜像
商品库存操作：
用户下单减库存：每个下单都是独立的分布式事务，不同的XID
商户增加库存：不是分布式事务
隔离性
写隔离：
分支事务提交前拿到全局锁、
拿全局锁超时，回滚本地事务，释放本地锁
读隔离（数据库读已提交）
默认全局隔离级别是读未提交
如何做到读已提交：SELECT FOR UPDATE实现读已提交
如何实现可重复读：前镜像能否实现MVCC
Sharding Sphere 与 Seata集成
思考：
分支事务已经提交，如何回滚 undo log 回滚前镜像
防止其他数据对数据的修改 行锁->分布式锁
其他分布式事务的修改
非分布式事务的修改
三、企业级MySQL数据库高可用设计与实战
数据库冗余部署
一主一从或多从：增加主库同步压力
级联部署：降低了住的压力，但是串联同步方式可靠性低
尽量保证数据不丢失
延时库部署案例
一主多从抗线上流量
级联部署延迟从做备份
不要执行无条件 DELETE UPDATE
数据库高可用方案
提供两个VIP
VIP1指向主库，VIP2指向从库
主库发故障
VIP1和VIP2指向从库
故障节点恢复
VIP2指向新的从库
1491
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
