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

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

曹洪伟，《深入分布式缓存》一书的作者之一。 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的机制了；另外多级缓存提升了性能，也保护了远程缓存服务器。所以，没有绝对正确的方法，只有相对合适的方案。

 

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

作者介绍：

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

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

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

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

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

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

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

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

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

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

京东购书，扫描二维码：