sina weibo架构与关系存储

草草整理的网络的

• 1.构建可扩展微博架构TimYang 新浪微博技术架构师

• 2.从博客到微博

• 3.博客功能 发表 浏览 留言 ContentManager System

• 4.博客技术 ,LAMP MySQL master/slave Memcached PHP CDN

• 5.微博微博，产品 Real-time关注关系信息聚合

• 6.信息聚合

• 7.信息聚合微博两种信息聚合设计模式 Push(推 )Pull( 拉)

• 8.Push 把微博看做邮件Inbox:收到的微博Outbox:已发表微博发表：存到所有粉丝 inbox(重 )查看：直接访问Inbox(轻 )

• 9.Push(Figure) User A UpdateAction Inbox (Append to 1’s hometimeline) Inbox (Append to 2’s home timeline) Inbox (Append to 3’shome timeline) Followers of User A = 1, 2, 3

• 10.Push 优点：实现简单，首选缺点：分发量

• 11.Pull 发表：存到自己outbox(轻 )查看：所有关注对象Inbox(重 )

• 12.Pull User I Get home_timeline Outbox (statuses sent by A) Outbox(Statuses sent by B) Outbox (Statuses sent by C) User I’sFollowing List = A, B, C

• 13.Pull 优点：节约存储缺点：计算量大

• 14.微博是一个消息分发系统可采取推或拉的方式实现

• 15.架构挑战：峰值-如除夕、春节

• 16.请求量如果发表量 5,000万 /天 平均：578条 /秒设计系统容量： 2,000?

• 17.IO 瓶颈峰值： 5,000– 10,000? 100,000?

• 18.后果LatencyDB read timeout 前端timeout(503 error) 解决方案？

• 19.异步设计不同步等待 将消息存入消息队列 (MessageQueue) 轻量级的发表

• 20.MQ products Kestrel by twitter RabbitMQ, an Erlang Queue ServerMemcacheq 在新浪微博项目大规模使用

• 21.Memcacheq 基于Berkeleydb, 稳定可靠Memcachedprotocol, 丰富的clientlibrary 容易监控(statsqueue) 只有2个命令：get/set

• 22.避免单点故障核心服务，需避免单独故障 方法 使用多个 Memcacheq池 Get操作:轮询所有服务器Set操作:随机选择一个无需其他复杂“架构”设计

• 23.MQ 方式通用的优点Offlinework 应用请求量不均衡解耦 异步通讯 原则

• 24.使用MQ原则计算开销大于消息分发开销

• 25.架构挑战：实时性

• 26.越重要的事件，越希望实时性

• 27.The value of the tweet decreases exponentially with time JohnKalucki, Twitter http://t.sina.com.cn/pub/star#a_ty

• 28.解决思路Cache中心化Ramis the new the disk

• 29.Local Cache Memcached Database buffer/cache

• 30.LAMP 中，cache=可选层Cache中心化后新的问题

• 31.容量问题TB级思路：压缩 QuickLZLZO 不用gzip

• 32.单点问题单点故障 ,SIGSEGV 如何应对1.Consistent hash 2. Read-through cache

• 33.Consistent hash 原理优点 震荡最小

• 34.Read-through cache

• 35.Read-through and Write-through Products or projects MySQL memcachedUDF Cache money for Ruby on Rails Or wrap a proxy for the db driver,in any language

• 36.Evictions 问题Evections:cache 数据被踢性能的噩梦 Latency产生的源头之一

• 37.如何避免evictions规划cache容量将永久数据与临时数据分开 不使用随机字符作为 key

• 38.Multiget 问题Whenmemcached servers are CPU bound, adding more memcached serversdoesn't help serve more requests. - Jeff Rothschild, Vice Presidentof Technology at Facebook

• 39.Cache 挑战：multigethole

• 40.解决方法Memcachedreplication

• 41.架构挑战：海量存储

• 42.架构挑战：国内网络带宽问题

• 43.地理分布考虑到以下原因，需要分布式部署 访问速度 IDC不可用故障 分布的核心是数据分布

• 44.数据地理分布原理Master-slaveMaster-master 2PC/3PC Paxos http://timyang.net/data/multi-idc-design/

• 45.地理分布的方案MySQLmaster/slave Dynamo/Cassandra PNUTS

• 46.架构挑战：API访问量

• 47.以新浪微博开放平台为例RESTAPI 编程简单，library丰富可用 curl,javascript 实现一个client缺点单向询问方式如何解决轮询压力

• 48.解决方案：SinaApp Engine Sina App Engine 应用云平台提供微博API底层支持并可以 host微博app

• 49.微博,Web 2.0 最核心技术之一还有更多的架构挑战等待解决 欢迎加入新浪微博技术团队

• 50.Q&A 新浪微博：@TimYang Twitter: @ xmpp Email: iso1600 @ gmail.com

新浪微博至今发言或评论要刷新点按多次才能发出，有时weibo.com都无法访问，这些都是scalable扩展性做得不是非常线性的现象所在。

这里主要从 存储和接口角度来讲

对于大流量系统的架构设计，对于写入方面是特别需要注意的，基本上现在遇到的系统都是对于主数据库的写入，然后对于从数据库实现流量的分发。

对于存储，记得公司老大说过，对于BD的项目的架构如果从设计上可以达到20PB的存储规模不出什么大的问题，就说明这个架构设计是合格的。

对于存储，新浪微博使用了redis的部分功能,主要用在用户信息方面的使用,现在只有单机设计,但是对于现在的单机完全可以提供大量的内存比如32G以上，完全可以达到存储数据的要求。

对于MYSQL这里所涉及到的就是设计规范和分库分表，最大的感触是大家为了便利就直接用自增的ID来进行，对于唯一ID的设计也是我一直注意的，因为唯一的设计是涉及到全局的。

将将自己最近总结的PHP和微博架构方面：

1.进行快速开发的过程中，订好规范，按照规范执行是非常的重要的，涉及到的沟通会比较少，其实和其他人联调是很费时间的。

2.对于性能跟踪方面使用使用xhprof来跟踪PHP的执行过程及性能问题，可以初略的估计出来。

3.对于核心代码的复用程度及核心的代码量的把握，核心要灵活可扩展而且保持小

4.技术选型比如对于使用memcache扩展和memcached的扩展还是很重要的

5.对于代码的目录结构和命名还是挺重要的,php的autoload不要搜索太多的目录会比较好

6.考虑下工具类的复用，一直在造轮子每次都重写一遍，这个不是很郁闷的事情，怎么样让这些类不要耦合的太紧？设计很重要

7.对于有些服务是PHP做起来不合适的,比如spam模块的高危词过滤还是用C/C++模块来处理比较好。

8.微博技术的应用Inbox/Outbox/Timeline/Following/Follows/Feed/MQS

9.推荐算法和消息推送的处理，各种高并发的处理