分布式数据库

高性能

业务场景变化带来业务量激增导致高性能需求

小额支付的流行

以前超市十几块钱东西刷卡,收银员白眼。现在大街小巷的商户摊贩都支持扫码支付,没人跟你叽歪

高可靠

银行高可靠方案很多都是SRDF,主要问题是成本

数据库主备,高端共享存储存数据库文件和日志

三个问题,高端存储硬件成本高;备库日常空闲,资源闲置;备库不是active,需要定期演练确保其可用,增大使用成本

不用分布式数据库的备选方案

垂直扩展

最偷懒也最可靠。升内存、CPU获得更好性能。硬件有天花板,不能完全解决问题

读写分离

方案很成熟,但非所有应用都有效。通常都是异步数据同步,存在延时,要评估查询业务延时容忍度

写性能并没提升

微服务

垂直分库分表,没有分布式事务干扰,分库是个好办法,代价是微服务本身的改造成本

热点服务,仍有性能压力

如果非业务本身,仅为分摊压力而拆库,很多事务的东西暴露到应用层,加大应用复杂度


上述都不能解决问题,最后两招,水平分库分表和分布式数据库

争吵最多的也是这两方案的拥护者,其他方案利弊比较容易看清

水平分库分表

Sharding+Proxy

直接拆数据库应用影响太大,大家都感觉疼,加Proxy让应用无感知,Proxy方案还是蛮多且历史悠久,Sharding-JDBC/TDDL/Atlas/MyCat

几个问题 1、跨分片的SQL怎么处理 2、唯一键、外键等全局约束怎么处理 3、全局ID如何生成 4、分片通常是基于业务键Hash,要求数据存在一个稳定的业务键恰好能解决访问热点,业务是否支持 5、是否支持分布式事务

这个方案也在不断的演化来解决上述问题,直到DRDS及类似方案的出现,已经转化为Proxy流派的分布式数据库

分布式数据库

三类

Aurora代表,log is database为理念,不适用多数银行场景

Proxy流派延续,内核还是关系型数据库(多采用MySQL),增加SQL解析适配、节点调度、全局事务控制等

NewSQL流派,通常存储与计算引擎分离,访问接口兼容SQL,存储用KV存储和LSM模型,主副本用Paxos/Raft同步,支持分布式事务,完全ShareNothing架构

一个很贴切的比喻,IT系统就像时装,既要有实用性,还要符合时尚潮流