“The open-source, in-memory data store used by millions of developers as a cache, vector database, document database, streaming engine, and message broker.”

这句介绍语翻译过来就是：开源的内存数据存储，被数百万开发人员用作缓存、矢量数据库、文档数据库、流引擎和消息代理。

分析官方对Redis的介绍，我不太理解的第一个地方在于——Redis的主要功能既然是在内存存储数据，但是我们平时定义变量不就是在内存中存储数据吗，为什么还需要Redis？

这是因为，在单机系统中，确实可以直接通过定义变量来存储数据，并且这种方式在某些情况下可能是更简单、更高效的选择。但是，在分布式系统中，情况就会变得更加复杂。

分布式系统中的各个节点之间需要共享数据，并且需要保证数据的一致性、可靠性和高可用性。而直接通过定义变量来存储数据在分布式系统中是行不通的，因为每个节点都有自己的内存空间，无法直接共享变量。

这时候就需要像 Redis 这样的分布式数据存储系统。Redis 提供了分布式特性，可以在多个节点之间共享数据，并且提供了数据持久化、高可用性、数据结构丰富等功能，使得在分布式系统中存储和管理数据变得更加可靠和高效。

因此，在分布式系统中，Redis 是一种非常合适的选择，可以作为缓存、数据库、消息队列等多种用途的数据存储和处理引擎。

既然提到分布式网络，那么必然会涉及到进程。在现代操作系统中，进程之间是相互隔离的，它们有自己独立的内存空间和运行环境。这种隔离性意味着一个进程无法直接访问另一个进程的内存空间，因此要想实现进程之间的数据共享或通信，就需要借助进程间通信（Inter-Process Communication，IPC）的手段。网络作为进程间通信的手段：在分布式系统中，进程通常分布在不同的主机上，因此不能简单地依靠进程间的直接通信。相反，需要通过网络来实现进程之间的通信和数据交换。这就涉及到了网络通信技术，包括 TCP/IP 协议栈等。

Redis 作为一个基于网络的分布式数据存储系统，提供了一种可靠、高效的方式，让不同的进程或主机之间可以通过网络连接到 Redis 服务器，并进行数据的读取、写入和处理。Redis 可以将自己内存中的数据提供给其他进程使用，甚至是在不同的主机上的进程。这使得 Redis 成为一个非常适合在分布式系统中实现数据共享和通信的工具。

所以Redis 利用网络作为进程间通信的手段，为分布式系统提供了一种高效、可靠的数据共享和通信方案，帮助不同的进程或主机之间实现数据的共享和协同处理。

那么我们为什么需要把Redis当作数据库呢？我们不是已经有了MySQL等等这些数据库了？

将 Redis 视为数据库的主要原因之一是其出色的性能。Redis将数据存储在内存中，并且由于其内存中的操作速度非常快，因此可以实现非常低延迟的读写操作。相比之下，传统的磁盘数据库（如 MySQL）需要在磁盘上进行读写操作，其速度较慢。

在某些应用场景下，对于需要快速读写和响应的数据，如缓存、会话存储、实时分析等，Redis的高速度和低延迟使其成为更好的选择。

然而，Redis也有一些局限性，其中包括存储空间有限和持久化方面的限制。由于 Redis 将数据存储在内存中，因此受到可用内存的限制。而且，虽然 Redis 可以通过将数据持久化到磁盘来防止数据丢失，但其持久化方案相对简单，与传统的数据库相比，可靠性和灵活性较低。

因此，虽然 Redis 在速度和低延迟方面表现出色，但它不适用于所有的数据库用例。在需要更大存储容量、更丰富功能和更复杂数据模型的情况下，传统的关系型数据库（如 MySQL）可能更为合适。综合考虑业务需求和数据库特性，选择合适的数据库解决方案至关重要。

那么有没有存储空间又大，性能又好的方案？

将 Redis 和 MySQL 结合起来使用是最典型的方案，其实也就是 cache。

常用数据可以存储在 Redis 中，利用其快速读写的特性，以提高系统的响应速度。而全量数据则可以存储在 MySQL 或其他磁盘数据库中，以满足数据存储量大的需求。通过这种方式，可以实现系统在性能和存储空间之间的平衡。

当然，将 Redis 和 MySQL 结合使用也会带来一些挑战和复杂性。其中最主要的挑战是数据同步的问题。因为数据存储在两个不同的地方，当数据发生修改时，需要确保 Redis 中的数据和 MySQL 中的数据保持同步，否则可能会导致数据不一致的问题。为了解决这个问题，可以采用一些数据同步的方案，如定期同步、使用消息队列等。

此外，由于涉及到两种不同类型的数据库，系统的复杂度也会增加。需要考虑到数据的存储、读写、同步等方面的问题，以及如何处理两种不同数据库的错误和异常情况。

综合来说，将 Redis 和 MySQL 结合起来使用可以在一定程度上解决存储空间大、性能好的需求，但我们也需要权衡其带来的复杂性和挑战。所以我们在实际应用中需要仔细评估业务需求和技术能力，选择最合适的方案。

盛赞Redis

Redis是一种基于键值对（key-value）的NoSQL数据库，与许多其他键值对数据库不同之处在于，Redis中的值可以采用多种数据结构和算法组成，包括字符串、哈希、列表、集合、有序集合、位图、HyperLogLog、地理信息定位等。因此，Redis可以满足许多不同的应用场景。由于Redis将所有数据存储在内存中，因此具有出色的读写性能。此外，Redis还可以通过快照和日志的形式将内存中的数据保存到硬盘上，以防止数据丢失，这对于处理类似断电或机器故障的情况至关重要。除了上述功能外，Redis还提供了诸如键过期、发布订阅、事务、流水线、Lua脚本等附加功能。

2008年，Redis的作者Salvatore Sanfilippo在开发名为LLOOGG的网站时，需要实现一个高性能的队列功能。最初他尝试使用MySQL来实现，但发现无论如何优化SQL语句都无法提高网站的性能。于是他决定自己开发一款专属于LLOOGG的数据库，这就是Redis的前身。随后，Salvatore Sanfilippo将Redis 1.0的源代码发布到GitHub上，其后Redis迅速走红。

虽然可以开玩笑说“还有谁不使用Redis”，但根据Redis官方公司的统计数据显示，许多重量级公司都在使用Redis。国外知名公司如Twitter、Instagram、Stack Overflow、GitHub等，国内则有新浪微博、阿里巴巴、腾讯、搜狐、优酷土豆、美团、小米、唯品会等公司。此外，许多开源技术如ELK等都将Redis作为其重要组件之一，并且Redis提供了模块系统，允许第三方开发人员实现功能扩展，进一步提高了Redis的灵活性和可扩展性。因此，熟练使用和管理Redis已成为开发和运维人员的必备技能之一。

Redis 特性

Redis 之所以受到如此多公司的青睐，必然有之过人之处，接下来我们谈谈关于 Redis 的几个重要特性。

速度快

