一．背景

为了适应业务增长,数据库数据量快速增长，性能日趋下降，稳定性不佳的实际情况，急需架构逐步演变适应未来的业务发展。

二．现状

【稳定性】数据库为单点，没有高可用和稳定性方案。

单表数据只增不删，数据持续增长;

【业务优化，剥离难】业务比较复杂，单纯的业务梳理剥离和优化，涉及业务方沟通及方案确立周期太长;

【查询慢】单机性能已出现过cpu瓶颈导致响应缓慢，大量的慢查询。

三．架构升级方案概要

数据库架构演变顺序:

优点:通过拆分大表，拆分冷热数据，从而减少单表的数据扫描，进而优化数据库性能。

缺点:只能缓解大表的数据增量，但是不能彻底解决快速增长数据的本质问题。以目前的业务增量，即便做了冷热数据分离，也最多多支持几个月时间。

【风险:高 效果:应该比较明显】

3) 用户维度拆分方案【风险:高 效果:最好】

缺点:拆分多库，可用性和服务器稳定性下降（但是理论上出问题仅影响部分用户，可以保证总体可用性不会降低）。后期维护索引和更新，运维工作量加大多倍。业务代码基本大部分稍微调整（需要选择分库），部分业务代码需要分布式事务支持（基本现有代码的所有一致性事务需要调整）。

4) 业务降低事务化方案【风险:中，效果：高并发下面效果好】

缺点:需要代码级别支持读库宕机，移除节点，平滑故障（需要分库分表中间件支持配置中心和数据库故障检测信息打通，自动故障转移）。要梳理业务逻辑，使一部分业务代码的查询切换到读库。

【风险:中 效果：未知】

缺点:未来业务确保不会出现耦合度粘性的发展，细粒度服务会更多，但是开发稳定后一般不会更改。

四．架构简单示意图