不限流量网站空间,网站vr视角怎么做,珠海网站制作定制,扫描到网站目录然后怎么做1.Redis队列与Stream
Redis5.0 最大的新特性就是多出了一个数据结构 Stream#xff0c;它是一个新的强大的支持多播的可持久化的消息队列。 Redis Stream 的结构如上图所示,每一个Stream都有一个消息链表#xff0c;将所有加入的消息都串起来#xff0c;每个消息都有一个唯…1.Redis队列与Stream
Redis5.0 最大的新特性就是多出了一个数据结构 Stream它是一个新的强大的支持多播的可持久化的消息队列。 Redis Stream 的结构如上图所示,每一个Stream都有一个消息链表将所有加入的消息都串起来每个消息都有一个唯一的 ID 和对应的内容。消息是持久化的Redis 重启后内容还在。
每个 Stream 都有唯一的名称它就是 Redis 的 key在我们首次使用xadd指令追加消息时自动创建。
每个 Stream 都可以挂多个消费组每个消费组会有个游标last_delivered_id在Stream 数组之上往前移动表示当前消费组已经消费到哪条消息了。
每个消费组都有一个 Stream 内唯一的名称消费组不会自动创建它需要单独的指令xgroup create进行创建需要指定从 Stream 的某个消息 ID 开始消费这个ID 用来初始化last_delivered_id变量。
每个消费组 (Consumer Group) 的状态都是独立的相互不受影响。也就是说同一份 Stream 内部的消息会被每个消费组都消费到。
同一个消费组 (Consumer Group) 可以挂接多个消费者 (Consumer)这些消费者之间是竞争关系任意一个消费者读取了消息都会使游标last_delivered_id往前移动。每个消费者有一个组内唯一名称。
消费者 (Consumer) 内部会有个状态变量 pending_ids它记录了当前已经被客户端读取,但是还没有 ack 的消息。如果客户端没有 ack这个变量里面的消息 ID 会越来越多一旦某个消息被 ack它就开始减少。这个 pending_ids 变量在 Redis 官方被称之为 PEL也就是 Pending Entries List这是一个很核心的数据结构它用来确保客户端至少消费了消息一次而不会在网络传输的中途丢失了没处理。
消息 ID 的形式是 timestampInMillis-sequence例如 1527846880572-5它
表示当前的消息在毫米时间戳 1527846880572 时产生并且是该毫秒内产生的第5 条消息。消息 ID 可以由服务器自动生成也可以由客户端自己指定但是形式必须是整数-整数而且必须是后面加入的消息的 ID 要大于前面的消息 ID。
消息内容就是键值对形如 hash 结构的键值对这没什么特别之处。
2.常用命令
2.1生产端
xadd 追加消息
xdel 删除消息这里的删除仅仅是设置了标志位不会实际删除消息。
xrange 获取消息列表会自动过滤已经删除的消息
xlen 消息长度
del 删除 Stream
xadd streamtest * name mark age 18 streamtest 表示当前这个队列的名字也就是我们一般意义上 Redis 中的 key
* 号表示服务器自动生成 ID
“name mark age 18”是我们存入当前 streamtest 这个队列的消息采用的也是 key/value 的存储形式返回值 1626705954593-0 则是生成的消息 ID由两部分组成时间戳-序号。
时间戳时毫秒级单位是生成消息的 Redis 服务器时间它是个 64 位整型。序号是在这个毫秒时间点内的消息序号。它也是个 64 位整型。
为了保证消息是有序的因此 Redis 生成的 ID 是单调递增有序的。由于 ID中包含时间戳部分为了避免服务器时间错误而带来的问题例如服务器时间延后了Redis 的每个 Stream 类型数据都维护一个 latest_generated_id 属性用于记录最后一个消息的 ID。若发现当前时间戳退后小于 latest_generated_id 所记录的则采用时间戳不变而序号递增的方案来作为新消息 ID这也是序号为什么使用 int64 的原因保证有足够多的的序号从而保证 ID 的单调递增性质。
如果不是非常特别的需求强烈建议使用 Redis 的方案生成消息 ID因为这种时间戳序号的单调递增的 ID 方案几乎可以满足全部的需求但 ID 是支持自定义的。 xrange streamtest - 其中-表示最小值 , 表示最大值 或者我们可以指定消息 ID 的列表 xdel streamtest 1626706380924-0
xlen streamtest del streamtest 删除整个 Stream 2.2 消费端
2.2.1 单消费者
虽然 Stream 中有消费者组的概念但是可以在不定义消费组的情况下进行Stream 消息的独立消费当 Stream 没有新消息时甚至可以阻塞等待。Redis 设计了一个单独的消费指令 xread可以将 Stream 当成普通的消息队列 (list) 来使用。使用 xread 时我们可以完全忽略消费组 (Consumer Group) 的存在就好比 Stream 就是一个普通的列表 (list)。
xread count 1 streams stream2 0-0
“count 1”表示从 Stream 读取 1 条消息缺省当然是头部“streams”可以理解为 Redis 关键字“stream2”指明了要读取的队列名称“0-0”指从头开始 xread count 2 streams stream2 1626710882927-0
也可以指定从 streams 的消息 Id 开始(不包括命令中的消息 id) xread count 1 streams stream2 $
$代表从尾部读取上面的意思就是从尾部读取最新的一条消息,此时默认不返回任何消息
所以最好以阻塞的方式读取尾部最新的一条消息直到新的消息的到来
xread block 0 count 1 streams stream2 $
block 后面的数字代表阻塞时间单位毫秒
一般来说客户端如果想要使用 xread 进行顺序消费一定要记住当前消费
到哪里了也就是返回的消息 ID。下次继续调用 xread 时将上次返回的最后
一个消息 ID 作为参数传递进去就可以继续消费后续的消息。
2.2.2 消费组
创建消费组
Stream 通过 xgroup create 指令创建消费组 (Consumer Group)需要传递起始消息 ID 参数用来初始化 last_delivered_id 变量。
xgroup create stream2 cg1 0-0
“stream2”指明了要读取的队列名称“cg1”表示消费组的名称“0-0”表示从头开始消费 xgroup create stream2 cg2 $
$ 表示从尾部开始消费只接受新消息当前 Stream 消息会全部忽略 现在我们可以用 xinfo 命令来看看 stream2 的情况
xinfo stream stream2 xinfo groups stream2 消息消费
有了消费组自然还需要消费者Stream 提供了 xreadgroup 指令可以进行消费组的组内消费需要提供消费组名称、消费者名称和起始消息 ID。
它同 xread 一样也可以阻塞等待新消息。读到新消息后对应的消息 ID 就会进入消费者的 PEL(正在处理的消息) 结构里客户端处理完毕后使用 xack 指令通知服务器本条消息已经处理完毕该消息 ID 就会从 PEL 中移除。
xreadgroup GROUP cg1 c1 count 1 streams stream2
“GROUP”属于关键字
“cg1”是消费组名称
“c1”是消费者名称
“count 1”指明了消费数量 号表示从当前消费组的 last_delivered_id 后面开始读
每当消费者读取一条消息last_delivered_id 变量就会前进 前面我们定义 cg1 的时候是从头开始消费的自然就获得 Stream2 中第一条消息
再执行一次上面的命令 自然就读取到了下条消息。
我们将 Stream2 中的消息读取完
xreadgroup GROUP cg1 c1 count 2 streams stream2
很自然就没有消息可读了 xreadgroup GROUP cg1 c1 count 1 streams stream2 然后设置阻塞等待
xreadgroup GROUP cg1 c1 block 0 count 1 streams stream2 我们新开一个客户端发送消息到 stream2
xadd stream2 * name lison score 98 回到原来的客户端发现阻塞解除收到新消息 我们来观察一下观察消费组状态 如果同一个消费组有多个消费者我们还可以通过 xinfo consumers 指令观
察每个消费者的状态
xinfo consumers stream2 cg1 可以看到目前 c1 这个消费者有 5 条待 ACK 的消息空闲了 441340 ms 没
有读取消息。
如果我们确认一条消息
xack stream2 cg1 1626751586744-0
就可以看到待确认消息变成了 4 条 xack 允许带多个消息 id比如 同时 Stream 还提供了命令 XPENDIING 用来获消费组或消费内消费者的未处理完毕的消息每个 Pending 的消息有 4 个属性
消息 ID
所属消费者
IDLE已读取时长
delivery counter消息被读取次数
命令 XCLAIM 用以进行消息转移的操作将某个消息转移到自己的 Pending列表中。需要设置组、转移的目标消费者和消息 ID同时需要提供 IDLE已被读取时长只有超过这个时长才能被转移。
更多的 Redis 的 Stream 命令请大家参考 Redis 官方文档
Redis Streams | Docs
Commands | Docs
同时 Redis 文档中在每个命令的详情页右边会显示“Related commands”
可以通过这个列表快速了解相关的命令和进入具体命令的详情页。
3.Redis队列实现方式
3.1基于List的PUSHBRPOP实现
简单消费消息延迟几乎为零但是需要处理空闲连接的问题。如果线程一直阻塞在那里Redis 客户端的连接就成了闲置连接闲置过久服务器一般会主动断开连接减少闲置资源占用这个时候 blpop 和 brpop 或抛出异常所以在编写客户端消费者的时候要小心如果捕获到异常需要重试。
其他缺点包括
做消费者确认 ACK 麻烦不能保证消费者消费消息后是否成功处理的问题宕机或处理异常等通常需要维护一个 Pending 列表保证消息处理确认
不能做广播模式如 pub/sub消息发布/订阅模型不能重复消费一旦消费就会被删除不支持分组消费
3.2基于Sorted-Set的实现
多用来实现延迟队列当然也可以实现有序的普通的消息队列但是消费者无法阻塞的获取消息只能轮询不允许重复消息。
PUB/SUB订阅/发布模式
优点
典型的广播模式一个消息可以发布到多个消费者多信道订阅消费者可以同时订阅多个信道从而接收多类消息消息即时发送消息不用等待消费者读取消费者会自动接收到信道发布的消息。
缺点
消息一旦发布不能接收。换句话就是发布时若客户端不在线则消息丢失不能寻回不能保证每个消费者接收的时间是一致的若消费者客户端出现消息积压到一定程度会被强制断开导致消息意外丢失。通常发生在消息的生产远大于消费速度时可见Pub/Sub 模式不适合做消息存储消息积压类的业务而是擅长处理广播即时通讯即时反馈的业务。
3.3 基于Stream类型的实现
4.消息队列的问题
4.1 Stream消息太多怎么办
要是消息积累太多Stream 的链表岂不是很长内容会不会爆掉?
xdel 指令又不会删除消息它只是给消息做了个标志位。
Redis 自然考虑到了这一点所以它提供了一个定长 Stream 功能。在 xadd 的指令提供一个定长长度 maxlen就可以将老的消息干掉确保最多不超过指定长度。
4.2消息如果忘记 ACK 会怎样?
Stream 在每个消费者结构中保存了正在处理中的消息 ID 列表 PEL如果消费者收到了消息处理完了但是没有回复 ack就会导致 PEL 列表不断增长如果有很多消费组的话那么这个 PEL 占用的内存就会放大。所以消息要尽可能的快速消费并确认
4.3PEL 如何避免消息丢失?
在客户端消费者读取 Stream 消息时Redis 服务器将消息回复给客户端的过程中客户端突然断开了连接消息就丢失了。但是 PEL 里已经保存了发出去的消息 ID。待客户端重新连上之后可以再次收到 PEL 中的消息 ID 列表。不过此时 xreadgroup 的起始消息 ID 不能为参数而必须是任意有效的消息ID一般将参数设为 0-0表示读取所有的 PEL 消息以及自 last_delivered_id 之后的新消息。
4.4死信问题
如果某个消息不能被消费者处理也就是不能被 XACK这是要长时间处于 Pending 列表中即使被反复的转移给各个消费者也是如此。此时该消息的delivery counter通过 XPENDING 可以查询到就会累加当累加到某个我们预设的临界值时我们就认为是坏消息也叫死信DeadLetter无法投递的消息由于有了判定条件我们将坏消息处理掉即可删除即可。删除一个消息使用XDEL 语法注意这个命令并没有删除 Pending 中的消息因此查看 Pending消息还会在可以在执行执行 XDEL 之后XACK 这个消息标识其处理完毕。
4.5Stream 的高可用
Stream 的高可用是建立主从复制基础上的它和其它数据结构的复制机制没有区别也就是说在 Sentinel 和 Cluster 集群环境下 Stream 是可以支持高可用的。不过鉴于 Redis 的指令复制是异步的在 failover 发生时Redis 可能会丢失极小部分数据这点 Redis 的其它数据结构也是一样的。
4.6 分区 Partition
Redis 的服务器没有原生支持分区能力如果想要使用分区那就需要分配多个 Stream然后在客户端使用一定的策略来生产消息到不同的 Stream。
4.7 Stream 小结
Stream 的消费模型借鉴了 Kafka 的消费分组的概念它弥补了 Redis Pub/Sub 不能持久化消息的缺陷。但是它又不同于 kafkaKafka 的消息可以分partition而 Stream 不行。如果非要分 parition 的话得在客户端做提供不同的 Stream 名称对消息进行 hash 取模来选择往哪个 Stream 里塞。总的来说如果是中小项目和企业在工作中已经使用了 Redis在业务量
不是很大而又需要消息中间件功能的情况下可以考虑使用 Redis 的 Stream 功能。但是如果并发量很高资源足够支持下还是以专业的消息中间件比如RocketMQ、Kafka 等来支持业务更好。
5.Redis 中的线程和IO模型
5.1 什么是Reactor模式
“反应”器名字中”反应“的由来“反应”即“倒置”“控制逆转”,具体事件处理程序不调用反应器而向反应器注册一个事件处理器表示自己对某些事件感兴趣有时间来了具体事件处理程序通过事件处理器对某个指定的事件发生做出反应这种控制逆转又称为“好莱坞法则”不要调用我让我来调用你)
5.2 单线程Reactor模式流程
服务器端的 Reactor 是一个线程对象该线程会启动事件循环并使用Acceptor 事件处理器关注 ACCEPT 事件这样 Reactor 会监听客户端向服务器端发起的连接请求事件(ACCEPT事件)。
客户端向服务器端发起一个连接请求Reactor监听到了该ACCEPT事件的发生并将该ACCEPT事件派发给相应的Acceptor处理器来进行处理。建立连接后关注的READ事件这样一来Reactor就会监听该连接的READ事件了。
当Reactor 监听到有读READ事件发生时将相关的事件派发给对应的处理器进行处理。比如读处理器会通过读取数据此时read()操作可以直接读取到数据而不会堵塞与等待可读的数据到来。
在目前的单线程Reactor模式中不仅I/O操作在该Reactor线程上连非I/O 的业务操作也在该线程上进行处理了这可能会大大延迟I/O请求的响应。所以我们应该将非I/O的业务逻辑操作从Reactor线程上卸载以此来加速Reactor 线程对I/O 请求的响应。 5.3 单线程Reactor工作者线程池
与单线程Reactor模式不同的是添加了一个工作者线程池并将非I/O操作从Reactor 线程中移出转交给工作者线程池来执行。这样能够提高Reactor线程的I/O响应不至于因为一些耗时的业务逻辑而延迟对后面I/O请求的处理。但是对于一些小容量应用场景可以使用单线程模型对于高负载、大并发或大数据量的应用场景却不合适
主要原因如下
① 一个NIO线程同时处理成百上千的链路性能上无法支撑即便NIO线程的CPU负荷达到100%也无法满足海量消息的读取和发送
② 当NIO线程负载过重之后处理速度将变慢这会导致大量客户端连接超时超时之后往往会进行重发这更加重了NIO线程的负载最终会导致大量消息积压和处理超时成为系统的性能瓶颈 5.3 多Reactor 线程模式
Reactor 线程池中的每一Reactor线程都会有自己的Selector、线程和分发的事件循环逻辑。
mainReactor 可以只有一个但subReactor 一般会有多个。
mainReactor线程主要负责接收客户端的连接请求然后将接收到的SocketChannel传递给subReactor由 subReactor 来完成和客户端的通信。
多Reactor 线程模式将“接受客户端的连接请求”和“与该客户端的通信”分在了两个Reactor线程来完成。
mainReactor完成接收客户端连接请求的操作它不负责与客户端的通信而是将建立好的连接转交给subReactor线程来完成与客户端的通信这样一来就不会因为read()数据量太大而导致后面的客户端连接请求得不到即时处理的情况。并且多Reactor线程模式在海量的客户端并发请求的情况下还可以通过实现subReactor线程池来将海量的连接分发给多个subReactor 线程在多核的操作系统中这能大大提升应用的负载和吞吐量。 5.4Redis 中的线程和IO概述
Redis 基于 Reactor 模式开发了自己的网络事件处理器- 文件事件处理器file event handler后文简称为 FEH而该处理器又是单线程的所以redis设计为单线程模型。
采用I/O多路复用同时监听多个socket根据socket当前执行的事件来为socket 选择对应的事件处理器。
当被监听的socket准备好执行accept、read、write、close等操作时和操作对应的文件事件就会产生这时FEH就会调用socket之前关联好的事件处理器来处理对应事件。
所以虽然FEH是单线程运行但通过I/O多路复用监听多个socket不仅实现高性能的网络通信模型又能和 Redis 服务器中其它同样单线程运行的模块交互保证了Redis内部单线程模型的简洁设计。 socket
文件事件就是对socket操作的抽象 每当一个 socket 准备好执行连接accept、read、write、close 等操作时 就会产生一个文件事件。一个服务器通常会连接多个socket 多个socket可能并发产生不同操作每个操作对应不同文件事件.
5.5 I/O 多路复用程序
I/O 多路复用程序会负责监听多个socket。尽管文件事件可能并发出现 但 I/O 多路复用程序会将所有产生事件的socket 放入队列 通过该队列以有序、同步且每次一个socket的方式向文件事件分派器传送socket。当上一个socket产生的事件被对应事件处理器执行完后 I/O 多路复用程序才会向文件事件分派器传送下个socket 如下 I/O 多路复用程序的实现
Redis 的 I/O 多路复用程序的所有功能都是通过包装常见的 select、epoll、evport 和 kqueue 这些 I/O 多路复用函数库实现的。
每个 I/O 多路复用函数库在 Redis 源码中都对应一个单独的文件因为 Redis 为每个 I/O 多路复用函数库都实现了相同的 API 所以 I/O 多路复用程序的底层实现是可以互换的。Redis 在 I/O 多路复用程序的实现源码ae.c文件中宏定义了相应规则使得程序在编译时自动选择系统中性能最高的I/O 多路复用函数库作为 Redis 的 I/O 多路复用程序的底层实现性能降序排列
5.6文件事件分派器
文件事件分派器接收 I/O 多路复用程序传来的socket并根据socket产生的事件类型 调用相应的事件处理器
5.7 文件事件处理器
服务器会为执行不同任务的套接字关联不同的事件处理器 这些处理器是一个个函数 它们定义了某个事件发生时 服务器应该执行的动作。Redis 为各种文件事件需求编写了多个处理器若客户端连接Redis对连接服务器的各个客户端进行应答就需要将socket映射到连接应答处理器写数据到Redis接收客户端传来的命令请求就需要映射到命令请求处理器从Redis读数据向客户端返回命令的执行结果就需要映射到命令回复处理器当主服务器和从服务器进行复制操作时 主从服务器都需要映射到特别为复制功能编写的复制处理器。
5.8 文件事件的类型
I/O 多路复用程序可以监听多个socket的 ae.h/AE_READABLE 事件和ae.h/AE_WRITABLE 事件 这两类事件和套接字操作之间的对应关系如下当socket 可读比如客户端对Redis执行write/close操作或有新的可应答的socket 出现时即客户端对Redis执行connect操作socket就会产生一个AE_READABLE 事件。当socket 可写时比如客户端对Redis执行read操作socket会产生一个AE_WRITABLE 事件。I/O 多路复用程序可以同时监听AE_REABLE和AE_WRITABLE两种事件要是一个socket 同时产生这两种事件那么文件事件分派器优先处理AE_REABLE事件。即一个socket又可读又可写时 Redis服务器先读后写socket
5.9 总结
Redis 启动初始化时将连接应答处理器跟AE_READABLE事件关联。若一个客户端发起连接会产生一个AE_READABLE事件然后由连接应答处理器负责和客户端建立连接创建客户端对应的socket同时将这个socket的AE_READABLE 事件和命令请求处理器关联使得客户端可以向主服务器发送命令请求。当客户端向Redis发请求时不管读还是写请求客户端socket都会产生一个AE_READABLE 事件触发命令请求处理器。处理器读取客户端的命令内容然后传给相关程序执行。当Redis 服务器准备好给客户端的响应数据后会将socket的AE_WRITABLE事件和命令回复处理器关联当客户端准备好读取响应数据时会在socket产生一个AE_WRITABLE事件由对应命令回复处理器处理即将准备好的响应数据写入socket供客户端读取。命令回复处理器全部写完到 socket 后就会删除该socket的AE_WRITABLE事件和命令回复处理器的映射
6.问题
6.1 Redis6.0 之前的版本真的是单线程吗
Redis 在处理客户端的请求时包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理这就是所谓的“单线程”。但如果严格来讲从Redis4.0之后并不是单线程除了主线程外它也有后台线程在处理一些较为缓慢的操作例如清理脏数据、无用连接的释放、大 key 的删除等等
6.2 Redis6.0 之前为什么一直不使用多线程
官方曾做过类似问题的回复使用Redis时几乎不存在CPU成为瓶颈的情况Redis主要受限于内存和网络。例如在一个普通的Linux系统上Redis通过使用pipelining 每秒可以处理100万个请求所以如果应用程序主要使用O(N)或O(log(N))的命令它几乎不会占用太多CPU。使用了单线程后可维护性高。多线程模型虽然在某些方面表现优异但是它却引入了程序执行顺序的不确定性带来了并发读写的一系列问题增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。Redis通过AE事件模型以及IO多路复用等技术处理性能非常高因此没有必要使用多线程。单线程机制使得 Redis 内部实现的复杂度大大降低Hash 的惰性Rehash、Lpush 等等 “线程不安全” 的命令都可以无锁进行。
6.3 Redis6.0 为什么要引入多线程呢
Redis 将所有数据放在内存中内存的响应时长大约为100纳秒对于小数据包Redis服务器可以处理80,000到100,000 QPS这也是Redis处理的极限了对于80%的公司来说单线程的Redis已经足够使用了。但随着越来越复杂的业务场景有些公司动不动就上亿的交易量因此需要更大的QPS。常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器但该方案有非常大的缺点例如要管理的Redis服务器太多维护代价大某些适用于单个Redis服务器的命令不适用于数据分区数据分区无法解决热点读/写问题数据偏斜重新分配和放大/缩小变得更加复杂等等。从Redis 自身角度来说因为读写网络的read/write系统调用占用了Redis执行期间大部分CPU时间瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:
• 提高网络 IO 性能典型的实现比如使用 DPDK 来替代内核网络栈的方式
• 使用多线程充分利用多核典型的实现比如 Memcached。
协议栈优化的这种方式跟 Redis 关系不大支持多线程是一种最有效最便捷的操作方式。
所以总结起来redis支持多线程主要就是两个原因
• 可以充分利用服务器 CPU 资源目前主线程只能利用一个核
• 多线程任务可以分摊 Redis 同步 IO 读写负荷
6.4.Redis6.0 默认是否开启了多线程
Redis6.0 的多线程默认是禁用的只使用主线程。如需开启需要修改redis.conf 配置文件io-threads-do-reads yes开启多线程后还需要设置线程数否则是不生效的。关于线程数的设置
官方有一个建议4核的机器建议设置为2或3个线程8 核的建议设置为6个线程线程数一定要小于机器核数。还需要注意的是线程数并不是越大越好官方认为超过了8个基本就没什么意义了
6.5.Redis6.0 采用多线程后性能的提升效果如何
Redis 作者 antirez 在 RedisConf 2019 分享时曾提到Redis 6 引入的多线程IO 特性对性能提升至少是一倍以上。国内也有大牛曾使用unstable版本在阿里云esc进行过测试GET/SET 命令在4线程 IO时性能相比单线程是几乎是翻倍了。如果开启多线程至少要4核的机器且Redis实例已经占用相当大的CPU耗时的时候才建议采用否则使用多线程没有意义
6.6.Redis6.0 多线程的实现机制
流程简述如下
1、主线程负责接收建立连接请求获取 socket 放入全局等待读处理队列
2、主线程处理完读事件之后通过 RR(Round Robin) 将这些连接分配给这些 IO 线程
3、主线程阻塞等待 IO 线程读取 socket 完毕
4、主线程通过单线程的方式执行请求命令请求数据读取并解析完成但并不执行回写 socket
5、主线程阻塞等待 IO 线程将数据回写 socket 完毕
6、解除绑定清空等待队列该
设计有如下特点
1、IO 线程要么同时在读 socket要么同时在写不会同时读或写
2、IO 线程只负责读写 socket 解析命令不负责命令处理
6.7.开启多线程后是否会存在线程并发安全问题
从上面的实现机制可以看出Redis的多线程部分只是用来处理网络数据的读写和协议解析执行命令仍然是单线程顺序执行。所以我们不需要去考虑控制key、lua、事务LPUSH/LPOP 等等的并发及线程安全问题。
6.8.Redis6.0 的多线程和Memcached多线程模型进行对比
Memcached 服务器采用 master-woker 模式进行工作服务端采用 socket 与客户端通讯。主线程、工作线程 采用 pipe管道进行通讯。主线程采用 libevent 监听 listen、accept 的读事件事件响应后将连接信息的数据结构封装起来根据算法选择合适的工作线程将连接任务携带连接信息分发出去相应的线程利用连接描述符建立与客户端的socket连接 并进行后续的存取数据操作。
相同点都采用了 master线程-worker 线程的模型
不同点Memcached 执行主逻辑也是在 worker 线程里模型更加简单实现了真正的线程隔离符合我们对线程隔离的常规理解。而 Redis 把处理逻辑交还给 master 线程虽然一定程度上增加了模型复杂度但也解决了线程并发安全等问题
