作者介绍：

丁浪，现就职于某垂直电商平台，担任技术架构师。关注高并发、高可用的架构设计，对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享。

来源：infoQ||聊聊架构

1题记

“分库分表”是谈论数据库架构和优化时经常听到的关键词。那么对于这些业务量正在高速增长的公司，它有那么容易实践吗？

在谈论数据库架构和数据库优化的时候，我们经常会听到“分库分表”、“分片”、“Sharding”…这样的关键词。让人感到高兴的是，这些朋友所服务的公司业务量正在（或者即将面临）高速增长，技术方面也面临着一些挑战。

让人感到担忧的是，他们系统真的就需要“分库分表”了吗？“分库分表”有那么容易实践吗？为此，笔者整理了分库分表中可能遇到的一些问题，并结合以往经验介绍了对应的解决思路和建议。

2垂直分表

垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中，如下图所示：

小结

在字段很多的情况下，拆分开确实更便于开发和维护（笔者曾见过某个遗留系统中，一个大表中包含100多列的）。某种意义上也能避免“跨页”的问题（MySQL、MSSQL底层都是通过“数据页”来存储的，“跨页”问题可能会造成额外的性能开销，这里不展开，感兴趣的朋友可以自行查阅相关资料进行研究）。

拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎。

3垂直分库

垂直分库在“微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中。如下图：

小结

系统层面的“服务化”拆分操作，能够解决业务系统层面的耦合和性能瓶颈，有利于系统的扩展维护。而数据库层面的拆分，道理也是相通的。与服务的“治理”和“降级”机制类似，我们也能对不同业务类型的数据进行“分级”管理、维护、监控、扩展等。

众所周知，数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈，是大型分布式系统中优化数据库架构的重要手段。

然后，很多人并没有从根本上搞清楚为什么要拆分，也没有掌握拆分的原则和技巧，只是一味的模仿大厂的做法。导致拆分后遇到很多问题（例如：跨库join，分布式事务等）。

4水平分表

水平分表也称为横向分表，比较容易理解，就是将表中不同的数据行按照一定规律分布到不同的数据库表中（这些表保存在同一个数据库中），这样来降低单表数据量，优化查询性能。最常见的方式就是通过主键或者时间等字段进行Hash和取模后拆分。如下图所示：

小结

水平分表，能够降低单表的数据量，一定程度上可以缓解查询性能瓶颈。但本质上这些表还保存在同一个库中，所以库级别还是会有IO瓶颈。所以，一般不建议采用这种做法。

5水平分库分表

水平分库分表与上面讲到的水平分表的思想相同，唯一不同的就是将这些拆分出来的表保存在不同的数据中。这也是很多大型互联网公司所选择的做法。如下图：

某种意义上来讲，有些系统中使用的“冷热数据分离”（将一些使用较少的历史数据迁移到其他的数据库中。而在业务功能上，通常默认只提供热点数据的查询），也是类似的实践。

在高并发和海量数据的场景下，分库分表能够有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈。当然，投入的硬件成本也会更高。同时，这也会带来一些复杂的技术问题和挑战（例如：跨分片的复杂查询，跨分片事务等）

6分库分表的难点

垂直分库带来的问题和解决思路：

跨库join的问题

在拆分之前，系统中很多列表和详情页所需的数据是可以通过sql join来完成的。而拆分后，数据库可能是分布式在不同实例和不同的主机上，join将变得非常麻烦。而且基于架构规范，性能，安全性等方面考虑，一般是禁止跨库join的。那该怎么办呢？

首先要考虑下垂直分库的设计问题，如果可以调整，那就优先调整。如果无法调整的情况，下面笔者将结合以往的实际经验，总结几种常见的解决思路，并分析其适用场景。

跨库Join的几种解决思路

全局表

所谓全局表，就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），所以也不用太担心“一致性”问题。

字段冗余

这是一种典型的反范式设计，在互联网行业中比较常见，通常是为了性能来避免join查询。

举个电商业务中很简单的场景：

“订单表”中保存“卖家Id”的同时，将卖家的“Name”字段也冗余，这样查询订单详情的时候就不需要再去查询“卖家用户表”。

字段冗余能带来便利，是一种“空间换时间”的体现。但其适用场景也比较有限，比较适合依赖字段较少的情况。最复杂的还是数据一致性问题，这点很难保证，可以借助数据库中的触发器或者在业务代码层面去保证。

