53

同程艺龙王晓波:缓存应该这样治理,高并发场景才能游刃有余!

 5 years ago
source link: http://network.51cto.com/art/201806/576755.htm?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

【51CTO.com原创稿件】2018年5月18-19日,由51CTO主办的全球软件与运维技术峰会在北京召开。此次峰会围绕人工智能、大数据、物联网、区块链等12大核心热点,汇聚海内外60位一线专家,是一场高端的技术盛宴,也是顶级IT技术人才学习和人脉拓展不容错过的平台。

在19日下午“高并发与实时处理”分会场,同程艺龙机票事业群CTO王晓波带来了《高并发场景的缓存治理》的主题演讲,针对如何让缓存更适合高并发使用、如何正确使用缓存、如何通过治理化解缓存问题等热点展开了阐述。会后,51CTO记者根据王晓波在WOT2018全球软件与运维技术峰会的演讲内容进行了整理。

王晓波演讲中谈到,在高并发场景下,很多人都把cache(高速缓冲存储器)当做可以“续命”的灵丹妙药,哪里高并发压力大,哪里就上传cache来解决并发问题。但有时候,即使使用了cache,却发现系统依然卡顿宕机,是因为cache技术不好吗?非也,其实这是缓存的治理工作没有做好。

IfaE7f3.jpg!web

看看同程“趟过的坑”

王晓波比较系统地介绍了同程“趟过的坑”。

为了缓解高并发的压力,同程最初选择memcache(分布式的高速缓存系统)技术,后来又转到Redis架构(数据结构服务器,可用作数据库高速缓存),部署了接近200台服务器。但情况并没有好转,系统经常性的宕机,应用中调用的脚本乱七八糟,多实例部署资源不均衡,太脆弱数据消失了。

为了实现对这些服务器的管理,同程开启了主从+keepalived(IT第3层、第四层、第五层交换机制的软件)模式,并选择从单机Redis逐渐升级到集群Redis。很快他们就发现,当集群大量部署的时候,运维端没有办法做运维,虽然可以通过脚本来统一运行,但是集群不可控,而且很多运维技术手段还容易导致高并发系统停机,直接对整体业务端产生影响。“当时系统随时可能会挂,运维团队快崩溃了。”王晓波回忆道。

所有遭遇的问题症结在哪里?王晓波总结到,最大的问题在于技术人员对cache的使用的规范,人们常常会忘记它本身的缺点,只想到它的好处“快”。他举了一个例子,在一次系统故障总结报道里,一名技术人员写到,没想到初始状态下只有30000行的代码的Redis,它竟然带来如此神奇的功能。这样的想法以至于让程序员感觉手里拿了一个锤子,看见钉子就想锤。换而言之,让他们看见任何的需求都想用缓存去解决。在这样的误导下,人们开始频繁使用基于缓存的日志搜集器、基于缓存的倒计时、基于缓存的计数器、基于缓存的订单系统。这些功能出现之后,人们只沉醉于它的快,却忽视了如何去保障它的正常运行。

缓存真正的故障是什么?王晓波归纳成四点:一是过度依赖,这一点最突出,有时候明明不需要缓存,可技术人员却非得去用缓存。二是数据落盘,三是超大容量,四是缓存雪崩。为什么会出现这些故障呢,王晓波认为,使用的者的乱用、滥用、懒用是最大的问题。此外,运维数千台毫无使用规则的缓存服务器,运维人员不懂开发,开发人员不懂运维,导致了缓存在无设计无控制中被使用,太多的服务器资源被浪费等都是常见的现象。

到底人们需要一个什么样的缓存?需要一个什么样的缓存治理?王晓波认为,其实从真正的开发哲学上来说,其实人们想要的是一个“百变的魔术箱”,能够神奇地满足各种高并发需求。简单来说,也就是说缓存是大是小、是好是坏,都不需要开发者关心。因为开发人员对缓存技术了解有限,最怕其胡乱使用。值得警惕的是,很多开发人员都忽视了现在缓存中的许多数据并不是永远的热数据,在高并发到来前也没有做充足的估算,导致在应用时再发现瓶颈就晚了。

同程“凤凰涅槃”

为了真正发挥出缓存的作用,应对高并发,同程技术团队最终开发出phoenix方案。最初设计时,他们希望这个架构中在应用端会有一个简单的SDK能够让开发人员去使用。只要开发人员声明所做的项目和相关数据场景,就会得到一个key,有了这个key,SDK就会给开发人员分配一个新的缓存仓库,可以在上面运行Redis,让整个调度平台来调用它,速度非常快。除此之外,phoenix还能从客户端调用开始全面监控,当然更重要的是能防止缓存的崩塌,实现动态扩容缩容。

后来,phoenix方案又加入了代理层。因为客户端多语言开发时间成本太大,而且客户端在应用中的升级是个大问题,王晓波透露,几乎所有的嵌入式应用的中间件升级都是一个最大的麻烦,一旦升级,系统要重新测试,很容易再度挂掉。所以通过本地缓存控制更好,部分使用频率不高的可以使用磁盘做缓存。

最后,phoenix方案中又加入了容器。当实现容器化部署后,通过多个小集群+单节点、以场景划分集群、实时平衡调度数据,同程的整体监控、数据迁移、伸缩调度都变得更灵活更容易操作。以数据迁移为例,同程做了整套的迁移系统,从流量扩容到数据的扩容,从纵向跟横向的扩容,全部实现了一个比较好的全自动处理。

以上内容是51CTO记者根据同程艺龙机票事业群CTO王晓波在WOT2018全球软件与运维技术峰会的采访内容整理,更多关于WOT的内容请关注51cto.com。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【责任编辑:周雪 TEL:(010)68476606】


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK