↑↑↑点上方蓝字关注并星标⭐「IT技术思维」
一起培养顶尖技术思维
来源：IT技术思维原创，转载请注明原出处
专访嘉宾：陈波，新浪微博研发中心平台架构技术专家
作为互联网公司，只要是直接面向用户的业务，要想持续确保系统的访问性能和可用性，都需要使用缓存。
以新浪微博为例，日活跃用户已超2亿，每日访问量百亿级，历史数据高达千亿级。核心接口可用性要达到99.99%，响应时间在10-60ms以内，核心单个业务的数据访问量高达百万级QPS。
如果用户的每次请求，服务后端都要查询用户的个人信息、社交关系图谱，以及关系图谱涉及到的大量关联信息。还要将这些信息进行聚合、过滤、筛选和排序，最终响应给用户。如果这些信息全部从DB中加载，将会是一个无法忍受的漫长等待过程，而缓存的使用，是提升系统性能、改善用户体验的唯一解决之道。
这次IT君采访到新浪微博的技术专家陈波，他在微博工作数十年，见证了微博缓存处理的发展。
建议你花5分钟时间，吸收他在缓存方面的成长心得。
本期嘉宾介绍
▼
陈波
新浪微博研发中心平台架构技术专家
现负责新浪微博feed平台的基础设施、缓存中间件、分布式存储等的研发及架构优化工作。
他于2008年加入新浪，从事IM的后端研发；2009年起着手微博Feed平台系统的研发及架构工作，深度参与了最初若干个版本几乎所有业务的开发和架构改进。
从2013年至今，他负责微博平台基础架构相关的研发工作，经历了新浪微博从起步到月活数亿用户的大型互联网系统的技术演进过程。
作为资深技术人，他常作为架构师相关大会的分享嘉宾，细数微博Redis优化和缓存架构演进历程，2017年参与撰写技术畅销书《深入分布式缓存：从原理到实践》
以下为专访内容整理
▼
IT 君：您是2008年加入新浪的，从一位后端研发到现在架构技术专家，您为什么选择专攻缓存和分布式相关方向，您的成长中有什么里程碑，或者说转折触发点吗？
陈波：
在微博平台研发最初3-4年，我主要从事后端研发，除了做业务开发，也做了不少关于分布式缓存和存储的工作。
后来微博成立平台架构组，由于我做了不少相关工作，对业务开发感受很深，就转了过来，目前主要从事微博Feed平台的基础设施、缓存中间件、分布式存储等的研发及架构优化工作。

