彻底搞懂Redis的线程模型

最新推荐文章于 2024-10-08 19:41:02 发布
最新推荐文章于 2024-10-08 19:41:02 发布
阅读量2.6w 收藏 172
点赞数 19
分类专栏： 数据库和中间件 Java面试你要知道这些 文章标签： redis 线程模型
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/y277an/article/details/98342442
版权

为了接下来一篇博客，能使读者更加完整地学习线程模型，所以本文对Redis的线程模型进行必要的讲解。

由于《Redis设计与实现》对于Redis的讲解简练优雅，所以本文大部分内容节选自本书，也欢迎对Redis有更多底层了解需求的读者，自行购买学习。

640?wx_fmt=jpeg

文件事件处理器

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

640?wx_fmt=png

消息处理流程

  • 文件事件处理器使用I/O多路复用(multiplexing)程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。

  • 当被监听的套接字准备好执行连接应答(accept)、读取(read)、写入(write)、关闭(close)等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生事件的套接字都推到一个队列里面，然后通过这个队列，以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， I/O多路复用程序才会继续向文件事件分派器传送下一个套接字。

I/O 多路复用程序的实现

Redis的I/O多路复用程序的所有功能是通过包装select、epoll、evport和kqueue这些I/O多路复用函数库来实现的，每个I/O多路复用函数库在Redis源码中都对应一个单独的文件，比如ae_select.c、ae_epoll.c、ae_kqueue.c等。

因为Redis为每个I/O多路复用函数库都实现了相同的API，所以I/O多路复用程序的底层实现是可以互换的，如下图所示。

640?wx_fmt=png

有关epoll的详细讲解，可以点击查看，彻底搞懂epoll高效运行的原理

Redis在I/O多路复用程序的实现源码中用#include宏定义了相应的规则，程序会在编译时自动选择系统中性能最好的I/O多路复用函数库来作为Redis的I/O多路复用程序的底层实现：

/* Include the best multiplexing layer supported by this system.
 * The following should be ordered by performances, descending. */
#ifdef HAVE_EVPORT
#include "ae_evport.c"
#else
    #ifdef HAVE_EPOLL
    #include "ae_epoll.c"
    #else
        #ifdef HAVE_KQUEUE
        #include "ae_kqueue.c"
        #else
        #include "ae_select.c"
        #endif
    #endif
#endif

文件事件的类型

I/O 多路复用程序可以监听多个套接字的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE事件，这两类事件和套接字操作之间的对应关系如下：

  • 当套接字变得可读时（客户端对套接字执行write操作，或者执行close操作），或者有新的可应答（acceptable）套接字出现时（客户端对服务器的监听套接字执行connect操作），套接字产生AE_READABLE 事件。

  • 当套接字变得可写时（客户端对套接字执行read操作），套接字产生AE_WRITABLE事件。I/O多路复用程序允许服务器同时监听套接字的AE_READABLE事件和AE_WRITABLE事件，如果一个套接字同时产生了这两种事件，那么文件事件分派器会优先处理AE_READABLE事件，等到AE_READABLE事件处理完之后，才处理AE_WRITABLE 事件。这也就是说，如果一个套接字又可读又可写的话，那么服务器将先读套接字，后写套接字。

文件事件的处理器

Redis为文件事件编写了多个处理器，这些事件处理器分别用于实现不同的网络通讯需求，常用的处理器如下：

  • 为了对连接服务器的各个客户端进行应答， 服务器要为监听套接字关联连接应答处理器。

  • 为了接收客户端传来的命令请求， 服务器要为客户端套接字关联命令请求处理器。

  • 为了向客户端返回命令的执行结果， 服务器要为客户端套接字关联命令回复处理器。

连接应答处理器

networking.c中acceptTcpHandler函数是Redis的连接应答处理器，这个处理器用于对连接服务器监听套接字的客户端进行应答，具体实现为sys/socket.h/accept函数的包装。

当Redis服务器进行初始化的时候，程序会将这个连接应答处理器和服务器监听套接字的AE_READABLE事件关联起来，当有客户端用sys/socket.h/connect函数连接服务器监听套接字的时候， 套接字就会产生AE_READABLE 事件， 引发连接应答处理器执行， 并执行相应的套接字应答操作，如图所示。

640?wx_fmt=png

命令请求处理器

networking.c中readQueryFromClient函数是Redis的命令请求处理器，这个处理器负责从套接字中读入客户端发送的命令请求内容， 具体实现为unistd.h/read函数的包装。

当一个客户端通过连接应答处理器成功连接到服务器之后， 服务器会将客户端套接字的AE_READABLE事件和命令请求处理器关联起来，当客户端向服务器发送命令请求的时候，套接字就会产生 AE_READABLE事件，引发命令请求处理器执行，并执行相应的套接字读入操作，如图所示。

