关于后端:做好分库分表其实很难之一

是否须要分

说到数据库分库分表，不能一味的谋求，咱们要明确为什么要进行分库分表才是最终目标。当初网上一些人宣扬分库分表如何应答了多大数据，却不知针对很多人的业务来说，分库分表策略兴许并非是银弹，而是令人焦虑的焦油坑。

分库分表是业务倒退到肯定阶段，数据积攒到一定量级而衍生进去的解决方案。当 DB 的数据量级达到一个阶段，写入和读取的速度会呈现瓶颈，即便是有索引，索引也会变的很大，而且数据库的物理文件大的会使备份和复原等操作变的很艰难。这个时候因为 DB 的瓶颈曾经严重危害到了业务，最无效的解决方案莫过于 DB 的分库分表了。

有的 leader 甚至架构师会在业务初期以本人的主观志愿就进行分库分表，会为当前业务高速倒退做铺垫。然而这里我要表白我几个观点：

1. 如果以后这个业务并非公司的外围业务，而且在业务是否能存活的前提下，高级的设计不要这么简单。如果每个业务咱们都按淘宝那样的规模做零碎架构设计，未来岂但会害死业务，更会让程序员死的更惨，背上黑锅的数量会更多。
2. 单台数据库的能力并非设想中那么软弱。就算是 mysql 单表数据量大部分场景下也在百万级别（当然这和存储的具体数据格式无关），sqlserver 更是不在话下，我司用的 sqlserver，单表千万级别数据的大有所在，亿级的也有几个，Oracle 更是不必多说。
3. 如果业务周期比拟短，或者人力物力有余的状况下，自觉的在初期就进行分库分表设计，更是给本人下了绩效背 D 的套，
4. 零碎的设计初期和公司的根底数据有间接关系，比方微信这样的数据规模，略微一个小零碎就有可能是千万甚至上亿的数据级别，然而少数初创公司有多少能有这样的级别呢？我这里喷一句：有的守业公司号称从 XX 大公司重金挖来的 CTO，技术总监等等高人，尤其是这些带着金色光环的人在守业初期给开发人员埋雷，一个守业公司搞一套 XX 分布式，XX 设计，殊不知，在以后的公司环境下这些其实没有必要，给公司带来的更多是苦不堪言。

一个好的零碎设计者会在开始设计之初，充分考虑到各方面的综合因素来综合思考。

分库

依据业务划分

说到分库，菜菜这里想多啰嗦一句：举荐大家依据业务来进行划分，我始终在过来的文章中强调，一个零碎的好坏，业务的边界划分起到无足轻重的作用。业务依照规定划分好边界，每个业务对应的数据库自然而然就诞生了，不要站在数据库的层面下来给业务分库。有的 leader 会有这样的行为：某个表的数据量太大，调配到独自的一个库，后果导致的后果就是很多 SQL 语句必须跨库 Join。

具体的业务怎么划分呢？这个规定我不敢说，每个公司的业务状态不同，划分的维度就会不同。举一个简略的例子：一个典型的电商零碎依据业务可划分为商品，订单，这也是许多公司的典型业务划分，然而我司依据本人的业务规定，划分为商品，订单，领取。因为领取零碎在我司是一个独立的业务，岂但蕴含了订单的领取，还蕴含了很多其余的领取场景。依据业务上的划分，DB 的层面就呈现了商品 DB，订单 DB 和领取 DB。

同一业务横向划分

除了依据业务垂直切分的策略之外，还有另外一种罕用的分库计划，如果某个具体业务数据量比拟大，能够把这业务的数据库依据某种规定来进行横向切分。比方用户信息的业务，当用户量达到一定量级，有些公司会把用户信息拆分到多个数据库，说到这里，有的同学会问，这和拆分到多个表有什么区别呢？如果把用户信息横切到同一个数据库的多个表，如果这些表位于一个物理磁盘上，对于进步这个业务的写入和读取 IO 最大值并没有什么用途，然而如果调配到多个服务器上，意味着这个业务整体的最大 IO 失去了晋升，在肯定水平上要比拆表成果要好，当然如果用到了表分区，每个分区散落在不同的物理磁盘上，也不肯定比分库形式差。
把某个业务的 DB 依照规定横向切分之后，当然也会引入新的问题，下边会介绍。切分的规定在很多状况下用的最多的就是哈希取余的形式了，有工夫咱们在探讨。

分库引入复杂性

我在上文提到过，分库分表并非是银弹，任何一种解决方案能解决一个问题，然而有可能会引入其余问题，世界是偏心的，计算机世界亦如此。那分库会引入哪些问题呢？

1. 在执行了分库之后，难以避免会将本来逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，咱们少数状况下无奈 join 位于不同分库的表（因为少数公司都明令禁止跨库 sql），后果本来一次查问可能实现的业务，可能须要屡次查问能力实现。
2. 原来在单体 DB 环境下，能够用 DB 的事务来保障一些操作的原子操作，然而在扩散到多个数据库的状况下，对立治理这些操作变的艰难。尽管一些大厂提供的也有跨库的事务解决方案，然而性能上切实是差强人意，所以在很多状况下并不实用。比方上边提到的商品库存领取，在单体利用的状况下，三个业务在同一个数据库，当产生领取业务，更改商品库存和更新订单状态这两个操作能够利用数据库提供的事物来实现，而且性能在可承受范畴之内，如果这三个业务散布在不同的数据库，有几率会产生只执行其中一个操作的状况产生，其实这也是分布式事物要解决的问题。在很多状况下，分布式事物是无奈防止的，依据业务综合状况适当采纳分布式事物也是一种无效的解决方案，最坏的状况下，可能须要人工染指了。
3. 分库对于 DBA 来说意味着工作量的成倍增加，原来只须要治理一个 DB，当初却要治理 N 个 DB，而且每个 DB 都须要备份，监控，甚至做高可用，扩大等工作。原来可能只须要一个 DBA 管理人员，分库之后可能会须要两个甚至三个，导致了公司在人力投入上的加大。

对于分库你有什么要说的吗？欢送在留言区探讨

更多精彩文章

• 分布式大并发系列
• 架构设计系列
• 趣学算法和数据结构系列
• 设计模式系列