Redis - 1 ( 11000 字 Redis 入门级教程 )

一：服务端高并发分布式结构演进之路

1.1 常见概念

1.2 评价指标

1.3 架构演进

1.3.1 单机架构

在初期阶段，我们可以依靠精干的技术团队快速将业务系统投入市场以进行验证，并灵活应对变化需求。由于前期用户访问量较小，对系统性能和安全性要求不高，且架构简单，无需专业运维团队，因此选择单机架构是一个合理的决定。当用户在浏览器中输入 www.bit.com 时，首先通过 DNS 服务将域名解析为 IP 地址 10.102.41.1，随后浏览器会访问该 IP 对应的应用服务。

1.3.2 应用数据分离架构

随着系统上线，我们如预期般取得了成功，吸引了一批忠实用户，系统访问量逐步上升，逐渐逼近硬件资源的极限。同时，团队在此过程中积累了丰富的业务流程经验。面对当前的性能压力，我们需要未雨绸缪，通过系统重构和架构优化来提升系统的承载能力。由于预算有限，我们选择以最小代价提升性能的方法，将应用和数据分离。与之前的架构相比，主要区别在于将数据库服务独立部署在同一数据中心的其他服务器上，应用服务通过网络访问数据库，从而提高了系统的承载能力。

1.3.3 应用服务集群架构

随着系统的广受欢迎，爆款产品的出现使单台应用服务器无法满足需求。单机架构的应用服务器首先遇到了性能瓶颈，技术团队面临两种解决方案，并围绕各方案的优劣展开了热烈讨论。

经过团队的学习、调研和讨论，我们最终选择了水平扩展方案来解决问题，但这需要引入一个新的组件——负载均衡。负载均衡的作用是解决用户流量如何分发到不同应用服务器的问题，它是一个专门用于流量分发的系统组件。在实际应用中，负载均衡不仅工作在应用层，也可能涉及网络层。同时，流量调度的算法种类繁多，这里简单介绍几种常见的算法。

1.3.4 读写分离 / 主从分离架构

在将用户请求通过负载均衡分发到不同的应用服务器后，系统可以并行处理请求，并通过动态扩展服务器数量来缓解压力。然而，在当前架构下，无论扩展多少台应用服务器，这些请求最终都需要从数据库进行读写操作。随着业务增长，数据库的压力逐渐成为系统承载能力的瓶颈。与应用服务器不同，数据库由于其特殊性无法简单地通过横向扩展来解决问题。原因在于，数据分散到多台服务器后，无法保证数据的一致性。数据的一致性是指在同一系统中，无论何时何地，用户看到的数据都应保持统一。例如，在银行的转账系统中，如果一笔转账的金额在一台数据库中被修改，而另一台数据库中未修改，用户看到的账户金额将是错误的。

为了解决这一问题，我们采用主从架构的方式。系统中保留一个主数据库处理写操作，而其他数据库作为从数据库，只负责从主库同步数据并处理读请求。从库通过数据同步机制维持与主库一致的状态。这样，所有写操作由主库承担，而读操作则分散到多个从库，从而分担数据库的压力。由于大多数系统中读写请求的比例极不均衡，例如100次读对应1次写，因此通过将读请求分散到各个从库，数据库的整体压力显著降低。当然，这种架构也有一定的代价，即主库到从库的数据同步存在时间成本，但这一问题暂时不在讨论范围内。

1.3.5 引入缓存 ⸺ 冷热分离架构

随着访问量的持续增加，我们发现业务中有一部分数据的读取频率远高于其他数据，这部分被称为热点数据，而其余为冷数据。针对热点数据，为了提升读取响应时间，我们引入本地缓存和分布式缓存机制。例如，缓存热门商品信息或热门商品的 HTML 页面。通过缓存，可以在数据库读写前拦截绝大多数请求，从而大幅降低数据库的压力。具体技术包括使用 Memcached 作为本地缓存，Redis 作为分布式缓存，同时需要解决缓存一致性、缓存穿透、缓存击穿、缓存雪崩以及热点数据集中失效等问题。