640?wx_fmt=png

在客户端连接服务器的整个过程中，服务器都会一直为客户端套接字的AE_READABLE事件关联命令请求处理器。

命令回复处理器

networking.c中sendReplyToClient函数是Redis的命令回复处理器，这个处理器负责将服务器执行命令后得到的命令回复通过套接字返回给客户端，具体实现为unistd.h/write函数的包装。

当服务器有命令回复需要传送给客户端的时候，服务器会将客户端套接字的AE_WRITABLE事件和命令回复处理器关联起来，当客户端准备好接收服务器传回的命令回复时，就会产生AE_WRITABLE事件，引发命令回复处理器执行，并执行相应的套接字写入操作， 如图所示。

640?wx_fmt=png

当命令回复发送完毕之后， 服务器就会解除命令回复处理器与客户端套接字的 AE_WRITABLE 事件之间的关联。

一次完整的客户端与服务器连接事件示例

假设Redis服务器正在运作，那么这个服务器的监听套接字的AE_READABLE事件应该正处于监听状态之下，而该事件所对应的处理器为连接应答处理器。

如果这时有一个Redis客户端向Redis服务器发起连接，那么监听套接字将产生AE_READABLE事件， 触发连接应答处理器执行：处理器会对客户端的连接请求进行应答， 然后创建客户端套接字，以及客户端状态，并将客户端套接字的 AE_READABLE 事件与命令请求处理器进行关联，使得客户端可以向主服务器发送命令请求。

之后，客户端向Redis服务器发送一个命令请求，那么客户端套接字将产生 AE_READABLE事件，引发命令请求处理器执行，处理器读取客户端的命令内容， 然后传给相关程序去执行。

执行命令将产生相应的命令回复，为了将这些命令回复传送回客户端，服务器会将客户端套接字的AE_WRITABLE事件与命令回复处理器进行关联：当客户端尝试读取命令回复的时候，客户端套接字将产生AE_WRITABLE事件， 触发命令回复处理器执行， 当命令回复处理器将命令回复全部写入到套接字之后， 服务器就会解除客户端套接字的AE_WRITABLE事件与命令回复处理器之间的关联。

640?wx_fmt=png

Redis疑问快答

详细的解答，请查看笔者之前的几篇Redis博客。

是否使用过Redis集群，集群的原理是什么？

Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。

如何使用过Redis做异步队列？

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

如果不用sleep，list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。

如果想要生产一次消费多次，可以使用pub/sub主题订阅者模式，可以实现1:N的消息队列，但在消费者下线后，生产的消息会丢失，想要持久化的话，需要使用消息队列如rabbitmq等。

redis如何实现延时队列？

使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。

如果有大量的key需要设置同一时间过期，需要注意什么？

如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。一般需要在过期时间上加一个随机值，使得过期时间分散一些。

Redis单点吞吐量

单点TPS达到8万/秒，QPS达到10万/秒，补充下TPS和QPS的概念

  1. QPS: 应用系统每秒钟最大能接受的用户访问量。每秒钟处理完请求的次数，注意这里是处理完，具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。

  2. TPS：每秒钟最大能处理的请求数。每秒钟处理完的事务次数，一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较合理。

Redis哈希槽

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

Redis集群最大节点个数是多少？

Redis集群预分好16384个桶(哈希槽)

Redis事务是什么？

Redis事务可以一次执行多个命令，有以下特点：

  • 批量操作在发送 EXEC 命令前被放入队列缓存。

  • 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。

  • 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

 

