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

2012·2汇总

Tumblr是世界上最流行的轻博客服务之一，2007年成立。

 

一，MySQL+Memcached

初期，其通知系统是由 MySQL＋Memcached 的传统架构组成。

缺点：

MySQL负担重，表象就是 MySQL 并发事务数常常达到 InnoDB global transaction 最大值，即只能有1023个并发事务（注：特指 mysql5.0/5.1存在的问题，5.5.4以上版本修复）。

 

二，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）

 

三，修改后的架构：Staircar+Redis

2011年，他们上线了如下架构：

Staircar 的轻量级HTTP服务器+ Redis 集群。

 

架构图为：

 

四，性能指标要求

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

Staircar 实际达到的指标：

在最高峰时的响应时间也在5ms以下，其性能测试结果是能处理每秒30,000次左右的请求。

 

五，引入 redis 的 presharding 思路

关键词：presharding。

缺点是，引入了运维复杂度，导致运维管理成本增加；要用好 Presharing 方案，必须有相应的自动化运维手段相配套，比如：Redis实例的启停脚本、能检查Redis状态的运维监控手段。

优点是，更好的性能，更简单的容错，更能适应业务增长。

Presharding 思路大致的描述为：

『

假设有N台主机，每台主机上部署M个实例，整个系统有T = N × M个实例；

由于一个Redis实例的资源消耗非常小，所以一开始就可以部署比较多的 Redis 实例，比如128个实例；
在前期业务量比较低的时候，N可以比较少，M比较多，而且主机的配置（CPU+内存）可以较低；
在后期业务量较大的时候，N可以较多，M变小。

总之，通过这种方法，在容量增长过程可以始终保持Redis实例数(T)不变，所以避免了重新 Sharding 的问题。

』

拆分过程如下：

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

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

 

六，一些细节

来自于 Tumblr 开发者的一些信息：

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

 

参考资源：

1）2011，tumblr官方博客，Staircar: Redis-powered notifications；

2）上文的中文译稿；

3）2011，antirez，Redis Presharding ；

4）2011，InfoQ，Redis复制与可扩展集群搭建，谈及一种基于MySQL作为主库，Redis作为高速数据查询从库的异构读写分离的方案：

 

---

赠图一枚：