分布式数据库
1、先抛出两个问题
问题一、当mysql单表数据量爆炸时，你怎么办？
问题二、当你的数据库无法承受高强度io时你怎么办？
MHA
4.3.2 MMM
5、 应用案例
5.1 记录一次mongo迁移mysql的过程(分库分表使用jproxy)
mongo怎么了？跟分片无关的部分简单说。
? mongo很好，只是业界并没有成熟的MongoDB运维经验，jd too。
像高并发的系统 订单和库存 商品 还是拿nosql把，高并发的写,也不会打挂他,比如hbase，顶多GC频繁点，但是也是可用的。
一致性完全可以CAS搞定，而不是mysql的排他锁。
- 迁移数据库的一个方案
1) 中心化(统一入口)
2) 双写(先同步写mysql如果发生异常改异步，尽量避免服务不可用)
3) 倒库(jproxy支持通过游标形式全量遍历库-逐个表操作，可以利用其异步同步数据)
4) 数据校验
5) 切库提供服务
去mongo+优化方案(此处引入了分片的概念)
压测与性能
去mongo任务线
| 类型 | 任务 | 备注 | 影线系统 | 风险 |
|---|---|---|---|---|
| design | 海关迁移方案设计评审 | … | … | 无 |
| design | 分库分表技术选型 | jproxy | … | 无 |
| apply | 申请迁移相关应用(辅助系统) | 跑批任务 | … | 无 |
| apply | 申请mysql集群 | dbs系统 | … | 无 |
| apply | 申请jproxy集群 | 直接找接口人 | … | 无 |
| apply | 申请es集群 | esm杰斯 | … | 无 |
| coding | trace表服务中心化 | soa | center | 高 |
| coding | 涉及trace业务逻辑梳理，全部切换中心接口 | 接口完全适配 | platform | 低 |
| verify | 回归测试，并线上走单验证一段时间 | 先预发后正式 | … | 高 |
| coding | 实现mysql版本共2个表sql映射文件 | 基于自主研发的generator | center | 低 |
| verify | mysql版本sql映射文件单元测试 | 基于自主研发的generator | center | 低 |
| coding | trace表实现基于jproxy的分库分表 | 128个库(主) 1主3从 | center | 中 |
| coding | es分别按照商家id分片，保税区id分片，异步写，读开放jsf | 2套集群4套索引 | es | 中 |
| coding | 中心接口加入代理层，可利用开关切换读mongo/mysql/es | … | center | 高 |
| coding | 异步补偿mongo,mysql,es功能开发 | 基于jmq | platform | 中 |
| coding | 代理层实现mongo和mysql版本互为主被双写(mongo主)，异步写es | 双11后mysql主 | center | 高 |
| verify | 线上开双写(包括es) | 两套es集群 | … | 中 |
| coding | 倒库功能开发，数据校验功能开发 | reactor | config | 高 |
| verify | 倒库，并进行数据校验 | 校验规则(特殊字段不校验) | … | 高 |
| verify | 对中心接口进行压测 | 线上，压测环境隔离(jsf别名) | … | 高 |
| coding | 优化配置(mysql调整最大连接数,es使用filterCache) | … | … | 高 |
| verify | 对中心接口进行压测 | … | … | 高 |
| verify | 升级后架构正式上线 | … | … | 无 |
| verify | 监控切换mysql之后的接口性能 | … | … | 无 |
| verify | 监控切换mysql之后对相关依赖系统的影响 | … | … | 无 |
| todo | 停mongo写 | … | … | 无 |
| todo | 继续迁移海关mongo中其他表(以上均为trace表) | … | … | 无 |
| todo | 彻底下线mongo数据库服务器，只保留mysql服务器 | … | … | 无 |
5.2 记录一次异构具有复杂分片规则数据库的过程
5.2.1 难点
? 交易库存复杂的分片规则，数据量大，更新频繁，一致性保证。
回到本源，缓存+队列