蚂蚁京东新浪10位架构师424页佳作深入分布式缓存从原理到实践pdf

最新推荐文章于 2024-06-29 03:19:28 发布

Java技术那些事儿

最新推荐文章于 2024-06-29 03:19:28 发布

阅读量173

点赞数

文章标签：后端 java 学习分布式开发语言

本文链接：https://blog.csdn.net/LBWNB_Java/article/details/125973399

版权

本文深入剖析了分布式缓存的重要性，从理论基础到实现细节，涵盖Ehcache、Memcached、Redis等主流缓存系统，以及在社交、电商等场景中的应用。通过具体案例，展示了如何利用缓存技术解决高并发、大数据量下的性能挑战，是理解并应用分布式缓存的宝贵参考资料。

摘要由CSDN通过智能技术生成

前言

最近刷到了一句耐人寻味的话，“解决雪崩问题的最好办法是不发生雪崩”。

不论是在硅谷互联网公司里还是在国内的互联网平台上，曾多次遇到过海量规模的交易瞬间吞噬平台的悲惨故事。

核心的解决方案大同小异，都是通过缓存，逐层减少流量的冲击，保护用户的体验和平台的服务可用。

金融、财务行业有现金为王的说法，互联网技术行业用“缓存为王"清楚地概括了缓存的重要性。

而本文深入浅出地讨论了Ehcache、Memcached、Redis、 Tair、 EVCache等各种常用缓存开源系统的方案及精粹。

虽然读过不少国外有关缓存的技术专著，大多数偏原则和理论，具体实施方案和案例较少，特别是结合中国互联网技术实践的更少。

所以本文实际上填补了缓存技术文献在这方面的空白。尤其是结合微博、社交和电商平台的应用实践探讨，对想学习如何利用缓存技术解决实践中具体问题的读者大有裨益。

主要内容

本文是从大型互联网系统的应用角度探讨分布式缓存的。本文站在原理、框架、架构、案例等多个视角对分布式缓存进行了探讨。

互联网系统随着容量需求的陡增，许多看似简单的存储类场景都面临着巨大的容量问题和稳定性风险，而其中大部分问题都可以通过对缓存的合理使用来规避。读者从本文中将会获得应对这些问题的思路，也会对分布式缓存有一个体系化的认识。

本文内容共分为三个部分，16章的内容，全文按照从理论到实现，再到实践的思路撰写。

首先介绍分布式缓存的背景知识，对“分布式”和“缓存”这两个关键词进行了全面阐述，从而为后续章节的叙述打下基础;

接着介绍业界主流的缓存，关注其原理与实现，囊括了Ehcache、Memcached、Redis、 Tair、 EVCache、Aerospike等六个缓存或类缓存系统;

最后讨论缓存在互联网系统中的实践，从广告、社交、新闻、电商、营销等五类典型的互联网应用入手，分析它们面临的性能稳定性问题以及如何利用分布式缓存解决这些问题。

第1章，缓存为王

在商业的世界中，常说的一句话是“现金为王”。在互联网、移动互联网乃至整个软件技术世界中，与之相近的一个说法就是“缓存为王”。什么是缓存呢?

第2章，分布式系统理论

分布式理论体系宏大精深，可以通过一大厚本专著来专门阐述，本文难以尽述之，本章拟从分布式系统概论、分布式系统概念、分布式系统理论，比如Paxos、分布式系统设计策略、心跳检测、分布式系统设计实践、全局ID生成等几个方面略勾画之。本章可作为后续章节阅读的基础，比如Master-Slave节点切换需要心跳检测、Redis 多节点选主也有相应的理论体系( Paxos或者Raft协议等)支撑，一致性哈希、路由表甚至负载均衡也是常见的分布式服务调用策略。

第3章，动手写缓存

