听小董谝存储 二

序章

在上一节，我们只是画出了个一个KV存储系统的顶层架构图，同时也大体地划分了各个模块的功能，但是整个系统的核心：$路由是怎么划分的，怎么确定一个key具体存储在哪个particle$我们还一无所知。这一节我们就重点讲讲这个路由相关的知识。

第零章 先举个例子

老鸟:其实我和布鲁克斯的看法是一致的:所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。我们现在干的事情就是使用编程语言表达这些抽象实体。那么具体如何表达呢？我认为可以参考显示世界。
小菜：你和布鲁克斯的看法一致的。。。。。
老鸟：不要取笑。现实世界，和存储最相关的就是咱们小区里的快递点。每个管理员有一个小库房。假定库房里有4个货架，每个货架上面有5个栏位，一共20个栏位。最开始的时候，每天收到的快递还不多，管理员就取收货人的手机号的后两位，然后0-4放到第一个栏位上，5-9放到第二个栏位上，95-99放到第20个栏位上。（至于第n个栏位到底在哪个货架上，这个管理员自己肯定有个小本都记录着）
后来快递点的生意越来越好，因为货架的容量有限，每个货栏里能放的包裹的体积也是有限的，怎么办？之前不是20个货栏么。现在再来4个货架，每个货架5个货栏，等于再增加20个货栏。本来手机尾号是0-4的货物只放到一个货栏里，现在分成两个货栏就OK了。
之后40个货栏也不够用了，同时库房里的8个货架也塞满了，怎么办？再来一个库房呗。这个库房可以放20个货架。如果还不够，按照上面的思路继续扩充呗。甚至用户的手机号直接取后4位，这样最多就可以用10000个货栏承载了。
上面的例子只是让你再回顾一下显示世界的样子，后面咱们存储系统的设计，很多思路就是增加货架，增加库房。至于咱们系统里什么逻辑对应库房，什么是货架，什么是货栏，后面你就慢慢清楚了。

第一章 来个中间层

老鸟：还记得上一节，我们直接用key的hash值取余，来确定key到底存放在哪个机器上的思路么？
小菜：记得呀，但是这个思路有个很大的问题，如果之前有99个机器，后面增加1台，变成了100。那么之前对99取余，现在对100取余，数据大都找不到了。具体怎么办呢？
老鸟：我们一般采用面向google编程，请google hash环。（https://zhuanlan.zhihu.com/p/34985026）
小菜：嗯hash环我明白了。然后呢？这和我们的存储系统有什么关系，我们的存储系统也是这么设计的么？
老鸟：我们的系统路由部分，和hash环有相似的地方，但也不完全一样。(至少在我们的方案里，新增加一个机器后，我们原先的数据还在原来的机器上)这里让你看hash环，只是想告诉你一个计算机界的名言：
Any problem in computer science can be solved by anther layer of indirection.
$计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决$
小菜：别卖关子了，具体说说。

图一 数据分片与路由
老鸟：小菜，咱们系统的路由系统大概如上图一。你懂了么？
小菜：大概有内味了。经过hash的key对N取余数，n可能是1w也可能是100w，这个暂时不重要，取余后存放到某个槽位。之后的定位包含两步：

• 这个槽位由某个data shard接管
• 这个data shard又由某个具体的particle接管。
  老鸟：是的。$前面让你看hash环，只是让你理解槽位的思路。$
  $这里引入槽位的概念只是为了确定某个key具体由哪个datashard负责。$
  $至于某个datashard由哪个particle咱们后面再说，不要着急。$另外，那对上面的图，你就没有什么疑问么。
  小菜：嗯，都看懂了。没有什么问题。
  老鸟：其实作为一个程序员，面对一个解决方案的时候，不应该只是停留在嗯，这个方案可以解决这个问题，应该多问自己几个为什么。OK，那我问你，咱们
  $完全可以直接让particle接管那些槽位，为什么还要引入datashard这一层呢$
  小菜：你说吧。
  老鸟：这个data shard只是一个逻辑概念。和系统实现本身没有关系，只是方便理解与运维。换言之，以上图为例，ParticleB接管了两块区域，这一块一块的区域，你总的起个名字吧。我们就叫它data shard。
  小菜：我懂了，但是我还有一个问题，上面的图是存储系统的数据存储逻辑图。如果有多个用户呢？多个用户共享那10w个槽位么？
  老鸟：不要问我。其实这个问题，无外乎两种么。要么共享，要么不共享。咱们分析分析两个方案的优劣点就知道了么。
  小菜：如果共享，劣势就是同一个data shard内可能既有用户A的数据也有用户B的数据。如果用户AB的优先级不一样，我甚至不能为他们分别部署不同等级的服务器。优势么，少存储一个路由关系表，能省一点内存。所以，选择很明显了，每个业务独立使用一组槽位。数据搬迁的时候，就以data shard为单元。然后一个Particle上可能既有业务a的data shard也有业务b的data shard。

第二章 说说data shard

小菜：前面说了，data shard只是一个逻辑概念，代表了槽位集上面的一段区间。槽位有10w个（或者100w个）。这是咱们整个整个系统的初始配置，不会变。举个例子，某个用户申请我们的服务，那到底分多少个data shard呢。
老鸟:这个看运维经验。一般情况下，为了运维方便，一个data shard的存储空间是2GB。
小菜：哦明白了。
老鸟：然后呢？
小菜：然后什么？2GB我记下了。
老鸟：尼玛，我让你记2GB的数字有个毛作用。你就不能提出一点问题么？？
小菜：哦，我想想额。如果一个数据分片2GB，一个用户说我需要200GB的空间，那就给他分100个分片。如果半年之后，200G不够用了，用户说，我需要600GB。然后单个分片就扩展到6G了。感觉有点问题哦。
老鸟：算你还有点悟性。系统对单data shard到底可以存储多少数据是没有限制的，也就是说一个data shard存100GB都没有问题。但是因为分片是运维的最小单位，一般情况下不会让分片超过2GB。那现在数据总量就是胀大了，怎么办？分裂呗。

图二 分片的分裂
小菜：哦，看这个图，我就懂了，单个分片的总容量不变，如果分布在这些槽位上的数据量增加了，就让多个分片来承担这些槽位上的数据。
老鸟：嗯，孺子可教，光看图就懂了。然后呢？
小菜：可是之前分片里面的数据是存在一个机器上的。现在分裂了，数据还在一块么。分裂具体怎么操作，我还是不清楚。
老鸟：不要着急，一口气吃不了一个胖子，这个咱们后面再说。
小菜：好的。那一个大分片既然可以分裂，那两个小分片是不是也可以合并？一个分片原来在A机器上，是不是也可以搬迁到B机器上。
老鸟：不错，不错，可以举一反三了。分片就是前面说的货栏，一组particle就是一个库房，至于货架，咱们后面说。

第三章 一致与安全

老鸟：前面已经说了，为了保持数据的安全性，所谓的particle其实是一组。如果说，一组机器是3台的话，那么这样就算有一个机器挂了，我还有另外两个机器可以服务。安全性有保障了。
小菜：老师，你别看我，我听懂你说的了。不过你说的是陈述句，我实在不知道有什么问题。
老鸟：OK，现在数据是3副本。那么这3个副本有什么关系。读写的顺序是什么？这里建议你看一下CAP原理。
https://www.cnblogs.com/mingorun/p/11025538.html
具体的咱们下节课再说。
好了，老师乏了，你退下吧。
总之，我爱glt。