高并发库表设计随想

       随着移动互联网的蓬勃发展，大数据时代已经来临。面对高流量高并发的要求挑战。数据库的性能往往成为了后段开发的重中之重。以下就此问题结合笔者的一些实践谈谈库表设计的一些思路。

1，使用中间件，这种中间件一般都是mysql的外层代理，比如my cat这种，其核心思路是代理真实的mysql instance 支持一些库表路由策略，比如按ID取余，时间线切割等，中间件的好处是大大降低业务开发人员对数据库的细节敏感度，可以专注于业务开发，但是中间件的维护的重任往往就交由运维去管理，或者一个单独的中间件团队。中小型公司往往难以承受。此外中间件也有一定的性能损失。

2，服务端分库分表，这里的服务端是指需要连接数据库的各个服务，各个服务按照自己的策略将多个数据源配置在自己的服务里面，依据自身的义务需求路由到不同的表和库，这样的设计去除了中间件的性能损耗，可以达到数据库百分百性能的利用率，但是却耦合了库表路由策略，这些策略被写死在各自的服务里，往往不能轻易改动。

 3，服务端表拆分，就分库分表的策略而言目前比较流行的做法是按ID取余法和时间线分割法。ID取余说白了可以根据订单ID％X  散列到不同的表中这样的分表策略对于分页查询支持度比较差，同时查询的时候还需要携带分表策略所需要的ID。以mysql为例，如果单表支撑在一个亿的量级，分十张表足以支撑10亿数据量，这对绝大多数公司来说绰绰有余。此外我们也可以按照时间线分割的方法去拆表，以笔者所在的公司为例，一天的的数据流水量在千万级别，这种量级如果采用取余法分表很快就将支撑不住，如果按照时间线切割一天一张表，那么就可以完美的解决未来数据量扩容的问题，不会存在数据量的上限，而且天然的存在冷热分离的特性。除了当天的表其他表都是冷表。如果单天数据量再升一级又改如何处理呢？这里我们可以再次结合取余法，时间线分割的法存在单表性能压力，比如高峰时段单表写入压力过大，查询压力可以通过主从解决，写入却不能。再回到取余法，取余法的特点是将同一时刻的单表写入操作分担到多个表上，这里就出现了压力分担的效果。那我们是否可以将取余法与时间线法结合使用呢，例如单天的时间线表数据量可能上亿，高峰期并发写入压力很大，此时可以将单天的表按ID取余分拆成N个表，这样写入压力顿时降低到1/n,同时单表数据量也大大降低，以一天1亿的流水数据量来讲，也不会存在丝毫压力。

4，服务端库拆分，分库的策略更多的体现在不同的业务拆分上面，服务化的今天，一个企业内部几十个服务已经不足为奇，一台数据库集中存放这些库显然有点力不从心，按照不同的业务将不同的库拆分到不同的instance上是一种比较常见的做法。分库也可以结合分表做取余拆表设计，比如将某个订单表拆为8个库，每个库8张表。

5，痛点？分库分表的拆分是为了应对大数据量高并发的情况，但是其本省存在着一定的局限性，回顾一下以上策略，是否发现拆的越细，查询的时候越复杂呢？显然一门技术的推出可能会解决当前的某个痛点，但是随之而来的必然带来一些痛苦，就像拆了东墙补了西墙一样。很多时候需要结合自身的业务特点来抉择。业务重点关注的指标我们可以坚持去遵守，其他方面有所弱化未尝不可！