Redis执行命令的速度非常快，在正常情况下，可以达到每秒10万次的读写性能。这样的速度主要得益于以下几个方面的因素：

数据存放在内存中：Redis将所有数据存放在内存中，而内存的读写速度远远快于磁盘存储。根据Google在2009年给出的数据，内存的读写速度是硬盘的数百倍甚至数千倍。因此，将数据存储在内存中是Redis速度快的最主要原因之一。
采用C语言实现：Redis使用C语言实现，通常来说，C语言实现的程序与操作系统之间的接口更为紧密，执行速度相对会更快。
单线程架构：Redis采用单线程架构，避免了多线程可能产生的竞争和同步问题。虽然在6.0版本中引入了多线程机制，但主要是用于处理网络和IO，数据命令的执行仍然采用单线程模式。这种简单而高效的设计使得Redis能够更好地利用CPU资源，提高了系统的响应速度。多线程提高效率的前提时CPU密集型的任务，使用多个线程可以充分的利用CPU多核资源。但是Redis的核心任务主要就是操作内存的数据结构，不会吃很多CPU。
核心功能简单：Redis主要围绕着一些基本的操作内存的数据结构展开操作，这些数据结构设计简洁清晰，易于理解和使用。
持久化策略的选择：Redis提供了多种持久化策略，包括RDB快照和AOF日志，用户可以根据自身需求选择合适的持久化方式。对于读密集型的场景，可以选择较轻量级的RDB快照方式，减少持久化对性能的影响。
优化的数据结构和算法：Redis在设计和实现过程中充分考虑了数据结构和算法的优化，采用了一些高效的数据结构（如哈希表、跳表等）和算法（如快速查找算法、排序算法等），以提高数据操作的效率和速度。
缓存机制：Redis可以作为缓存中间件使用，通过缓存热门数据可以减少对后端存储系统的访问，从而提高系统整体的响应速度。缓存命中率高的情况下，可以大大加快数据访问的速度。
异步操作：Redis支持异步操作，例如异步持久化和异步复制，这些操作不会阻塞主线程的执行，从而提高了系统的并发能力和响应速度。
网络通信机制和使用了IO多路复用的方式（epoll）：

高效的网络通信：
- TCP协议： Redis采用TCP/IP协议进行网络通信。TCP协议是一种可靠的、面向连接的传输层协议，它提供了数据的可靠传输、流量控制、拥塞控制等功能，适用于对数据传输有较高要求的场景。通过使用TCP协议，Redis能够保证数据的可靠性和稳定性。
- 异步非阻塞IO： Redis使用异步非阻塞IO模型进行网络通信。在传统的同步阻塞IO模型中，每个连接都需要一个线程来处理，当连接数量较多时，会导致系统资源消耗过大。而采用异步非阻塞IO模型，可以利用少量的线程处理大量的连接，提高系统的并发处理能力和资源利用率。
- 事件驱动模型： Redis基于事件驱动模型进行网络通信。通过监听和处理事件，当有数据到达时立即进行处理，而不是等待数据准备好后才进行处理。这样可以最大程度地减少系统的等待时间，提高了系统的响应速度和吞吐量。
  
  IO多路复用的方式（epoll）：
  - epoll是Linux内核的一个I/O事件通知机制，用于提高I/O性能。
  - 与传统的select和poll相比，epoll具有更高的性能和扩展性，适用于处理大量的并发连接。
  - epoll通过在内核中维护一个事件表来管理文件描述符（FD），当某个FD上有事件发生时，内核会通知应用程序进行相应的处理。
  - epoll的优点之一是支持水平触发和边缘触发两种工作模式，水平触发表示只要FD上有数据可读或可写就会通知，边缘触发表示只有当FD上的状态发生变化时才会通知，可以避免因为重复通知而导致的性能损耗。
  - epoll还支持使用epoll_wait系统调用进行阻塞等待事件，或者使用epoll_ctl系统调用动态地添加、删除、修改事件。
    
    通过使用高效的网络通信机制和IO多路复用的方式，Redis能够充分利用系统资源，提高了系统的吞吐量和并发能力，从而更好地处理客户端的请求，保证了系统的稳定性和性能。
优雅的代码设计：Redis的源代码经过作者精心打磨，被一些人评价为少有的集性能和优雅于一身的开源代码。作者在设计和实现Redis时考虑了各种性能和效率问题，尽可能地优化了代码结构和算法，使得Redis具备了出色的性能和稳定性。

综上，Redis之所以能够拥有如此快速的读写性能，是因为它充分利用了内存的优势，采用了高效的单线程架构，并且在设计和实现上追求了代码的优雅和简洁。这使得Redis成为了众多应用场景下的首选解决方案之一。

谷歌公司给出的各层级硬件执行速度：

考虑一个场景：一个单机系统，其中的应用程序要用键值对的格式来存储一些数据。我们是用一个redis来存还是直接在内存中搞一个Hash Map来存储呢？

使用 Hash Map 是直接通过操作内存进行存储；使用redis是先通过网络，再操作内存。

上述场景中是否要使用redis存储数据还是要结合我们的实际的需求来确定。虽然引入redis会导致性能下降，但是有了redis就可以把数据单独存储，后续应用服务器重启，不会影响到数据内容。而且未来我们可能需要把单机系统扩展成分布式系统，所以使用redis是更佳的选择？

请注意，我们必须明确一点：Redis的"速度快"是相对于关系型数据库如MySQL等的。这意味着在某些场景下，Redis的性能可能会优于传统的关系型数据库。但是，我们也必须认识到，这种性能优势是有条件的。

如果是直接和内存中的操作变量进行比较，redis就没有任何优势了。

所以在考虑使用Redis之前，我们必须仔细权衡各种因素。例如，如果应用程序需要频繁地读写内存中的变量，那么直接使用内存中的数据结构，如Hash Map，可能会比使用Redis更加高效。因为直接操作内存可以避免通过网络进行数据传输，从而提高了数据访问的速度和效率。

然而，当我们需要一个持久化的数据存储方案，并且希望数据在应用服务器重启后不丢失时，引入Redis就变得更加合适了。尽管使用Redis会导致性能略微下降，但这种牺牲是值得的，因为我们可以确保数据的持久性和可靠性。此外，如果将来我们计划将单机系统扩展成分布式系统，那么使用Redis就是一个更好的选择，因为Redis具有分布式特性，可以轻松地扩展到多个节点上。

因此，我们在决定是否引入一项技术时，必须针对具体情况做出评估和分析。我们必须清楚地了解问题的来龙去脉，考虑未来的发展需求，并根据实际情况做出明智的决策。盲目地使用某项技术是不可取的，我们必须根据实际需求和场景来选择合适的解决方案。

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

几乎所有的编程语言都提供了类似字典的功能，例如C++中的map、Java中的map、Python中的dict等。这种组织数据的方式被称为基于键值对的方式，即通过键来唯一标识数据，并通过键来访问对应的值（非关系数据库的存储组织数据的方式，关系型数据库则是通过表）。与许多键值对数据库不同的是，Redis 中的值不仅可以是简单的字符串，还可以是各种复杂的数据结构，如哈希、列表、集合、有序集合等（key都是String）。这样的设计不仅方便了在许多应用场景中的开发，同时也提高了开发效率。

