单实例支撑每天上亿个请求的SSDB

         SSDB 是一个 C++ 开发的 NoSQL 存储服务器, 支持 zset, map 数据结构, 可替代 Redis, 特别适合存储集合数据. SSDB 被开发和开源出来后, 已经在生产环境经受了3个季度的考验, 一直稳定运行.

在一个支撑数千万用户的列表数据(例如用户的订单历史, 用户的好友列表, 用户的消息列表等)的实例上, SSDB 每天处理上亿个读写请求, 仍然能保持 CPU 占用在3%左右, 内存占用为 1G. 这种数据规模是我们原来使用的 Redis 所无法满足的, 因为 Redis 无法保存如此大量的数据, 物理内存的容量限制了 Redis 的能力. 根据我们的经验, Redis在10G数据规模时比较适用, 数据规模再扩大时, Redis 就非常吃力, 而且几乎无法扩展. 这时, 必须改用 SSDB.

SSDB 具有和 Redis 高度重合的 API, 而且对于 hash(map) 还是可分段遍历的, 相比较, Redis 只能通过 hgetall 一次遍历 hash 中的所有元素, 在大的 hash 中, 这个操作非常低效.

如果要列出几条必须放弃 Redis, 改为使用 SSDB 的观点, 我相信这几条非常有吸引力:

• 单个实例的存储容量相当于 100 个 Redis 实例!
• 内存占用只有 Redis 的一千分之一(最大设计容量时).
• 所有的数据集合(包括 KV)都是可分段(分页)遍历的.
• 特别适合存储列表等集合数据.

案例分析：

      在一个网站广告系统中, 需要针对每一个用户所接受的弹窗次数和点击次数这两个重要指标进行统计, 从而进行效果分析和精准投放的改进. 这两个指标的统计算法其实非常简单, 主要的难点在于大数据量. 广告系统的涉及的用户量达到数千万人, 每天的日志数据量是几亿条.

最开始的想法是使用 MySQL 数据库, 不过这个方案马上就被否, 因为如此大量数据已经远远超过 MySQL 的存储能力, 必定带来许多无谓的问题.

        第二个方案是使用 Redis. Redis 是内存存储方案, 速度快, 而且 zset 数据结果存储列表数据非常方便, 能直接地统计用户的弹窗次数和点击次数. 不过, Redis 本身的局限就是它最多能存储不超过内存容量的数据, 对于一台 100G 内存的服务器, Redis 最好是存储不超过 30G 的数据量. 因此, Redis 的方案在运行了短时间之后也被否定了.

         第三个方案是使用 SSDB. SSDB 可以存储 TB(1000GB) 级别的数据, 并且支持列表等集合数据结构, 有着和 Redis 高度兼容的 API, 所以, 当从 Redis 迁移到 SSDB 时, 改动非常小.

每一个用户的弹窗历史用一个 zset 来存储, key 是时间戳, 对应的 score 也是时间戳, 因为我们只关心用户的弹窗历史, 具体的弹窗信息会用 map 来存储(时间戳作为 key, 对应弹窗信息 value). SSDB 的 zset 支持根据 score 范围来查询, 所以只需要一条命令就能算出用户在任意时间段内的弹窗次数.

用户的点击统计也是类似.