大理白族自治州网站建设_网站建设公司_建站流程_seo优化

作为“先导篇”的第一篇文章，本文主要是给不熟悉 Redis 的小伙伴，快速介绍一下 Redis 的相关概念和使用场景。

本文主要从三个方面来介绍（如下图所示）：Redis 是什么、为什么使用 Redis 以及 Redis 与 Memcached 的对比。其中，第二、第三方面也是面试的重灾区，在不同等级的面试中，多多少少都会涉及到这两方面的问题。

Redis 是什么？

先来说说 Redis 是什么东西吧，有的小伙伴可能是第一次接触 Redis。

一般我们看一个东西是什么的时候，都是去官网上看一下 Introduction， 那我们 Redis 官网（https://redis.io/）走起，如下截图：

毕竟官网的解释最标准而权威，所以我们就一起解读下官网对于 Redis 的介绍。

• Redis 是一个开源的、内存的、有数据结构的存储，通常会被用作 DB、缓存、消息队列、流处理引擎。

• Redis 提供了非常多的数据类型，比如，String、Hash、Set、List 等。Redis 还提供了主从复制、Lua 脚本、LRU 淘汰机制，以及持久化、哨兵 、Cluster。（小声说一句，这些东西就是我们把 Redis 玩明白的关键内容。）

• Redis 有不少亮点，比如，原子操作，内存数据库性能好，自带了持久化机制，还有异步复制、部分复制的功能。

• Redis 提供了多种语言的客户端，换句话说，就是 Redis 的生态好，资料多，学习成本低。

• Redis 由 C 语言编写，推荐在 Linux/UNIX 系统上部署，官方没有提供 Windows 系统上的安装包。

总结一下，Redis 是一个 KV 数据库，它的优点有：丰富的数据类型，性能好，支持原子操作，支持持久化，整个生态也很好。

为什么要用 Redis？

很多时候，面试官问 Redis 的起手式就是：你项目里面为什么要用 Redis？

Redis 在实践中最常被用作缓存，下面我们可以尝试从服务演化的角度来回答“为什么要用 Redis 做缓存”这个问题。

服务最开始的时候，是只有一个 MySQL 存储，就和下面这张图一样：用户通过浏览器来发一个请求，会打到 Java 服务器上，就是我们用 Spring 、MyBatis 之类的框架写的这个后端的 Java 服务，然后，这个后端的服务会访问 MySQL，去查询数据或者是写入数据。

之后，随着业务不断发展，会出现两个情况。

第一个情况是单表单库的数据量会不断增大，这个时候就可以考虑分库分表。如下图：

当请求发送过来，Java Server 就会用 MySQL 中间件，比如 MyCAT、Sharding Sphere 之类的框架，根据某个字段进行分库分表的路由，把请求打到不同的 MySQL 实例上面。比如说，用户登录服务里面分了 10 个库，就可以用 userId 对 10 取模，得到的就是那个 MySQL 库的编号，这样的话，我们的服务就知道这个用户的数据存到哪个库里面。另外，还可以降低每一个 MySQL 上面存放的数据量，以及每一个 MySQL 要支撑的请求数和并发量。

第二个情况就是单个 MySQL 的读写压力比较大。如果我们碰到的是读多写少的场景，可以先尝试添加合适的索引，如果添加合适的索引之后，MySQL 单机还是无法抗住读流量，可以考虑添加从库进行读写分离，让多个从库来分摊读流量；如果是读写相对均衡，也可以考虑主从读写分离的方案，这样可以让主库只处理写流量，从库只处理读流量，也可以缓解单个 MySQL 上的压力。另外，如果碰到的是写多读少且没有事务需求的场景，使用 MySQL 做存储就不是那么合适了，可以考虑 HBase 等写入性能较强的存储产品。

MySQL 主从架构如下图所示：

其实，这种情况也是依赖 Java 里面的数据库中间件，它可以识别出一次数据库操作到底是 select 语句，还是 insert、update 或者 delete 语句。如果是修改数据的话，会把 SQL 语句发到主库上执行；如果是查询数据的话，select 语句就会把请求打到从库上。

不难看出：这些优化点的本质都是分治的思想，都是为了减少打到单台 MySQL 实例上的流量。

顺着这个思路想，除了在全量数据上面进行分治，还可以考虑根据数据访问情况进行分治，区分出冷热数据，把一部分经常访问的 “热” 数据放到一个更快的存储里面去，比如说缓存，这就用到了我们今天要说的 Redis。

这样就得到了下面这张架构图：在我们读写数据的时候，先会去 Redis 中读取，如下图红色 1 所示；如果 Redis 命中，直接返回数据，结束此次查询；如果 Redis 未命中，则执行下图红色 2 步骤，从 MySQL 集群读取目标数据；在将数据返回的同时，Server 会执行下图的红色 3 步骤，将从 MySQL 中获取的数据，写入到 Redis 中缓存，等待下次读取。

在修改数据的时候，会执行上图中蓝色 1 步骤，修改 MySQL 中存储的数据；在 MySQL 事务提交的时候，会产生 binlog 日志，触发上图中的蓝色 2 步骤，修改 Redis 中存储的缓存数据，这样也就是实现了 Redis 和 MySQL 的数据一致性。

不过，Redis 在实际生产中，多是以Redis Cluster或者主从复制这些分布式的模式对外提供服务的，所以我们应该把上面这个 Redis 单机的地方再改成 Redis 分布式存储的模式。（这个后面详细介绍 Redis 主从和 Cluster 的时候，会再详细聊这个东西。）修改情况如下图：