Redis 的全称是 REmote Dictionary Server，它主要提供了 5 种基本数据结构：字符串（string）、哈希（hash）、列表（list）、集合（set）、有序集合（ordered set / zset）。此外，Redis 还在字符串的基础之上演变出了位图（Bitmaps）和 HyperLogLog 等特殊的数据结构。随着基于位置服务（Location Based Service，LBS）的不断发展，Redis 3.2 版本还加入了关于地理信息定位（GEO）的功能。总之，在这些多样的数据结构的帮助下，开发者可以创造出各种有趣和复杂的应用。

Redis 的这种设计使得它不仅仅是一个简单的键值对数据库，而是一个功能丰富、灵活多样的数据结构服务器。它为开发者提供了丰富的工具和选择，可以根据具体的应用场景来选择合适的数据结构，从而更加高效地构建应用程序。无论是存储简单的键值对数据还是复杂的数据结构，Redis 都能够提供快速、高效的存储和访问，成为众多开发者的首选之一。

丰富的功能

除了提供了 5 种基本数据结构之外，Redis 还提供了许多额外的功能，使其成为一个功能强大的数据存储和处理引擎：

键过期功能：Redis 提供了键过期功能，允许设置键的过期时间，当键到期时会自动删除。这个功能常被用来实现缓存，可以有效地管理缓存数据的生命周期，节省内存空间。
发布订阅功能：Redis 支持发布与订阅功能，允许客户端订阅一个或多个频道，并接收对应频道的消息发布。这个功能常被用来实现消息系统，使得不同模块之间可以进行消息的发布和订阅，实现解耦和异步通信。
Lua 脚本功能：Redis 支持 Lua 脚本功能，允许用户编写 Lua 脚本来执行一系列 Redis 命令。这样的功能使得用户可以根据具体业务需求编写复杂的逻辑，扩展 Redis 的功能，提高数据处理的灵活性和效率。
简单的事务功能：Redis 提供了简单的事务功能，允许一组命令按顺序执行，保证了事务的原子性。虽然 Redis 的事务功能相对简单，但可以在一定程度上保证事务特性，适用于一些简单的业务场景。
流水线（Pipeline）功能：Redis 提供了流水线功能，允许客户端将一批命令一次性传输到 Redis，然后批量执行，减少了网络通信的开销。这样可以大大提高多个命令的执行效率，尤其是在需要批量操作数据的情况下，极大地提升了性能。

总之，Redis 不仅提供了丰富多样的数据结构，还提供了许多额外的功能，如键过期、发布订阅、Lua 脚本、事务、流水线等，使其成为一个强大而灵活的数据存储和处理引擎，适用于各种不同的应用场景。针对Redis的操作，我们都可以直接通过简单的交互式命令进行操作，也可以通过脚本的一些方式批量执行一些操作，甚至可以带有一定的逻辑。

简单稳定

Redis的简单性体现在几个方面。首先，Redis的源代码相对较少。早期版本的代码仅有大约2万行左右，即使在添加了集群特性后，到了3.0版本，代码量也只增加到了大约5万行左右。相比许多NoSQL数据库而言，Redis的代码量要少得多。这意味着普通的开发和运维人员完全可以轻松地理解和掌握它。其次，Redis采用单线程模型，这不仅使得Redis服务器端的处理模型变得简单，也使得客户端的开发变得更加简单。最后，Redis不需要依赖于操作系统中的类库（例如，Memcache需要依赖libevent等系统类库），而是自己实现了事件处理的相关功能。

与简单相对应的是Redis具有相当的稳定性。在大量的使用过程中，很少出现因为Redis自身BUG而导致宕机的情况。这种稳定性使得Redis成为许多企业和开发团队首选的数据存储解决方案之一。

客户端语言多

Redis提供了简单的TCP通信协议，这使得许多编程语言可以轻松地与Redis进行通信。由于Redis受到了广泛的社区和行业认可，因此支持Redis的客户端语言也非常丰富。几乎涵盖了主流的编程语言，例如C、C++、Java、PHP、Python、Node.js等等。每种语言都有相应的Redis客户端库，使得开发者可以在自己熟悉的编程环境中方便地使用Redis，从而更加轻松地构建各种类型的应用程序。

这种多语言支持为开发者提供了更大的灵活性和选择余地，无论是在构建Web应用、移动应用、实时数据处理系统还是其他类型的应用中，都可以方便地集成Redis，并充分发挥其强大的功能和性能。在接下来的说明中，我们将详细介绍Redis客户端在不同编程语言中的使用方法，以及如何最大程度地利用Redis来满足各种应用场景的需求。

可扩展性

Redis提供了一系列API，允许开发者通过C、C++、Rust等语言编写扩展，这些扩展本质上是动态链接库（DLL，在Windows上，或者.so在Linux上）。这些扩展可以包含特定功能的实现，然后可以被Redis服务器加载并动态链接到Redis进程中。通过这种方式，开发者可以利用不同语言编写扩展，以满足特定需求或增加新功能，从而扩展了Redis的能力和灵活性。这些扩展可以包括新的数据类型、命令、功能等，使得Redis能够更好地适应各种不同的使用场景和需求。

在Windows上，动态链接库的扩展通常以.dll文件的形式存在，这些文件可以被应用程序（如Redis服务器）动态加载和链接，使得应用程序可以调用其中包含的代码。

在Linux上，动态链接库的扩展通常以.so文件的形式存在，其工作原理与Windows上的.dll文件相似，都是通过动态链接的方式使得应用程序能够调用其中的函数或方法。

持久化（Persistence）

一般情况下，将数据存储在内存中是不安全的。一旦发生断电或者机器故障，重要的数据可能会丢失。因此，Redis提供了两种持久化方式：RDB和AOF。这两种策略可以将内存中的数据保存到硬盘中，如下图所示。

Redis 内存到硬盘的持久化：

通过这样的方式，Redis保证了数据的可持久性，即使在发生意外情况时也能保持数据的完整性和一致性。

RDB（Redis DataBase）持久化方式会在指定的时间间隔内生成一个数据快照（snapshot），并将其保存到磁盘上的一个文件中。这个快照文件包含了Redis在生成快照时的所有数据，因此可以完整地恢复Redis的数据状态。RDB持久化方式适合用于备份数据或者进行灾难恢复。
AOF（Append Only File）持久化方式会将每次写操作（如set、incr等）都记录到一个追加日志文件中。这个日志文件记录了Redis服务器接收到的所有写命令，可以用来重放这些写操作，从而恢复数据。AOF持久化方式通常比RDB持久化方式更安全，因为它可以提供更精确的恢复点，但相对而言，AOF文件可能会比较大。

通过RDB和AOF两种持久化方式，Redis可以满足不同需求的持久化方案，并在发生意外情况时保护数据的安全性。

