2021 最新腾讯 Java 高级面试题总结

程序员蜂蜜水

关注

发布于: 1 小时前

主要内容

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

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

本文内容共分为三个部分，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 做出权衡的业务领域。从参与者来区分有用户、商户、平台运营人员;从基础领域模型来看有商品、订单、库存、库房、营销、物流、干系人等。

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

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

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

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