Tumblr的消息通知系统是如何构建的

• 按时间排序（Ordered by time）
• 唯一性，每一条消息都是唯一的（Unique (no duplicate notifications)）
• 读写比大概是 60%/30%（Medium read/write ratio (60%/30%), mostly thanks to heavy caching）
• 每个用户的消息条数一定（Fixed number of notifications per user）
• 数据按用户划分，每个用户只能读自己的消息（Keyed by user, and read only by him/her）

• notification request volume (over 7,500/s)
• data set size (23MM blogs, 100 notifications per blog, 160bytes per message),
• response times (<5ms)

拆分过程如下：

1. 在新机器上启动好对应端口的 Redis 实例。
2. 配置新端口为待迁移端口的从库。
3. 待复制完成，与主库完成同步后，切换所有客户端配置到新的从库的端口。
4. 配置从库为新的主库。
5. 移除老的端口实例。
6. 重复上述过程迁移好所有的端口到指定服务器上。

以上拆分流程是 Redis 作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖 Redis 本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。

• Machine failures：每一个 Redis 实例都有自己的 slave，这样确保可以做 failover。
• Performance：Staircar 没有 redis 快。但它最主要的目的是，让 redis 基础设施对任何客户端都是透明的。
• Early Optimization：在一个庞大的基础架构中，你会面对很多局部性细节，很慢的客户端，机器宕机，其他运维问题等。我们感兴趣的是在 redis 实例池之上，构建一个高性能代理。