到目前为止, SSDB 还是一个单机存储方案, 存储容量受到单机硬盘的限制, 虽然 SSDB 可以自动压缩数据, 将存储容量提高 10 倍以上, 但还是在 TB 级别. 不少 SSDB 的用户一直在呼唤 SSDB 分布式, SSDB 集群, 但是千呼万唤不出来. 为什么?
分布式数据存储是一个真正的技术难道, 不说各种理论, 最简单的是数据怎么迁移. 想想, 原来你只有一个存储节点, 但数据多了之后, 硬盘存不下, 这时怎么把一部分数据迁移到另一个新的存储节点? 这就是数据迁移问题. 这其实是2个问题:
1. 一份数据应该存储在哪个节点? 原有的节点, 还是新加入的节点?
2. 在什么时机, 用什么手段来迁移? 如何保证迁移的过程不影响服务?
有些同学一听到分布式数据存储, 就言必称"一致性哈希", 遇到这种人我只有一个字 - 滚!
所谓的"一致性哈希"只解决了上面的问题1, 而且仅仅是解决问题1的众多方案中的一种, 也不是最好的一种. 而对于分布式数据存储来说, 解决了问题1, 只不过是解决了万分之一, 只是皮毛. 你言必称"一致性哈希", 不让你滚蛋还能怎么样?
怎么解决数据迁移?
方案一: 引入唯一的 proxy
引入了唯一的 proxy 之后, 所以有请求必须通过 proxy, 那么就可以在 proxy 上做数据迁移, 迁移中的数据如果被请求到, 就先挂起请求, 快的话, 只需要挂起几百毫秒.
这种方案就是 twemproxy 采用的. 缺点也很明显, proxy 很容易成为瓶颈.
方案二: 停机维护
这种方案看起来比较土. 当我的存储空间不够的时候, 我就把网站停了, 然后人工操作, 写脚本导数据. 数据导完后, 再采用著名的"使用者自己分布式(客户端分布式)".
--------
还有更多的方案, 欢迎大家讨论. SSDB 不会采用 proxy 方式, 因为这种方式大概只能支撑两三台这个量级的"集群". 如果采用方案二, 那么 SSDB 集群将可以支持无限庞大.
说实话, 集群不集群这两个概念有时很模糊. 例如, 某个公司部署了数千个 Redis 实例, 这些实例可能分为几个一组, 支持不同的业务, 但对外宣传, 却可以把"千个实例的集群"作为噱头. 如果这种也算集群, 那么全世界的所有 MySQL 实例就是一个"十万个实例的集群", 全世界的 PC 机和笔记本也是一个"数十亿实例的集群", 等等, 虽然不是每一个实例都同意被归在集群里.
我的意思是说, 你不能在想象中把多个没有联系的实例划到一起, 就叫做"集群".
但是, SSDB 会做分布式数据存储集群, 因为在设计中, 这个群集的所有节点之间是有直接联系的, 数据可以在集群节点间迁移.
对于一个集群, 能动态的添加新节点, 或者某一个节点从集群中移除, 这是最基本的特性, 没有这个特性就不能称为"集群"! SSDB 分布式将从最基本的特性开始, 第一步先提供方便地增删存储节点的功能.
Loading ...
另外也可参考淘宝tair,也是使用leveldb的分布式存储.有专门的中心节点负责集群路由表，通知存储节点进行迁移工作 Reply
迁移数据的时机和手段确实需要仔细考虑.在线上环境部署过tair,说一些可能会有坑的地方:1.在迁移数据的过程中如果再次发生节点故障 2.迁移数据操作的对磁盘的压力可能会影响实时的读写 这些细节供你实现时参考
至于迁移数据的具体方法,我觉得可以像目前的zset结构一样,在leveldb存储时key前面加上分布式信息的前缀(类似于其他系统中的bucket号等),迁移数据时用这个前缀在leveldb中扫描需要迁移的数据. Reply