`
ivan
  • 浏览: 180969 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

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

    博客分类:
  • arch
阅读更多
《设计可伸缩的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

使用云计算,简单又省钱
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics