技术领导力: 深度访谈《深入分布式缓存》

  1. 云栖社区>
  2. 博客>
  3. 正文

技术领导力: 深度访谈《深入分布式缓存》

abel_cao 2018-01-19 09:16:08 浏览360
展开阅读全文

attachments-2018-01-a1EDCN945a6096a13deea.jpg于君泽,蚂蚁金服支付核算技术部负责人、互联网金融业务近8年,电信业务8年经验。兴趣在高可用分布式架构应用,研发管理,内建质量等。维护公众号:技术琐话。《深入分布式缓存》一书联合作者,总策划。



attachments-2018-01-cGCIKqG15a6096ae050ba.jpg

曹洪伟,《深入分布式缓存》一书的作者之一。 70后老码农,全栈工匠一枚,在多家世界500强企业从事软硬件开发工作,后投身创业企业侧重研发管理和体系架构,曾出版过几本技术小册子,发表过几篇短文,拥有10几个国内外专利的署名权。不忙的时候,偶尔在技术会议上分享一点心得,同时维护着公众号wireless_com和同名的博客。目前,投身于智能硬件领域,任渡鸦科技的CTO,产品Raven-H 已经在线预售,欢迎访问www.raventech.cn看一下他们的研发成果。


—————————————————————————————————————————————————————


技术领导力:据我了解,您可以说有着丰富的实战经验,在您的职业生涯里有没有重要的里程碑和转折点?

 曹洪伟:20多年的职业生涯,有很多转折点,比如2000年互联网泡沫破灭导致的创业失败,移动互联网产业链生态的从无到有,比如创业维艰而步履蹒跚蹒跚,软硬件敏捷一体化的摩擦阵痛等等。

而最重要的里程碑和转折点是在入行时转折,从一个硬件工程师转型测试再转到软件开发,具体地,我在《挨踢部落故事汇(2):机缘所致转型之路》记载了这段经历,这里不再赘述。 20年, 一个轮回,现在重新来到了这个领域,已经成为了智能硬件, AI 已经开始为硬件赋能了。

 

技术领导力:怎么会想到要写《深入分布式缓存:从原理到实践》这本书?大概历时多久完成的?在这期间有没有难忘的人或事?

于君泽:本书的产生要追溯到N年前,我一直对缓存技术抱有热情,关注开源框架的发展,亦在工作中关注所遇所见、乃至所听的案例。从应用程序研发方面看分布式缓存,并需要所有的程序员都具备开发一套组件的能力,但是需要具备正确使用它的能力。如易宝CTO陈斌老师所言,“解决雪崩问题的最好办法是不发生雪崩”。不论是在硅谷互联网公司⾥还是在国内的互联网平台上,曾多次遇到过海量规模的交易瞬间吞噬平台的悲惨故事。我亦了解一些缓存因为代码缺陷或者使用不当被击穿的案例,不同数量级的请求产生的结果天壤之别,不可不慎。

2年前偶遇机械工业出版社的杨福川老师,攀谈之下就萌发了创作本书的念头。但由于工作繁忙且想呈现心中所想之提纲,应邀请一些不同场景下的专家共同完成。组团过程多有波折,特别感动的是北京的孔庆龙兄。他非常有兴趣参与合作,但时逢小孩即将出生,为此,孔兄开了一次家庭会议来讨论此事。虽然孔兄后续未决定参与,但可见其待人之真、之诚,是值得交的朋友。2年间发生了不少事情,刘暻宇leo、何涛、曹洪伟总和程超都换了工作。KickOff前程超家的小朋友还未出生,现在都快2岁了。大家都很忙,大约1个月碰一下进度,有时候可能一点都没有进展。期间,程超和leo都一度要退出,终坚持了下来。还有些朋友中间退出了,同时有陈波、王晓波等朋友加入了进来。到这时,啥时候出版不那么心焦了,水到渠成。就是问初心,我们有没有尽自己的努力来呈现一份关于工具书的纪念!

 曹洪伟:当时怀着“挖人”的险恶用心,进入了中生代技术社区,认识了右军等诸多有趣的技术人。后因为自己在公众号的一篇随笔《老曹眼中的缓存》,右军找到了我,于是开始参与《深入分布式缓存》一书的写作。我加入的时候,本书的架构已经几本成型,于是,我主要负责开篇和面向云服务的分布式缓存,同时review 伙伴们的部分章节。

虚拟团队合作本身就是一种挑战,更何况作者们的本职工作都很繁重,期间又经历了部分伙伴生小孩,换工作等等,使得整本书的写作进度差点失控。大家最后坚持了下来, 坚守着对伙伴的承诺,这本身就是一件难忘的事。

 

技术领导力:在大型网站应用当中,分布式系统设计有哪些策略?哪些实践?能否就其中一二详细说说呢?