简单来说就是Redis会将数据异步地写入硬盘上的持久化文件中，通常是通过RDB快照或AOF日志的方式。这样即使Redis服务器重启，也可以通过加载硬盘上的备份数据来恢复内存中的数据，确保数据不会丢失，系统能够在重启后恢复到之前的状态。因此，硬盘可以看作是对内存中数据的一种备份存储，提供了数据的持久性保障。

在后面的说明中，我们也会对Redis的持久化机制进行详细的介绍和说明，以帮助大家选择适合自己应用场景的持久化策略。

主从复制（Replication）

Redis提供了复制（replication）功能，使得可以创建多个相同数据的Redis副本（replica），如下图所示。复制功能是分布式Redis的基础，通过复制功能，可以实现数据的备份、负载均衡和故障恢复等功能。主从复制的工作原理是将一个Redis服务器的数据复制到其他的Redis服务器上，这样即使主服务器发生故障，从服务器仍然可以继续提供服务。

主服务器（master）负责接收写操作，而从服务器（slave）则负责接收主服务器的写操作，并将这些写操作同步到自己的数据副本中。主从服务器之间通过TCP连接进行通信，主服务器将写操作通过网络发送给从服务器，从服务器则根据主服务器的写操作进行相应的数据更新。

通过主从复制功能，可以实现数据的备份和冗余，提高了系统的可用性和容错性。当主服务器发生故障或者需要升级维护时，可以快速切换到从服务器上，从而保证了系统的持续稳定运行。

在接下来的说明中，我们将详细演示Redis的复制功能，包括如何配置主从服务器、如何监控复制状态以及如何处理复制中的常见问题，以帮助用户充分利用Redis的复制功能来构建高可用、高可靠的分布式系统。

Redis 主从复制架构：

高可用（High Availability）和分布式（Distributed）【支持集群】

Redis作为一个分布式系统中的中间件，支持集群是非常关键的。集群能够提供水平扩展的能力，类似于传统关系型数据库中的"分库分表"，通过引入多个主机并在其上部署多个Redis节点，可以有效地扩展Redis的存储容量和处理能力。在Redis集群中，每个节点负责存储部分数据，并处理部分请求。通过在多个节点上分散存储数据，可以减轻单个节点的负载压力，并提高整个系统的并发处理能力和容错性。当需要增加存储容量或处理能力时，可以简单地通过添加新的节点来实现水平扩展，而无需对现有节点进行修改或升级。

Redis集群通常采用分片（sharding）的方式来实现数据的分布式存储和负载均衡，将数据按照某种规则（如哈希算法）分散到不同的节点上。同时，Redis集群还提供了一致性哈希（Consistent Hashing）等机制，以确保在节点动态增减或出现故障时，数据的分布仍然能够保持相对稳定，从而保证了系统的可靠性和可用性。

通过支持集群，Redis能够实现分布式存储和处理，满足大规模应用的存储需求，并提供高可用性、可扩展性和性能的保证。

结合上方“支持集群”的特性还有“主从复制”特性，再做一个总结：

Redis提供了高可用和分布式方面的解决方案，以满足不同场景下的需求。

高可用（High Availability）：Redis Sentinel（Redis哨兵）是用于实现高可用的解决方案。Redis Sentinel能够监控Redis节点的运行状况，一旦发现某个节点出现故障，就会自动将故障节点从服务中移除，并从剩余的可用节点中选举出新的主节点，从而保证了系统的持续可用性。Redis Sentinel还支持自动故障恢复和自动故障转移，可以在不需要人工干预的情况下保证系统的稳定运行。
分布式（Distributed）：Redis Cluster（Redis集群）是用于实现分布式的解决方案。Redis Cluster采用分布式哈希槽（hash slot）的方式，将数据分散存储在多个节点上，从而提高了系统的扩展性和容错性。Redis Cluster不仅可以提供高可用性，还能够实现读写分离和容量的水平扩展。当集群中的某个节点出现故障时，集群会自动将故障节点从服务中移除，并将该节点上的数据迁移到其他可用节点上，从而保证了系统的持续稳定运行。

通过Redis Sentinel和Redis Cluster这两种解决方案，Redis能够满足不同场景下的高可用和分布式需求，为用户提供了稳定可靠的数据存储解决方案。在接下来的说明中，我们将详细介绍Redis Sentinel和Redis Cluster的配置和使用方法，以帮助用户搭建高可用、分布式的Redis集群，并充分发挥其强大的功能和性能。

Redis 使用场景

我们已经了解了 Redis 的特性，接下来我们来看⼀下 Redis 的典型应用场景有哪些。

但是要想充分理解 Redis 的作⽤，需要大家对网站的架构有一定的基础理解，考虑到大家可能缺少这方面的背景知识，建议先移步我的上一篇博客——服务端高并发分布式结构演进之路：服务端高并发分布式结构演进之路（概述、常见概念和评价指标、架构演进：【单机架构、应用数据分离架构、应用服务集群架构、读写分离 / 主从分离架构、引入缓存⸺冷热分离架构、垂直分库、业务拆分】）-CSDN博客

在对该领域的基础知识进行学习后我们继续。

适用场景：

当作数据库使用：
实时数据存储： Redis的多功能内存数据结构能够为需要低延迟和高吞吐量的实时应用程序构建数据基础设施。由于Redis将数据存储在内存中，并且提供了高效的数据访问方式，使得它非常适合用作实时数据存储。例如，在实时分析、实时计算、实时推荐等场景下，需要快速地处理大量实时数据，而Redis能够满足这种需求。
缓存层：
高速缓存： Redis常被用作高速缓存，用于存储频繁访问的数据，如页面片段、数据库查询结果、API调用结果等。通过将数据缓存在Redis中，可以减少数据库或其他后端服务的压力，提高系统的响应速度和吞吐量。特别是对于需要频繁读取但不经常变化的数据，如热门商品信息、用户会话信息等，使用Redis作为缓存层可以显著提升系统性能。
消息队列：
轻量级消息队列： Redis的发布订阅（Pub/Sub）功能和列表数据结构常被用于构建轻量级消息队列系统。通过发布者向频道发布消息，订阅者订阅相应的频道并接收消息，实现了简单而高效的消息通信机制。这种方式适用于需要快速、实时地传递消息的场景，如实时通知、事件驱动等。
会话存储：
会话管理： Redis可以用作会话存储，用于存储用户会话信息、登录状态等数据。由于Redis的高速读写能力和支持过期时间设置的特性，使得它成为了一个理想的会话存储解决方案。通过将会话数据存储在Redis中，可以实现会话的快速访问和管理，同时保证了会话数据的持久性和安全性。
计数器和排行榜：
实时计数器和排行榜： Redis的原子操作和有序集合数据结构常被用于构建实时计数器和排行榜功能。例如，可以利用Redis的INCR命令实现实时计数器，用于统计网站的访问量、文章的点赞数等；而有序集合则可以用于存储用户的积分、商品的销量等数据，并实时更新和排名，实现了高效的排行榜功能。

