本篇文章选自数据库内核杂谈系列文章。

欢迎阅读新一期的数据库内核杂谈。首先和大家道个歉，拖更太久了。下半年工作太忙了，一直没能空出时间来更新。终于到了感恩节假期，赶紧来填一下上一期留下的坑：假设给一个单机的数据库系统实现，在这个基础上如何把它扩建成分布式数据库系统。

先来说说这个坑的趣事，当时在原公司参与系统设计面试，但不幸和同事撞题了。。。这个题是我在推开面试会议室门的时候临时想的(被自己机智到了！)记得，当时是这么对面试者说的，“你好，今天我们要做的设计题是，假定现在给你一个单体的数据库系统实现，比如开源的Postgres或者MySql的实现，把它拓展成一个分布式数据库。要求是，一，分布式设置对客户端屏蔽，即，对客户端来说，还是连接到了一个逻辑的数据库实体；二，实现基本的SQL实现。”。后来我仔细想想，觉得这个设计题还是蛮不错的。足够开放，可以横向聊全局，也可以纵向聊细节。看到这里，大家可以暂停一下，思考一下，你会怎么做？

全局分配

题目的第一个要求是，分布式设置对客户端屏蔽。也就是说，客户端在连接到数据库之后，并不知道这是一个分布式数据库。不难想到，无论这个分布式数据库设置多少台机器，应该只有一台机器负责和客户端沟通，来屏蔽分布式的实现。 沿着这个思路想下去，这台机器接受客户端的指令，然后协调统筹其他机器完成操作。自然而然地就引出了一个leader节点带领着一群worker节点协同工作的全局架构(布局如下图所示)。这个设置中，由leader节点全权负责和客户端沟通：建立连接，增删改查；只需要暴露leader节点的地址和端口，客户端完全不需要知道有worker节点存在。如此，满足了要求一。另一个好处就是方便协调管理。Leader节点作为整个数据库的单一大脑，负责协调所有工作，worker节点只要听指挥工作即可。缺点也明显，就是leader节点是数据库的单点故障瓶颈(这里就暂不扩展如何解决这个瓶颈了)。 具体leader这个大脑负责哪些工作，后面的章节会做讨论。