曹洪伟:个人最早接触的分布式系统是基于Corba 的orbix。 分布式系统是用户需求导致技术演变的必然结果。大型网站应用中,分布式系统的设计策略取决于业务场景的具体需求,脱离业务谈架构设计大多被认为是“耍流氓”。

例如CAP理论的实践,AP和CP 的选择与具体的业务场景强相关。关于CAP较详细的一种解读可以参见 右军在公众号“技术琐话”中的一篇文字《CAP的相对论》。

具体设计策略包括分布式服务的粒度划分,通信方式,心跳检测与服务监控,容错机制,服务降级与限流,负载均衡与并发性等等。更多关于分布式系统设计的策略描述可以参见《深入分布式缓存》一书的第二章。

于君泽:网上有很多谈一个网站演进的文章,比如如何上缓存,数据库读写分离,数据拆分等。我之前总结了一篇文章,互联网架构的三板斧(https://yq.aliyun.com/articles/54449) 。那三板斧呢?活下来、简单可扩展、去并发。这三板斧解决的是稳定性,可扩展性以及对于高并发的处理。当然,还有运维,监控,治理等。这篇文章更侧重于几个涉及原则。


技术领导力:实现一个缓存框架,需要考虑哪些要素?有哪些分类?能否结合实际经验分享在这方面的心得呢?

曹洪伟:缓存本身有不同的分类。缓存框架一般归为平台级缓存框架和应用级环境框架。应用级缓存框架本身又有不同的分类,所以单纯说缓存框架的实现是一个模糊的概念。

就分布式缓存框架而言,主要考虑的要素数据存储,读写性能,冷启动,失效策略,更新策略, 高可用与高并发等等。以一个广告系统的缓存框架为例,采用了AS作为存储数据库,主要是实现了高实时性的约束。具体的实现方式可以参考《深入分布式缓存》一书的第11章 “Aerospike原理及广告业务应用”

于君泽:《深入分布式缓存》一书用了一个章节来说缓存框架这件事,是第三章:动手写缓存。但这些都是基本服务,其他特性需要考虑场景,不同场景采取不同的方案。


技术领导力:Ehcache、Memcached、Redis等缓存框架,主要的特点是什么?分别适用于哪些业务场景?

 曹洪伟:EHcache 是java 平台上比较优秀的缓存框架,是从hibernate的缓存开始被广泛使用起来的。数据可以伸缩到数G字节,节点可以到数百个,提供了对JSR107 JCACHE API最完整的实现。节点发现,冗余器和监听器都可以插件化。同时,提供了许多对缓存事件发生后的处理机制,兼具灵活性和扩展性。

EHcache 在很多企业级应用中应用广泛。

Memcached是一个高性能的分布式的内存对象缓存系统,通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中,然后从内存中读取,从而大大提高读取速度。

Memcached 支持对象缓存,一度成为很多互联网应用的首选,尤其是与mysql数据库的高度集成。

Redis 是一款高级键值对缓存和存储系统,在应用级缓存中的作用举足轻重。 Redis支持主从同步,可执行单层树状复制。由于完全实现了发布/订阅机制,使得从数据库在任何地方同步树的时侯,可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有作用。Redis 3.0版本加入cluster功能,解决了Redis单点无法横向扩展的问题。

Redis 是当前互联网应用的主流缓存架构,例如同城旅游的redis实践等等。

《深入分布式缓存》一书给出了大量的实践案例。

 

技术领导力:在社交场景中,主要的业务特点是什么?缓存的设计和使用,会遇到哪些问题?以及如何解决这些问题?

 曹洪伟:一个典型社交类系统的典型特性归结为三个关键词:大数据量、高访问量、非均匀性。

1)海量的数据。亿级的用户数量,每个用户千级的post数量,平均千级的follower/followee数量。

2)高访问量。每秒十万量级的平均页面访问,每秒万量级的post发布。

3)用户分布的非均匀。部分用户的post数量/follower数量、相关页面访问量会超出其它用户一到数个量级。

4)时间分布的非均匀。高峰时段的访问量、数据变更量高出非高峰时段一到数个量级

;高峰时段的长短也非均匀分布,存在日常的高峰时段和突发事件的高峰时段。

5)用户+时间的非均匀分布。某个用户可能突然某个时间成为热点用户,其follower可能陡增数个量级

随着用户规模的增长,会遇到各种各样的问题,例如用户关系表的膨胀,热点用户的信息广播,所有用户的信息摘要等等。都可以通过数据库sharding,引入分布式缓存的方式解决。详情请参考《深入分布式缓存》一书的第12章和第13章。


技术领导力:典型的电商类应用,面临哪些挑战?数据静态化、多级缓存等方案是如何运用的?