目前市面上已经有很多开源的缓存框架，比如Redis、Memcached、 Ehcache 等，那为什么还要自己动手写缓存?本章将带领大家从0到1写一个简单的缓存框架，目的是让大家对缓存的类型、缓存的标准、缓存的实现及原理有一个系统的了解，做到知其然，知其所以然。

第4章，Ehcache与Guava Cache

Ehcache是一个用Java实现的使用简单、高速、线程安全的缓存管理类库，其提供了用内存、磁盘文件存储，以及分布式存储等多种灵活的管理方案。同时Ehcache作为开放源代码项目，采用限制比较宽松的ApacheLicenseV2.0作为授权方式，被广泛地用于Hibernate、Spring、Cocoon 等其他开源系统。Ehcache 从Hibernate 发展而来，逐渐涵盖了全部功能,是目前发展势头很好的-一个项目。Ehcache具有快速、简单、低消耗、依赖性小、扩展性强、支持对象或序列化缓存、支持缓存或元素的失效、提供LRU/LFU/FIFO缓存策略、支持内存缓存及磁盘缓存、采用分布式缓存机制等特点。

为了方便大家了解最新版本的Ehcache, 4.2.1 、4.2.2、 4.2.3 节中采用最新的Ehcache 3.0的特性进行介绍，4.2.4 节采用Ehcache 2.10.2版本与Spring 相结合来做案例介绍，包括后面的源码分析也将采用这个版本。

GuavaCache和Ehcache一样也是本地缓存，但在细分领域也有不同的应用场景，4.5节中将做详细介绍。

第5章，从Memcached开始了解集中式缓存

许多Web应用程序都将数据保存到RDB中，但随着数据量的增大，RDB的负担加重,数据库响应恶化，性能严重下降。Memcached是高性能的分布式内存缓存服务器，一般用来缓存访问的热点数据,减轻数据库的负担。

第6章，Memcached周边技术

对于Memcached等常用的缓存组件，本身大多是以单机方式运行的，服务能力受到单个主机处理器、内存等资源的限制。在大型的互联网应用中，往往需要更大的数据访问量以及缓存更多的数据，这些需求都大大超出了单机缓存系统所能提供的能力范围。

解决高流量访问的方案有很多，直接的方式是提高单机缓存的性能和资源利用率，例如Twemcache,更多的是将多个缓存实例以集群的方式提供服务，利用资源优势提供更好的性能和更大的存储容量，以满足应用对缓存能力的需求。

如果说缓存是以空间换时间的艺术，那么，缓存的集群服务就是该艺术在另一种维度上的呈现，同时，还提供了高可用性。在设计缓存的集群方案时，一般考虑以下几点:

可扩展性:集群可以方便通过扩充机器来提供更高的缓存能力。
高可用性:集群能够对应用提供可靠的服务，实现缓存服务的高可用性。
可维护性:集群能够方便监控和运维。

本章主要介绍基于Memcached的周边技术，重点对Memcached的定制版Twemcache,对开源的缓存集群方案Twemproxy,以及Mcrouter等进行解析，以便充分地利用分布式缓存服务。

第7章，Redis探秘

Redis ( REmote DIctionary Server)是一个key-value存储系统，由Salvatore Sanfilippo开发，使用ANSIC语言编写，遵守BSD协议。

Redis运行于独立的进程，通过网络协议和应用交互，将数据保存在内存中，并提供多种手段持久化内存数据。Redis具备跨服务器的水平拆分、复制的分布式特性。Redis不同于Memcached将value视作黑盒，Redis 的value本身具有结构化的特点，对于value提供了丰富的操作。基于内存存储的特点使得Redis 与传统的关系型数据库相比，拥有极高的吞吐量和响应性能。

第8章，分布式Redis

Redis作为数据存储系统，无论数据存储在内存中还是持久化到本地，作为单实例节点，在实际应用中总会面临如下挑战:

