设计可伸缩的Twitter(Designing a Scalable Twitter)中文摘要

《设计可伸缩的Twitter》原文见http://natishalom.typepad.com/nati_shaloms_blog/2009/04/writing-your-own-scalable-twitter.html
期待有人翻译为中文。下面是我的中文摘要。

twitter的可伸缩性挑战
1、消息风暴问题。tweets、re-tweets，海量的消息如何处理。
2、阅读tweets问题。众多的用户同时阅读。

设计可伸缩的twitter:

选择正确的可伸缩性模式。
分区模式作为核心设计原则。
twitter是以数据库为中心设计（大多数web应用是这种模式）与以消息为中心设计的结合。
黑板模式适用于这一场景。
分区模式和黑板模式作为可伸缩twitter应用的基石。

可伸缩性需求
Tweet容量：每天100亿tweets
Tweet存储：每天100G（按10：1压缩）
其他假设：每条tweet最多140个字符、tweet不可更改（只能增、删）、限制客户端应用每小时只能发70次请求

使用内存数据网格In-Memory Data Grid (IMDG)作为黑板系统
将数据存到内存里，避免磁盘I/O
在memcached和IMDG两者中选择IMDG
memcached 读最多时选用比较好。不支持失败恢复、缺乏高可用性。使用memcached，必须以db作为后端，每次发表tweet， 必须同步写到memcached和db。读访问可伸缩性足够了，写和更新可伸缩性受限。
IMDG是设计来处理读/写场景。仍然可以用db来做长久的持久化，但因为IMDG已经负责在内存维护可靠性，可以异步更新db，避免db瓶颈。

设计分区架构
设计任何类型分区集群的主要考虑之一就是确定分区Key
twitter选用user-id作为分区Key
数据容量分析
全部数据都放到内存经济上不可行。所以IMDG只是作为缓存。实时搜索的数据（24小时内）会加载到内存。其他数据从db取。需要10台服务器，每台在内存保留10G数据。
选择正确的回收策略
采用基于时间的回收策略-内存里保留最新的数据。

tweet写的可伸缩性
通过@SpaceRouting指定路由属性
web前端直接调用space.write( new Tweet(..),..) 就可以发送tweets
space proxy隐藏了路由到不同分区的复杂性

tweet读的可伸缩性
黑板模式
所有东西都写到黑板上，followers可以读
SELECT * FROM Post WHERE UserID=<id> AND PostedOn > <from date>.
因为按user-id分区，通过mapreduce模式来找到所有follow的用户，进而查找那些用户的更新。在GigaSpaces中通过分布式任务api达到这一目的。

Web前端的可伸缩性
web应用<->IMDG代理（load-balancer<->web服务器集群）<->IMDG实例
保持web层的无状态，避免会话粘性
SNA

使用云计算，简单又省钱