总的来说，Redis适用于需要低延迟、高吞吐量和实时性的应用场景，尤其适用于互联网应用、实时数据分析、实时推荐、实时通信等领域。通过充分利用Redis的特性和功能，可以构建出高效、稳定的数据基础设施，为应用程序提供更好的性能和用户体验。

我们再补充得详细一些。

Redis 可以做什么

缓存（Cache）：

缓存（Cache）在大型网站和应用中发挥着至关重要的作用。它是一种存储数据的临时性介质，通常用于存储频繁访问的数据，以便快速检索和提供给用户。通过缓存，可以加快页面加载速度，减轻后端数据源（如数据库）的负载压力，提高系统的响应速度和整体性能。

在缓存选择方面，Redis 是一种备受推崇的高性能内存数据库，特别适合作为缓存层。Redis 提供了多种数据结构（如字符串、哈希、列表、集合、有序集合等）和灵活的过期策略，使其成为缓存的理想选择。通过将常用的数据缓存到 Redis 中，可以大大减少对后端数据源的访问次数，从而降低数据库的负载压力，提高系统的整体性能和稳定性。

Redis 的特点和优势使其成为了缓存层的首选，包括：

高性能：Redis 将数据存储在内存中，并且采用了高效的数据结构和算法，使得其具有出色的读写性能和响应速度。
丰富的数据结构：Redis 支持多种数据结构，可以根据不同的应用场景选择最合适的数据结构，如字符串、哈希、列表、集合、有序集合等。
灵活的过期策略：Redis 提供了灵活的过期策略，可以设置键的过期时间，以确保缓存数据的及时更新和释放，避免数据过期造成的问题。
持久化支持：Redis 提供了持久化功能，可以将内存中的数据定期保存到磁盘上，保证数据的持久性和安全性。
集群支持：Redis 支持集群模式，可以通过搭建 Redis 集群来实现数据的水平扩展和高可用性。

Redis 作为一种高性能的内存数据库，具有丰富的数据结构和灵活的过期策略，使其成为缓存层的理想选择，能够显著提升系统的性能和用户体验。
排行榜系统：

排行榜系统在社交网站、电商平台等场景中非常常见，用于根据某种规则或指标对数据进行排名和排序，以展示热门内容或热销商品等信息。Redis 的有序集合（Sorted Set）数据结构非常适合构建排行榜系统。

通过将用户行为数据（如点赞数、浏览量、销售额等）存储在有序集合中，可以实现数据的自动排序，并利用 Redis 提供的排序功能，可以方便地实现各种类型的排行榜。例如，可以根据点赞数或浏览量来排序，展示热门文章或热销商品；也可以根据销售额来排序，展示畅销产品或热门服务。

由于 Redis 的有序集合支持插入、删除、查找和范围查询等操作，并且具有高效的排序功能，因此可以快速地实现排行榜的更新和查询。同时，Redis 的持久化功能和集群模式也保证了排行榜数据的持久性和高可用性，即使在系统重启或发生故障时，也能够保留排行榜数据并确保系统正常运行。

Redis 的有序集合数据结构和排序功能为构建排行榜系统提供了强大的支持，能够满足各种排行榜应用场景的需求，为用户提供精准、实时的排行信息
计数器应用：

计数器应用通常用于统计用户行为、资源访问量等数据，以支持数据分析和个性化推荐等业务需求。Redis 的原子操作和高性能特性使其成为构建计数器应用的理想选择。

例如，可以利用 Redis 的 INCRBY 命令实现对某个键的自增操作，快速记录用户的点击次数、观看次数等信息。通过将计数数据存储在 Redis 中，可以高效地进行数据累加和统计，而 Redis 的原子操作保证了计数操作的线程安全性，避免了并发访问可能带来的数据不一致性问题。

此外，Redis 还提供了过期时间设置和持久化功能，确保计数数据的可靠性和一致性。通过设置计数键的过期时间，可以自动清理过期的计数数据，避免数据存储过多导致内存占用过高。同时，通过 Redis 的持久化机制，可以将计数数据持久化到磁盘上，即使系统重启或发生故障，也能够保证计数数据的安全性和可恢复性。

综合而言，Redis 提供了高效、可靠的计数器功能，可以满足各种计数应用场景的需求，包括用户行为统计、资源访问量统计等。
社交网络：社交网络应用通常需要处理大量的用户关系数据，包括好友关系、粉丝关系、私信等。Redis 的数据结构和操作命令提供了良好的支持，使其成为开发社交网络应用的理想选择。

例如，可以利用 Redis 的集合（Set）数据结构存储用户的好友列表。每个用户的好友列表可以存储在一个集合中，通过 Redis 提供的集合操作，如添加、删除、查询等，可以方便地管理用户之间的好友关系。

另外，可以使用有序集合（Sorted Set）存储用户的粉丝列表。有序集合中的成员是用户ID，分数是关注时间或其他权重值，通过有序集合的特性可以实现对粉丝列表的排序和范围查询，从而方便地进行粉丝关系的管理和查询。
通过利用 Redis 提供的交集、并集等集合操作，可以高效地进行社交关系的查询和统计，比如查找共同好友、共同关注的用户等。

此外，Redis 还提供了发布订阅（Pub/Sub）功能，可以用于实现实时消息推送和事件通知等功能。社交网络应用中常见的实时消息推送功能，如新粉丝提醒、私信通知等，可以借助 Redis 的发布订阅功能轻松实现，从而提升用户体验和互动性。
Session存储：Redis作为会话存储解决方案，以其高速的读写能力、支持过期时间设置、持久性和安全性等特性，为Web应用程序提供了可靠的会话管理服务。通过将会话数据存储在Redis中，应用程序可以实现快速的数据访问和管理，并有效地管理会话的生命周期。Redis的分布式特性还能够保证数据的可靠性和可用性，为应用程序提供稳定、高效的会话存储解决方案。

现在，我们考虑如何解决“每次交给同一台服务器负责同一个用户的登录操作”的问题：

① 想办法让负载均衡器把同一个用户的请求始终打到同一个机器上，不能够使用轮询的方式，而是要通过userID之类的方式分配机器。

② 把会话数据单独拎出来放到另一组独立的机器上存储，即REDIS，即使应用程序重启，会话也不会丢失。这通常可以通过以下几种方式解决：

粘性会话（Sticky Session）： 在负载均衡器上配置粘性会话，也称为会话持久性或会话保持。这会使负载均衡器将特定用户的所有请求都路由到同一台服务器上，确保用户会话在同一服务器上保持一致。这种方法通常基于用户的 IP 地址或会话 cookie 进行识别，以便负载均衡器可以将请求路由到正确的服务器。

会话复制（Session Replication）： 将会话数据复制到所有服务器或特定集群节点上。这样，无论用户请求被路由到哪个服务器，都可以访问到相同的会话数据。然而，这种方法可能会增加系统的复杂性和网络开销，并且可能会导致一致性和同步问题。