数据量伸缩:单实例Redis存储的key-value对的数量受限于单机的内存和磁盘容量。长期运行的生产环境中，随着数据不断地加入，存储容量会达到瓶颈。虽然Redis提供了key的过期机制，在作为缓存使用时通过海汰过期的数据可以达到控制容量的目的。但当Redis作为NoSQL数据库时，业务数据长期有效使得淘汰机制不再适用。
访问量伸缩:单实例Redis单线程地运行，吞吐量受限于单次请求处理的平均时耗。当业务数据集面临超过单实例处理能力的高吞吐量需求时，如何提升处理能力成为难点。
单点故障。Redis持久化机制一定程度上缓解了宕机/重启带来的业务数据丢失问题，但当单实例所在的物理节点发生不可恢复故障时，如何保证业务数据不丢以及如何在故障期间迅速地恢复对应业务数据的可用性也成为单点结构的挑战。

上述问题对于数据存储系统而言是通用的，基于分布式的解决方案如下:

水平拆分:分布式环境下，节点分为不同的分组，每个分组处理业务数据的一个子集，分组之间的数据无交集。数据无交集的特性使得水平拆分解决了数据量瓶颈,随着分组的增加，单个分组承载的数据子集更小，即通过增加分组来伸缩数据量。同时水平拆分也也解决了访问量瓶颈，业务数据全集的请求被分摊到了不同分组随着分组数的增加，数据全集的总吞吐量也增加，访问量的伸缩性得以实现。
主备复制:同一份业务数据存在多个副本，对数据的每次访问根据一定规则分发到某一个或多个副本上执行。通过W+R>N的读写配置可以做到读取数据内容的实时性。随着N的增加，当读写访问量差不多时，业务的吞吐量相比单实例会提升到過近2倍。但实际中，读的访问量常常远高于写的量，W=N, R=1,吞度量会随着读写比例的增加而提升。
故障转移:当业务数据所在的节点故障时，这部分业务数据转移到其他节点上进行，使得故障节点在恢复期间，对应的业务数据仍然可用。显然，为了支撑故障转移，业务数据需要保持多个副本，位于不同的节点上。

本章的编写目的就是，帮助读者了解如何通过Redis实现上述解决方案，本章包含的主要知识如下:

sharding: 水平拆分的支持。
replication: 作为读写分离和故障转移的基础。
fail-deteet: 和replication配合，支撑故障转移。
cluster(all-in-one): 完整的分布式解决方案。

第9章，Tair探秘

Tair ( TaoBao Pair的意思，Pair 即Key-Value数据对)是淘宝开发的一个优秀的分布式高可用的key/value 存储引擊。采用服务端自动负载均衡的方式，使客户端逻辑简单。

Tair分为持久化和非持久化两种使用方式。非持久化的Tair可以看成是一个分布式缓存。

持久化的Tair将数据存放于磁盘中。在最新版本的Tair项目中实现了以下4种存储引擎。

非持久化: mdb
持久化: fdb、kdb和ldb

这4种存储引擎分别基于四种开源的key/value数据库: Memcached、 Firebird、 KyotoCabinet和LevelDB。其中Firebird 是关系型存储数据库，Memcached. Kyoto Cabinet和LevelDB是NoSQL数据库。

第10章，EVCache探秘

云服务不仅为软件系统的开发和部署带来了更多的敏捷性，而且提供了更多创新的可能性。当分布式缓存技术遇到云服务会是怎样的情形呢? EVCache 就是这样的一种技术。

EVCache是一个开源、快速的分布式缓存，是基于Memcached的内存存储和Spymem-cached客户端实现的解决方案，主要用在亚马逊弹性计算云服务( AWS EC2 )的基础设施上，为云计算做了优化，能够顺畅而高效地提供数据层服务。

第11章，Aerospike原理及广告业务应用

