「论道架构师」拒绝无脑搬砖,从分库分表开始

18,540 阅读7分钟

「论道架构师」拒绝无脑搬砖,从分库分表开始

⚠️本文为掘金社区首发签约文章,未获授权禁止转载


事件起因

6月初我负责的商家数据某功能由于业务原因导致数据量不断上涨,当时使用的MySQL单表已经难以提供高效的查询,因此基于商家维度(商家主键ID)对它进行了分表,问题得以解决。

6月中旬我沉浸在无止尽的需求之中,边做边发出感慨:进大厂又能怎么样呢,还不是CRUD,面试造火箭罢了

此时,架构师笑了笑,于是乎有了本篇文章。


我的方式:取模水平分割

亮架构:说一下你上次分表的实现方案吧,Kerwin。

我:我是参照其他系统的方式进行的,利用商家主键Id(商家系统自增的Long型主键)对100取模,由此计算出它应该落在哪一张表,唯一的变动就是这个环节以及数据迁移了。

大概思路如下:

// 业务层代码...
String tableName = "orgcode_datas_" + orgcode % 100;
String insertUserSql = "INSERT INTO " + tableName + " VALUES ('" ... "');";

亮架构:所以你采用的就是最简单的方式,而且还把取模逻辑耦合在了业务层吗?

我:是啊,其他系统也都是这么做的,这样搞最快,最安全。

亮架构:你的系统用的是MyBatis对吧,你稍微调研一下就知道,我们可以借助MyBatis的拦截器实现刚刚业务代码中耦合取模的那部分逻辑,虽然本质上没有高明多少,但让它的数据操作底层变得更加清晰明了了,这不就是一种进步吗?

我(略感羞愧):你说的有道理,回去我研究研究。

亮架构:再来看另一个问题,你说了这次分表涉及到数据迁移,你现在分了100个表,万一以后还不够用怎么办?难道要再全部迁移一遍吗?

我(非常羞愧):啊这个,应该不会不够用吧...


一致性哈希方案

亮架构:Kerwin,你面试的时候有没有被问到过Redis的一致性哈希问题

我(来劲了):有,Redis中引入了一致性Hash算法。该算法对2^32 取模,将Hash值空间组成虚拟的圆环,整个圆环按顺时针方向组织,每个节点依次为0、1、2...2^32-1,之后将每个服务器进行Hash运算,确定服务器在这个Hash环上的地址,确定了服务器地址后,对数据使用同样的Hash算法,将数据定位到特定的Redis服务器上。如果定位到的地方没有Redis服务器实例,则继续顺时针寻找,找到的第一台服务器即该数据最终的服务器位置。

相关文章:「查缺补漏」巩固你的Redis知识体系(笑)

image-20210704155443807.png

亮架构:Redis的这个知识点你知道,MySQL的你就不知道了?如果我让你把简单取模法更换为一致性哈希方案,你该怎么做?

我(忐忑):如果参考Redis的话,我会这么做:

  1. 从表的命名开始,尽量取名为取模后相对均匀的名称,不以连续后缀结尾了
  2. 我需要找一个碰撞相对较少的哈希算法
  3. 取模的逻辑需要修改为两步,首先是建立数据表落点(即上图中的蓝球)并存储,再计算数据的落点(即红球),然后动态的计算它应该归属到哪一张表即可

亮架构:差不多,命名的部分可以再思考思考,但是你知道你这么做会遇到什么问题吗?提示:和Redis一样的问题。

我(信心满满):这个我知道,可能会出现数据过于集中的问题,这是由于数据和服务器分布不均匀导致的,例如上图中的情况,归属到一号服务器(顺时针第一个蓝球)的概率太大了,这个简单,我们只需要增加虚拟节点,或者从命名上考虑让它尽量平铺,均匀就好啦。

亮架构:孺子可教也,你说说看,这个方式和你刚刚的方式耗费的精力,优劣对比吧。

我(不好意思):从精力上讲,一致性哈希方案多了一步二次计算位置的动作,但是按您说的,如果我们在拦截器中去实现这一步动作的话,整体都是无感知的,只是多了一个方法而已,而从扩展性来讲,那就好多了,无论是增加节点还是减少节点,我们只需要迁移的对应的数据节点即可。

Tips:如下图中,如果我们增加了第四个服务器节点,第四个服务器节点的数据来源只可能是第一个服务器节点

image-20210704162853406.png


Range方式分表

亮架构:那我再考考你,假如让你去订单组,对订单快照或者说订单流水进行分表,你怎么做?

我(思考状):订单流水信息有一个明显的不同点在于它的主键Id是一个真正的无意义自增长整型,刚才提到的方式是可行且通用的,但是针对这种特殊场景,我会采用分段分表的方式,比如 1 - 100万为表1,100万01到200万为表2,以此类推,反正这个表只有插入和按Id查询,至于按订单人查询的功能,其他模块就满足了,不用我考虑。

我(瞬间反应过来):不对啊,那订单流水Id基于什么获取呢?我们都要分表了,难道用自增Id?

亮架构:你能想到这一点还挺好的,现在有很多分布式算法都可以解决这种问题,比如Twitter的分布式自增ID算法(Snowflake)、Redis的incr命令、百度的uid-generator算法等等,很好,你也有一点程序员的样子了,知道反问了。


把上述知识总结抽象,你能得到什么?

亮架构:你刚才提到了很关键的一点,你说你之所以用最简单的水平分割方式去处理,是因为其他系统的代码也都是这么写的?

我:是的,所以我就把它们复制粘贴,改了一下。

亮架构:OK,你看,无论是简单的水平取模方式,还是一致性哈希,亦或是Range方式,它的本质都是:SQL解析 =》SQL重写 =》 路由 =》 数据库执行 =》 结果返回

不同点在于,几个方案的路由策略不一样而已,你把这些东西抽象成可配置化的解决方案,放到咱们的Lib库中,以后别人再用的时候是不是就没那么麻烦了?

我:是的,既省时间,又省精力,只要咱们都用的是Mybatis和MySQL就行。

亮架构(扶额):你再想想...

我(思考状):对,是我狭隘了,我们刚刚所说的策略根本不用在乎是什么数据库,是什么ORM框架,无论是MongoDB也好,MySQL也罢,它真正的流程就那么几步,我只需要依赖Spring体系,获取到数据库连接信息,然后重写SQL为它分配路由即可。

亮架构(笑了笑,起身走了):孺子可教也,你还觉得每天都是CRUD了吗?明明有一个研究和学习的机会放在你的面前,是你自己选择了最简单的方式,因为你既追求速度,又害怕出问题,所以你用了和前人一样的方式来解决这个问题,工作中很难遇到造火箭的机会,但是造个自行车,哪怕是车轮,也是挺好的吧,认真学习,以后要抓住机会啊。

我看着架构师远去的背影,心中无比的激动,感谢他把本可以摸鱼的时间拿来教导我(手动狗头🤪)。


最后

推荐另一篇具有 “设计” 思想的文章:「奇淫技巧」如何写最少的代码

如果你觉得这篇内容对你有帮助的话:

  1. 当然要点赞支持一下啦~
  2. 另外,可以搜索并关注公众号「是Kerwin啊」,一起在技术的路上走下去吧~ 😋