彻底搞懂IO多路复用模型
yonggeit的博客
08-07 540
当我们去面试的时候，问到了 redis，nginx，netty他们的底层模型分别是什么？需要从操作系统的层面上来谈。
Redis为什么快
baihualindesu的博客
05-14 980
Redis有多快？ Redis采用的是基于内存的采用的是单进程单线程模型的KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。这个数据不比采用单进程多线程的同样基于内存的 KV 数据库 Memcached 差！ 为什么这么快？ 1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中； 2、数据结构简单，对数据操作也简单，Redi...
Redis的线程模型
smietao的博客
03-09 3318
redis 最基本的内部原理和特点：redis 实际上是个单线程工作模型
redis 的线程模型
C18298182575的博客
12-17 1545
一、redis 的线程模型# redis 内部使用文件事件处理器file event handler，它是单线程的，所以redis才叫做单线程模型。它采用IO多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。 文件事件处理器的结构： 多个 socket IO 多路复用程序 文件事件分派器 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器） 线程模型 多个 socket 可.
redis线程模型
空杯心态_虚怀若谷
03-30 1145
Redis 基于 Reactor 模式开发了自己的网络事件处理器： 这个处理器被称为文件事件处理器（file event handler）： 文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（clo
【Redis】Redis线程模型
关关的博客
10-08 2031
尽管 Redis 是单线程的，但它能够高效地处理大量并发连接，因为它不需要为每个连接创建单独的线程或进程，而是通过事件驱动的方式监听和处理多个连接上的请求。【Redis单线程模型】
【万字长文】带你搞懂Redis中的所有知识点
1_5_2_的博客
01-29 826
本文详细讲述了Redis中所有的知识点，包括：性能、数据结构、持久化、过期策略、内存淘汰策略、集群部署、数据复制、高可用等内容
后端开发【一大波有用知识】Redis的线程模型和异步机制
Linuxhus的博客
05-10 364
文章目录 Redis 6.0引入多线程 异步机制 Redis pipeline技术 Redis 事务 ACID特性分析 redis 发布订阅 我们通常说，Redis 是单线程，主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。 但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。 为什么使用单线程: 多线程并发开销大，访问共享资源时
从网络通信的演进过程彻底搞懂Redis高性能通信的原理（全网最详细，建议收藏）
m0_62301431的博客
10-18 261
我们一直说Redis的性能很快，那为什么快？Redis为了达到性能最大化，做了哪些方面的优化呢？ 这篇文章中，其实从数据结构上分析了Redis性能高的一方面原因。 在目前的k-v数据库的技术选型中，Redis几乎是首选的用来实现高性能缓存的方案，它的性能有多快呢？ 根据官方的基准测试数据，一台普通硬件配置的Linux机器上运行单个Redis实例，处理简单命令（O(n)或者O（logn）），QPS可以达到8W，如果使用pipeline批处理功能，QPS最高可以达到10W。 Redis 为什么那么快 R
分布式缓存的面试题2
weixin_34168700的博客
08-03 337
1、面试题 redis和memcached有什么区别？redis的线程模型是什么？为什么单线程的redis比多线程的memcached效率要高得多（为什么redis是单线程的但是还可以支撑高并发）？ 2、面试官心里分析 这个是问redis的时候，最基本的问题吧，redis最基本的一个内部原理和特点，就是redis实际上是个单线程工作模型，你要是这个都不知道，那后面玩儿...
redis的线程模型
佐杰的博客
11-24 213
redis线程模型文件事件处理器文件事件文件事件处理器客户端与redis的一次通信流程 文件事件处理器 redis基于reactor模式开发了网络事件处理器，这个处理器的模式叫做文件事件处理器，file event handler,这个文件事件处理器，是单线程的，redis才叫做单线程事件模型，采用io多路复用机制同时监听多个socket,根据socket上的事件来选择对应事件处理器来处理这个事件...
Redis线程模型
08-31 468
Redis是一个开源的远程内存型数据库（Remote Dictionary Server（远程字典服务器）），它不仅性能强劲，而且提供了5 种不同类型的数据结构，我们项目实践中可能会遇到的大部分问题都可以很自然地映射到这些数据结构上。除此之外，Redis通过复制、持久化（persistence）、Redis Sentinel、客户端分片（client-side sharding）等特性，让用户可以很方便地将Redis 扩展成一个高可用能够包含数百GB 数据、每秒处理上百万次请求的系统。...
多个客户端访问Redis的同一个数据库是怎么保证不会发生访问资源冲突的，比如对应一个变量进行desc
最新发布
03-31
<think>好的，我需要理解用户的问题：多个客户端同时访问Redis同一个数据库时，如何避免资源冲突，比如对一个变量进行递减操作。用户可能想知道Redis在单线程模型下如何处理并发问题，特别是像DECR这样的操作。 首先，回顾之前关于Redis单线程和事务的讨论。Redis是单线程的，所有命令按顺序执行，自然不会有并发冲突。但用户可能疑惑，如果多个客户端同时发送DECR命令，为什么不会出错。这时候需要解释单线程如何保证原子性，以及像DECR这样的命令是原子操作。 然后，可能需要提到Redis的命令执行机制，每个命令都是原子的，不会被打断。例如，DECR命令在执行时不会被其他客户端的命令插入，所以即使多个客户端发送DECR，Redis会一个一个处理，每个DECR都是完整执行后才处理下一个命令，所以结果正确。 接着，用户可能混淆了并发中的竞态条件和Redis的处理方式。虽然客户端是并发的，但Redis内部是串行处理，所以实际上没有真正的并行，自然不会有冲突。但需要明确解释这一点，可能用例子说明。 另外，用户提到的“事务队列”，可能需要区分事务中的多个命令和单个命令的原子性。比如，在事务中多个命令会被一起执行，但每个单独的DECR本身已经是原子的，不需要事务也能保证安全。而事务的作用是将多个命令打包，但执行时依然是顺序的，所以不会有冲突。 可能还需要补充WATCH机制，用于处理更复杂的场景，比如在事务中需要先读取值再修改的情况，这时候使用WATCH来检测值是否被其他客户端修改，从而保证一致性。但用户的问题可能更关注基础的单命令原子性，所以需要分层次回答。 最后，总结Redis如何通过单线程模型和原子操作保证资源访问安全，不会有冲突。同时提醒用户注意长时间操作可能导致的阻塞问题，以及在高并发下性能的考虑。</think>Redis通过其单线程架构和原子操作机制，确保多个客户端对同一数据的并发访问不会产生资源冲突。以下从三个关键维度解析其实现原理： --- ### **一、单线程序列化执行核心** 1. **事件循环架构** Redis采用单Reactor模式，所有客户端请求通过I/O多路复用进入队列，主线程严格按照FIFO顺序执行命令，物理层面消除并发竞争。 ```mermaid graph LR C1[客户端A: DECR counter] --> EventQueue C2[客户端B: DECR counter] --> EventQueue EventQueue --> MainThread[主线程] MainThread --> |顺序执行| ResultA[结果A] MainThread --> |顺序执行| ResultB[结果B] ``` 2. **原子操作保证** Redis所有单命令操作（如`DECR`/`INCR`）在源码层面实现为原子操作： ```c // Redis源码示例：DECR命令实现 void decrCommand(client *c) { long long value; // 原子性获取当前值 if (getLongLongFromObjectOrReply(c,c->argv[1],&value,NULL) != C_OK) return; value--; // 原子性写入新值 setKey(c->db,c->argv[1],createStringObjectFromLongLong(value)); addReplyLongLong(c,value); } ``` - 整个`DECR`操作包含：取值→计算→写回，这三个步骤在单线程中不可分割 - 即使多个客户端同时发送`DECR`命令，实际执行时序为： $$ \text{ClientA.DECR} \rightarrow \text{ClientB.DECR} \rightarrow \text{ClientC.DECR} $$ --- ### **二、并发场景模拟验证** 假设初始值`counter=100`，三个客户端同时发起`DECR`操作： | 时间片 | 执行内容 | 内存值变化 | |--------|-----------------------|------------| | t1 | 执行ClientA的DECR | 99 | | t2 | 执行ClientB的DECR | 98 | | t3 | 执行ClientC的DECR | 97 | - 最终结果必然为97，完全符合线性执行预期 - 客户端感知的"并发"实为网络层面的并行请求，服务端实际处理仍为严格串行 --- ### **三、进阶场景与解决方案** 1. **复合操作竞态** 当需要实现"先读后写"逻辑时（如：`GET value; 业务计算; SET value`），需采用额外机制： ```bash WATCH balance current = GET balance MULTI SET balance (current - 100) EXEC # 若balance被修改则自动失败 ``` 2. **Lua脚本原子性** Redis通过`EVAL`命令支持原子执行Lua脚本： ```lua -- 原子化扣减库存 local stock = redis.call('GET', KEYS[1]) if tonumber(stock) >= tonumber(ARGV[1]) then return redis.call('DECRBY', KEYS[1], ARGV[1]) else return -1 end ``` - 脚本执行期间会阻塞整个服务，需控制脚本复杂度 3. **性能极限测试数据** | 操作类型 | QPS(单核) | 线程模型 | |-------------|-----------|-------------------| | 单DECR操作 | 120,000 | 单线程 | | 事务操作 | 80,000 | 单线程 | | Lua脚本操作 | 60,000 | 单线程 | --- ### **四、设计取舍与最佳实践** 1. **优势** - 无锁编程彻底规避死锁风险 - 上下文切换成本趋近于零 - 确定性执行时序便于问题复现 2. **使用建议** - 对热点键操作优先使用原子命令（`INCRBY/DECRBY`等） - 复杂逻辑使用Lua脚本而非事务 - 避免在Redis中实现需要强隔离的业务逻辑 - 监控慢查询：`slowlog get 10` 3. **特殊场景注意** ```bash # 危险操作示例（阻塞主线程） EVAL "for i=1,1000000 do redis.call('PING') end" 0 # 正确做法：拆分复杂操作 ``` --- **结论**：Redis通过单线程模型+原子操作设计，在保证数据一致性的同时，实现了每秒十万级操作的超高并发处理能力。开发者需根据其特性设计数据访问模式，在简单原子操作与复杂业务逻辑间找到平衡点。
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值