目录
序言
第一版
第二版
第三版
第四版
序言
小董本人是2017年研究生毕业，当年7月份就进入了深圳一家互联网公司的架构平台部，从事NoSQL的底层存储引擎研发。20年4月份来到杭州某互联网公司，从事上层业务研发，最近偶尔想起之前的存储相关知识，发现有一些细节知识都已经模糊了。有感而发，遂成此文。一方面为自己的技术生涯做个阶段性的总结，其二也希望为对存储领域有兴趣的小伙伴做一下知识普及。
来吧，那就开始吧，我争取用最简单的方式让大家能从零到一的明白一个典型的NoSQL引擎的工作原理。
我们知道NoSQL是包括时序，kv，列，图等多种存储系统的总称。本文暂时只介绍KV存储。换句话说，这个系统对外只提供get，set，del等接口。
本文的行文，参考了《How tomcat works》一书，一点点的构建系统，一点点的增加模块，到最终形成一个基本可用的存储系统。同时在讲述迭代过程的时候，采用课堂上小菜与老鸟一问一答的形式，尽量的让大家都清楚为什么这么设计。
第一版
图一 单机版存储
小菜：如上图，就是我设计的第一版存储系统。
老鸟：我尼玛。。。。这也叫存储系统？这是个什么玩意？
小菜：都说了，从零开始么。直接调用java的HashMap，外面包一层网络连接就OK么。
老鸟：好吧，这个系统的优点就不说了，简单。呢缺点呢？
小菜：额，不能扩展吧。基于内存1TB也就差不多了，就是使用序列化持久到硬盘，也还是个单机系统，容量也就最多几十TB。
老鸟：嗯还不错，至少有自知之明，再去设计一版吧。
小菜：嗯，我想想，要扩充容量，那就引入多个存储机，再加一个确定key到底在哪个机器的模块就OK。
第二版
图二 数据分开存储
小菜：如上，我们把存储数据的节点叫做particle，client读写数据的时候直接连接master，master根据数据的Key，进行hash，然后对3取余，余几就把数据存放到几号particle节点里。
老鸟：上面的思路，有问题么？大体上是没有问题的，至少典型的分布式结构有了。
Master存储每个key的路由关系
Particle存储具体的数据
但是还有一个绕不开的问题，现在是3个节点，key进行hash后对3取余，如果要加机器，变成了4个机器，咋办？
没事，先不着急，咱们先只考虑最大的架构图怎么设计，具体的技术方案，后面再说。
OK，那就从模块上说，上面的架构还有问题么？
小菜：有。所有的请求都经过master，只有一个master肯定扛不住。
那简单，多来几个particle，分担client的请求数量就OK。
老鸟：聪明。那就再设计一版。
第三版
图三 多个portal
小菜：如上图三，用户的请求直接连接portal，portal连接particle。
具体的说：
Portal：每个portal都有所有数据的全量路由，这样一来，不管client访问哪个portal都能达到真实存储数据的particle。
Particle：具体的存储数据
Master：管理整个集群，包括portal和particle。
老鸟：嗯不错了，那client怎么知道连接哪个portal呢？
小菜：这个感觉不难，加一名字服务系统就OK，每次给集群里加一个portal的时候，就在名字系统对应的栏目下加一个ip：port，client通过某个名字就能获得所有的portal的信息。
老鸟：嗯不错，名字服务系统不算存储系统的核心，就不用画到架构图里面了。那还有一个问题，上面有3个particle，每个particle都只有一个副本，如果机器死了咋办？再想想，重新设计一版吧。
小菜：只有一个副本，不安全，那就多个副本，冗余呗。
第四版
图四 最终版
小菜：如上，每个particle都有3个副本，这样一个机器死了，还有两个副本。另一方面，我考虑到如果存储机器死掉了，还得考虑数据的搬迁，就加上了dispatcher与mover
Dispatcher：当发现系统里某个paticle机器死了，就分配数据搬迁任务给mover。毕竟2份数据肯定比3份数据危险。
Mover：具体执行数据搬迁任务。
咋样，老师？
老鸟：整体没有什么问题了。
小菜：开心~~~
老鸟：别开心太早
1 portal怎么记录路由
2 master怎么记录路由
3 3个副本的数据更新怎么做，先更新哪个再更新哪个，还是一起更新？
4 还有之前提到的，如果增加一组particle，hash到底怎么映射？
5 也是最关键的，particle里面数据怎么存储？
小菜：那怎么做呢？
老鸟：为师乏了，下节课再说。
小菜：我尼玛。。。
另外赞美glt
glt是谁？
我媳妇
