听小董谝存储 一

听小董谝存储 一

目录

​​序言​​

​​第一版​​

​​第二版​​

​​第三版​​

​​第四版​​

序言

小董本人是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是谁？

我媳妇

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。