Aerospike是一个分布式的，可扩展的键-值存储的NoSQL数据库。支持灵活的数据模式，并且支持满足ACID特性的事务。其主要的优势是采用混合存储架构，数据索引信息存储在RAM (随机存取存储器)中，而数据本身可以存储在SSD (固态硬盘)或HDD(机械硬盘)上。并且针对采用多核处理器和多处理器机器的现代硬件进行了优化，通过直接硬盘访问(绕过文件系统)，可以带来难以置信的性能。主要应用于百G,数T等大规模并且并发在数万以上，对读写性能要求较高的场景，目前主要集中应用在互联网广告行业，如:

MediaV, InMobi, eXelate, BuleKai, 时趣互动等。

Aerospike Server能够根据需求安装到多个数据中心多个集群的多个节点上。方便扩展，只需要将节点添加到集群即可，Aerospike群集将自动在所有可用的服务器之间重新平衡数据负载，无须分片，无须人工干预。降低运维成本，具有业界最低的TCO (总体拥有成本)。

本章将会介绍Aerospike 的架构原理，集群部署，基本用法以及在广告行业中的具体应用;本章基于Aerospike的3.8.4版本(主要针对具体的部署操作部分，而对于原理，架构的描述则不局限于此)。接”下来开始介绍Aerospike整体的架构实现和原理。

第12章，社交场景架构进化:从数据库到缓存

本章以一个典型的社交类应用为例，基于一个简化的领域模型和业务场景，叙述该应用在面临不断增加的业务吞吐量时，传统的基于数据库的方案将面临的性能风险，随后阐述如何利用缓存技术对这些典型的性能问题进行解决。

本章分为5个小节，首先引入示例应用的领域模型和业务场景，随后分别针对其relation.post,timeline三个模型的相关场景分别叙述基于数据库的解决方案和问题，以及在此之上引入的缓存方案。最后一小节讨论对这个示例应用在机房本身面临瓶颈时，如何应用缓存辅助其多机房部署。

第13章，缓存在社交网络Feed系统中的架构实践

在社交网络发展如火如荼的今天，人们越来越倾向于用新媒介来展现自我和沟通交互。

以新浪微博为例，作为移动社交时代的重量级社交分享平台，2017年初日活跃用户1.6亿，月活跃用户近3.3亿，每天新增数亿条数据，总数据量达千亿级，核心单个业务的后端数据访问QPS高达百万级。

在社交网络系统运行过程中，面对庞大用户群的海量访问，良好架构且不断改进的缓存体系具有非常重要的支撑作用。本章将以新浪微博Feed系统架构的发展历程作为背景，基于一个典型的社交网络Feed系统架构，介绍Feed系统的缓存模型、缓存体系架构，以及缓存体系如何伴随业务规模来扩展及演进。

第14章，典型电商应用与缓存

分布式系统的CAP理论首先把分布式系统中的三个特性进行了如下归纳:

一致性(C):在分布式系统中的所有数据备份，在同- -时刻是否是同样的值(等同于所有节点访问同一份最新的数据副本)。
可用性(A):在集群中--部分节点故障后，集群整体是否还能响应客户端的读写请求(对数据更新具备高可用性)。
分区容忍性(P): 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

电商领域是典型的要在CAP做出权衡的业务领域。从参与者来区分有用户、商户、平台运营人员;从基础领域模型来看有商品、订单、库存、库房、营销、物流、干系人等。

用户的诉求是什么?买到好东西(正品，价格最好还便宜),支付方便，安全快捷。

商户的诉求是什么?业务模式上解决快速回款;技术上解决对账清晰，数据准确。

平台的诉求是什么?越来越多的用户，越来越多的品类，越来越好的商家。

基于以上三方的诉求，那么电商平台会面临及时响应性的用户需求(我购买成功，还是失败);数据准确性需求(我的钱有没有多扣);平台海量请求的诉求(营销活动、秒杀、大促等);高可用的诉求(每-秒都是钱，每一笔成交背后都是收入，如果平台不可用，对应可以直接换算成资金损失)。