【Redis 初阶】 从分布式演进背景到环境搭建全解析

🔥草莓熊Lotso： 个人主页
❄️个人专栏: 《C++知识分享》 《Linux 入门到实践：零基础也能懂》
✨生活是默默的坚持，毅力是永久的享受！

---

🎬 博主简介：

---

文章目录

• 前言：
• [一. 初识 Redis：为分布式而生的内存数据库](#一. 初识 Redis：为分布式而生的内存数据库)
• • [1.1 Redis 的本质定位](#1.1 Redis 的本质定位)
  • [1.2 经典组合：MySQL + Redis 冷热分离](#1.2 经典组合：MySQL + Redis 冷热分离)
• [二. 分布式系统演进之路](#二. 分布式系统演进之路)
• • [2.1 起点：单机架构](#2.1 起点：单机架构)
  • [2.2 为什么要走向分布式？](#2.2 为什么要走向分布式？)
  • [2.3 第一步：应用与数据库分离](#2.3 第一步：应用与数据库分离)
  • [2.4 第二步：应用集群与负载均衡](#2.4 第二步：应用集群与负载均衡)
  • [2.5 第三步：数据库读写分离](#2.5 第三步：数据库读写分离)
  • [2.6 第四步：引入缓存加速](#2.6 第四步：引入缓存加速)
  • [2.7 第五步：分库分表应对海量数据](#2.7 第五步：分库分表应对海量数据)
  • [2.8 第六步：微服务架构拆分](#2.8 第六步：微服务架构拆分)
  • [2.9 分布式系统核心评价指标](#2.9 分布式系统核心评价指标)
  • [2.10 分布式演进小结](#2.10 分布式演进小结)
• [三. Redis 核心特性与应用场景](#三. Redis 核心特性与应用场景)
• • [3.1 Redis 核心特性](#3.1 Redis 核心特性)
  • [3.2 Redis 为什么这么快？](#3.2 Redis 为什么这么快？)
  • [3.3 Redis 典型应用场景](#3.3 Redis 典型应用场景)
  • [3.4 一个务实的思考](#3.4 一个务实的思考)
• [四. Redis 环境搭建实战](#四. Redis 环境搭建实战)
• • [4.1 Ubuntu 系统安装 Redis5](#4.1 Ubuntu 系统安装 Redis5)
  • [4.2 CentOS 系统安装 Redis5](#4.2 CentOS 系统安装 Redis5)
  • [4.3 Redis 客户端的三种形态](#4.3 Redis 客户端的三种形态)
• 结尾：

---

前言：

做后端开发的朋友，没人能绕开 Redis。面试里它是八股重灾区，工作中它是性能救命稻草。但很多人上手就背命令、记数据结构，却很少停下来想：我们到底为什么需要 Redis？它在整个分布式架构里，处于什么位置？本文顺着技术发展的逻辑，从单机架构的演进讲起，带你理解 Redis 诞生的技术背景，拆解它的核心特性与适用场景，再一步步完成 Linux 环境的搭建与验证。全文兼顾原理与实战，既是入门指南，也能帮你梳理面试高频考点。

---

一. 初识 Redis：为分布式而生的内存数据库

1.1 Redis 的本质定位

Redis 本质上是一个基于网络的内存数据中间件 ------ 它把自己内存中的数据，通过网络暴露给其他进程、甚至其他主机的进程使用，它最核心的舞台，就是分布式系统。

我们常拿它和 MySQL 做对比：

• MySQL 是关系型数据库，数据存储在磁盘上，优势是存储空间大、功能完善，适合存储全量业务数据；
• Redis 是键值型非关系数据库，数据存储在内存中，最大的优势就是快。

从量级上直观感受：内存访问大约是 100ns 级别，而磁盘寻道是 10^7ns 级别，性能差了好几个数量级。但快是有代价的：内存的存储空间远小于磁盘，这也是 Redis 相比 MySQL 最大的短板。

1.2 经典组合：MySQL + Redis 冷热分离

单个组件永远做不到 "又大又快"，工业界的解决方案就是组合使用：用 MySQL 存储全量数据保证 "容量大"，用 Redis 存储热点数据保证 "访问快"，这就是经典的缓存架构，也叫冷热分离。

这个方案的底层逻辑是 "二八原则"：业务中 20% 的热点数据，往往能支撑 80% 的访问请求。把这部分高频访问的数据放进 Redis，就能挡住大部分数据库请求，系统整体性能会有质的提升。

当然，计算机领域没有银弹。引入缓存也带来了新的问题：当数据库的数据被修改时，如何保证缓存中的数据同步更新？如何保证两者同时成功或失败？这就是缓存与数据库的数据一致性问题，也是分布式领域的经典课题。

Redis 最重要的应用场景都在分布式系统中，要真正理解它，我们得先搞清楚：分布式系统到底是什么？它是怎么一步步演化而来的？

---

二. 分布式系统演进之路

分布式从来不是什么 "高大上的最优解"，而是无奈之举------ 当一台机器的硬件资源扛不住业务压力时，才不得不引入更多机器。我们顺着业务增长的脉络，看看架构是如何一步步迭代的。

2.1 起点：单机架构

所有系统的起点，都是单机架构。一台服务器，上面同时跑应用程序和数据库，所有业务逻辑、数据存储都在这一台机器上完成。

别小看这种架构，如今绝大多数中小公司的产品，单机架构都完全能 hold 住。现代服务器的硬件性能已经非常强，普通的业务量根本触达不到单机瓶颈。

2.2 为什么要走向分布式？

单机的硬件资源终究有上限。随着用户量增长、并发请求变多，CPU、内存、磁盘、带宽总有一个会先成为瓶颈，导致响应变慢、请求超时甚至服务出错。

应对瓶颈有两种思路：

• 节流：从软件层面做优化，通过性能测试定位瓶颈，针对性改造代码。这种方式门槛高，非常考验开发人员的能力，且优化总有物理上限。
• 开源：直接增加硬件资源。简单粗暴，但单台机器的扩展能力有限，加到顶了还不够，就只能引入更多主机。

当系统引入多台主机协同工作时，它就成为了分布式系统。

记住一句话：分布式不是银弹，它是用系统复杂度换取性能和容量的选择。机器越多，出 bug 的概率越高，运维和开发成本也会指数级上升。

2.3 第一步：应用与数据库分离

架构演进的第一步，通常是把应用服务和数据库服务拆到两台不同的机器上。

• 应用服务器负责业务逻辑计算，更消耗 CPU 和内存；
• 数据库服务器负责数据持久化存储，更需要大容量硬盘和高 IO 性能。

拆分之后，我们可以给不同服务器搭配对应规格的硬件，性价比更高，也各自拥有了独立的扩展空间。

2.4 第二步：应用集群与负载均衡

如果业务继续增长，应用服务器的 CPU、内存先扛不住了怎么办？答案是增加机器，搭建应用服务器集群。

但多台应用服务器，用户的请求该发给谁？这就需要引入负载均衡器（也叫网关）。用户的所有请求先到达负载均衡器，再由它按照指定算法，均匀分发给后端的应用服务器。比如 1 万个请求，两台应用服务器，每台各处理 5000 个。

这个逻辑听起来像多线程，但本质不同：多线程是在同一台主机内的并发，而负载均衡是跨主机的分布式协作。

有人会问：负载均衡器扛下所有请求，它不会先扛不住吗？ 实际上，负载均衡器只做转发、不执行复杂业务逻辑，它的请求承载能力远强于应用服务器。真到了瓶颈，还可以通过多机房、多区域的方式继续横向扩展。

2.5 第三步：数据库读写分离

应用服务器扩容后，数据库承受的请求量也会随之上涨。而绝大多数业务场景都是读多写少 ，于是就有了数据库读写分离架构。

采用一主多从的模式：

• 主库（master）负责处理所有写操作，同时将数据变更同步给所有从库；
• 从库（slave）负责处理读请求，多个从库共同分摊读压力。

通过这种方式，就能用多个从节点承接海量的读请求，大大缓解数据库的读压力。

2.6 第四步：引入缓存加速

即使做了读写分离，数据库的响应速度依然受限于磁盘 IO。想要再进一步提升性能，就要在应用和数据库之间引入缓存层。

我们把高频访问的热点数据放进缓存服务器（也就是 Redis）。用户请求先查缓存，命中就直接返回；没命中再查数据库，同时把数据回写缓存。

基于二八原则，只需要缓存一小部分热点数据，就能挡住大部分数据库请求，系统响应速度会有质的飞跃。 当然，引入缓存也带来了新的挑战：缓存与数据库的数据一致性问题，这也是后续我们要重点攻克的内容。

2.7 第五步：分库分表应对海量数据

如果业务数据量持续增长，大到一台数据库服务器都存不下了怎么办？这时候就要做分库分表。

分库分表本质是对数据库做水平拆分：

• 分库：把不同业务的数据库，拆分部署到不同的数据库服务器上；
• 分表：如果单张表数据量过大，就把一张表拆分成多张，分布在不同服务器上。

具体怎么拆没有标准答案，完全依赖业务场景。永远记住：技术服务于业务，业务决定技术选型。

2.8 第六步：微服务架构拆分

当系统复杂到一定程度，单体应用的代码会越来越臃肿，开发维护、团队协作都会成为瓶颈。这时候就有了微服务架构。

微服务的核心，是把一个庞大的单体应用，按业务功能拆分成多个独立的小服务，每个服务只负责单一功能，独立部署、独立迭代。

微服务本质上解决的是 "人" 的问题。当团队规模大了，需要分工协作，按业务拆分服务，对应到不同的开发团队，协作效率会更高。如果只是两三个人的小团队，搞微服务反而徒增复杂度。

微服务带来的代价也很明显：

1. 性能下降：服务间调用依赖网络通信，网络延迟远高于本地函数调用；想要弥补性能，就得增加更多机器，本质就是加钱。
2. 系统复杂度升高：服务节点变多，出现故障的概率变大，需要完善的监控报警、运维体系来保障系统可用性。

对应的优势也很突出：团队分工清晰、功能复用方便、服务可独立部署与扩缩容。

2.9 分布式系统核心评价指标

衡量一个分布式系统的好坏，有三个核心指标：

• 可用性（Availability）：系统正常提供服务的时间占总时长的比例，常用 "几个 9" 来衡量。比如 4 个 9 就是 99.99% 的可用性，对应全年停机时间不到 53 分钟。我们常说的 "高可用（HA）" 就是对这个指标的追求。
• 响应时长（Response Time, RT）：从用户发起请求到收到响应的时长，原则上越小越好，具体阈值和业务场景强相关。
• 吞吐（Throughput）与并发（Concurrent）：吞吐指单位时间内系统成功处理的请求数量；并发指系统同一时刻能承载的最高请求量。我们常说的 "高并发"，就是对这两个指标的追求。

2.10 分布式演进小结

我们梳理了从单机到分布式的完整演进路径：

1. 单机架构：应用程序 + 数据库部署在同一台主机
2. 服务分离：应用与数据库拆分到不同主机，各司其职
3. 负载均衡：应用服务器做集群，负载均衡器分发请求
4. 读写分离：数据库一主多从，主写从读，分摊读压力
5. 引入缓存：冷热分离，热点数据缓存加速，降低数据库压力
6. 分库分表：数据库水平拆分，应对海量数据存储
7. 微服务：按业务拆分应用，解决团队协作与代码维护问题

这个过程不是严格的线性进化，实际项目中完全根据业务发展节奏来选择。核心逻辑只有一个：用最低的成本，满足当前的业务需求。

---

三. Redis 核心特性与应用场景

理解了分布式系统的大背景，我们再回头看 Redis，就会明白它的每一个特性，都是为分布式场景设计的。

3.1 Redis 核心特性

Redis 是一款基于内存的键值型中间件，它能成为分布式系统的标配，离不开这几个核心特性：

1. 内存存储，丰富的键值结构 和 MySQL 的关系型表结构不同，Redis 以键值对的形式组织数据，数据全部驻留内存，这是它高性能的根本。它内置了多种数据结构，能灵活应对各种业务场景。

2. 可编程性 Redis 支持 Lua 脚本，可以把多个命令打包成一个脚本批量执行，既可以实现简单业务逻辑，也能保证操作的原子性，在很多场景下非常实用。

3. 可扩展能力 Redis 提供了模块扩展 API，开发者可以用 C、C++、Rust 等语言编写扩展模块，给 Redis 增加自定义的数据结构和命令，灵活性非常高。

4. 持久化机制 内存数据是易失的，进程退出、服务器重启都会导致数据丢失。Redis 提供了持久化机制，可以把内存数据异步备份到硬盘，服务重启时重新加载恢复数据，做到内存为主、硬盘为辅，兼顾速度与数据安全。

5. 集群支持 单台 Redis 的内存容量有限，通过集群模式可以部署多个 Redis 节点，每个节点存储一部分数据，实现水平扩展，对应数据库领域的 "分库分表" 思想。

6. 高可用主从 和数据库的主从架构类似，Redis 也支持主从复制，从节点作为主节点的实时备份。当主节点故障时，从节点可以快速接管服务，实现高可用。

3.2 Redis 为什么这么快？

这是面试中的高频经典题，我们可以从四个核心层面回答：

• 内存存储是根本：数据全部在内存中，访问延迟是纳秒级，远快于磁盘 IO，这是最核心的原因。
• IO 多路复用网络模型：采用 epoll 实现 IO 多路复用，单线程就能管理大量客户端连接，网络 IO 效率极高。
• 单线程核心执行模型：核心命令的执行是单线程的，避免了多线程的锁竞争、上下文切换开销。Redis 的瓶颈从来不在 CPU，而在内存和网络，单线程完全够用。

补充：高版本 Redis 也引入了多线程，但主要用在网络 IO 的收发上，核心的数据操作逻辑依然是单线程。

• 核心逻辑简洁轻量：Redis 的核心操作都是简单的内存数据结构操作，没有复杂的事务解析、约束校验，执行逻辑非常轻量。

至于 "C 语言开发所以快" 的说法，有一定道理但不是核心 ------MySQL 同样是 C 语言开发的，两者的速度差距，主要还是存储介质和架构设计带来的。

3.3 Redis 典型应用场景

Redis 的应用场景非常广泛，最核心、最常见的有这四个：

1. 内存数据库 把 Redis 当做主数据库使用，全量数据都存储在 Redis 中，适合对读写延迟要求极高、数据量不算特别大的场景。缺点是硬件成本高，内存比磁盘贵得多，且数据可靠性保障弱于关系型数据库。

2. 数据缓存 这是 Redis 最主流的应用场景。全量数据存在 MySQL，热点数据缓存到 Redis，大幅降低数据库压力，提升系统响应速度。遵循二八原则，用很小的成本，换取大部分请求的性能提升。

3. 分布式会话存储（Session） 在分布式应用集群中，用户的请求可能被分发到不同的应用服务器。如果 Session 存储在应用服务器本地，就会出现登录状态丢失的问题。

行业内有两种主流解决方案：

• 让负载均衡器基于用户 ID 做粘性，同一个用户的请求始终分发到同一台机器；
• 把 Session 统一存储在 Redis 中，所有应用服务器都从 Redis 读取会话数据。

第二种方案更通用，是分布式系统的标准做法，且应用服务器重启不会丢失会话数据。

4. 轻量消息队列 Redis 的 Stream 数据类型可以实现消息队列功能，支持高吞吐数据写入、消息消费、事件通知等，本质是网络版的生产者消费者模型。

它的优势是轻量，不需要额外引入专业 MQ 组件；但功能完整性和可靠性不如 RabbitMQ、Kafka 这类专业消息队列。适合对消息队列依赖不高、不想增加技术栈的轻量场景。

3.4 一个务实的思考

很多初学者会问：单机系统里，我直接用 HashMap 存数据不行吗？为什么要用 Redis？

答案很现实：

• 直接操作 HashMap 是纯内存访问，速度一定比 "网络请求 + Redis 内存读写" 更快；
• 但 HashMap 的数据和应用进程深度绑定，应用重启数据就丢失了，且无法共享给其他服务、其他主机。

Redis 的核心价值，在于数据的独立存储、跨进程跨主机共享，以及未来向分布式架构平滑扩展的能力。技术选型没有绝对的对错，只看是否匹配当下的业务需求。

---

四. Redis 环境搭建实战

理论讲完，我们进入实战环节，一步步完成 Redis 的环境搭建。Redis 官方并不原生支持 Windows，微软维护有 Windows 分支，但生产环境统一使用 Linux。

本次我们安装 Redis 5.x 版本，相对更简单稳定，适合入门学习；后续学到集群相关内容时，再使用 Docker 部署。

4.1 Ubuntu 系统安装 Redis5

Ubuntu 下安装非常简单，通过 apt 包管理器即可完成。

1. 切换到 root 用户

su root

1. 搜索 redis 软件包

apt search redis

1. 安装 redis 服务

apt install redis-server

1. 查看服务端口 安装完成后，Redis 默认会自动启动，通过 netstat 可以查看监听状态：

netstat -anp | grep redis

默认会监听 127.0.0.1:6379，绑定本地环回地址意味着默认只能本机客户端访问，跨主机无法连接。后续需要远程访问的话，可以修改配置文件调整绑定地址。

1. 配置文件说明 Redis 的所有定制化配置都在配置文件中，Ubuntu 下默认路径为 /etc/redis/redis.conf。后续修改端口、密码、持久化等配置，都在这个文件中操作。
2. 重启服务 修改配置后，需要重启服务才能生效：

service redis-server restart

1. 客户端连接验证 Redis 自带命令行客户端 redis-cli，直接输入即可连接本地服务：

redis-cli

进入交互界面后，输入 ping，如果返回 PONG，说明连接成功。

127.0.0.1:6379> ping
PONG

按 Ctrl + D 可以退出客户端。

4.2 CentOS 系统安装 Redis5

CentOS 不同版本的安装方式有区别：

• CentOS 8：yum 源默认就是 Redis5，直接安装即可

yum install redis

• CentOS 7：yum 源默认是 Redis 3.2，版本较老，需要通过软件集安装 Redis5。

# 安装软件集源
yum install centos-release-scl-rh

# 安装Redis5
yum install rh-redis5-redis

通过这种方式安装的 Redis，文件会分布在多个系统目录下，比如配置文件在 /opt/rh/rh-redis5/register.content/etc/opt/rh/rh-redis5/redis.conf，可执行文件在对应 bin 目录下。如果觉得查找麻烦，可以创建符号链接简化路径：

ln -s 源路径 目标路径

另外还需要在配置文件中做两个基础配置：

1. 开启守护进程模式（后台运行）：

daemonize yes

开启后 Redis 会以后台进程运行，不会随着终端关闭而停止。

1. 设置工作目录 先创建数据目录：

mkdir -p /var/lib/redis

再在配置文件中指定：

dir /var/lib/redis

这个目录用于存放 Redis 的持久化文件等数据。

配置完成后启动服务，同样用 redis-cli 连接验证即可。停止服务可以直接 kill 进程，或者使用系统服务管理命令。

4.3 Redis 客户端的三种形态

Redis 是典型的客户端 - 服务器架构，服务器负责存储和管理数据，客户端主要有三种形态：

1. 命令行客户端 redis-cli Redis 自带的命令行工具，是我们学习、调试、线上排查问题最常用的工具，也是入门阶段的重点。
2. 图形化客户端 包括桌面程序、Web 管理界面等，可视化操作更直观。但实际工作中，生产服务器通常有严格的网络限制，办公电脑的图形化工具往往无法直接连接线上 Redis，实际使用率并不高。
3. 编程 API 客户端 这是工作中最主流的形态。各种编程语言都有对应的 Redis 客户端 SDK，比如 Java 的 Jedis、C++ 的 hiredis 等，我们通过 API 在代码中操作 Redis，就像 JDBC 操作 MySQL 一样。后续我们会专门讲解编程开发相关的内容。
   
   
   

核心考点总结

最后我们把本文的核心知识点做个梳理，也是面试中的高频考点：

1. 分布式架构演进：能完整说出从单机到微服务的 7 个阶段，每个阶段解决的问题、以及引入的新问题。
2. 缓存设计思想：冷热分离、二八原则的核心逻辑，以及缓存带来的数据一致性问题。
3. Redis 高性能的原因：内存存储、IO 多路复用、单线程模型、轻量核心逻辑，四个核心点要能讲清楚区别与联系。
4. Redis 核心特性：持久化、集群、高可用主从、可编程、可扩展五大特性。
5. Redis 应用场景：数据缓存、分布式会话、内存数据库、轻量消息队列，以及各自的适用场景与局限性。
6. 分布式评价指标：可用性、响应时长、吞吐与并发的定义与区别。
7. 环境搭建要点：默认端口 6379、配置文件的作用、守护进程模式、客户端验证方式。

结尾：

🍓 我是草莓熊 Lotso！若这篇技术干货帮你打通了学习中的卡点：
👀 【关注】跟我一起深耕技术领域，从基础到进阶，见证每一次成长
❤️ 【点赞】让优质内容被更多人看见，让知识传递更有力量
⭐ 【收藏】把核心知识点、实战技巧存好，需要时直接查、随时用
💬 【评论】分享你的经验或疑问（比如曾踩过的技术坑？），一起交流避坑
🗳️ 【投票】用你的选择助力社区内容方向，告诉大家哪个技术点最该重点拆解
技术之路难免有困惑，但同行的人会让前进更有方向～愿我们都能在自己专注的领域里，一步步靠近心中的技术目标！

结语：本文顺着技术发展的逻辑，从分布式系统的演进讲起，带你理解了 Redis 诞生的背景与定位，拆解了它的核心特性与应用场景，最后完成了 Linux 环境下的安装与验证。这只是 Redis 学习的第一步。接下来我们会深入 Redis 的五大数据结构、持久化机制、过期策略与淘汰机制、主从复制与集群等核心内容，一步步吃透 Redis 的底层原理与实战技巧。

✨把这些内容吃透超牛的！放松下吧✨ ʕ˘ᴥ˘ʔ づきらど