背景：
互联网业务发展初期，系统很小，所有的业务代码都放在同一个工程，所有数据也都存放在一个DB中。业务持续发展，代码量一天天膨胀，为了提高开发、测试、上线的效率以及线上系统的稳定性，架构上会采用分布式系统，系统被拆分成多个子系统，子系统拥有独立的版本控制和测试发布过程。此时，如果还是一个DB，多个工程会占用很多连接数，多项业务并行增长，数据量会猛增，数据库的瓶颈马上突显。同时，数据库只有一个实例，如果某一业务系统在某一时间点对数据库造成很大压力，导致数据库崩溃，会直接影响到其他业务系统。
互联网业务发展迅猛，用户量和订单等数据日益增加，订单单表的数据量可能达到千万甚至上亿的级别，数据存储可能占到几十上百G，即使采用主从架构，增加多个从库，提高服务器资源配置，各种索引优化，依然存在很多查询不理想的情况。数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护。为了满足持续增长的业务，数据库架构必须面临升级。
上面提到的场景下，我们分别需要对数据库进行垂直拆分和水平拆分来解决。
［什么是垂直分库？］
- 一个数据库由很多表构成，每一张表对应一类业务，按照业务进行归类，将不通业务的表分散到独立的数据库中，来达到分散数据库的压力的目的。
［解决方案？］
以电商系统为例
-
业务初期，一个开发团队，几个人，为了快速实现业务，一套代码，一个数据库实例。前期业务包含用户、商品、订单、支付等。
分库1.png
-
业务后期，增加了促销、团购等很多新业务，同时用户量持续上升，订单量不断增加，数据库压力与日俱增。开发人手增加，不同团队维护不同业务， 系统按业务模块拆分，数据库对应做垂直拆分。
分库2.png
潜在的问题：
数据库实例分为了多个，但是某一业务系统还是会关联多个数据库。会有以下痛点：
- user数据的查询sql，在登录和下单的工程里面可能存在2份拷贝。当user表发生变更时，下单业务代码也需要修改。一处升级，多处修改。
- 促销和下单都会访问到product表，两者的sql逻辑可能不一样，两个工程由不同的团队维护，如果促销代码由初级工程师写出来，sql性能比较差，可能会影响商品数据库的整体稳定性进而影响到下单。所以sql难以收口，不好控制。
- 架构升级可能导致product表拆分或者扩展，那么product相关的所有查询可能都要改，促销、下单等所有工程将会受到影响。耦合太大，业务架构优化很难推进。
架构升级必然会带来新的问题，所以为了代码的复用性、屏蔽底层业务的复杂度、实现数据库解藕，在垂直分库的基础上需要继续服务化的改造。服务化之后，提供通用的接口，性能瓶颈统一在服务层优化。
分库3.png
服务化以后，垂直分库的架构得以成功实施。
［什么是水平分库？］
- 水平分库就是我们常说的分库分表，一张表分成N多个小表，每张表的结构相同。 即将单张表的海量数据，按某个维度将记录行分散到多个数据库的多个表中，以降低单表的数据量来提高性能并支持无限增长的业务数据存储。
［解决方案？］
- 一旦涉及水平分库，逃不开“分库依据”sharding key的概念，即使用哪一个字段来切分数据库。选择标准是尽量避免应用代码和SQL性能受影响，这就要求当前SQL在分库后，访问尽量落在单个库里，否则单库访问变成多库扫描，读写性能会受较大影响。同时要保证每个数据库的数据分布是均匀的，且每个数据库的请求压力是均匀的。大部分业务场景会使用业务id取模来分库。
举一个例子：
用户库db-user，user表水平切分后变为2个库，分库依据sharding key采用userId。userId%2=0的数据会落到db0，userId=1的数据则路由到db1。
分库4.png
产生的问题：
- 表的主键id无法正常使用数据库的自增策略。因为多个库中的记录id不能重复。
＃必须保证auto_increment的初始值不同，且步长统一；或者在应用层采用自定义的主键生成策略。 - 对于带聚合运算的查询，如带groupBy/orderby/min/max/avg等关键字，需要多库查询。
＃应用层要有统一的DAL层将单个数据库的查询结果进行汇总，效率比单库的聚合查询效率低很多，且实现起来复杂。 - user库暂时切分为2个库，业务发展到一定阶段可能需要拆分成更多的数据库实例。
＃因为采用了hash取模的算法，当数据库切分为更多后，现有数据库的数据需要迁移。假如切分为4个库以后，现在2个库必须各迁移一半到另外2个库中。业务不停增长，数据库实例可能越来越多，我们需要按照2的N次方进行扩展以降低数据的迁移难度。
网友评论