基于Redis构建系统的经验和教训

Redis 是一个非常快速和强大的 Key-Value 存储(持久化)系统, 相对于一般的 NoSQL 存储系统, 它最大的特点是支持丰富的数据结构. 特别是其 zset(sorted set)数据结构, 堪称表达能力最强的结构之一(其它强大的数据结构如 sorted hashmap), 可以直接地表达业务逻辑。

拿一个 Messaging(消息传递)系统来举例, 收件箱发件箱这样的业务逻辑直接用 zset 存储即可, 因为 zset 的每一个元素都有一个用于排序的权重值, 可以非常方便快速地地进行插入和删除操作. 如果使用纯粹的 KV 系统, 存储列表等非字符串结构的数据将是无尽的痛苦。

由于 Redis 本身的限制, 它所能处理的数据必须完全放在内存中, 而硬盘上的数据是内存数据的一个镜像, 所以, 限制了它的容量不能超过内存的容量(VM 模式无实际意义, 已在新版本中去除). 当前, 服务器的内存以 32G 为普遍情况, 96G 算较好, 如果一个系统要存储 1T 的数据, 那么必须用上 10 台服务器, 硬件成本非常高 — 且先不谈由此面临的软件的架构改动. 当前, 1T 的数据只能算零头, 对于一个100万活跃用户的系统, 平均每人每天产生 1K 数据, 便需要 1G 的存储空间, 这仅相当于每个用户每天只发10条微博或者10条聊天信息, 真正流行的系统将远远超过这个数据规模。

持久化, 复制和备份带来的系统和网络问题

一般数据达到几百 M 或者 1G 时, Redis 必须且只能开启 aof 操作日志异步写硬盘的持久化模式, 由于用户记录数据变更日志的 aof 文件体积增加比较严重, 必须定期对 aof 文件进行收缩(rewrite). 收缩的过程其实是将内存数据镜像到硬盘的过程, Redis 主进程需要 fork 一个进程出来, 虽然操作系统有写时拷贝功能, 但仍然要为 fork 出来的进程保留足够的内存空间, 所以 Redis 只能使用内存容量的 50%。

在写 aof 文件时, Redis 完全没有任何速度控制策略, 经常导致硬盘读写占满, 其它进程一旦涉及到文件操作, 都将被阻塞住。

Redis 自身支持主从模式, 可以方便地进行数据备份, 避免单点失败造成数据丢失. 但是, Redis 的主从模式并不成熟, 例如当网络出现抖动时, 可以导致主从之间发生一次全量复制, 这对网络带宽是一个打击。

无分布式方案导致软件设计的复杂度增加

Redis 是一个单机的存储方案, 当数据超过单台服务器的内存容量时, 必须由软件的设计者在软件逻辑层面设计出一套数据拆分的方案. 这必然导致软件设计者无法关注于业务逻辑, 而将大量的精力放在数据存储层, 即增加了软件的复杂度, 也造成可维护性的下降。

结论

Redis 不适合作为海量数据存储方案. Redis 适合在数据规模较小, 性能要求较高的条件下应用。

海量数据存储的备选方案

根据业务公开的经验, 海量数据的存储方案主要有：

• Cassadra, 据我所知是纯粹的 KV 方案, 对结构化数据表达能力非常弱.
• HBase, 是 Google Bigtable 的一种实现, 在 Facebook 有应用. 其对结构化数据的表达能力的最大优点是数据是一维有序的(按 Key 排序)。
• mongoDB

我们需要什么样的海量数据存储方案(个人看法)?

实际经验来看, 纯粹的 KV 方案太过简单, 简单到几乎无法直接表达任何业务数据, 相当于拿着一堆铁锭, 然后开发者自己再去制作自己需要的零件. 显然, 对于使用者角色的开发者来说, 这不友好。

真正友好的还是结构化数据存储方案, 也就是对数据有一定的理论模型, 从而产生一些数据结构. 要创造出一个普遍适用的数据模型是非常困难的, Bigtable 那样的模型并不是经常被创造出来, 而且在 Bigtable 之外仍然需要更多的模型。

从我自己的开发经验来看, 最基本的, 数据应该是有序的, 可以根据权重来排序. 一旦数据是有序的, 便能分段访问和传输, 而不必全量拷贝, 海量数据处理的原则是拷贝(传输)最少的数据。

大多数业务的模式都是这样的: 首先, 实体被存储在一个空间里, 可通过 key 访问; 其次, 创建实体 key 的若干个有序子集. 这两种结构似乎已经包含了所有的业务逻辑. 所有聊天消息(实体), 为所有的用户创建表示其收件箱消息集合(子集). 所有的微博消息(实体), 为每个用户创建 timeline 消息集合(子集)……