于君泽:电商类应用具有如下特点:

1)稳定性决定服务能力:在前几个月,某电商网站搞【买200减100的】活动,才进行了2小时就卡得不行。购物车的商品无法下单结算,查看商品详情也非常慢,属于一路塞车的节奏。该网站研发团队通过限流恢复了部分能力,但是对于蜂拥而至的用户而言,大部分用户的体验很差,因为他们买不到商品。

2)高并发性场景:大家都知道,扩展分为Scale Out和Scale Up 2种模式。

Scale Out:横向扩展,增加处理节点提高整体处理能力,俗称加机器。

Scale Up:纵向扩展,通过提升单个节点的处理能力达到提升整体处理能力的目的。

在互联网架构中,采用廉价的服务器做Scale Out已经是非常通用的手段了,但是是不是所有场景扛不住都可以加机器?比如秒杀场景,除了高流量以外,压力在于秒杀商品的高并发,那么热点商品拆分、上缓存、队列等技术自然就很重要了

3)业务发展性能也得发展:举一个例子,有一个系统作支付链路的规则决策,起初可能就4万行代码;后来增加到8万,现在又增加到10万。代码行增加了,该应用的职责增加了,也可能调用逻辑的运算复杂度。那么如何保持对外API的TPS不降低,RT不降低?每次release不仅要完成功能用例的构建,亦要完成性能的测试。

4)产品快速试错:多年前,就有人想把软件从业者变成像制造工人一样的,不断流水线工作。但是这几乎没什么可能,因为要解决的问题域太复杂。虽然业界有很多规范、标准、套装软件,但是仍然未解决问题之万一。我们来看一下是如何复杂的。

以我们的一个team为例,7个人1年做了400多个需求。大家都知道满足需求,实现业务价值是软件的天职,至于为了更好适应未来发展的平台化能力也好,新特性也好只能在业务发展的过程中做掉。在这么多需求的过程中,除了技术以外,对于业务包括规则要有深度把握,包括上下游的一些问题。如有评估不到位,问题就大了。分析到设计阶段的缺失,到代码、测试、发布这些阶段可能一如既往的缺失了。早些年,某些系统已经复杂到只有1-2个人能搞懂部分了,幸好这些系统今天都完成了拆分和治理。

数据静态化、多级缓存的部分几句话说不清楚,建议阅读我们的书《典型电商应用与缓存》章节。前几天看到有朋友再说,热点的数据是不是一定要用多级缓存呢? 最简单粗暴的是可以把热点key的数据拆分几份放到不同server上,规避过热数据把服务器击穿。但是如果热点key没有事前预期呢? 则需要一套发现热点key的机制了;另外多级缓存提升了性能,也保护了远程缓存服务器。所以,没有绝对正确的方法,只有相对合适的方案。

 

attachments-2018-01-TnWXmjTM5a60979d74348.jpg

新书推荐:《深入分布式缓存》


作者介绍:

于君泽:蚂蚁金服高级技术专家、花名右军,IT从业超过十五年。对高并发、分布式架构、内建质量、研发管理有一些心得。维护公众号“技术琐话”。

程超:“爱农驿站”首席支付技术专家。InfoQ、中生代技术社区签约作者,CSDN博主专家,Springfor all社区贡献者,擅长微服务和分布式架构。

邱硕:蚂蚁金服技术专家,花名牧丘,在阿里和支付宝从事中间件、应用系统的性能/稳定性技术风险相关工作。Cobar主要作者。

曹洪伟:70后老码农,全栈工匠一枚,服务过多家世界500强,后连续创业,现任渡鸦科技CTO,致力于人工智能硬件,维护有“wireless_com”公众号和博客

 刘璟宇:拍拍贷资深架构师,十余年互联网行业从业经验,主要研究云计算、服务化基础框架以及各种基础组件。

 张开涛:京东架构师,畅销书《亿级流量网站架构核心技术》作者,维护有“开涛的博客”公众号。

 何涛:网联高级架构师,对高流量下的架构设计有丰富的实践经验,热衷于高可用、高并发和高性能的架构研究。

 宋慧庆:勤诚互动研发总监兼高级架构师,十年互联网广告行业经验,主要研究高可用架构技术,为流量变现提供更好的服务。

 陈波:新浪微博技术专家,负责平台基础架构及优化,经历了微博从起步到成为数亿用户的大型互联网系统的演进过程。

 王晓波:同程旅游首席架构师,10余年互联网行业从业经验,负责中间件、微服务、分布式架构、运维、安全等方面工作。


京东购书,扫描二维码:

attachments-2018-01-oJR04AXb5a6097dc946df.png


网友评论

登录后评论
0/500
评论
abel_cao
+ 关注