Tumblr是世界上最流行的轻博客服务，其用户量在最近的一次统计中已经达到2090万，超过了全球最大的博客服务WordPress。而我们今天要介绍的是Tumblr通知系统的架构，其通知系统由一个叫Staircar的轻量级HTTP服务器和其下层的大规模Redis集群组成。
应用分析
在Tumblr初期，其通知系统是由MySQL＋Memcached的传统架构组成，但是由于通知系统庞大的添加操作，导致MySQL负担非常大，经常搞得InnoDB global transaction max（1024）都超出了。于是他们打算重新构建消息系统。首先他们分析了消息系统的应用特点：
- 按时间排序
- 唯一性，每一条消息都是唯一的
- 读写比大概是 60%/30%
- 每个用户的消息条数一定
- 数据按用户划分，每个用户只能读自己的消息
架构
基于上面应用特点的考虑，Tumblr选择了Redis的sorted sets作为其数据存储。
他们的存储方式是：
- 给每个用户分配一个sorted sets，其中每一项保存一条通知
- 每条通知以时间戳为score在sorted sets中进行排序
- 超出100条通知后进行trim操作
Tumblr的数据量：2300万个BLOG，每个BLOG 100条消息，每条消息体大概160bytes。
响应速度：大概每秒提供7,500次请求，每次请求的响应时间小于5ms。
考虑到容灾性及可能快速增长的数据量，Tumblr打算采用preshard的方式来架构他们的Redis集群，于是他们开发了Staircar（一个提供HTTP服务的Redis集群调度管理组件）。下面是他们的通知系统架构图：
实际上在开发Staircar前，他们考查了一些其它的类似功能的产品，但都不能满足他们所有需求（或者说闲杂功能过多）。
性能
Staircar由C语言写成，以libevent为网络驱动层，提供JSON格式的RESTFul接口，其性能超出了Tumblr工程师们的想象，其在最高峰时的响应时间也在5ms以下，其性能测试结果是大概能处理每秒30,000次左右的请求。下面是其性能测试图，从图上可以看到，其绝大部分请求（红色区域）的响应时间在3－4ms之间：
来源：engineering.tumblr.com