作者｜晓楚
单个分布式数据库集群系统的节点数从几个到上百个不等，为几个到几千个租户提供服务。如何做到负载均衡，在充分利用硬件资源的同时又能保证每个租户的QoS，这是一个问题；如何让文科生理解这件事，是另一个问题
图片
老婆虽然是德语专业毕业，但很关心 OceanBase 的发展，经常会关心一下我的工作内容。
昨天问我最近在做什么，答曰 “负载均衡”。
老婆：”哦，就是把两边搞得一样对吧？“
我：“是这么个意思。那么，两边是哪两边？一样是什么一样呢？”
老婆：“… —— 那不就是你要做的事情吗？！你还问我！”（蒙混耍赖脸）
我：“哈哈，我想想怎么给你解释一下。”
给文科生讲技术，最好的方式是类比。
我思考片刻：“想象一下我们在整理图书馆的书架。图书馆一共有三个书架，书都集中到了第一个书架，第二个第三个书很少，这就出现了不均衡。我们就需要把第一个书架的书，搬一些到第二个、第三个书架里，让每个书架的书本数差不多。搬书的过程，就是在做负载均衡。”
老婆：“ 噢，懂了，就是把你们存的数据搬来搬去，让每个机器上一样多！”
我：“ Bingo！你要不要来 OceanBase 面个试，我们正在大量招人！不过，我做的工作跟这个还略有不同。通常，图书馆里的书都是分门别类的，不同书架上应该放不同的书。假设我们图书馆只有三类图书：天文、地理、历史。我们搬书会分两步，第一步分类，把天文放到第一个书架，地理放到第二个书架，历史放到第三个书架。第二步打散，每个书架都有 9 个小格子，我们要把天文的书分散到 9 个小格子里，让每个格子都不会全满，方便取书，地理和历史以此类推。”
老婆：“ 就是先分大类，然后再分小类呗。“
我：“ 对，蛮简单吧。但以前对这个问题认识不够深入，没意识到分类的问题，写出来的负载均衡算法 DBA 根本不敢用，说开了负载均衡，数据就被全搞乱了。”
老婆：“怎么乱法？”
还是得继续打比方…
我：“还是图书馆的例子，稍微改一改。以前遇到的问题是这样：假设图书馆买了十万套《十万个为什么》，上架天文、地理、历史，使用了错误的方法，导致混乱。你认为正确的上架方式是怎样的？”
老婆：“把十万本天文放到天文架子上，并且 9 个格子里每个格子里放 3333 本。剩余一本 —— 丢掉！”
我：“哈哈哈，靠谱！我们开始的算法太傻，没区分图书种类，只考虑了每个小格子里放相同本书的书。具体做法是，先一数，27 个小格子，从书堆里随便拿一本放到第 1 格，然后拿第二本放第 2 格，然后第 3 格，等等，直到 27 个格子全部放了一遍后，回过头又从第一个格子放起。这么做的结果是，虽然每个小格子里的图书数量是一样的，但每个小格子里却混杂了三种书。”
我：“ 理解客户需求比较重要，当时我们只想到计算机里存了数据，负载均衡就是要把这些数据均摊到每台计算机里，没意识到这些数据之间有逻辑联系。最后费老大劲写了代码，用户还不买账。”
老婆：“那你现在写对了吗？”
我：“ 应该写对了，线上运行很久了，已经解决了好几个业务的均衡问题 ”
老婆：“ 那，以后晚上可以早回来吗？”
我：“ 这个。。。又有新任务。。。”
老婆：”😭“
OceanBase 副本的均衡，考虑了这样一个业务需求：使用了分表的业务，要把同一时间段写入的数据打散。在历史库类的业务中，数据表被拆成了 100 个分表。举个例子，原来 money 表只有一张，它按照月份分成了若干个分区，每个月的数据写入到不同的分区。后来 money 表被拆成了 money_00, money_01, …., money_99 一百张表，每个表保持按照月份分区。负载均衡算法需要把这 100 张表里 1 月份的数据打散，2 月份的数据打散，等等。
映射到图书馆的例子里，把 1 月份的数据想象成《天文》， 2 月份数据想象成《地理》， 3 月份数据想象成《历史》，然后把 1 月份数据打散到天文架子的 9 个小格子里，2 月份数据打散到地理架子的 9 个小格子里， 3 月份数据打散到历史架子的 9 个小格子里。
假设 9 个格子放不下 1 月份的数据怎么办？馆长（DBA）会购买一个新的架子（机器），把 9 个格子扩充成 18 个格子。这时候，我们的算法会计算出一个最小代价的搬迁计划，把 9 个格子里的数据匀出一半来搬到新架子上。这个扩充就是负载均衡算法对机器扩容的支持。
