草莓熊Lotso个人主页❄️个人专栏:《C知识分享》 《Linux 入门到实践零基础也能懂》✨生活是默默的坚持毅力是永久的享受 博主简介文章目录前言一. 初识 Redis为分布式而生的内存数据库1.1 Redis 的本质定位1.2 经典组合MySQL Redis 冷热分离二. 分布式系统演进之路2.1 起点单机架构2.2 为什么要走向分布式2.3 第一步应用与数据库分离2.4 第二步应用集群与负载均衡2.5 第三步数据库读写分离2.6 第四步引入缓存加速2.7 第五步分库分表应对海量数据2.8 第六步微服务架构拆分2.9 分布式系统核心评价指标2.10 分布式演进小结三. Redis 核心特性与应用场景3.1 Redis 核心特性3.2 Redis 为什么这么快3.3 Redis 典型应用场景3.4 一个务实的思考四. Redis 环境搭建实战4.1 Ubuntu 系统安装 Redis54.2 CentOS 系统安装 Redis54.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 第六步微服务架构拆分当系统复杂到一定程度单体应用的代码会越来越臃肿开发维护、团队协作都会成为瓶颈。这时候就有了微服务架构。微服务的核心是把一个庞大的单体应用按业务功能拆分成多个独立的小服务每个服务只负责单一功能独立部署、独立迭代。微服务本质上解决的是 “人” 的问题。当团队规模大了需要分工协作按业务拆分服务对应到不同的开发团队协作效率会更高。如果只是两三个人的小团队搞微服务反而徒增复杂度。微服务带来的代价也很明显性能下降服务间调用依赖网络通信网络延迟远高于本地函数调用想要弥补性能就得增加更多机器本质就是加钱。系统复杂度升高服务节点变多出现故障的概率变大需要完善的监控报警、运维体系来保障系统可用性。对应的优势也很突出团队分工清晰、功能复用方便、服务可独立部署与扩缩容。2.9 分布式系统核心评价指标衡量一个分布式系统的好坏有三个核心指标可用性Availability系统正常提供服务的时间占总时长的比例常用 “几个 9” 来衡量。比如 4 个 9 就是 99.99% 的可用性对应全年停机时间不到 53 分钟。我们常说的 “高可用HA” 就是对这个指标的追求。响应时长Response Time, RT从用户发起请求到收到响应的时长原则上越小越好具体阈值和业务场景强相关。吞吐Throughput与并发Concurrent吞吐指单位时间内系统成功处理的请求数量并发指系统同一时刻能承载的最高请求量。我们常说的 “高并发”就是对这两个指标的追求。2.10 分布式演进小结我们梳理了从单机到分布式的完整演进路径单机架构应用程序 数据库部署在同一台主机服务分离应用与数据库拆分到不同主机各司其职负载均衡应用服务器做集群负载均衡器分发请求读写分离数据库一主多从主写从读分摊读压力引入缓存冷热分离热点数据缓存加速降低数据库压力分库分表数据库水平拆分应对海量数据存储微服务按业务拆分应用解决团队协作与代码维护问题这个过程不是严格的线性进化实际项目中完全根据业务发展节奏来选择。核心逻辑只有一个用最低的成本满足当前的业务需求。三. 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 系统安装 Redis5Ubuntu 下安装非常简单通过 apt 包管理器即可完成。切换到 root 用户suroot搜索 redis 软件包aptsearch redis安装 redis 服务aptinstallredis-server查看服务端口 安装完成后Redis 默认会自动启动通过 netstat 可以查看监听状态netstat-anp|grepredis默认会监听127.0.0.1:6379绑定本地环回地址意味着默认只能本机客户端访问跨主机无法连接。后续需要远程访问的话可以修改配置文件调整绑定地址。配置文件说明 Redis 的所有定制化配置都在配置文件中Ubuntu 下默认路径为/etc/redis/redis.conf。后续修改端口、密码、持久化等配置都在这个文件中操作。重启服务 修改配置后需要重启服务才能生效serviceredis-server restart客户端连接验证 Redis 自带命令行客户端redis-cli直接输入即可连接本地服务redis-cli进入交互界面后输入ping如果返回PONG说明连接成功。127.0.0.1:6379 ping PONG按Ctrl D可以退出客户端。4.2 CentOS 系统安装 Redis5CentOS 不同版本的安装方式有区别CentOS 8yum 源默认就是 Redis5直接安装即可yuminstallredisCentOS 7yum 源默认是 Redis 3.2版本较老需要通过软件集安装 Redis5。# 安装软件集源yuminstallcentos-release-scl-rh# 安装Redis5yuminstallrh-redis5-redis通过这种方式安装的 Redis文件会分布在多个系统目录下比如配置文件在/opt/rh/rh-redis5/register.content/etc/opt/rh/rh-redis5/redis.conf可执行文件在对应 bin 目录下。如果觉得查找麻烦可以创建符号链接简化路径ln-s源路径 目标路径另外还需要在配置文件中做两个基础配置开启守护进程模式后台运行daemonize yes开启后 Redis 会以后台进程运行不会随着终端关闭而停止。设置工作目录 先创建数据目录mkdir-p/var/lib/redis再在配置文件中指定dir /var/lib/redis这个目录用于存放 Redis 的持久化文件等数据。配置完成后启动服务同样用redis-cli连接验证即可。停止服务可以直接 kill 进程或者使用系统服务管理命令。4.3 Redis 客户端的三种形态Redis 是典型的客户端 - 服务器架构服务器负责存储和管理数据客户端主要有三种形态命令行客户端 redis-cliRedis 自带的命令行工具是我们学习、调试、线上排查问题最常用的工具也是入门阶段的重点。图形化客户端包括桌面程序、Web 管理界面等可视化操作更直观。但实际工作中生产服务器通常有严格的网络限制办公电脑的图形化工具往往无法直接连接线上 Redis实际使用率并不高。编程 API 客户端这是工作中最主流的形态。各种编程语言都有对应的 Redis 客户端 SDK比如 Java 的 Jedis、C 的 hiredis 等我们通过 API 在代码中操作 Redis就像 JDBC 操作 MySQL 一样。后续我们会专门讲解编程开发相关的内容。核心考点总结最后我们把本文的核心知识点做个梳理也是面试中的高频考点分布式架构演进能完整说出从单机到微服务的 7 个阶段每个阶段解决的问题、以及引入的新问题。缓存设计思想冷热分离、二八原则的核心逻辑以及缓存带来的数据一致性问题。Redis 高性能的原因内存存储、IO 多路复用、单线程模型、轻量核心逻辑四个核心点要能讲清楚区别与联系。Redis 核心特性持久化、集群、高可用主从、可编程、可扩展五大特性。Redis 应用场景数据缓存、分布式会话、内存数据库、轻量消息队列以及各自的适用场景与局限性。分布式评价指标可用性、响应时长、吞吐与并发的定义与区别。环境搭建要点默认端口 6379、配置文件的作用、守护进程模式、客户端验证方式。结尾 我是草莓熊 Lotso若这篇技术干货帮你打通了学习中的卡点 【关注】跟我一起深耕技术领域从基础到进阶见证每一次成长 ❤️ 【点赞】让优质内容被更多人看见让知识传递更有力量 ⭐ 【收藏】把核心知识点、实战技巧存好需要时直接查、随时用 【评论】分享你的经验或疑问比如曾踩过的技术坑一起交流避坑 ️ 【投票】用你的选择助力社区内容方向告诉大家哪个技术点最该重点拆解 技术之路难免有困惑但同行的人会让前进更有方向愿我们都能在自己专注的领域里一步步靠近心中的技术目标结语本文顺着技术发展的逻辑从分布式系统的演进讲起带你理解了 Redis 诞生的背景与定位拆解了它的核心特性与应用场景最后完成了 Linux 环境下的安装与验证。这只是 Redis 学习的第一步。接下来我们会深入 Redis 的五大数据结构、持久化机制、过期策略与淘汰机制、主从复制与集群等核心内容一步步吃透 Redis 的底层原理与实战技巧。✨把这些内容吃透超牛的放松下吧✨ʕ˘ᴥ˘ʔづきらど