Staircar:Tumblr的Redis集群控制层
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
建议继续学习:
- redis源代码分析 - persistence (阅读:31231)
- Redis消息队列的若干实现方式 (阅读:10773)
- 基于Redis构建系统的经验和教训 (阅读:9387)
- 浅谈redis数据库的键值设计 (阅读:8351)
- redis运维的一些知识点 (阅读:7519)
- redis在大数据量下的压测表现 (阅读:7443)
- Redis和Memcached的区别 (阅读:6895)
- Redis作者谈Redis应用场景 (阅读:6628)
- redis 运维实际经验纪录之一 (阅读:6535)
- 记Redis那坑人的HGETALL (阅读:6375)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:Elton 来源: Elton's Blog
- 标签: Redis Tumblr
- 发布时间:2011-07-30 21:40:56
- [71] Twitter/微博客的学习摘要
- [65] IOS安全–浅谈关于IOS加固的几种方法
- [64] find命令的一点注意事项
- [64] android 开发入门
- [62] 如何拿下简短的域名
- [62] Go Reflect 性能
- [60] Oracle MTS模式下 进程地址与会话信
- [60] 流程管理与用户研究
- [57] 图书馆的世界纪录
- [57] 读书笔记-壹百度:百度十年千倍的29条法则