当然，也需要结合实际业务场景来看一致性的要求。就像上面例子，如果卖家修改了Name之后，是否需要在订单信息中同步更新呢？

数据同步

定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步。当然，同步本来会对数据库带来一定的影响，需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询。笔者曾经在项目中是通过ETL工具来实施的。

系统层组装

在系统层面，通过调用不同模块的组件或者服务，获取到数据并进行字段拼装。说起来很容易，但实践起来可真没有这么简单，尤其是数据库设计上存在问题但又无法轻易调整的时候。

具体情况通常会比较复杂。下面笔者结合以往实际经验，并通过伪代码方式来描述。

简单的列表查询的情况

伪代码很容易理解，先获取“我的提问列表”数据，然后再根据列表中的UserId去循环调用依赖的用户服务获取到用户的RealName，拼装结果并返回。

有经验的读者一眼就能看出上诉伪代码存在效率问题。循环调用服务，可能会有循环RPC，循环查询数据库…不推荐使用。再看看改进后的：

这种实现方式，看起来要优雅一点，其实就是把循环调用改成一次调用。当然，用户服务的数据库查询中很可能是In查询，效率方面比上一种方式更高。（坊间流传In查询会全表扫描，存在性能问题，传闻不可全信。其实查询优化器都是基本成本估算的，经过测试，在In语句中条件字段有索引的时候，条件较少的情况是会走索引的。这里不细展开说明，感兴趣的朋友请自行测试）。

小结

简单字段组装的情况下，我们只需要先获取“主表”数据，然后再根据关联关系，调用其他模块的组件或服务来获取依赖的其他字段（如例中依赖的用户信息），最后将数据进行组装。

通常，我们都会通过缓存来避免频繁RPC通信和数据库查询的开销。

列表查询带条件过滤的情况

在上述例子中，都是简单的字段组装，而不存在条件过滤。看拆分前的SQL：

这种连接查询并且还带条件过滤的情况，想在代码层面组装数据其实是非常复杂的（尤其是左表和右表都带条件过滤的情况会更复杂），不能像之前例子中那样简单的进行组装了。试想一下，如果像上面那样简单的进行组装，造成的结果就是返回的数据不完整，不准确。

有如下几种解决思路：

1. 查出所有的问答数据，然后调用用户服务进行拼装数据，再根据过滤字段state字段进行过滤，最后进行排序和分页并返回。

   这种方式能够保证数据的准确性和完整性，但是性能影响非常大，不建议使用。

2. 查询出state字段符合/不符合的UserId，在查询问答数据的时候使用in/not in进行过滤，排序，分页等。过滤出有效的问答数据后，再调用用户服务获取数据进行组装。

   这种方式明显更优雅点。笔者之前在某个项目的特殊场景中就是采用过这种方式实现。

跨库事务（分布式事务）的问题

按业务拆分数据库之后，不可避免的就是“分布式事务”的问题。以往在代码中通过spring注解简单配置就能实现事务的，现在则需要花很大的成本去保证一致性。

7垂直分库总结和实践建议

本篇中主要描述了几种常见的拆分方式，并着重介绍了垂直分库带来的一些问题和解决思路。读者朋友可能还有些问题和疑惑。

1. 我们目前的数据库是否需要进行垂直分库？

根据系统架构和公司实际情况来，如果你们的系统还是个简单的单体应用，并且没有什么访问量和数据量，那就别着急折腾“垂直分库”了，否则没有任何收益，也很难有好结果。

切记，“过度设计”和“过早优化”是很多架构师和技术人员常犯的毛病。

2. 垂直拆分有没有原则或者技巧？

没有什么黄金法则和标准答案。一般是参考系统的业务模块拆分来进行数据库的拆分。比如“用户服务”，对应的可能就是“用户数据库”。但是也不一定严格一一对应。

有些情况下，数据库拆分的粒度可能会比系统拆分的粒度更粗。笔者也确实见过有些系统中的某些表原本应该放A库中的，却放在了B库中。有些库和表原本是可以合并的，却单独保存着。还有些表，看起来放在A库中也OK，放在B库中也合理。

如何设计和权衡，这个就看实际情况和架构师/开发人员的水平了。

3. 上面举例的都太简单了，我们的后台报表系统中join的表都有n个了， 
分库后该怎么查？

