五分钟学Redis系列<一>-Redis入门指南

原创

五分钟学SRE

修改于 2024-08-12 11:35:23

2220

文章被收录于专栏：五分钟学SRE

Redis（Remote Dictionary Server）是一个开源的高性能键值对数据库，它支持多种数据结构，如字符串、列表、集合、有序集合等，并提供丰富的操作命令。Redis的数据是存储在内存中的，这使得它具有极高的读写速度，适用于缓存、高速数据处理等场景。此外，Redis支持数据持久化，可以通过快照（RDB）和追加日志（AOF）两种方式将内存中的数据保存到磁盘，以防止数据丢失。Redis还提供了主从复制、哨兵模式和集群等高可用性解决方案，以保障服务的稳定性和扩展性.

Redis的数据类型

Redis提供了多种数据类型，每种类型都有其特定的应用场景：

String：最基本的数据类型，可以存储字符串、整数或浮点数，最大可达512MB。
List：有序集合，可以存储字符串元素，支持双向遍历和索引操作。
Set：无序集合，存储唯一的字符串元素，支持集合运算。
Hash：键值对的集合，适合存储结构化数据。
Zset（有序集合）：与集合类似，但每个元素都有一个分数，可以根据分数进行排序。
Bitmap：用于存储位集合，可以进行位操作。
HyperLogLog：用于近似计算唯一值的数量，适用于基数统计。
Geospatial：用于存储地理位置信息。
Streams：用于消息队列和日志存储，支持消息的持久化和时间排序

Redis IO模型概述

Redis的IO模型是构建在单线程架构之上的，这使得它避免了多线程环境下常见的并发问题，如锁竞争和线程上下文切换。然而，单线程设计也带来了一个问题：如何有效处理大量并发连接？Redis通过以下方式解决了这一问题：

事件驱动：Redis采用事件驱动模型来处理IO操作，这意味着只有在IO操作准备好时（如数据到达或发送完成），才会执行相应的操作。
非阻塞IO：Redis的IO操作是非阻塞的，它使用非阻塞IO多路复用技术来同时监控多个套接字。

Redis的“单线程”真相

许多人认为Redis是单线程的，这主要是因为其核心的网络IO和键值对读写操作是由单一线程处理的。然而，Redis的持久化、异步删除和集群同步等功能实际上是由其他线程完成的。因此，将Redis称为单线程，更多是一种简化的说法，它实际上是一种高效的多线程设计。

Redis为何选择单线程？

在多线程的世界里，增加线程数似乎总能带来性能的提升。但Redis却选择了另一条路。多线程虽然能提升并发处理能力，却也带来了同步和资源竞争的复杂性。Redis的单线程设计，让我们避免了这些难题，让开发和维护变得更加直接和高效。

单线程Redis的速度秘诀

Redis之所以能够以单线程实现高速性能，得益于以下几个关键因素：

内存操作：大部分操作直接在内存中完成，减少了I/O延迟。
优化的数据结构：使用高效的数据结构，如哈希表和跳表，加速了数据存取。
多路复用技术：利用Linux的epoll等技术，单线程也能并发处理大量网络请求。

深入探索多路复用

多路复用技术是Redis的另一个超能力。它允许Redis在单线程中同时监听多个套接字，当数据到达时，内核会触发事件并将其放入队列，Redis线程随后处理这些事件。这种方式不仅避免了CPU资源的浪费，还确保了对请求的快速响应。

Redis 6.0 多线程模型的改进

Redis 6.0引入了多线程模型，这是相对于之前版本的一个重要改进。在Redis 6.0之前的版本中，即使存在后台线程用于执行如unlink删除大key、RDB持久化等任务，但执行用户命令的请求部分仍然是单线程模型。这意味着在处理大量网络I/O操作时，Redis的性能受到限制。

Redis 6.0的多线程模型主要用于网络数据的读写和协议解析，而不是执行命令本身。这样的设计允许Redis更好地利用多核处理器，提高在高并发环境下的性能，尤其是在处理大量网络I/O操作时。执行命令的线程仍然是单线程的，这避免了多线程数据竞争的问题，保持了命令执行的效率和一致性.

在Redis 6.0中，多线程的启用是可配置的，用户可以通过调整配置项 io-threads 来指定多线程的数量，默认情况下多线程功能是关闭的。此外，Redis 6.0还提供了 io-threads-do-reads 配置项，用于决定是否让IO线程参与读取操作，从而进一步提高网络处理的并发能力.

持久化策略：AOF与RDB的双保险

Redis提供了两种持久化策略：AOF（Append Only File）和RDB（Redis DataBase）快照，以确保数据的持久性和在系统重启或故障后能够恢复数据。

AOF日志

Redis提供了两种持久化策略：AOF（Append Only File）日志和RDB（Redis DataBase）快照。