1.3.6 垂直分库

随着业务数据量的不断增加，将大量数据存储在同一个数据库中已显得力不从心，因此可以根据业务需求对数据进行分库分表。例如，对于评论数据，可以按照商品ID进行哈希路由到对应的表中存储；对于支付记录，可以按小时创建表，并进一步拆分为小表，通过用户ID或记录编号来路由数据。这样，只要实时操作的表数据量足够小，并且请求能够均匀分发到多台服务器上的小表，就能通过水平扩展的方式提升数据库性能。其中，像 Mycat 这样的工具可以支持在大表拆分为小表情况下的访问控制。然而，这种方法显著增加了数据库运维的难度，对DBA提出了更高的要求。

当数据库设计发展到这种结构时，可以称为分布式数据库。尽管它在逻辑上是一个整体，但其不同部分由独立的组件实现。例如，分库分表的管理和请求分发由 Mycat 实现，SQL 的解析依赖单机数据库，读写分离可能由网关和消息队列完成，查询结果的汇总则由数据库接口层处理。这种架构是一类大规模并行处理（MPP）架构的实现方式，能够在高并发和大数据量的场景中发挥显著优势。

1.3.7 业务拆分 ⸺ 微服务

随着人员的增加和业务的发展，我们将业务拆分给不同的开发团队维护。每个团队独立实现自己的微服务，并通过隔离数据的直接访问来降低耦合性。团队之间的服务调用可以通过 Gateway、消息总线等技术实现关联。此外，一些通用功能，如用户管理、安全管理、数据采集等业务，也可以提取为公共服务，供各团队共享使用，从而提高整体开发效率和系统灵活性。

二： Redis

2.1 Redis 简介

Redis 是一种基于键值对（key-value）的 NoSQL 数据库，与其他键值对数据库不同，Redis 的值可以是多种数据结构和算法的组合，如字符串（string）、哈希（hash）、列表（list）、集合（set）、有序集合（zset）、位图（Bitmaps）、HyperLogLog 和地理信息定位（GEO）等，因此能够满足多种应用场景。Redis 将所有数据存储在内存中，具备极高的读写性能，同时通过快照和日志的方式将数据持久化到硬盘上，保证在断电或机器故障等情况下数据不会丢失。此外，Redis 还提供了键过期、发布订阅、事务、流水线、Lua 脚本等功能，灵活强大。在合适的场景中，Redis 如同一把功能丰富的瑞士军刀，发挥出强大的作用。

2.2 Redis 的特性

2.2.1 速度快

正常情况下 Redis 执行命令的速度非常快，根据官方数据，读写性能可以达到每秒 10 万次。当然，这也与机器性能有关，但这里暂不讨论硬件差异，仅从以下四个方面分析 Redis 高速性能的原因：

2.2.2 基于键值对的数据结构服务器

几乎所有编程语言都提供类似字典的数据结构，例如 C++ 的 map、Java 的 map、Python 的 dict 等，这种以键值对方式组织数据的方式在开发中非常常见。而 Redis 不同于普通的键值对数据库，除了支持字符串作为值，还支持多种复杂的数据结构，这不仅方便应对多种应用场景，还能显著提高开发效率。Redis 的全称是 Remote Dictionary Server，主要提供五种数据结构：字符串（string）、哈希（hash）、列表（list）、集合（set）和有序集合（ordered set/zset）。此外，在字符串基础上，衍生出了位图（Bitmaps）和 HyperLogLog 等特殊数据结构，并在 Redis 3.2 版本中增加了 GEO（地理信息定位）功能，以支持 LBS（基于位置服务）的开发。在这些强大数据结构的帮助下，开发者可以构建出更多“有趣”和实用的应用。

2.2.3 丰富的功能

除了 5 种数据结构，Redis 还提供了许多额外的功能：

2.2.4 简单稳定

