昆明建设网站,wordpress为何需要lamp环境,企业网站建设的步骤过程,中天控股集团有限公司转: http://www.infoq.com/cn/articles/weibo-multi-idc-architecture 在国内网络环境下#xff0c;单机房的可靠性无法满足大型互联网服务的要求#xff0c;如机房掉电#xff0c;光缆被挖的情况也发生过。微信就曾发生大面积故障#xff0c;包括微信信息无法发出、无法刷…转: http://www.infoq.com/cn/articles/weibo-multi-idc-architecture 在国内网络环境下单机房的可靠性无法满足大型互联网服务的要求如机房掉电光缆被挖的情况也发生过。微信就曾发生大面积故障包括微信信息无法发出、无法刷新朋友圈、无法连接微信网页版或接收到的图片无法打开等。同时微信公众平台也出现了503报错范围影响北京、上海、广东、浙江等近20个省市。故障的原因微信团队指出是由于“市政道路施工导致通信光缆被挖断影响了微信服务器的正常连接”。单机房除了单点风险之外另外一个问题是不适应复杂的网络环境下图是调研国外各地区用户访问微博的延迟情况可以看到南方海外用户的访问延迟比较大。 为了解决上述问题微博在2010年启动了多机房部署的架构升级。微博不同于静态内容静态内容CDN基本上大的互联网公司都会做已经非常成熟。动态内容CDN是业内的难点国内很少有公司能够做到非常成熟的多机房动态内容发布的成熟方案。同时根据微博业务特点又要求多机房方案能够支持海量规模、可扩展、高性能、低延迟、高可用所以面临很多技术挑战。 微博的多机房架构V1版本解决了海量动态数据的CDN同步问题。一般业界的数据同步架构可以归纳为三种Master-SlaveMulti-MasterPaxos。考虑到微博的特点是海量数据低延迟弱一致性所以Paxos并不适合微博而Multi-Master在当时并没有成熟的产品所以微博开始采用的是Master-Slave方案如下图 由于Memcached服务端是无状态的分布式是在客户端实现所以需要解决两个机房Memcached数据同步的问题。微博研发了MytriggerQ通过解析Mysql的binlog还原更新操作实现Memcached数据同步。 数据库方面Mysql自身的Master-Slave同步实现是比较成熟的。但是在微博的海量数据情况下广州两从的结构就导致同步的数据量翻倍导致带宽被大量占用。针对这个问题微博是通过Relay的方式来解决即北京到广州仅需要同步一份数据到广州后再由Relay服务器同步两份数据给从库。由于Relay服务器可以代理多个从库所以在基本没有增加资源的情况下我们把同步带宽降低了一倍。 而Redis的同步实现就不太成熟了由于不支持断点续传一旦网络抖动导致主从不一致后导致大量的带宽被占用甚至出现过专线100%被占用的情况严重影响正常的机房间通信同步恢复时间需要几个小时甚至几天。所以微博对Redis的同步机制进行了改造利用AOF特性支持断点续传。改造后即使在专线中断的情况下同步也可以在几秒钟内恢复正常。 V1版本实现了微博多机房从无到有V2版本重点解决了多机房的可靠性和可扩展性。V2版本实现了Master-Master架构通过消息总线同步用户操作行为而不再依赖底层存储系统的同步每个机房都独立完成读写操作。 相关厂商内容 想要快速学习Amazon EMR最佳实践赶快报名InfoQ在线课堂 ArchSummit 晚场活动对外招募邀您和架构师畅聊技术 如何快速搭建一个完整的移动端直播系统 你离成为一位合格的技术领导者还有多远 证券行业的Docker应用实践 相关赞助商 GMTC全球移动技术大会2016年6月24日-25日北京点击了解详情 面对微博海量实时数据业界通用的消息总线产品无法满足性能要求所以我们自己基于MemcacheQ实现了一套消息总线WMB它与普通消息总线产品最大的差别是采用一写一读的方式实现消息同步。这种方式最大的好处是消除了并发锁消耗单机性能可以发挥到极致而吞吐量可以通过增加机器线性扩容。目前这套消息总线同步性能单机极限达到每秒10万消息同步性能。 可靠性方面由于各机房仅通过消息总线进行同步不依赖任何底层资源所以各个机房都可以独立对外提供服务任何一个机房出现问题都可以实现流量快速切换。可扩展性方面增加一个机房仅需线性扩展消息总线即可完成机房的部署结构与数据同步对业务完全透明。微博多机房已经实现从北京、广州两个机房的结构升级到广州亚太、北京电信、北京联通三个核心机房的部署结构。 Master-Master架构非常依赖消息总线的一致性而在网络延迟比较验证的多机房环境下MemcacheQ存在消息丢失的隐患即而服务端完成消息读取但在传输过程中超时客户端无法再次获取这条消息。为了解决这个问题我们在WMB的升级版WeiBus消息总线中实现了消息同步序号的功能支持客户端在超时情况下可重复获取消息。 但是随着微博业务的蓬勃发展业务依赖关系越来越复杂多机房部署成本压力越来越大而且运维成本也不断攀升下图是一个产品的服务依赖关系图。微博多机房V3版本实现了业务灵活多机房部署架构支持业务自定义机房部署个数及部署区域。 业务定制部署需要解决业务路由问题。在当前全国的网络环境下南北网络专线延迟一般在30到40毫秒之间而机房内延迟一般小于1ms。业务路由需要支持尽可能路由到调用本地机房调用对需要跨机房调用的请求进行打包以便减少网络延迟的影响。微博根据自身业务特点实现了业务路由服务支持将多个业务请求进行打包将多个请求打包成一个请求自动识别本地业务部署把需要跨机房调用的请求一次性请求到对应机房并将返回的结果打包后一并返回。并且支持自动识别业务部署结构变更并对非核心业务异常自动隔离。 随着移动互联网的迅猛发展3个机房的部署结构不能完全解决用户访问速度问题一种解决方案是让机房更加靠近用户。但是社交网络由于数据的网状访问较难选择合适的切分维度目前微博核心业务仍需要各机房同步全量数据部署更多机房的成本压力比较大。QZone的SET化和Tumblr的Cell化在解决社交网络拆分维度方面都值得参考微博也在进行Cell化方面的尝试相关信息也会在 微博平台架构 微博帐号上与社区进行交流希望感兴趣的同学积极与我们互动。 微博只是多机房之路上迈出了一小步仍有很多难题有待攻克。希望对多机房系统对微博的架构感兴趣的同学加入到我们微博的团队共同打造一流的分布式系统。 感谢刘宇对本文的审校。转载于:https://www.cnblogs.com/jhj117/p/5610701.html
