微博“异地多活”部署经验谈

  • 时间:
  • 浏览:0
  • 来源:uu快3开奖历史_uu快3玩法_注册

时间到了2015年,新技术层出不穷,时候可是 成本很高的事情目前都会了很好的避免方案。接下来当愿意们 儿将在近五年异地多活部署探索的基础上,继续将微博的异地多活部署体系化。

异地多活的好处阿里巴巴的同学可能充分阐述,微博的初始出发点包括异地灾备、提升南方电信用户访问速率单位、提升海外用户访问速率单位、降低部署成本(北京机房机架费太贵了)等。通过实践,当愿意们 儿发现优势还包括异地容灾、动态加速、流量均衡、在线压测等,而挑战包括增加研发冗杂度、增加存储成本等。

以下是方案选型时须要考虑的你你这个 维度:

根据微博的实践,一般做异地多活都会遇到如下的问题报告 :

升级跨机房消息同步组件为跨机房消息同步服务。面向业务隔离跨机房消息同步的冗杂性,业务只须要对消息进行避免即可,消息的跨机房采集、一致性等由跨机房同步服务保障。且可不须要作为所有业务跨机房消息同步的专用通道,各个业务均可不须要复用,例如于于快递公司的角色。

先句子微博内外部的历程,整个过程可谓是一波多折。微博的主要机房都集中在北京,只有很小一帕累托图业务在广州部署,2010年10月,因微博高速发展,可是 准备扩大广州机房服务器规模,并对微博做异地双活部署。

可能广州机房总体的机器规模较小,为了提升微博核心系统容灾能力,2013年年中当愿意们 儿又将北京的机房进行拆分,至此微博平台实现了异地三节点的部署模式。依托于此模式,微博具备了在线容量评估、分级上线、快速流量均衡等能力,应对极端峰值能力和应对故障能力大大提升,时候历次元旦、春晚峰值均顺利应对,日常上线原因分析分析的故障也大大减少。上线后,根据微博运营清况 及成本的须要,也曾数次调整各个机房的服务器规模,否则整套技术上可能基本性成熟期期期图片 的句子是什么。

以上介绍了一下微博在异地多活方面的实践和益得,也对比了一下阿里巴巴的避免方案。就像越来越 完美的通用架构一样,异地多活的最佳方案也要因业务清况 而定。可能业务请求量比较小,则根本越来越 必要做异地多活,数据库冷备足够了。不管哪种方案,异地多活的资源成本、开发成本相比与单机房部署模式,都会大大增加。

利用Docker提升前端快速扩容能力。借助Docker的动态扩容能力,当流量过大时分钟级从你你这个 服务池摘下一批机器,并完成本服务池的扩容。时候可不须要将各种资源也纳入到Docker动态部署的范围,进一步扩大动态调度的机器源范围。

2011年底在微博平台化完成后,开使英文英文启用基于MCQ的跨机房消息同步方案,并开发出跨机房消息同步组件WMB(Weibo Message Broker)。经过与微博PC端等部门同学的同时努力,终于在2012年5月完成Weibo.com在广州机房的上线,实现了“异地双活”。

这套方案中,每个机房的缓存是全部独立的,由每个机房的Processor(专门负责消息避免的tcp连接池池,类Storm)根据收到的消息进行缓存更新。可能消息不不重复采集,否则信息完备,可是 MytriggerQ方案趋于稳定的缓存更新脏数据问题报告 就避免了。而当缓存不趋于稳定时,会穿透到MySQL从库,否则进行回种。可能经常经常出现的问题报告 是,缓存穿透,否则MySQL从库可能此时经常经常出现延迟,从前就会把脏数据种到缓存中。当愿意们 儿的避免方案是做有5个 延时10分钟的消息队列,否则由有5个 避免tcp连接池池来根据你你这个 消息做数据的重新载入。一般从库延时时间不超过10分钟,而10分钟内的脏数据在微博的业务场景下也是可不须要接受的。

借助微服务避免中小服务依赖问题报告 。将对资源等的操作包装为微服务,并将中小业务迁移到微服务架构。从前只须要对十几个 微服务进行异地多活部署改造,众多的中小业务就不再须要关心异地部署问题报告 ,从而可不须要低成本完成众多中小服务的异地多活部署改造。

本文来自云栖企业企业合作伙伴“linux中国”

(题图来自:jimijones.com)

推进Web层的异地部署。可能远距离专线成本巨大且稳定性很难保障,当愿意们 儿已暂时放弃远程异地部署,而改为业务逻辑近距离隔离部署,将Web层进行远程异地部署。同时,计划不再依赖昂贵且不稳定的专线,而借能够通过算法寻找较优路径的妙招 通过公网进行数据传输。从前当愿意们 儿就可不须要将Web层部署到离用户更近的机房,提升用户的访问性能。妙招 当愿意们 儿去年做微博Feed全链路的经验,上方链路占掉了90%以上的用户访问时间,将Web层部署的离用户更近,将能大大提升用户访问性能和体验。

而配套体系的问题报告 ,技术上都会很冗杂,否则操作时却很容易出问题报告 。比如,微博开使英文英文做异地多活部署时,测试同学越来越 在上线时对广州机房做预览测试,从前原因分析分析过你你这个 线上问题报告 。配套体系须要覆盖整个业务研发周期,包括方案设计阶段的是否要做多机房部署、部署阶段的数据同步、发布预览、发布工具支持、监控覆盖支持、降级工具支持、流量迁移工具支持等方方面面,并需开发、测试、运维都参与进来,将关键点纳入到流程当中。