Redis 的简单性主要体现在以下三个方面：首先，Redis 的源码非常精简，早期版本只有约 2 万行代码，3.0 版本后由于增加了集群功能，代码量也仅增至约 5 万行，相较于许多 NoSQL 数据库，代码量要少得多，这使得开发和运维人员完全可以深入理解其源码。其次，Redis 使用单线程模型，这不仅让服务端的处理模型更简单，同时也简化了客户端开发。最后，Redis 不依赖操作系统的外部类库（例如 Memcached 依赖 libevent），而是自行实现了事件处理的相关功能。尽管 Redis 设计简单，但其稳定性极高，在大量使用场景中，因 Redis 自身 BUG 导致宕机的情况非常少见。

2.2.5 客户端语言多

Redis 提供了简单的 TCP 通信协议，使得许多编程语言可以轻松接入。同时，Redis 因受到社区和各大公司的广泛认可，支持它的客户端语言也非常丰富，几乎涵盖了所有主流编程语言，如 C、C++、Java、PHP、Python、NodeJS 等。后续将对 Redis 的客户端使用进行详细说明。

2.2.6 持久化

通常情况下，将数据存放在内存中存在一定风险，一旦断电或机器故障，重要数据可能会丢失。为了解决这一问题，Redis 提供了两种持久化方式：RDB 和 AOF。这两种策略可以将内存中的数据保存到硬盘，从而保障数据的持久性。后续将对 Redis 的持久化机制进行详细说明。

2.2.7 主从复制

Redis 提供了复制功能，可以创建多个数据完全相同的 Redis 副本（Replica），这也是实现分布式 Redis 的基础。后续将对 Redis 的复制功能进行详细演示。

2.2.8 高可用和分布式

Redis 提供了高可用的实现方式，如 Redis 哨兵（Redis Sentinel），用于故障检测和自动故障转移。同时，Redis 还支持 Redis 集群（Redis Cluster），实现真正的分布式架构，具备高可用性、读写扩展性和容量扩展能力。

2.3 Redis 的应用场景

2.4 Redis 重要文件及作用

Redis 的安装过程就跳过了，我们直接讲 Redis 中重要文件的作用

2.5 Redis 命令行客户端

现在我们已经启动了 Redis 服务，接下来介绍如何使用 redis-cli 来连接和操作 Redis 服务。redis-cli 提供了两种方式连接 Redis 服务器，具体如下。

1. 交互方式：

[root@host ~]# redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set key hello
OK
127.0.0.1:6379> get key
"hello"

2. 命令方式：

[root@host ~]# redis-cli -h 127.0.0.1 -p 6379 ping
PONG
[root@host ~]# redis-cli -h 127.0.0.1 -p 6379 set key hello
OK
[root@host ~]# redis-cli -h 127.0.0.1 -p 6379 get key
"hello"

三： 预备知识

3.1 KEYS pattern

KEYS pattern 返回匹配指定 pattern 的所有键。

MSET firstname Jack lastname Stuntman age 35
"OK"

KEYS *name*
1) "firstname"
2) "lastname"

KEYS a??
1) "age"

KEYS *
1) "age"
2) "firstname"
3) "lastname"

3.2 EXISTS

EXISTS 用于判断一个或多个 key 是否存在，返回存在的 key 的数量。

redis> SET key1 "Hello"
"OK"

redis> EXISTS key1
(integer) 1

redis> EXISTS nosuchkey
(integer) 0

redis> SET key2 "World"
"OK"

redis> EXISTS key1 key2 nosuchkey
(integer) 2

3.3 DEL

DEL 命令用于删除一个或多个 key，返回值为成功删除的 key 的数量。

redis> SET key1 "Hello"
"OK"

redis> SET key2 "World"
"OK"

redis> DEL key1 key2 key3
(integer) 2

3.4 EXPIRE

EXPIRE 命令为指定的 key 添加秒级的过期时间。如果设置成功返回值为 1；如果设置失败返回值为 0，因为 key 可能不存在，所以导致设置失败。

redis> SET mykey "Hello"
"OK"

redis> EXPIRE mykey 10
(integer) 1

redis> TTL mykey
(integer) 10

