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

  • 时间:
  • 浏览:2
  • 来源:5分快乐8APP下载_5分快乐8APP官方

根据微博的实践,一般做异地多活一定会遇到如下的现象:

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

跟阿里巴巴遇到的现象同类,大伙 也遇到了数据库同步的现象。可能性微博对数据库全部都是强依赖,添加数据库双写的维护成本过大,大伙 挑选的方案是数据库通过主从同步的办法进行。这套方案可能性的缺点是可能性主从同步慢,或者 缓存穿透,这时可能性会突然跳出脏数据。这种同步办法已运行了三年,整体上非常稳定,没有处在可能性数据同步而愿因分析的服务故障。从2013年开使了了,微博启用HBase做在线业务的存储处置方案,可能性HBase有一种不支持多机房部署,添加早期HBase的业务比较小,且有单独接口都要能回调北京机房,好多好多 没有做异地部署。到今年可能性HBase支撑的对象库服务可能性成为微博非常核心的基础服务,大伙 也在规划HBase的异地部署方案,主要的思路跟MySQL的方案同类,同步也在考虑基于MCQ同步的双机房HBase独立部署方案。

时间到了2015年,新技术层出不穷,日后好多好多 成本很高的事情目前全部都是了很好的处置方案。接下来大伙 将在近五年异地多活部署探索的基础上,继续将微博的异地多活部署体系化。

第一版跨机房消息同步方案采取的是基于自研的MytriggerQ(借助MySQL从库的触发器将INSERT、UPDATE、DELETE等事件转为消息)的方案,这种方案的好处是,跨机房的消息同步是通过MySQL的主从完成的,方案性性心智旺盛期是什么是什么 期度高。而缺点则是,微博同一5个业务会有好几张表,而每张表的信息又不全,曾经每发第两根微博会有多条消息先后到达,曾经愿因分析有较多时序现象,缓存容易花。

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

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

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

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

数据同步现象处置日后,紧接着就要处置依赖服务部署的现象。可能性微博平台对外提供的全部都是Restful风格的API接口,好多好多 独立业务的接口都要能直接通过专线引流回北京机房。或者 对于微博Feed接口的依赖服务,直接引流回北京机房会将平均处置时间从百毫秒的量级直接升至几秒的量级,这对服务是无法接受的。好多好多 ,在2012年大伙 对微博Feed依赖的主要服务也做了异地多活部署,整体的处置时间终于降了下来。当然这全部都是最优的处置方案,但在当时微博业务体系还相对简单的状态下,很好地处置了现象,确保了2012年5月的广州机房部署任务的达成。

微博的异地多活方案如下图(一5个节点同类,消息同步全部都是通过WMB):

以上是对微博异地多活部署的或多或少总结和思考,希望要能对大伙 有所启发,也希望看到更多的同学分享一下每各人公司的异地多活架构方案。

(题图来自:jimijones.com)

这套方案中,每个机房的缓存是全部独立的,由每个机房的Processor(专门负责消息处置的守护进程,类Storm)根据收到的消息进行缓存更新。可能性消息不必重复架构设计 ,或者 信息完备,好多好多 MytriggerQ方案处在的缓存更新脏数据现象就处置了。而当缓存不处在时,会穿透到MySQL从库,或者 进行回种。可能性突然跳出的现象是,缓存穿透,或者 MySQL从库可能性此时突然跳出延迟,曾经就会把脏数据种到缓存中。大伙 的处置方案是做一5个延时10分钟的消息队列,或者 由一5个处置守护进程来根据这种消息做数据的重新载入。一般从库延时时间不超过10分钟,而10分钟内的脏数据在微博的业务场景下也是都要能接受的。

以下是方案选型时时要考虑的或多或少维度:

升级跨机房消息同步组件为跨机房消息同步服务。面向业务隔离跨机房消息同步的多样化性,业务只时要对消息进行处置即可,消息的跨机房架构设计 、一致性等由跨机房同步服务保障。且都要能作为所有业务跨机房消息同步的专用通道,各个业务均都要能复用,同类于快递公司的角色。

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

先的话微博组织组织结构的历程,整个过程可谓是一波多折。微博的主要机房都集中在北京,没有很小一次要业务在广州部署,2010年10月,因微博高速发展,好多好多 准备扩大广州机房服务器规模,并对微博做异地双活部署。

第一套方案未能成功,但也让大伙 认识到跨机房消息同步的核心现象,并不利于大伙 全面下线MytriggerQ的消息同步方案,而改用基于业务写消息到MCQ(MemcacheQ,新浪自研的一套消息队列,类MC协议)的处置方案。

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

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

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

借助微服务处置中小服务依赖现象。将对资源等的操作包装为微服务,并将中小业务迁移到微服务架构。曾经只时要对好多个微服务进行异地多活部署改造,众多的中小业务就不再时要关心异地部署现象,从而都要能低成本完成众多中小服务的异地多活部署改造。

本文来自云栖媒体合作伙伴“linux中国”

阿里巴巴挑选了单元化的处置方案,这套方案的优势是将用户分区,或者 所有这种用户相关的数据全部都是一5个单元里。通过这套方案,都要能较好的控制成本。但缺点是除了主维度(阿里巴巴是买家维度),或多或少所有的数据还是要做跨机房同步,整体的多样化度基本没降低。另外或者 数据分离后可能性拆成了共要两份数据,数据查询、扩展、现象处置等成本均会增加较多。总的来讲,每各人认为这套方案更适用于WhatsApp、Instagram等国外业务相对简单的应用,而不适用于国内功能多样化、依赖众多的应用。

而配套体系的现象,技术上全部都是好多好多 样化,或者 操作时却很容易出现象。比如,微博刚开使了了做异地多活部署时,测试同学没有在上线时对广州机房做预览测试,曾经愿因分析过或多或少线上现象。配套体系时要覆盖整个业务研发周期,包括方案设计阶段的与否要做多机房部署、部署阶段的数据同步、发布预览、发布工具支持、监控覆盖支持、降级工具支持、流量迁移工具支持等方方面面,并需开发、测试、运维都参与进来,将关键点纳入到流程当中。