有很多朋友跟我提过类似的问题。其实互联网的业务系统中，本来就应该尽量避免join的，如果有多个join的，要么是设计不合理，要么是技术选型有误。请自行科普下OLAP和OLTP，报表类的系统在传统BI时代都是通过OLAP数据仓库去实现的（现在则更多是借助离线分析、流式计算等手段实现），而不该向上面描述的那样直接在业务库中执行大量join和统计。

8送书环节

介绍作者

首先，我必须得介绍下作者，因为这个作者在IT领域，一直是一个非常努力的同学，虽然人生的起点很低，但是海到无边天作岸，山登绝顶我为峰！只要努力就能成功！这个作者就是 安晓辉！

安晓辉，从最初的技术售后支持进入IT行业，到转型做开发宽带接入产品的软件工程师，再到研发部门经理，再到创业，创业失败，回归开发岗位，最后，脱离组织，成为自由职业者，出了好几本书！真的非常励志！这种从未放弃自己，一直认真的态度，努力的精神，值得大家学习！

介绍书籍

作为一名普通的程序员：

• 你想买一套房子，不想再租住在远离公司的偏僻地带每天通勤 4 个小时上下班

• 你想买一部车子，可以周末开着去山里转转，看看红叶听听鸟鸣

• 你想买衣服时去窗明几净微笑服务的商场而不是每次都找一个不知名姓的小二网购经济适用款

• 你想每年出去旅游 10 次 8 次，今天在苏梅岛潜水明天在魁北克吃枫糖

• 你想每年给爸爸妈妈 5 万块的生活费，让他们露出欣慰的笑脸

这些想法不能实现，会经常性地带给你痛苦。这种痛苦，会随着你工作时间的增长而加深，渐渐变成你生活的底色——你的底色原本简单明快，现在幽暗阴郁。

实际上，这些所谓的痛苦，有 90% 都可以通过钱来解决。前提是：你的价值能够不断提升，赚钱速度超越需求膨胀。消除了这些痛苦，幸福感就有生长的环境，就不那么容易被淹没。

可是作为普通的程序员，你却发现瓶颈一个接一个地扑过来。做技术，不知道怎么做到持续精进、怎么坚持；转管理，又不知如何开始。结果还没等想明白呢，半载一年就过去了，蓦然回首，好像自己的能力没怎么提高，薪水增速却越来越跑不过通货膨胀了。

有时候你觉得开发工作越来越吃力，转型的呼声越来越高，却不知道如果离开开发岗位自己还能干什么。看着别人可以选择当自由职业者，或者能实现财务自由，内心羡慕，然而转过身却只能叹息：自己的路，究竟在哪里？

仔细想想，你就会发现，要搞定这些事情和问题，只要能赚到更多的钱就可以了！

这个结论很俗吗？

不，现实正是如此！

对于大部分开发者来讲，工作和生活的诸多烦恼，其实都源自于：怎么赚到更多的钱。

要想赚到更多的钱，就要回到问题的原点，想想个人赚钱的本质是什么。

个人赚钱的本质是——出售时间！对吗？

从出售时间的角度来看：

个人收入=每天可售时间数量×单位时间价格×单位时间出售次数

在这个公式里，有三个要素，简单描述就是：

• 每天可出售的时间数量

• 单位时间价格

• 同一份时间的出售次数

结合开发者的具体情况，可以找到多种提升收入的方式。参考下表：

或许你知道所有这些方式甚至知道更多，但是，怎么做到呢？

这是个大问题！

知道和做到之间有一道鸿沟，要想跨越它，你不但要努力，还要讲究方法。

那么，到底要用什么样的思维、方法，才能找到适合你的提升收入的方式呢？安晓辉的新书

《程序员的成长课》为您解惑！

领取方式：

这一次安晓辉作者一共赞助了5本书，暂时没办法惠及到所有的渴求知识的小伙伴，只好按照 3+1+1 的规则来分配。活动规则如下：

1.从留言区选出点赞数最多的前 3 位朋友。

2.从留言区选出我个人最喜欢的 1 条留言。

3.从赞赏的朋友当中随机抽取  1位。

送书活动截止时间：2017年12月21日18点整！

觉得有帮助？请转发给更多人！

架构师小秘圈，聚集10万架构师的小圈子！不定期分享技术干货，行业秘闻！汇集各类奇妙好玩的话题和流行动向！长按左侧图片，扫码加入架构师微信群！