其实这些变动并不完全是我个人的选择，更多的是业务需要和业务驱动。
因为微博平台重度依赖缓存，然后微博是多地部署，天然就有强烈的分布式存储的需要。
说到成长过程中的里程碑，我觉得有三个：
首先是2008年加入新浪这个大平台，进入一个开放、能持续研究、相互促进的团队，记得当初Tim每周都会召集小组成员进行知识分享和技术探讨，个人收益很大，而且也养成了持续研究、乐于分享、乐于探讨的习惯。
之后是2009年加入新浪微博这个项目，项目一上线就爆发性增长，本预计可以支撑1-2年的容量，半年后就快撑爆了，直接导致项目迭代很快，大家经常晚上9-10点在讨论方案，凌晨2-3点完成主体开发才回家。虽然比较辛苦，但看着业务数据暴增、系统越来越强壮，是很有成就感的事。
最后就是转入架构组，这让我有机会跳出单个业务，站在多个业务线条之上来观察，思考如何在短期需求和长期健壮性之间做Trade-off。
在微博一路成长的过程中，最大的感悟是要把工作当成事业、当作创业来做。这样你就会发现工作不是做完，而是做好和做到更好。也会发现研发不仅是编码，还要考虑架构演进、业界动态、技术发展、产品创新、成本控制（存储成本、机器耗电、公有云计费）等，最终你会发现大公司里也可以“创业”，不仅成本不高，而且还很有乐趣。
▼
IT 君：您目前致力于微博feed平台架构工作。如今微博日活跃用户达到2亿+，每日新发feed 达到1-2亿，每日访问量过百亿级，历史数据更是高达千亿级，这对缓存处理来说是个很大的挑战，您在其中主要负责什么，作出了怎样的贡献？
陈波：
微博开发之初，在数据访问项我主导设计了Storage proxy架构，将数据对Cache、DB的访问进行封装。这样业务开发时，对于Cache访问，不用做任何修改，仅仅通过设置配置，即可直接实现对Local-cache、MC的访问（后来也支持其他Cache组件）。
之后，我提出并实现了第一版的Master-slave的MC架构，解决了MC部分节点异常引发系统故障的难题。同事提出可以再加一层L1，我们迭代出了L1-M-S架构，形成微博MC使用的基本姿势，进而可以支撑各种突发流量，沿用至今。
同时我们基于Storage proxy又进一步开发了Common-cache，后续在开发Motan时进一步对其进行扩展，目前只需几行配置，即可使用Local-cache、MC的L1-M-S架构、Redis及其他多种Cache衍生，在确保系统性能、稳定性的同时，大幅降低了开发难度。
微博是在2010年底引入Redis，然后我们就根据线上需要，持续对Redis做定制和深度优化，目前不仅可以支持：域名均衡访问、动态升级、完全增量复制，还增加了许多新的更高内存/访问效率的数据结构，还增加了SSD访问支持、高效可控的动态扩缩等支持。
我们在SSD Cache、海量数据低成本高效判断与否、大规模计数、缓存服务化等也做了一系列服务支持，对微博业务的服务能力和稳定性做了很好的支撑。
▼
IT 君：可以给大家分享一次您印象最深或收获最大的项目吗？
陈波：
微博最初是重度依赖MC（Memcached），我们最初使用MC池是单层业务池，采用取模或一致性Hash进行分布，随着业务规模增加，发现MC机器宕机或网络异常，对线上服务的稳定性影响很大。
2010年的一个晚上，几个核心MC节点异常引发雪崩，整个服务在数十分钟后才完全恢复。这件事情虽然是硬件故障导致，但给我留下深刻印象，经过几天的深入分析，我提出并实现了第一版的Master-slave的MC架构，服务的稳定性大幅提升，部分MC节点异常很难再引发系统级故障。
但不久后发现有偶发脏数据的问题，而且没有任何规律。有童鞋甚至提出要废除M-S架构，恢复之前的单层结构。
当时万幸我顶住了这些建议的压力，通过和DBA合作，并进行日志、抓包等各种手段分析后，发现原来是因为MC资源池沿用了之前的一致性Hash分布策略，如果有节点不稳定，间断上线、下线几次后，会产生脏数据，正好有若干机器反复故障，于是暴露了这个问题。
我们迅速进行排查，将MC池切换到取模模式进行分布，同时也增加若干其他保障措施，使整个系统不仅稳定性大幅上升，数据一致性也得到很好的保障。
▼
IT 君：您认为在互联网公司，Redis或其他分布式缓存具体的应用场景有哪些？工作中需要注意哪些问题？
陈波：
互联网公司，只要是直接面对用户的业务，要想持续确保系统的访问性能和可用性，都需要使用缓存。缓存使用设计的过程中，需要注意如下问题：
  1. 在系统设计之初，就要对待缓存的数据、缓存系统进行良好架构和设计；
  2. 要对使用的缓存组件有良好且深入的理解，做到知其然知其所以然，从而在缓存数据不符合预期时，能快速定位问题；
  3. 需要从Client访问端、Server端对缓存建立监控体系，从而能持续观察缓存状态，并能及时发现资源SLA异常，通过人肉或自动化处理，确保整体系统的稳定；
  4. 要根据业务、资源的使用状况和SLA变化，对缓存数据和缓存架构体系进行持续改进；
  5. 需要持续关注业界的技术变化趋势，并在必要时进行测试、引入及验证，并结合业务进行改进，以提高业务系统的性能和稳定性，并更好的促进业务发展。