通过上述存储架构演化过程，我们先是使用数据水平切分的思想，引入了 MySQL 分库分表的架构；然后采用流量切分的思想，引入了 MySQL 读写分离的架构；最后使用冷热数据切分的思想，引入了 Redis 作为缓存的架构，并重新应用数据和流量切分的思想，引入了 Redis 集群的架构。同时，使用监听 binlog 的方式，让 MySQL 与 Redis 中的数据保持最终一致。这样就较为完整地从架构演进的角度回答了“为什么要引入 Redis 缓存”这一问题。

这里我也额外说明下，不仅是“缓存”这个技术，其他的技术也是一样，当面试官问到为什么要引入这个技术的时候，最直接的答案肯定就是“我需要”。但除了简单地回答 “我需要” 之外，我们还必须要合理地说服面试官“为什么需要”，这个时候我们就可以从服务演化的角度，说明白怎样一步步引入新技术，以及是怎么一步步调整服务架构来解决问题的。

技术选型问题：Redis VS Memcached

既然用了缓存，那为什么要用 Redis，而不是 Memcached 呢？这又是面试官常问的一道技术选型问题。

你可能是只知道 Redis，所以选了 Redis，这个理由没问题。但是，我们需要用另一个话术来说，比如，选 Redis 的一个原因是公司里面大多数人的技术栈，他们都熟悉 Redis，相较于其他缓存技术来说，Redis 的部署、维护、使用以及线上问题的处理，我们更能 hold 得住。

除了技术栈的原因之外，我们最好的回答方式是能找到几个 Redis 的对标方案，然后知道每个方案的优缺点，然后再结合项目的场景，着重说明 Redis 优点和对标方案的缺点。

回到缓存的技术选型，Redis 一般会和 Memcached 对标，那你可以从以下维度来理解和回答。

第一点，对复杂数据类型的支持。

Memcached 的话，只支持字符串，也就是说它的 value 值只能是字符串，这在面对一些复杂需求的时候，会增加业务代码的复杂度。举个简单的例子，你要存储一个集合类型，比如说存个 Hash 结构，你就要把它先序列化成一个 JSON 或是别的字符串结构，才能存进去；然后在修改 Hash 里面的一个值的时候，就要把整个集合读到 Java 服务里边，反序列化之后才能完成修改；修改完成之后，还要序列化整个集合，再通过网络 IO 写回到 Memcached 里面。这样的话，整个集合在网络上就走了一遍，在目标集合比较大的场景中，如果只修改里面的一个元素，网络 IO 基本都在传输那些没变的数据，有效负载很低。

而 Redis 就不一样了，Redis 天生就支持 Set、Hash、ZSet、List 这些结构，要修改 Hash 集合中的一个值的话，只需要传输目标值就可以了。如果说我们的项目里边，要用到这些复杂结构的话，那基本上就可以把 Memcached 淘汰了。

第二点，对持久化的支持。Memcached 本身不支持持久化，也就是说进程退出的时候，Memcached 里面存储的数据就全没了。而 Redis 本身则支持多种持久化方式。这样看来，如果需要数据持久存储，那 Memcached 也就被淘汰了。

第三点，高性能的内存管理。内存管理方面的话，Redis 和 Memcached 的内存管理方式虽然不一样，但是都非常优秀，我觉得差不多可以打平。

第四点，线程模型的设计。Memcached 是多线程的，在多核机器上，Memcached 会比 Redis 的性能好一点，尤其是在碰到大 Key 的时候，因为大 Key 直接会把 Redis 的单线程堵死。但是 Redis 的单线程能帮我们实现一些原子操作，这个在很多场景下是很有用的。

因此，这个就需要根据业务场景进行选择了，如果有原子操作的需求，可以优先考虑 Redis。

第五点，是否支持集群。

Memcached 采用了伪分布式的方案，服务端各实例之间是不通信的，Memcached 是依赖客户端对 Key 进行一致性哈希，然后请求到 Memcached 集群的单台实例上。在出现故障的时候，Memcached 本身不做处理，没有自动故障转移的能力，需要我们自己进行二次开发来提高 Memcached 的高可用。

Redis 天生就支持了很多种分布式的模式，例如，前面提到的主从模式、Sentinel 模式还有 Redis Cluster，而且 Sentinel 模式和 Redis Cluster 模式都有自动故障转移的能力。

这样看来，在集群以及高可用方面，Redis 又胜 Memcached 一筹。

总结

这一篇文章我们主要做了三件事：

• 首先，我们一起看了一下 Redis 官网的文档，了解了一下 Redis 的重要特性；

• 然后，从服务架构演进的角度，回答了一下为什么要在项目里面使用 Redis 的问题；

• 最后，通过五个维度的对比，详细回答了一个技术选型的问题：我们为什么选用 Redis 而不是 Memcached？

这些都是些开放性的问题，本文给出的回答也比较简单，你可以再思考一下，尝试从其他角度回答。也欢迎你在留言区分享你的问题和想法。
的问题；

• 最后，通过五个维度的对比，详细回答了一个技术选型的问题：我们为什么选用 Redis 而不是 Memcached？

这些都是些开放性的问题，本文给出的回答也比较简单，你可以再思考一下，尝试从其他角度回答。也欢迎你在留言区分享你的问题和想法。

运维学习资料分享

• 软考高级系统架构设计师备考学习资料
• 软考中级数据库系统工程师学习资料
• 软考高级网络规划设计师备考学习资料
• 软考高级系统规划与管理师学习资料
• 软考中级系统集成项目管理师学习资料
• Kubernetes CKA认证学习资料分享
• AI大模型学习资料合集
• PuTTY中文版安装包
• MobaXterm中文版安装包
• pinginfoview网络诊断工具中文版
• Xshell、Xsftp、Xmanager中文版安装包
• 毕业设计高质量毕业答辩 PPT 模板分享
• IT行业工程师面试简历模板分享