3.5 TTL

TTL 用于获取指定 key 以秒为单位的剩余过期时间。返回值为剩余的过期时间；如果返回 -1 表示该 key 没有设置过期时间，返回 -2 表示该 key 不存在。

redis> SET mykey "Hello"
"OK"

redis> EXPIRE mykey 10
(integer) 1

redis> TTL mykey
(integer) 10

3.6 TYPE

TYPE 命令用于返回指定 key 的数据类型，可能的返回值包括：none（key 不存在）、string（字符串）、list（列表）、set（集合）、zset（有序集合）、hash（哈希）和 stream（流）。

redis> SET key1 "value"
"OK"

redis> LPUSH key2 "value"
(integer) 1

redis> SADD key3 "value"
(integer) 1

redis> TYPE key1
"string"

redis> TYPE key2
"list"

redis> TYPE key3
"set"

3.7 Redis 数据结构和内部编码

Redis 提供多种数据结构，包括 string（字符串）、list（列表）、hash（哈希）、set（集合）和 zset（有序集合），这些是对外暴露的基本数据类型。实际上，Redis 针对每种数据结构都有多种底层内部编码实现，并会根据具体场景自动选择最适合的内部编码，以优化性能和存储效率。

可以看到每种数据结构通常都有两种或以上的内部编码实现，例如 list 数据结构包含 linkedlist 和 ziplist 两种编码。同时，一些内部编码（如 ziplist）可以被多种数据结构共用作为其内部实现。具体的内部编码可以通过执行 object encoding 命令进行查询。

127.0.0.1:6379> set hello world
OK

127.0.0.1:6379> lpush mylist a b c
(integer) 3

127.0.0.1:6379> object encoding hello
"embstr"

127.0.0.1:6379> object encoding mylist
"quicklist"

可以看出，键 hello 的值采用了 embstr 编码，而键 mylist 的值则使用了 ziplist 编码。Redis 的这种设计带来了两个重要优势：

3.8 单线程架构

Redis 采用单线程架构来实现高性能的内存数据库服务。下面通过多个客户端命令调用的示例，说明 Redis 单线程的命令处理机制；接着分析其单线程模型为何能够实现如此高的性能；最后解释为什么理解单线程模型是使用和运维 Redis 的关键。首先我们开启三个 redis-cli 客户端同时执行命令

1. 客⼾端 1 设置⼀个字符串键值对：

127.0.0.1:6379> set hello world

2. 客⼾端 2 对 counter 做⾃增操作：

127.0.0.1:6379> incr counter

3. 客⼾端 2 对 counter 做⾃增操作：

127.0.0.1:6379> incr counter

Redis 客户端发送的命令经历了发送命令、执行命令、返回结果三个阶段，其中重点在于命令的执行过程。Redis 的单线程模型指的是：尽管从宏观上看，多个客户端似乎同时向 Redis 发送命令，但从微观角度来看，这些命令是以线性方式逐条执行的。虽然命令的执行顺序可能不确定，但一定不会有两条命令同时被执行。可以将 Redis 想象成只有一个服务窗口，多个客户端按照到达的先后顺序排队接受服务。例如，两条 incr 命令无论执行顺序如何，结果一定是正确的，不会发生并发问题，这就是 Redis 单线程执行模型的核心特点。

通常情况下，单线程的处理能力往往不如多线程。例如，运输 10,000 公斤货物，如果每辆车一次只能运载 200 公斤，需要 50 次才能完成；但如果有 50 辆车合理分工，只需一次即可完成任务。然而，Redis 使用单线程模型仍然能够实现每秒万级别的处理能力，这主要归结于以下三点原因。

虽然单线程为 Redis 带来了许多优势，但也存在一个致命的问题：对单个命令的执行时间有严格要求。如果某个命令执行时间过长，其他命令将被阻塞在等待队列中，无法及时响应，从而导致客户端阻塞。这对 Redis 这样的高性能服务来说是非常严重的。因此，Redis 更适用于需要快速执行的场景。