第一版跨机房消息同步方案采取的是基于自研的MytriggerQ(借助MySQL从库的触发器将INSERT、UPDATE、DELETE等事件转为消息)的方案,你你这个 方案的好处是,跨机房的消息同步是通过MySQL的主从完成的,方案性成熟期期期图片 的句子是什么度高。而缺点则是,微博同有5个 业务会有好几张表,而每张表的信息又不全,从前每发十根微博会有多条消息先后到达,从前原因分析分析有较多时序问题报告 ,缓存容易花。

可能几十毫秒的延时,跨机房服务调用性能很差,异地多活部署的主体服务须要要做数据的冗余存储,并辅以缓存等构成一套独立而相对全部的服务。数据同步有可是 层面,包括消息层面、缓存层面、数据库层面,每有5个 层面都可不须要做数据同步。可能基于MytriggerQ的方案的失败,微博随后采取的是基于MCQ的WMB消息同步方案,并通过消息对缓存更新,再加微博缓存高可用架构,可不须要做到即便数据库同步有问题报告 ,从用户体验看服务还是正常的。

跟阿里巴巴遇到的问题报告 例如于,当愿意们 儿也遇到了数据库同步的问题报告 。可能微博对数据库都会强依赖,再加数据库双写的维护成本过大,当愿意们 儿选择的方案是数据库通过主从同步的妙招 进行。这套方案可能的缺点是可能主从同步慢,否则缓存穿透,这时可能会经常经常出现脏数据。你你这个 同步妙招 已运行了三年,整体上非常稳定,越来越 趋于稳定可能数据同步而原因分析分析的服务故障。从2013年开使英文英文,微博启用HBase做在线业务的存储避免方案,可能HBase一种生活不支持多机房部署,再加早期HBase的业务比较小,且有单独接口可不须要回调北京机房,可是 越来越 做异地部署。到今年可能HBase支撑的对象库服务可能成为微博非常核心的基础服务,当愿意们 儿也在规划HBase的异地部署方案,主要的思路跟MySQL的方案例如于,同步也在考虑基于MCQ同步的双机房HBase独立部署方案。

第一套方案未能成功,但也帮当愿意们 儿认识到跨机房消息同步的核心问题报告 ,并能够当愿意们 儿全面下线MytriggerQ的消息同步方案,而改用基于业务写消息到MCQ(MemcacheQ,新浪自研的一套消息队列,类MC协议)的避免方案。

原文发布时间:2015-04-29

数据同步问题报告 避免时候,紧接着就要避免依赖服务部署的问题报告 。可能微博平台对外提供的都会Restful风格的API接口,可是 独立业务的接口可不须要直接通过专线引流回北京机房。否则对于微博Feed接口的依赖服务,直接引流回北京机房会将平均避免时间从百毫秒的量级直接升至几秒的量级,这对服务是无法接受的。可是 ,在2012年当愿意们 儿对微博Feed依赖的主要服务也做了异地多活部署,整体的避免时间终于降了下来。当然这都会最优的避免方案,但在当时微博业务体系还相对简单的清况 下,很好地避免了问题报告 ,确保了2012年5月的广州机房部署任务的达成。

微博的异地多活方案如下图(有5个 节点例如于,消息同步都会通过WMB):

以上是对微博异地多活部署的你你这个 总结和思考,希望要能对当愿意们 儿有所启发,也希望都看更多的同学分享一下各人 公司的异地多活架构方案。

关于为应对故障而进行数据冗余的问题报告 ,阿里巴巴的同学也做了充分的阐述,在此也补充一下当愿意们 儿的你你这个 经验。微博核心池容量冗余分有5个 层面来做,前端Web层冗余同用户规模成正比,并预留日常峰值3000%左右的冗余度,而后端缓存等资源可能相对成本较低,每个机房均按照整体两倍的规模进行冗余。从前可能某有5个 机房不可用,首先当愿意们 儿后端的资源是足够的。接着当愿意们 儿首先会只将核心接口进行迁移,你你这个 操作分钟级即可完成,同时可能冗余是按照整体的3000%,可是 即使所有的核心接口流量全部迁移过来要能支撑住。接下来,当愿意们 儿会把你你这个 服务池的前端机也改为部署核心池前端机,从前在一小时内即可实现整体流量的承接。同时,可能故障机房是负责数据落地的机房,DBA会将从库升为主库,运维调整队列机开关配置,承接数据落地功能。而在整个过程中,可能当愿意们 儿核心缓存可不须要脱离数据库支撑有5个 小时左右,可是 服务整体会保持平稳。

阿里巴巴选择了单元化的避免方案,这套方案的优势是将用户分区,否则所有你你这个 用户相关的数据都会有5个 单元里。通过这套方案,可不须要较好的控制成本。但缺点是除了主维度(阿里巴巴是买家维度),你你这个 所有的数据还是要做跨机房同步,整体的冗杂度基本没降低。另外可是 我数据分离后可能拆成了大慨两份数据,数据查询、扩展、问题报告 避免等成本均会增加较多。总的来讲,当时人认为这套方案更适用于WhatsApp、Instagram等国外业务相对简单的应用,而不适用于国内功能冗杂、依赖众多的应用。