外部会话存储（External Session Storage）： 将会话数据存储在独立的外部存储系统中，如 Redis、Memcached 或专用的会话存储服务。这些存储系统通常具有高速读写能力和持久性保证，可以确保会话数据的可靠性和一致性。通过将会话数据与应用程序的状态分离，可以使应用程序更易于扩展和管理。

在以上方法中，使用 Redis 作为外部会话存储是一种常见且可靠的解决方案。通过将会话数据存储在 Redis 中，可以确保会话的快速访问和管理，同时保证了数据的持久性和安全性。即使应用程序重启或用户请求被路由到不同的服务器上，都可以通过 Redis 获取到相同的会话数据，从而提供一致的用户体验。
消息队列系统：

在这里，消息队列是一个服务器，其作用类似于一个中间件，用于连接生产者和消费者，并在它们之间传递消息。基于这个消息队列服务器，可以实现一个网络版本的“生产者-消费者模型”，即通过网络连接的方式将生产者和消费者连接起来，并实现异步消息传递。

生产者是向消息队列中发送消息的应用程序或服务，而消费者则是从消息队列中接收并处理消息的应用程序或服务。通过消息队列，生产者和消费者之间实现了解耦，即它们不需要直接通信，而是通过消息队列进行交互。生产者将消息发送到消息队列，而消费者则从消息队列中获取消息并进行处理，这种异步通信方式可以提高系统的性能和可伸缩性。

通过网络版本的“生产者-消费者模型”，我们可以将生产者和消费者部署在不同的计算机上，甚至是不同的网络中。消息队列服务器充当了消息的中转站，负责接收、存储和转发消息，从而实现了生产者和消费者之间的异步通信。这种模型在分布式系统中具有重要的作用，能够简化系统架构，提高系统的灵活性和可扩展性。

消息队列系统是一种用于实现应用之间解耦和异步通信的重要工具，它在现代软件架构中发挥着关键作用。Redis作为一种轻量级消息队列系统，提供了发布订阅（Pub/Sub）功能和列表数据结构，可用于搭建简单而高效的消息传递机制。

通过Redis的发布订阅功能，生产者可以将消息发布到指定的频道，而消费者则可以订阅感兴趣的频道并接收相应的消息。这种基于频道的发布订阅模型使得消息的传递变得简单直观，同时具有低延迟和高吞吐量的优势。对于任务调度、事件驱动等场景，Redis的消息队列功能能够满足基本的消息传递需求，并且能够在高并发情况下保持稳定可靠的性能表现。

虽然Redis的消息队列功能相对于专业的消息队列系统来说功能较为简单，但对于一般的消息传递场景已经足够使用。其轻量级、易于部署和高性能的特点使得Redis成为构建简单消息队列系统的理想选择，为应用程序提供了可靠的消息传递服务。

Redis 不可以做什么

实际上，和任何一门技术一样，每个技术都有自己的应用场景和边界。也就是说，Redis 并非适用于所有问题，尽管它对于很多情况下都是理想的选择，但也存在一些不适合它解决的问题。我们可以从数据规模和数据热度的角度来进行分析。

从数据规模的角度来看，数据可以分为大规模数据和小规模数据。Redis 将数据存储在内存中，尽管内存的成本已经相对较低，但如果数据量非常巨大，比如每天有数亿的用户行为数据，那么使用 Redis 来存储将会是一个巨大的开销，经济成本相当高。

考虑数据的热度，我们可以将其分为热数据和冷数据。热数据通常是指那些经常被访问和操作的数据，而冷数据则相反。以视频网站为例，视频的基本信息通常在各个业务线中被频繁操作，而用户的观看记录可能并不总是被频繁访问。虽然暂时不考虑数据规模的差异，但单纯从数据热度的角度来看，视频信息属于热数据，而用户的观看记录属于冷数据。如果将这些冷数据存储在 Redis 中，将会对内存资源造成一种浪费。但对于一些热数据，将其存储在 Redis 中可以加速读写操作，同时减轻后端存储的负担，实现事半功倍的效果。

综上，我们可以总结如下：

Redis虽然是一种强大的数据存储和缓存工具，但也存在一些限制和不适用的情况，包括但不限于：

大规模数据存储： Redis的数据存储在内存中，因此对于大规模数据的存储会面临内存成本高昂的问题。当数据量非常大时，如每天数亿的用户行为数据，使用Redis可能会带来巨大的成本压力。
持久化能力有限： Redis支持将数据持久化到磁盘，但其持久化能力相对有限。对于一些对数据持久性要求非常高的场景，如金融交易记录等，可能需要更为可靠的数据持久化解决方案。
复杂的数据结构处理： Redis虽然支持多种数据结构，如字符串、哈希、列表等，但对于一些复杂的数据结构处理，如图形数据、文档存储等，Redis并不是最佳选择。
不适合大型分析工作负载： 对于大规模的数据分析工作负载，特别是需要复杂的查询和聚合操作的情况，Redis并不是最佳选择。相比之下，使用专门的数据分析工具和技术更为合适。
不适合作为主要数据库： 尽管Redis可以用作持久化数据存储，但其主要设计目的是作为缓存和快速访问数据的中间层，而不是作为主要的数据库系统。在需要复杂查询、事务支持等功能的应用场景中，应选择更适合的数据库解决方案。

因此，Redis 并非解决所有问题的银弹。相信随着我们对 Redis 的逐步学习，能够更清晰地认识到 Redis 的真正使用场景。

Redis重大版本（了解即可）

Redis的重大版本号遵循了Linux操作系统的版本命名规则。若版本号的第二位为奇数，则表明该版本为非稳定版本（如2.7、2.9、3.1），而若为偶数，则表示为稳定版本（如2.6、2.8、3.0、3.2）。当前奇数版本通常是下一个稳定版本的开发版本，例如2.9版本是3.0版本的开发版本。因此，在生产环境中，我们通常选择偶数版本的Redis。若想提前了解和使用某些新特性，则可以选择最新的奇数版本。目前，Redis的最新版本是7.0版本。接下来，我将详细介绍Redis发展过程中的一些重要版本及其特性。

Redis 2.6

Redis 2.6于2012年正式发布，相较于Redis 2.4，引入了一系列主要特性，包括：

服务端支持Lua脚本。
删除了虚拟内存相关功能。
放开对客户端连接数的硬编码限制。
键的过期时间支持毫秒级别。
从节点提供只读功能。
引入两个新的位图命令：bitcount和bitop。
增强了redis-benchmark的功能，支持定制化的压测、CSV格式输出等功能。
基于浮点数的自增命令：incrbyfloat和hincrbyfloat。
redis-cli可以使用--eval参数执行Lua脚本。
shutdown命令增强。
Info命令可以按照section输出，并且添加了一些统计项。
重构了大量的核心代码，所有集群相关的代码都被移除，集群功能将在3.0版本中支持。
优化了sort命令。

Redis 2.8

Redis 2.8于2013年正式发布，相较于Redis 2.6，引入了一系列主要特性，包括：

