数据库架构演变概要

一．背景

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

二．现状

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

【数据量大】数据库目前400G左右，每月大约100G的增量；

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

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

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

三．架构升级方案概要

数据库架构演变顺序:

1) 大表表级拆分多表方案【风险:中 效果:不会特别明显】

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

缺点:只能缓解大表的数据增量，可是不能完全解决快速增加数据的本质问题。以目前的业务增量，即使作了冷热数据分离，也最多多支持几个月时间。

总结:只能缓解增量的症状[避免全表扫描的没必要要的数据筛选]，但不能解决本质问题。

2) UUID转int方案【风险:高 效果:应该比较明显】

优势:保守估计性能大约有6倍左右的提高（连表操做），索引及内存存储量下降为原来的1/4左右，表大小，数据库大小都会有相应的减小。

缺点:现有的数据库太大约400g，总体迁移过程和步骤相对很是复杂，须要自行经过编码实现迁移，难度很高。

总结:在cpu运算上和内存上会有明显优化，可是解决不了数据量（磁盘）本质问题。

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

优势:经过用户维度拆分多个用户库和主库（这里的主库不必定是一个库，也能够是垂直拆分的多库），从而分散数据量，增长多个表和库锁的粒度，数据库的链接池，硬件资源等；用户维度性能提高n倍,主库能够经过读写分离提高性能；足够业务n年的数据发展和平滑扩展。

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

总结:全维度（cpu，内存，磁盘）优化数据库，较完全解决数据库平行扩展和性能问题（除主库外）。相应的业务运维和运营的工做量加大和调整，但外围业务用户基本无感知架构变化。

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

优势:经过下降事务等级，减小读共享锁，避免部分业务更新操做的阻塞；从而提高并发处理的性能（相似java读写锁原理，如今让数据库读不加锁或者部分加锁）。

缺点:部分数据会出现脏读（可是用户基本无感知）(资金财务相关的不得下降事务等级),但去锁并不会加快单条数据查询的速度。业务代码基本大部分须要根据业务场景，进行细粒度的事务等级控制（原则上一些查询校验，能不用事务就不用事务；大块事务尽可能拆开多个事务；能经过Tcc或者最终一致性的业务幂等解决就不用强事务）（相似java方法级的锁，修改为方法内的多条代码级锁，减小锁粒度，保证尽快释放事务和锁）。

总结:有效的下降锁竞争致使的阻塞问题，可以有效提高业务高并发下面的整体并发能力，可是对无高并发下面的单笔业务处理耗时不会有明显提高，同时业务代码改动和梳理时间略费时间，但可根据状况自行取舍。mysql和sqlserver事务锁处理可能略有不一样，可是整体下降事务等级思路不变。

5) 数据库读写分离方案【风险:中 效果:比较好】

优势:基于用户维度拆分后，特别是针对主库进行读写分离（根据用户维度读指定的读库）; 将一些报表性查询，根据业务的实际状况选择读库或者写库(再加上低事务等级)，极大的提高数据库的性能（主库中一些全局的配置能够作读写分离，用户维度考虑硬件层面读备热切换和读写分离）。

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

总结:读写分离主要解决用户维度拆分后，主库的读压力(也能够部分分布式缓存解决)和稳定性。从二八理论上讲，能分担大部分的性能到从库，可是从库会有数据延迟的可能性，故在业务读写分离处理时需考虑。

6) 绝对低耦合(独立性)服务数据库垂直拆分【风险:中 效果：未知】

优势:低耦合的服务化数据库拆分红独立服务或者功能，此服务化数据库又能够按照多维和技术特性进行更细粒度的服务化拆分和高性能，能够提供服务复用性和独立稳定性规划。进一步下降业务数据量，提升业务的纯性能。（通常独立服务拆分有个特色: 要么是共性业务，要么不带业务属性的功能，并且这种服务数据量很多或稳定性要求极高）

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

总结:只拆绝对低耦合的业务为服务(如没把握，宁肯不拆)

四．架构简单示意图

 by 车江毅