可扩展微博架构【新浪微博架构】

构建可扩展微博架构TimYang新浪微博技术架构师从博客到微博博客•功能–发表–浏览–留言•ContentManagerSystem博客•技术,LAMP–MySQLmaster/slave–Memcached–PHP–CDN微博•微博，产品–Real-time–关注关系–信息聚合信息聚合信息聚合•微博两种信息聚合设计模式–Push(推)–Pull(拉)Push•把微博看做邮件–Inbox:收到的微博–Outbox:已发表微博•发表：存到所有粉丝inbox(重)•查看：直接访问Inbox(轻)Push(Figure)UserAUpdateActionInbox(Appendto1’shometimeline)Inbox(Appendto2’shometimeline)Inbox(Appendto3’shometimeline)FollowersofUserA=1,2,3Push•优点：实现简单，首选•缺点：分发量Pull•发表：存到自己outbox(轻)•查看：所有关注对象Inbox(重)PullUserIGethome_timelineOutbox(statusessentbyA)Outbox(StatusessentbyB)Outbox(StatusessentbyC)UserI’sFollowingList=A,B,CPull•优点：节约存储•缺点：计算量大•微博是一个消息分发系统•可采取推或拉的方式实现架构挑战：峰值-如除夕、春节请求量•如果发表量5,000万/天•平均：578条/秒•设计系统容量：2,000?IO瓶颈•峰值：5,000–10,000?•100,000?后果•Latency•DBreadtimeout•前端timeout(503error)•解决方案？异步设计•不同步等待•将消息存入消息队列(MessageQueue)•轻量级的发表MQproducts•Kestrelbytwitter•RabbitMQ,anErlangQueueServer•Memcacheq–在新浪微博项目大规模使用Memcacheq•基于Berkeleydb,稳定可靠•Memcachedprotocol,丰富的clientlibrary•容易监控(statsqueue)•只有2个命令：get/set避免单点故障核心服务，需避免单独故障方法1.使用多个Memcacheq池2.Get操作:轮询所有服务器3.Set操作:随机选择一个无需其他复杂“架构”设计MQ方式通用的优点•Offlinework•应用请求量不均衡•解耦•异步通讯•原则使用MQ原则计算开销大于消息分发开销架构挑战：实时性越重要的事件，越希望实时性ThevalueofthetweetdecreasesexponentiallywithtimeJohnKalucki,Twitter解决思路Cache中心化Ramisthenewthedisk•LocalCache•Memcached•Databasebuffer/cache•LAMP中，cache=可选层•Cache中心化后新的问题容量问题•TB级•思路：压缩–QuickLZ–LZO–不用gzip单点问题•单点故障,SIGSEGV•如何应对–1.Consistenthash–2.Read-throughcacheConsistenthash•原理•优点–震荡最小Read-throughcacheRead-throughandWrite-through•Productsorprojects–MySQLmemcachedUDF–CachemoneyforRubyonRails•Orwrapaproxyforthedbdriver,inanylanguageEvictions问题•Evections:cache数据被踢•性能的噩梦•Latency产生的源头之一如何避免evictions•规划cache容量•将永久数据与临时数据分开•不使用随机字符作为keyMultiget问题WhenmemcachedserversareCPUbound,addingmorememcachedserversdoesn'thelpservemorerequests.-JeffRothschild,VicePresidentofTechnologyatFacebookCache挑战：multigetholeMemcached(MaxRPS:A)Memcached(MaxRPSC)Memcached(MaxRPS:B)Multiget(keys…)MultigetMultigetMultigetApplicationMaxRPSofapplication(AandBandC)Multiget解决方法•Memcachedreplication架构挑战：海量存储架构挑战：国内网络带宽问题地理分布•考虑到以下原因，需要分布式部署–访问速度–IDC不可用–故障•分布的核心是数据分布数据地理分布原理•Master-slave•Master-master•2PC/3PC•Paxos•地理分布的方案•MySQLmaster/slave•Dynamo/Cassandra•PNUTS架构挑战：API访问量以新浪微博开放平台为例•RESTAPI–编程简单，library丰富•可用curl,javascript实现一个client–缺点单向询问方式•如何解决轮询压力解决方案：SinaAppEngine•SinaAppEngine应用云平台提供微博API底层支持•并可以host微博app•微博,Web2.0最核心技术之一•还有更多的架构挑战等待解决•欢迎加入新浪微博技术团队Q&A新浪微博：@TimYangTwitter:@xmppEmail:[e-mail]