- Mysql分库分表
- 1.用户请求大
- 单服务器TPS、内存、IO有上限，需要分散请求
- 2.单库数据量大
- 单库数据库处理能力有限
- 3.单表数据量大
- 单表数据量过大引起SQL变慢
- 不同的业务场景可以用不同的分库分表key的方案
- 分库分表的问题：
- 1.事务问题：一次事务插入两条记录，分布在不同的服务器上，数据保障一致性
- 2.垮裤join：全局表（字典表）、字段冗余、系统层组装
- 3.额外的数据运算压力
- ShardingSphere(Sharding jdbc):张亮
- Sharding-jdbc和sharding-proxy、sharding-sidecar（规划）组成
- Sharding-jdbc：
- 适用于任何基于java的ORM框架，支持各种连接池，各种数据库(关系型)
- 主要功能：数据分片、分布式事务、数据库治理
- 1.引入依赖
- 2.规则配置
- 3.创建DataSource
- 分片算法
- 提供接口，需要自己实现分片算法。
- 精确分片算法preciseshardingalgorithm
- 范围分片算法rangshardingalgorithm
- 复合分片算法complexkeysshardingalgorithm
- hint分片算法hintshardingalgorithm
- 分片策略：分别是以上分片算法的封装实现
- 1.标准分片策略
- 2.复合分片策略
- 3.行表达式分片策略
- 4.hint分片策略
- SQL规范
- 1.多数据节点不支持case when/having/union(all)
- 2.只支持一层子查询
- 3.子查询中不支持聚合函数
- 4.不支持包含schemaSQL
- 5.分片健在表达式中将全路由（效率低）
- inline表达式
- ${begin..end}范围
- ${[unit,unit2..]}枚举值
- 主键生成策略
- UUID:效率较低
- SNOWFLAKE：64bit长整形
- 自定义主键生成器：实现shardingkeygenerator接口
- 读写分离支持
- 1.只支持单主库
- 2.可以独立使用
- 3.统一线程保证数据一致性
- 4.基于hint的强制主库路由
- 5.不支持主从数据同步
- 6.主从数据同步延迟
- 7.主库双写和多写不支持
- 8.跨主从的事务数据不一致
- 数据脱敏操作：自动化加解密
- 分布式事务
- CAP（强一致性）
- BASE（最终一致性）
- 2PC(两阶段提交)：1.准备阶段2.提交阶段
- 有性能问题，容易阻塞，数据一致性问题
- 3PC（三阶段提交）：1.可以提交2.准备提交3.提交
- 解决单点阻塞问题
- XA（强一致性）分布式事务规范
- 实现XA接口，通过事务管理器进行分布式事务管理，MYSQL只是一个参与者
- TCC（最终一致性）
- try/confirm/cancel
- 解决了协调者单点，
- 引入超时机制，超时补偿
- 控制一致性
- 消息队列模式（最终一致性）
- 1.事务主动方处理本地事务
- 2.事务主动方写消息，事务被动方处理事务，写消息
-
- Saga模式（最终一致性）
- 是一种补偿模式
- 1.向前回复，顺序执行，失败重试知道成功
- 2.向后回复，失败向后补偿
- Seata框架
- 有AT/TCC/SAGA，默认AT
- Mycat
- 支持垮裤Join
- 逻辑库、逻辑表
- 分片表、非分片表
- ER表、全局表
- Server.xml：配置mycat的系统配置信息
- mycat的全局序列生成方式
- 0：本地文件
- 1：数据库
- 2：本地时间戳
- 3：ZK
- schema.xml配置
- 配置逻辑库、表、分片节点
- rule.xml
- 分片规则配置