添加部分主从复制的功能，一定程度上降低了由于网络问题造成频繁全量复制导致RDB对系统的压力。
尝试性地支持IPv6。
可以通过config set命令设置maxclients。
可以用bind命令绑定多个IP地址。
Redis设置了明显的进程名，方便使用ps命令查看系统进程。
config rewrite命令可以将config set持久化到Redis配置文件中。
发布订阅功能添加了pubsub命令。
Redis Sentinel第二版，相较于Redis 2.6的Redis Sentinel，此版本已经变得更加适用于生产环境。

Redis 3.0

Redis 3.0于2015年正式发布，相较于Redis 2.8，引入了一系列主要特性，包括：

Redis Cluster：Redis提供的官方分布式实现。
全新的embedded string对象编码结果，优化了小对象内存访问，在特定的工作负载下，下载速度大幅提高。
优化了LRU算法，大幅提升性能。
migrate链接缓存，大幅提升键迁移的速度。
migrate命令新增两个参数：copy和replace。
client pause命令，在指定时间内暂停处理客户端请求。
bitcount命令性能提高。
config set设置maxmemory时能够设置不同的单位（以前只能是字节）。
Redis日志作了调整：日志中会反应当前实例的角色（master或者slave）。
incr命令性能提高。

Redis 3.2

Redis 3.2于2016年正式发布，相较于Redis 3.0，引入了一系列主要特性，包括：

添加了GEO相关功能，支持地理位置数据处理。
对SDS（Simple Dynamic Strings）进行了优化，在速度和空间上都有所提升。
支持使用upstart或者systemd管理Redis进程。
引入了新的List编码类型：quicklist，提高了列表数据的处理效率。
从节点读取过时数据保证一致性。
添加了hstrlen命令，用于获取哈希值中字段的字符串长度。
加强了debug命令，支持了更多的参数。
对Lua脚本功能进行了增强，并引入了Lua Debugger。
config set支持更多的配置参数。
优化了Redis崩溃后的相关报告。
新的RDB格式，但仍然兼容旧的RDB格式。
加速了RDB的加载速度。
spop命令支持个数参数，用于从集合中随机弹出指定数量的元素。
cluster nodes命令获得加速，提高了集群节点信息的获取速度。
更新Jemalloc到4.0.3版本，用于内存分配。

Redis 4.0

Redis 4.0于2017年正式发布，相较于Redis 3.2，引入了一系列主要特性，包括：

提供了模块系统（module），方便第三方开发者拓展Redis的功能，使得Redis更具灵活性和可扩展性。
PSYNC 2.0：优化了以前版本中，主从节点切换必然引发全量复制的问题，提高了主从同步的效率和稳定性。
提供了新的缓存剔除算法：LFU（Last Frequently Used），与LRU算法相比，LFU基于访问次数而不是访问时间，对已有算法进行了优化。
提供了非阻塞del和flushall/flushdb功能，并新增了unlink命令，使得删除操作可以异步执行，提高了系统的响应速度。
提供了memory命令，实现对内存更为全面的监控统计，帮助用户更好地管理内存资源。
提供了交互数据库功能，实现Redis内部数据库的数据置换，提高了数据库的管理和维护效率。
提供了RDB-AOF混合持久化格式，充分利用了AOF和RDB各自的优点，提高了数据持久化的灵活性和可靠性。
Redis Cluster兼容NAT和docker，提高了集群在不同网络环境下的适用性和可部署性。

Redis 5.0

Redis 5.0于2018年正式发布，相较于Redis 4.0，引入了一系列主要特性，包括：

新的流数据类型（stream），为Redis引入了新的数据结构，有助于处理实时数据流。
新的Redis模块API：定时器、集群和字典API，为开发者提供了更多的功能扩展能力。
RDB现在可存储LFU和LRU信息，提高了数据持久化的灵活性和可靠性。
redis-cli中的集群管理器从Ruby（redis-trib.rb）移植到了C语言代码，提高了集群管理的效率和性能。
新的有序集合（sorted set）命令：zpopmin/zpopmax和阻塞变体（blocking variants），增强了有序集合的功能。
升级Active defragmentation至v2版本，提高了内存碎片整理的效率。
增强HyperLogLog的实现，提升了基数估计的准确性和性能。
更好的内存统计报告，帮助用户更好地监控和管理内存资源。
许多包含子命令的命令现在都有一个help子命令，提供了更方便的命令使用文档。
客户端频繁连接和断开连接时，性能表现更好，提升了客户端连接的稳定性和性能。
许多错误修复和其他方面的改进，增强了Redis的稳定性和可靠性。
升级Jemalloc至5.1版本，提升了内存分配的效率。
引入client unblock和client id，为客户端管理提供了更多的控制能力。
新增lolwut命令，用于生成ASCII艺术。
在不存在需要保持向后兼容性的地方，弃用"slave"术语，以更准确、更包容的方式表示从节点。
网络层中的差异优化，提升了网络通信的效率。
增强对Lua的支持：将Lua脚本更好地传播到replicas/AOF，Lua脚本现在可以超时并在副本中进入-BUSY状态，提高了Lua脚本的灵活性和可用性。
引入动态的HZ（Dynamic HZ），以平衡空闲CPU使用率和响应性，提高了系统的响应速度。
对Redis核心代码进行了重构并在许多方面进行了改进，提高了系统的性能和可维护性。

Redis 6.0

Redis 6.0于2020年正式发布，相较于Redis 5.0，引入了一系列主要特性，包括：

引入多线程IO，但多线程部分仅用于处理网络数据的读写和协议解析，命令执行仍然是单线程。
实现了客户端缓存功能（client-side-caching）。放弃了caching slot，而只使用key names。
开始在兼容RESP 2的基础上，支持RESP 3（RESP，Redis Serialization Protocol是Redis服务端与客户端之间通信的协议）。
连接支持SSL，更加安全。
增强ACL权限控制：支持对客户端的权限控制，实现对不同的key授予不同的操作权限，新增一个新的ACL日志命令，允许查看所有违反ACL的客户机、访问不应该访问的命令、访问不应该访问的密钥，或者验证尝试失败。这对于调试ACL问题非常有用。
提升了RDB日志加载速度。
发布官方的Redis集群代理模块Redis Cluster Proxy。
提供了众多的新模块（modules）API。

Redis 7.0

Redis 7.0在2022年正式发布，相较于Redis 6.0，主要特性如下：

将AOF文件的存储方式改为在一个文件夹下存储多个文件。
将持久化文件RDB的版本升级为10，与之前的RDB文件版本不再兼容。
在读取旧的RDB文件格式时将ziplist转换为listpack，这种转换发生于两种情况之下：从磁盘读取文件或者从一个主节点进行复制文件的时候。
在redis.conf配置文件中，默认将protected-mode更改为yes，只有当你希望你的客户端在没有授权的情况下可以连接到Redis server的时候可以将protected-mode设置为no。
在ACL中，pub/sub channel默认是被阻塞的。
在从节点中，TTL的时间标识的是绝对时间，不再是相对时间，从而保证了过期数据被及时删除。
不再支持gopher协议。
当在配置文件中设置replica-serve-stale-data=no时，当主节点不再提供服务时，ping命令得不到返回值。