AOF（Append Only File）是Redis提供的一种持久化机制，它通过记录所有对数据库的写操作命令，将这些命令以日志的形式追加到一个文件中，从而实现数据的持久化存储。与Redis的另一种持久化方式RDB（Redis DataBase）相比，AOF在数据恢复的完整性上具有明显的优势，因为它能够通过重放日志中的所有写操作命令来恢复数据，理论上可以保证数据不丢失。

AOF提供了三种不同的同步策略，用于控制数据从内存写入到AOF文件的时机，这三种策略分别是：

即时同步（everysec）：这是AOF的默认同步策略，它意味着Redis每秒会将缓冲区中的数据同步到磁盘上的AOF文件一次。这种方式在保证数据安全性的同时，也考虑到了写磁盘操作带来的性能影响，是一种较为平衡的策略。
每秒同步（always）：这种策略要求每次写操作后立即同步到AOF文件，虽然可以最大限度地保证数据的持久性，但是频繁的磁盘I/O操作会显著降低Redis的写入性能。
背景同步（no）：这种策略完全依赖于操作系统的写回策略，Redis不会主动将数据写入磁盘，而是由操作系统在合适的时机进行写回。这种策略提供了最高的写入性能，但是数据的安全性最差，一旦服务器断电，可能会丢失大量的数据。

用户可以根据实际的应用场景和需求，在这三种同步策略之间进行选择，以达到数据安全性和写入性能的最佳平衡。

此外，AOF文件在达到一定大小时，Redis会自动进行重写，以压缩文件体积，移除过期或被覆盖的命令，从而提高读取效率和节省磁盘空间。AOF重写不会影响Redis的正常运行，因为Redis会同时维护旧的AOF文件和新的临时AOF文件，直到新的AOF文件重写完成，才会替换旧的AOF文件。这种机制确保了数据的完整性和服务的连续性。

深入理解RDB快照

内存快照，作为数据持久化的一种策略，其核心理念是在特定时间点捕获内存中的数据状态，类似于摄影中捕捉瞬间的场景。在数据存储领域，尤其是对于像Redis这样的内存数据库，这一概念尤为重要，因为它确保了即使在意外宕机或硬件故障的情况下，数据也能得以保存和恢复。

RDB文件与数据恢复

RDB（Redis Database）文件是Redis用于实现内存快照的机制。它通过将内存中的数据状态以二进制格式保存为文件，为数据提供了一个持久化的存储点。与AOF（Append Only File）日志记录所有操作命令的策略不同，RDB文件记录的是数据的某一特定状态。这意味着在恢复数据时，只需要加载RDB文件，即可快速重建内存中的数据状态，提供了一种高效的数据恢复手段。

快照生成的命令与策略

Redis提供了两种生成RDB文件的命令：

SAVE：在主线程中执行，会阻塞Redis服务，等待快照完成。这种命令在生产环境中很少使用，因为它会显著影响Redis的性能。
BGSAVE：创建一个子进程来执行快照生成，避免了对主线程的影响，是生产环境中推荐使用的快照命令。

为了在快照生成期间允许数据修改，同时保持数据的一致性，Redis引入了写时复制（Copy-On-Write, COW）技术。当子进程进行快照生成时，如果主线程需要修改数据，它会先复制一份数据副本，然后在副本上进行修改，而子进程继续使用原始数据生成RDB文件。这样既保证了快照的完整性，又允许了Redis在快照过程中继续处理客户端请求。

快照频率与混合持久化策略

快照的频率直接影响数据安全与系统性能。频率过低，可能导致宕机时丢失大量数据；频率过高，则会增加磁盘I/O负担和系统资源消耗。Redis 4.0引入的混合使用AOF日志和RDB快照的持久化策略，为这一问题提供了解决方案。通过结合RDB的快速恢复能力和AOF的细粒度数据记录，可以在两次RDB快照之间使用AOF记录所有数据修改，而在快照生成时清空AOF日志，因为此时所有修改都已包含在新的RDB文件中。

RDB快照与AOF日志的互补优势

RDB快照与AOF日志作为Redis的两大持久化策略，各自拥有独特的优势。AOF日志通过记录所有写操作，提供了更高级别的数据安全性和完整性，但文件体积较大，恢复速度较慢。相比之下，RDB快照恢复速度快，文件体积小，但数据安全性稍弱。

在实际应用中，结合使用RDB快照与AOF日志能够åç实现数据持久化与快速恢复的最佳实践。定期生成RDB快照作为全量备份，同时启用AOF日志捕捉实时写操作，以保证数据的完整性与最新状态。在服务器重启时，优先使用AOF文件进行恢复，而RDB快照则作为数据迁移或灾难恢复的辅助手段，确保数据的安全与服务的连续性。