比如微博Feed平台，设计之初就对Cache进行了专门设计，按业务分别设置了独立的用户、Feed-vector、Feed-content、Comment、DM等MC池(最初remote cache基本都是mc），关注关系也是缓存在MC中。Vector Cache缓存用户最新发表的200条Feed（单条微博) ID列表，Feed内容直接存Json和Xml格式字符串。
用户刷微博时，会首先查用户的关注人列表，然后根据关注列表拉取所有关注人的Feed Vector，然后进行聚合和静态组装，虽然这个过程当时看来很复杂，经历的步骤很多，但由于所有的访问都基本是全部命中缓存，所以整个响应可以高效快速返回。
随着用户数、访问量增大，我们通过监控发现Cache机器的带宽很容易被打满，而一旦用户刷到比较久之前的Feed，也会穿透到DB。
于是我们增加了存储最新50条、2000条Feed ID的Vector Cache，同时还增加了附带各种Flag的多列属性Vector Cache，使不同的访问模型会访问到不同的Vector，对Feed内存也从JSON、XML全部改为PB（Protocol Buffer）格式。
同时我们引入Redis进行缓存用户的关注列表，最初用原生Set，后来又开发了新的Longset结构，提升查询性能的同时大幅降低内存占用，最后不仅Feed聚合性能大幅提升30%-50%+，而且支持各种动态组装（之前只有静态组装）需求，很好的满足的业务需求。
后来我们进一步进行服务化改造，对各种业务的缓存访问SLA实时监控，并通过历史数据进行拟合，快速发现慢请求、突发流量，通过快速扩缩容，来确保整个系统在各种场景下的稳定运行。
▼
IT 君：如果技术工程师对缓存处理了解的不透彻，会对今后的发展有哪些阻碍？
陈波：
对于互联网系统，性能瓶颈的解决，缓存是最重要的一个环节，也是最容易出问题的一个环节。线上服务，规模越大，软硬件故障发生的概率越大，缓存系统一旦出现问题，轻则数据不一致、请求变慢，重则系统雪崩，整个系统无法提供服务。
我们对缓存组件、缓存架构深入理解，可以在系统架构设计之初就避开可能设计陷阱，在系统上线后，遇到各种问题也能快速定位解决。
▼
IT 君：如果想做好缓存处理，您能大致介绍一下需要掌握哪些知识要点吗？可以通过哪些途径去习得知识？
陈波：
  • 首先要熟练掌握缓存的基础知识
    ，了解缓存常用的分类、读写模式，熟悉缓存设计的几大经典问题及解决应对之策，同时要从缓存组件的访问协议、Client入手，熟练掌握如何访问各种缓存组件，如Memcached、Redis、Pika等。

  • 其次要尽可能深入理解缓存组件的实现方案、设计原理，了解缓存的各种特性、优势和不足，这样在缓存数据与预期不一致时，能够快速定位并解决问题。
  • 再次还要多了解线上大中型系统是如何对缓存进行架构设计的。线上系统，业务功能丰富多变，跨域部署环境复杂，而且热点频发，用户习惯迥异。因此，缓存系统在设计之初就要尽量进行良好设计，规划好如何进行Hash及分布、如何保障数据的一致性、如何进行扩容和缩容。当然，缓存体系也需要伴随业务发展持续演进，这就需要对缓存体系进行持续的状态监控、异常报警、故障演练，以确保在故障发生时能及时进行人肉或自动化运维处理，并根据线上状况不断进行优化和改进。
  • 最后，还要多了解缓存在各种场景下的最佳实践，理解这些最佳实践背后的Tradeoff，做到知其然知其所以然，以便在实际工作中能举一反三，把知识和经验更好的应用到工作实践中来。
这些缓存知识，网上各种文章介绍很多，虽然会有些零散和重复，但初学者可以从中快速了解梗概；其次可以阅读缓存相关的书籍、源码；最后，还可以通过一些来自实战总结的网络课程，通过其他人的经验总结，快速而深入的获得相关知识。
▼
IT 君：作为新浪微博资深架构，一定会有很多面试和考核工作，缓存内容在面试中的比重大概有多少？您都会如何考察面试者？在缓存方面，具备什么能力的人才会被您青睐？
陈波：
对于后端开发，缓存肯定是重要一个考察环节，缓存相关知识的理解深入程度，往往与着应聘者的开发经验和好学程度有强烈的关联。当然如果面试者其他方面非常优秀，而个人学习能力又很强，也可能会获得青睐，这里面并没有一个硬性的比重规定。
考察面试者，我会比较关注其面对工作的态度和工作之余的自我学习能力，关注其研发相关知识的深度和广度，当然对于社招的童鞋，相关领域的开发经历也是一个重要考量因素。
缓存方面，能熟练使用几种常见缓存组件，并能理解缓存组件的各种特性和在各种业务场景的最佳实践，这些都是不错的；当然如果能阅读过这些组件的源码，深入理解过这些缓存组件的设计原理和实现方案，那就更佳了。
▼
IT 君：我们了解到，您也常作为架构师相关大会的分享嘉宾，细数微博Redis优化和缓存架构演进历程，2017年曾参与撰写技术畅销书《深入分布式缓存：从原理到实践》。这做这些分享是基于什么样的初心呢？
陈波：
互联网进入移动社交时代后，互联网产品进入一个新时代。即从满足单向浏览需求的时代，发展到今天的以用户、关系为基础的个性化信息服务时代。
这些个性化信息的提供，意味着用户的每次请求，后端服务都需要获取用户的兴趣、社交关系图谱以及关系图谱涉及的大量关联信息，并通过实时计算才能返回。
在这个处理过程，缓存是重要的一个环，可以说良好设计的缓存架构是一个互联网系统能持续稳定运行的重要支撑。新浪微博作为移动互联网时代的一个开拓者和重量级社交分享平台，在这方面做了很多有意义的探索，也积累了很多经验和最佳实践，所以我们希望通过各种架构大会、书籍分享出来，让各种初学者、其他厂商的开发者参与其中，大家共同学习，共同探讨，共同进步，当然这也是我做一个在线课程的一个初衷。
本次陈波老师应拉勾之邀，依托他在微博feed流及缓存方面的资深背景，从底层原理开始，再现穿透、雪崩等七大经典问题和解决方案，巩固核心基础，同时加强Memcached和Redis进阶知识点，再升级到详解分布式缓存CAP，课程最后以3个实际应用场景为例，深度分析缓存在秒杀系统、计数器、Feed流中的应用，给你一套完整的缓存系列能力进阶画像。
以下为课程大纲
▼
戳阅读原文，查看课程。
↓↓↓
继续阅读
阅读原文
关键词
数据
问题
系统
微博
用户