业务场景变化带来业务量激增导致高性能需求
小额支付的流行：
以前超市十几块钱东西刷卡，收银员白眼
现在大街小巷的商户摊贩都支持扫码支付，没人跟你叽歪
传统高可靠
银行高可靠方案很多是SRDF，成本高
数据库主备，高端共享存储，存数据库的文件和日志
- 高端存储硬件成本高
- 备库日常空闲，资源闲置
- 备库不是active，需要定期演练确保其可用，增大使用成本
不用分布式数据库的备选方案
- 垂直扩展
最偷懒也最可靠。升内存、CPU获得更好性能
硬件有天花板，不能完全解决问题
- 读写分离
方案很成熟，但非所有应用都有效
通常都是异步数据同步，存在延时，要评估查询业务延时容忍度
写性能并没提升
- 微服务
垂直分库分表，没有分布式事务干扰，分库是个好办法，代价是微服务本身的改造成本
热点服务，仍有性能压力
如果非业务本身，仅为分摊压力而拆库，很多事务的东西暴露到应用层，加大应用复杂度
上述都不能解决问题，最后两招，水平分库分表和分布式数据库
争吵最多的也是这两方案的拥护者，其他方案利弊比较容易看清
水平分库分表
Sharding+Proxy
直接拆数据库应用影响太大，大家都感觉疼，加Proxy让应用无感知，Proxy方案还是蛮多且历史悠久
Sharding-JDBC/TDDL/Atlas/MyCat
几个问题
- 跨分片的SQL怎么处理
- 唯一键、外键等全局约束怎么处理
- 全局ID如何生成
- 分片通常是基于业务键Hash，要求数据存在一个稳定的业务键恰好能解决访问热点，业务是否支持
- 是否支持分布式事务
这个方案也在不断的演化来解决上述问题，直到DRDS及类似方案的出现，已经转化为Proxy流派的分布式数据库
分布式数据库
-
Aurora代表
log is database为理念，不适用多数银行场景
-
Proxy流派延续
内核还是关系型数据库（多采用MySQL），增加SQL解析适配、节点调度、全局事务控制等
-
NewSQL流派
通常存储与计算引擎分离，访问接口兼容SQL，存储用KV存储和LSM模型，主副本用Paxos/Raft同步，支持分布式事务，完全ShareNothing架构
一个很贴切的比喻，IT系统就像时装，既要有实用性，还要符合时尚潮流
深入剖析 SRDF/Mtreo 和 MetroSync 双活数据中心存储方案 https://blog.csdn.net/btb5e6nsu1g511eg5xeg/article/details/78129920