【运维专家大讲堂】腾讯资深运维专家周小军：QQ与微信架构的惊天(2)

数据的读写都在内存中进行,内存的Key采用多阶HASH来索引,读写性能极高,但受数据容量受内存的限制.数据在主、备上都落盘,保证了数据的持久性.一个存储集群可以支持业务混合存储,业务Key采用一致性HASH方式分布.可以看到,和Quorum_KV不同,Grocery的设计是面向写量、读量均大的业务.

Q4: 从存储的“五分钟原则”可知,当数据五分钟内被访问一次,该数据不应存储在硬盘,而应该存储在内存中,对坐拥几亿用户的QQ和微信等社交产品,可能要应对每秒几千万的读写请求,能否和我们分享下背后的集群是如何支撑起这种大规模的分布式存储?
A4: QQ在线峰值高达二亿多,每秒要响应几千万的读写请求,对分布式存储的压力非常大.传统的关系型数据库在高性能、分布式方面存在一些瓶颈,很难适应QQ海量业务场景所带来的挑战.

如我之前说提及的,腾讯的NoSQL存储系统经过精心设计,已经能够应对海量数据的高并发、高可用、低延迟的应用场景,由几百台存储机组成的存储集群可以轻松扛起数百万的读写并发.集群的性能具有线性扩展,集群最大可以容纳到几千台存储服务器.当然如此庞大的集群,相应地也会带来管理上的复杂,因此我们的一个集群不会超过1千台服务器.

在集群中,记录通过一致性HASH、号段范围或HASH取模等方式,均匀分布到后端的数百台存储设备.存储前端采用存储代理,屏蔽了应用对存储的直接访问,数据在集群扩展或收缩的过程中,通过代理的自动寻址保证了业务无对存储的无损访问.业务数据从1台存储扩展到100台存储,只需要数分钟即可完成,在此过程,业务是无感知的.

此外,应对存储集群的运维,我们还有强大的存储调度平台,可以保证集群中的代理和存储做到平均水位,避免有的机器忙死,不断应对高负载的压力、而有的机器应对低负载,出现闲置等问题.

最后,针对存储的内存问题,我想补充一点,业务的数据具有冷热区域,存储系统把热数据保存在内存中,冷数据保存在SSD盘中.淘汰系统通过KEY的过期时间自动把冷数据从内存淘汰到SSD盘,以释放内存空间.当冷数据第一次从SSD盘读取后会自动上升到内存.

Q5: 在国内网络环境下,单机房的可靠性无法满足大型互联网服务的要求,如机房掉电,光缆被挖的情况也发生过,微信和QQ有没有出现过服务器宕机的时候?您们当时是如何应急处理的?有没有更好的容灾机制来确保高可用性?
A5: 早期的QQ在单IDC时代,的确有过光缆被挖断、甚至城市运营商出口故障导致服务中断数小时的大故障.现在腾讯已经建设起成熟的海量服务运营体系,面对单机房的可靠性采用了全网调度理念来解决跨地域之上的高可用性.

首先是SET标准化.SET是标准业务部署模块,接入层、逻辑层和存储层标准化成不同的SET.

每个SET内都有固定数量的服务器和标准服务容量.譬如,上海XX接入SET设计容量XXX万用户,当前用户数为XXX万,离警戒水位还有XX%,XX小时后可进入扩容点.

SET都具有自动化部署能力,几百台服务器的SET部署时间小于10分钟.SET按单元分布在不同城市之间.每个重点城市都会部署许多套接入SET,逻辑SET和存储SET.

第三,SET间、城市间、区域间都具备全网调度能力.用户到接入SET的调度通过GLBS来切换,譬如接入SET会有许多个VIP,通过域名服务变更VIP就可以把用户请求从天津切到上海.

接入SET到逻辑SET,或逻辑SET到存储SET的访问则通过内部名字服务系统来切换.这样当任何一个IDC或某城市出现问题时,运维人员通过调度可以在几分钟内把流量切到正常的SET,甚至可以通过调度系统做到自动化切换.

第四,存储层的多地同步.存储层会在三地以上部署多套,譬如华南、华中和华北各部署一套存储SET.有写请求时先写华南SET,写成功后通过同步中心把数据同步到华中和华北SET,通过最终一致性保证数据保存在多地存储.数据在三地同步最长时间才几千毫秒,因此用户对数据的不一致基本无感知.

最后是系统的柔性策略.柔性可用即对服务进行分级,当系统变得不可靠的时候,优先提供重要优先级的服务.比如节假日用户大量访问相册出现流量峰值时,突然出现某机房核心专线故障,柔性系统会把相册从全尺寸图片浏览模式切到缩略图浏览模式,以减少图片的拉取,降低带宽流量,减少压力.

Q6: 在朋友圈的相册、QQ空间的相册里,或多或少会有一些个人隐私的数据,一旦丢失,后果很严重,那么它们对应的服务器集群是如何来确保数据的备份与安全性?
A6: 分布式存储系统都具有主备双机或主备多机架构.备机把更新流水落本地硬盘,并定期把内存镜像到磁盘.后端有统一的冷备系统来保存备份数据.因此数据的安全性是非常强的.

关键业务还有三地以上的存储SET同步,实现跨城容灾.
图片保存在分布式图片存储系统中,同样也会保存三份以上的副本,并且有跨地域的容灾副本.

Q7: 您在互联网行业积累了十多年的运维经验了,对很多朋友来讲,要想成为一名优秀的DevOps工程师,在成长道路上,您有哪些心得经验分享?
A7: 在运维道路上,我的切身体会比较多,简单总结一下主要有以下几点：
1、坚定的目标
目标是职业生涯远处的灯塔,它能冲破迷雾,让你在迷惘中坚定信念和方向.要想成为一名优秀的技术专家就要牢牢树立你的目标,持之以恒,每天一点一滴地前进.

2、运维服务能力
餐饮业的海底捞以服务口碑得到顾客的认可.同样,运维人员做为支撑服务部门,也要通过服务来获得用户和业务的认同.我们要以超出用户预期的目标来为用户和业务提供服务.

可能有人要问,我们是技术人员,为什么要特别强调服务能力?我觉得技术运维的团队目标不是提供功能的业务,而应该是提供持续化的服务能力,如资源交付能力,变更能力,可用性能力,调度能力等等,让业务如同水和电一样使用我们的服务.在这些服务能力的背后需要长时间的建设和积累.
例如传统的DBA团队重在技术支持,而我们数据运维团队除了技术支持之外,提供专业的服务已经成为团队的核心目标.
在服务能力上要致力于做到超出用户预期.什么是超出用户预期?就是用户期望得到五星的服务,而你能给他们提供到六星的服务.

要获得超出预期的服务,我认为要做好以下二方面：
1)主动服务
在我们运营中心,有句口话为“服务用户、服务业务、服务自己”,也就是说在做事时要考虑,我们的服务目标是谁.我们在制定目标和方向的时候不能只考虑到自己,要把眼光放得更长,看到业务,看到用户.
这里有一个例子,业务在申请设备资源时,按部就班走硬件成本资源采购是B级服务；通过虚拟化技术把设备申请从周提升到小时是A级服务；在虚拟化技术之上通过调度能力保证业务上线后,能根据实际流量实现人工或自动化的资源伸缩,即节省了成本,提高业务部署速度,还提升了运维能力,这就是S级超出预期的服务.

（编辑：ASP站长网）