安装Redis与客户端介绍

在Ubuntu上安装和配置Redis

1、先切换到root用户。

在终端中执行以下命令：sudo su

2、使用apt命令，搜索redis相关的软件包。apt search redis

我们选择这个最全的：

3、执行以下命令安装Redis：apt install redis

安装完成之后我们可以查看一下redis是否已经存在：

redis默认端口号6379（就和tomcat的8080端口一样）

但是我们发现有点小问题，IP是我们的环回IP（127.0.0.1）。如果我们绑定这个IP，就意味着我们以后只能由当前主机上的客户端进行访问，跨主机访问不了。

4、为了支持远程连接，需要我们手动修改配置文件：

修改以下两个配置项：

将 bind 127.0.0.1 修改为 bind 0.0.0.0，以允许来自任何IP地址的连接。
将 protected-mode yes 修改为 protected-mode no，以禁用保护模式，允许远程连接。

保存并退出文件。

具体步骤：

修改 /etc/redis/redis.conf：redis.conf是redis的配置文件，里面包含了redis的相关功能的配置内容。

使用 vim 命令打开redis.conf文件：vim redis.conf

修改两个配置：

修改 bind 127.0.0.1 为 bind 0.0.0.0：

然后我们可以使用vim编辑器进行编辑。我们可以使用键盘上下左右箭头键浏览文件，找到要修改的配置项，并按下i键进入插入模式以编辑文件。完成编辑后，按下Esc键退出插入模式，然后输入:wq并按下回车键保存并退出文件。

修改 protected-mode yes 为 protected-mode no：

5、执行以下命令重启Redis服务以使配置生效：

启动 Redis 服务：service redis-server start

重启 Redis 服务：service redis-server restart

我们可以通过： service redis-server status 来查看是否启动成功：

6、执行以下命令使用Redis自带的客户端连接服务器：redis-cli：

我们可以使用 ping 命令来验证是否连接成功：

退出redis客户端：Ctrl + D

7、执行以下命令停止Redis服务：service redis-server stop

补充说明与表达

在进行任何系统级操作之前，请确保已经了解了所执行操作的含义，并且具有相应的权限。
Redis默认使用端口6379，但也可以在配置文件中自定义。
在修改配置文件之后，确保重启Redis服务以使更改生效。
使用redis-cli工具可以方便地与Redis服务器进行交互，执行命令并查看结果，我们稍后详细介绍。
可以随时通过service redis-server status来检查Redis服务的状态。
在编辑文件时，记得保存并退出，通常是按下Esc键然后输入:wq并回车。
在Ubuntu上，service命令可以用于管理系统服务的启动、停止和重启等操作。

最后需要提醒一点：

在公共网络环境中，经常会受到未经授权的扫描和恶意攻击。为了增强系统的安全性，设置强密码是至关重要的一项措施。一个强大的密码可以有效地防止大多数简单的暴力破解尝试，从而提高系统的安全性。

云服务提供商如阿里云、腾讯云的服务器经常成为攻击目标，一旦遭到扫描，就可能受到恶意软件的感染，例如挖矿病毒。所以为了应对这种威胁，我们的最佳做法是设置一个足够强大的密码。在生产环境中，通常要求密码长度至少为14位以上，并包含大小写字母、数字和特殊符号的组合。这样的密码更加复杂，更难以被破解。

毕竟由于 IP 地址列表和端口列表可以被扫描枚举，因此一个接一个慢慢地进行扫描，总有可能找到漏洞（没设置过密码的redis）。设置强密码可以在一定程度上增加系统的安全性，降低被入侵的风险。因此，确保我们的 Redis 服务器设置了强密码是非常重要的。

要配置 Redis 的密码，我们需要编辑 Redis 的配置文件 redis.conf，并在其中添加或修改以下两个参数：

requirepass：指定 Redis 的密码。
masterauth：如果我们的 Redis 是主从复制模式，并且需要对主节点进行身份验证，则可以使用此参数指定主节点的密码。

在配置文件中找到这两个参数，将它们的值设置为我们想要的密码即可。如果已经找到了这两个参数，只需在其后面添加密码即可。如果没有找到，可以在配置文件的任何位置添加这两个参数，因为它们默认是被注释掉的。

编辑完成后，保存配置文件，并重启 Redis 服务，使更改生效。

客户端介绍

Redis客户端和服务器

Redis是一个开源的基于键值对的内存数据库系统，同时也是一个服务器客户端系统。它既包括了一个高性能的服务器端，用于存储和管理数据，也包括了多种客户端工具和库，用于与服务器进行交互。作为服务器端，Redis负责接收客户端发来的请求，并根据这些请求进行相应的操作，比如存储、检索、更新和删除数据。

Redis客户端和服务器既可以在同一台主机上部署，也可以在不同的主机上进行分布式部署。

Redis客户端负责向Redis服务器发起请求，并接收服务器返回的响应，这些请求和响应通过网络进行传输。

一个Redis服务器还能够同时为多个客户端提供服务，这使得Redis具有很好的并发性和可扩展性。而且多个客户端可以同时连接到同一个Redis服务器，共享所有数据，并进行数据操作。

Redis 客户端与服务端的交互过程：

Redis数据库系统

Redis是一个高性能的开源数据库系统，主要用于存储和管理数据。它支持多种数据结构，如字符串、哈希、列表、集合和有序集合等。

这些数据结构可以应用于各种场景，如缓存、会话存储、消息队列、排行榜等。通过这些丰富的数据结构，Redis可以满足各种不同的需求。

Redis具有数据共享的特性，允许一个客户端访问另一个客户端的数据。这种特性使得Redis成为一个强大的工具，可以用于构建复杂的应用程序和系统。

综上所述，Redis不仅提供了高性能的数据存储和管理功能，还具有很好的并发性和数据共享特性，可以广泛应用于各种不同的应用场景和需求中。

Redis客户端形态

命令行客户端（redis-cli）： Redis自带了一个命令行客户端，可以通过简单的命令行操作进行Redis服务器的连接和数据操作。例如：
- 直接连接默认端口号6379：redis-cli
- 连接其他端口号：redis-cli -h 127.0.0.1 -p 8080
图形化界面客户端：图形化界面的Redis客户端通常以桌面程序或者Web程序的形式存在。虽然功能强大，但在实际工作中很少使用，因为它们通常依赖于Windows系统，而企业环境中的Windows系统可能受到各种限制。
基于Redis API的自行开发客户端：这是工作中最常见的方式。开发者可以利用Redis提供的API开发自定义的客户端，以满足特定需求。类似于MySQL中的C语言API和JDBC，Redis提供了多种语言的API，如Python、Java、Node.js等，开发者可以根据自己的偏好和项目需求选择适合的API进行开发。

通过不同形态的Redis客户端，我们可以灵活地与Redis服务器进行交互和操作，实现数据的存储、检索和处理。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家小花儿/article/detail/697539