Redis中命令的原子性是什么

这篇文章主要讲解了“Redis中命令的原子性是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Redis中命令的原子性是什么”吧！业务中有时候我们会用 Redis 处理一些高并发的业务场景，例如，秒杀业务，对于库存的操作。。。先来分析下，并发场景下会发生什么问题并发问题主要发生在数据的修改上，对于客户端修改数据，一般分成下面两个步骤：1、客户端先把数据读取到本地，在本地进行修改；2、客户端修改完数据后，再写回Redis。我们把这个流程叫做读取-修改-写回操作（Read-Modify-Write，简称为 RMW 操作）。如果客户端并发进行 RMW 操作的时候，就需要保证 读取-修改-写回是一个原子操作，进行命令操作的时候，其他客户端不能对当前的数据进行操作。错误的栗子：统计一个页面的访问次数，每次刷新页面访问次数+1，这里使用 Redis 来记录访问次数。如果每次的读取-修改-写回操作不是一个原子操作，那么就可能存在下图的问题，客户端2在客户端1操作的中途，也获取 Redis 的值，也对值进行+1，操作，这样就导致最终数据的错误。对于上面的这种情况，一般会有两种方式解决：1、使用 Redis 实现一把分布式锁，通过锁来保护每次只有一个线程来操作临界资源；2、实现操作命令的原子性。栗如，对于上面的错误栗子，如果读取-修改-写回是一个原子性的命令，那么这个命令在操作过程中就不有别的线程同时读取操作数据，这样就能避免上面栗子出现的问题。下面从原子性和锁两个方面，具体分析下，对并发访问问题的处理为了实现并发控制要求的临界区代码互斥执行，如果使用 Redis 中命令的原子性，可以有下面两种处理方式：1、借助于 Redis 中的原子性的单命令；2、把多个操作写到一个Lua脚本中，以原子性方式执行单个Lua脚本。在探讨 Redis 原子性的时候，先来探讨下 Redis 中使用到的编程模型Redis 中使用到了 Reactor 模型，Reactor 是非阻塞 I/O 模型，这里来看下 Unix 中的 I/O 模型。操作系统上的 I/O 是用户空间和内核空间的数据交互，因此 I/O 操作通常包含以下两个步骤：1、等待网络数据到达网卡(读就绪)/等待网卡可写(写就绪) –> 读取/写入到内核缓冲区；2、从内核缓冲区复制数据 –> 用户空间(读)/从用户空间复制数据 -> 内核缓冲区(写)；Unix 中有五种基本的 I/O 模型阻塞式 I/O；非阻塞式 I/O；I/O 多路复用；信号驱动 I/O；异步 I/O；而判定一个 I/O 模型是同步还是异步，主要看第二步：数据在用户和内核空间之间复制的时候是不是会阻塞当前进程，如果会，则是同步 I/O，否则，就是异步 I/O。这里主要分下下面三种 I/O 模型阻塞型 I/O；当用户程序执行 read ，线程会被阻塞，一直等到内核数据准备好，并把数据从内核缓冲区拷贝到应用程序的缓冲区中，当拷贝过程完成，read 才会返回。阻塞等待的是「内核数据准备好」和「数据从内核态拷贝到用户态」这两个过程。非阻塞同步 I/O；非阻塞的 read 请求在数据未准备好的情况下立即返回，可以继续往下执行，此时应用程序不断轮询内核，直到数据准备好，内核将数据拷贝到应用程序缓冲区，read 调用才可以获取到结果。这里最后一次 read 调用，获取数据的过程，是一个同步的过程，是需要等待的过程。这里的同步指的是内核态的数据拷贝到用户程序的缓存区这个过程。非阻塞异步 I/O；发起异步 I/O，就立即返回，内核自动将数据从内核空间拷贝到用户空间，这个拷贝过程同样是异步的，内核自动完成的，和前面的同步操作不一样，应用程序并不需要主动发起拷贝动作。举个你去饭堂吃饭的例子，你好比应用程序，饭堂好比操作系统。阻塞 I/O 好比，你去饭堂吃饭，但是饭堂的菜还没做好，然后你就一直在那里等啊等，等了好长一段时间终于等到饭堂阿姨把菜端了出来（数据准备的过程），但是你还得继续等阿姨把菜（内核空间）打到你的饭盒里（用户空间），经历完这两个过程，你才可以离开。非阻塞 I/O 好比，你去了饭堂，问阿姨菜做好了没有，阿姨告诉你没，你就离开了，过几十分钟，你又来饭堂问阿姨，阿姨说做好了，于是阿姨帮你把菜打到你的饭盒里，这个过程你是得等待的。异步 I/O 好比，你让饭堂阿姨将菜做好并把菜打到饭盒里后，把饭盒送到你面前，整个过程你都不需要任何等待。在 web 服务中，处理 web 请求通常有两种体系结构，分别为：thread-based architecture（基于线程的架构）、event-driven architecture（事件驱动模型）thread-based architecture（基于线程的架构）：这种比较容易理解，就是多线程并发模式，服务端在处理请求的时候，一个请求分配一个独立的线程来处理。因为每个请求分配一个独立的线程，所以单个线程的阻塞不会影响到其他的线程，能够提高程序的响应速度。不足的是，连接和线程之间始终保持一对一的关系，如果是一直处于 Keep-Alive 状态的长连接将会导致大量工作线程在空闲状态下等待，例如，文件系统访问，网络等。此外，成百上千的连接还可能会导致并发线程浪费大量内存的堆栈空间。事件驱动的体系结构由事件生产者和事件消费者组，是一种松耦合、分布式的驱动架构，生产者收集到某应用产生的事件后实时对事件采取必要的处理后路由至下游系统，无需等待系统响应，下游的事件消费者组收到是事件消息，异步的处理。事件驱动架构具有以下优势：降低耦合；降低事件生产者和订阅者的耦合性。事件生产者只需关注事件的发生，无需关注事件如何处理以及被分发给哪些订阅者。任何一个环节出现故障，不会影响其他业务正常运行。异步执行；事件驱动架构适用于异步场景，即便是需求高峰期，收集各种来源的事件后保留在事件总线中，然后逐步分发传递事件，不会造成系统拥塞或资源过剩的情况。可扩展性；事件驱动架构中路由和过滤能力支持划分服务，便于扩展和路由分发。Reactor 模式和 Proactor 模式都是 event-driven architecture（事件驱动模型）的实现方式，这里具体分析下Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。在处理⽹络 IO 的连接事件、读事件、写事件。Reactor 中引入了三类角色reactor：监听和分配事件，连接事件交给 acceptor 处理，读写事件交给 handler 处理；acceptor：接收连接请求，接收连接后，会创建 handler ，处理网络连接上对后续读写事件的处理；handler：处理读写事件。Reactor 模型又分为 3 类：单线程 Reactor 模式；建立连接（Acceptor）、监听accept、read、write事件（Reactor）、处理事件（Handler）都只用一个单线程；多线程 Reactor 模式；与单线程模式不同的是，添加了一个工作者线程池，并将非 I/O 操作从 Reactor 线程中移出转交给工作者线程池（Thread Pool）来执行。建立连接（Acceptor）和 监听accept、read、write事件（Reactor），复用一个线程。工作线程池：处理事件（Handler），由一个工作线程池来执行业务逻辑，包括数据就绪后，用户态的数据读写。主从 Reactor 模式；对于多个CPU的机器，为充分利用系统资源，将 Reactor 拆分为两部分：mainReactor 和 subReactor。mainReactor：负责监听server socket，用来处理网络新连接的建立，将建立的socketChannel指定注册给subReactor，通常一个线程就可以处理；subReactor：监听accept、read、write事件（Reactor），包括等待数据就绪时，内核态的数据读写，通常使用多线程。工作线程：处理事件（Handler）可以和 subReactor 共同使用同一个线程，也可以做成线程池，类似上面多线程 Reactor 模式下的工作线程池的处理方式。reactor 流程与 Reactor 模式类似不同点就是Reactor 是非阻塞同步网络模式，感知的是就绪可读写事件。在每次感知到有事件发生（比如可读就绪事件）后，就需要应用进程主动调用 read 方法来完成数据的读取，也就是要应用进程主动将 socket 接收缓存中的数据读到应用进程内存中，这个过程是同步的，读取完数据后应用进程才能处理数据。Proactor 是异步网络模式，感知的是已完成的读写事件。在发起异步读写请求时，需要传入数据缓冲区的地址（用来存放结果数据）等信息，这样系统内核才可以自动帮我们把数据的读写工作完成，这里的读写工作全程由操作系统来做，并不需要像 Reactor 那样还需要应用进程主动发起 read/write 来读写数据，操作系统完成读写工作后，就会通知应用进程直接处理数据。因此，Reactor 可以理解为「来了事件操作系统通知应用进程，让应用进程来处理」，而 Proactor 可以理解为「来了事件操作系统来处理，处理完再通知应用进程」。举个实际生活中的例子，Reactor 模式就是快递员在楼下，给你打电话告诉你快递到你家小区了，你需要自己下楼来拿快递。而在 Proactor 模式下，快递员直接将快递送到你家门口，然后通知你。Redis 中使用是单线程，可能处于以下几方面的考虑1、Redis 是纯内存的操作，执行速度是非常快的，因此这部分操作通常不会是性能瓶颈，性能瓶颈在于网络 I/O;2、避免过多的上下文切换开销，单线程则可以规避进程内频繁的线程切换开销；3、避免同步机制的开销，多线程必然会面临对于共享资源的访问，这时候通常的做法就是加锁，虽然是多线程，这时候就会变成串行的访问。也就是多线程编程模式会面临的共享资源的并发访问控制问题；4、简单可维护，多线程也会引入同步原语来保护共享资源的并发访问，代码的可维护性和易读性将会下降。Redis 在 v6.0 版本之前，Redis 的核心网络模型一直是一个典型的单 Reactor 模型：利用 epoll/select/kqueue 等多路复用技术，在单线程的事件循环中不断去处理事件（客户端请求），最后回写响应数据到客户端：这里来看下 Redis 如何使用单线程处理任务Redis 的网络框架实现了 Reactor 模型，并且自行开发实现了一个事件驱动框架。事件驱动框架的逻辑简单点讲就是事件初始化；事件捕获；分发和处理主循环。来看下 Redis 中事件驱动框架实现的几个主要函数使用 aeMain 作为主循环来对事件进行持续监听和捕获，其中会调用 aeProcessEvents 函数，实现事件捕获、判断事件类型和调用具体的事件处理函数，从而实现事件的处理。可以看到 aeProcessEvents 中对于 IO 事件的捕获是通过调用 aeApiPoll 来完成的。aeApiPoll 是 I/O 多路复用 API，是基于 epoll_wait/select/kevent 等系统调用的封装，监听等待读写事件触发，然后处理，它是事件循环（Event Loop）中的核心函数，是事件驱动得以运行的基础。Redis 是依赖于操作系统底层提供的 IO 多路复用机制，来实现事件捕获，检查是否有新的连接、读写事件发生。为了适配不同的操作系统，Redis 对不同操作系统实现的网络 IO 多路复用函数，都进行了统一的封装。ae_epoll.c：对应 Linux 上的 IO 复用函数 epoll；ae_evport.c：对应 Solaris 上的 IO 复用函数 evport；ae_kqueue.c：对应 macOS 或 FreeBSD 上的 IO 复用函数 kqueue；ae_select.c：对应 Linux（或 Windows）的 IO 复用函数 select。监听 socket 的读事件,当有客户端连接请求过来，使用函数 acceptTcpHandler 和客户端建立连接当 Redis 启动后，服务器程序的 main 函数会调用 initSever 函数来进行初始化，而在初始化的过程中，aeCreateFileEvent 就会被 initServer 函数调用，用于注册要监听的事件，以及相应的事件处理函数。可以看到 initServer 中会根据启用的 IP 端口个数，为每个 IP 端口上的网络事件，调用 aeCreateFileEvent，创建对 AE_READABLE 事件的监听，并且注册 AE_READABLE 事件的处理 handler，也就是 acceptTcpHandler 函数。然后看下 acceptTcpHandler 的实现1、acceptTcpHandler 主要用于处理和客户端连接的建立；2、其中会调用函数 anetTcpAccept 用于 accept 客户端的连接，其返回值是客户端对应的 socket；3、然后调用 acceptCommonHandler 对连接以及客户端进行初始化；4、初始化客户端的时候，同时使用 aeCreateFileEvent 用来注册监听的事件和事件对应的处理函数，将 readQueryFromClient 命令读取处理器绑定到新连接对应的文件描述符上；5、服务器会监听该文件描述符的读事件，当客户端发送了命令，触发了 AE_READABLE 事件，那么就会调用回调函数 readQueryFromClient() 来从文件描述符 fd 中读发来的命令，并保存在输入缓冲区中 querybuf。readQueryFromClient 是请求处理的起点,解析并执行客户端的请求命令。1、readQueryFromClient()，从文件描述符 fd 中读出数据到输入缓冲区 querybuf 中；2、使用 processInputBuffer 函数完成对命令的解析，在其中使用 processInlineBuffer 或者 processMultibulkBuffer 根据 Redis 协议解析命令；3、完成对一个命令的解析，就使用 processCommand 对命令就行执行；4、命令执行完成，最后调用 addReply 函数族的一系列函数将响应数据写入到对应 client 的写出缓冲区：client->buf 或者 client->reply ，client->buf 是首选的写出缓冲区，固定大小 16KB，一般来说可以缓冲足够多的响应数据，但是如果客户端在时间窗口内需要响应的数据非常大，那么则会自动切换到 client->reply 链表上去，使用链表理论上能够保存无限大的数据（受限于机器的物理内存），最后把 client 添加进一个 LIFO 队列 clients_pending_write；在 Redis 事件驱动框架每次循环进入事件处理函数前，来处理监听到的已触发事件或是到时的时间事件之前，都会调用 beforeSleep 函数，进行一些任务处理，这其中就包括了调用 handleClientsWithPendingWrites 函数，它会将 Redis sever 客户端缓冲区中的数据写回客户端。1、beforeSleep 函数调用的 handleClientsWithPendingWrites 函数，会遍历 clients_pending_write(待写回数据的客户端) 队列，调用 writeToClient 把 client 的写出缓冲区里的数据回写到客户端，然后调用 writeToClient 函数，将客户端输出缓冲区中的数据发送给客户端；2、如果输出缓冲区的数据还没有写完，此时，handleClientsWithPendingWrites 函数就会调用 aeCreateFileEvent 函数，注册 sendReplyToClient 到该连接的写就绪事件，等待将后续将数据写回给客户端。上面的执行流程总结下来就是1、Redis Server 启动后，主线程会启动一个时间循环(Event Loop),持续监听事件；2、client 到 server 的新连接，会调用 acceptTcpHandler 函数，之后会注册读事件 readQueryFromClient 函数，client 发给 server 的数据，都会在这个函数处理，这个函数会解析 client 的数据，找到对应的 cmd 函数执行；3、cmd 逻辑执行完成后，server 需要写回数据给 client，调用 addReply 函数族的一系列函数将响应数据写入到对应 client 的写出缓冲区：client->buf 或者 client->reply ，client->buf 是首选的写出缓冲区，固定大小 16KB，一般来说可以缓冲足够多的响应数据，但是如果客户端在时间窗口内需要响应的数据非常大，那么则会自动切换到 client->reply 链表上去，使用链表理论上能够保存无限大的数据（受限于机器的物理内存），最后把 client 添加进一个 LIFO 队列 cli免费云主机域名ents_pending_write；4、在 Redis 事件驱动框架每次循环进入事件处理函数前，来处理监听到的已触发事件或是到时的时间事件之前，都会调用 beforeSleep 函数，进行一些任务处理，这其中就包括了调用 handleClientsWithPendingWrites 函数，它会将 Redis sever 客户端缓冲区中的数据写回客户端；beforeSleep 函数调用的 handleClientsWithPendingWrites 函数，会遍历 clients_pending_write(待写回数据的客户端) 队列，调用 writeToClient 把 client 的写出缓冲区里的数据回写到客户端，然后调用 writeToClient 函数，将客户端输出缓冲区中的数据发送给客户端；如果输出缓冲区的数据还没有写完，此时，handleClientsWithPendingWrites 函数就会调用 aeCreateFileEvent 函数，注册 sendReplyToClient 到该连接的写就绪事件，等待将后续将数据写回给客户端。在 Redis6.0 的版本中，引入了多线程来处理 IO 任务，多线程的引入，充分利用了当前服务器多核特性，使用多核运行多线程，让多线程帮助加速数据读取、命令解析以及数据写回的速度，提升 Redis 整体性能。Redis6.0 之前的版本用的是单线程 Reactor 模式，所有的操作都在一个线程中完成，6.0 之后的版本使用了主从 Reactor 模式。由一个 mainReactor 线程接收连接，然后发送给多个 subReactor 线程处理，subReactor 负责处理具体的业务。来看下 Redis 多IO线程的具体实现过程使用 initThreadedIO 函数来初始化多 IO 线程。可以看到在 initThreadedIO 中完成了对下面四个数组的初始化工作io_threads_list 数组：保存了每个 IO 线程要处理的客户端，将数组每个元素初始化为一个 List 类型的列表；io_threads_pending 数组：保存等待每个 IO 线程处理的客户端个数；io_threads_mutex 数组：保存线程互斥锁；io_threads 数组：保存每个 IO 线程的描述符。Redis server 在和一个客户端建立连接后，就开始了监听客户端的可读事件，处理可读事件的回调函数就是 readQueryFromClient使用 clients_pending_read 保存了需要进行延迟读操作的客户端之后，这些客户端又是如何分配给多 IO 线程执行的呢？handleClientsWithPendingWritesUsingThreads 函数：该函数主要负责将 clients_pending_write 列表中的客户端分配给 IO 线程进行处理。看下如何实现1、当客户端发送命令请求之后，会触发 Redis 主线程的事件循环，命令处理器 readQueryFromClient 被回调，多线程模式下，则会把 client 加入到 clients_pending_read 任务队列中去，后面主线程再分配到 I/O 线程去读取客户端请求命令；2、主线程会根据 clients_pending_read 中客户端数量对IO线程进行取模运算，取模的结果就是客户端分配给对应IO线程的编号；3、忙轮询，等待所有的线程完成读取客户端命令的操作，这一步用到了多线程的请求；4、遍历 clients_pending_read，执行所有 client 的命令，这里就是在主线程中执行的，命令的执行是单线程的操作。完成命令的读取、解析以及执行之后，客户端命令的响应数据已经存入 client->buf 或者 client->reply 中。主循环在捕获 IO 事件的时候，beforeSleep 函数会被调用，进而调用 handleClientsWithPendingWritesUsingThreads ，写回响应数据给客户端。1、也是会将 client 分配给所有的 IO 线程；2、忙轮询，等待所有的线程将缓存中的数据写回给客户端，这里写回操作使用的多线程；3、最后再遍历 clients_pending_write，为那些还残留有响应数据的 client 注册命令回复处理器 sendReplyToClient，等待客户端可写之后在事件循环中继续回写残余的响应数据。通过上面的分析可以得出结论，Redis 多IO线程中多线程的应用1、解析客户端的命令的时候用到了多线程，但是对于客户端命令的执行，使用的还是单线程；2、给客户端回复数据的时候，使用到了多线程。来总结下 Redis 中多线程的执行过程1、Redis Server 启动后，主线程会启动一个时间循环(Event Loop),持续监听事件；2、client 到 server 的新连接，会调用 acceptTcpHandler 函数，之后会注册读事件 readQueryFromClient 函数，client 发给 server 的数据，都会在这个函数处理；3、客户端发送给服务端的数据，不会类似 6.0 之前的版本使用 socket 直接去读，而是会将 client 放入到 clients_pending_read 中，里面保存了需要进行延迟读操作的客户端；4、处理 clients_pending_read 的函数 handleClientsWithPendingReadsUsingThreads，在每次事件循环的时候都会调用;1、主线程会根据 clients_pending_read 中客户端数量对IO线程进行取模运算，取模的结果就是客户端分配给对应IO线程的编号;2、忙轮询，等待所有的线程完成读取客户端命令的操作，这一步用到了多线程的请求；3、遍历 clients_pending_read，执行所有 client 的命令，这里就是在主线程中执行的，命令的执行是单线程的操作。5、命令执行完成以后，回复的内容还是会被写入到 client 的缓存区中，这些 client 和6.0之前的版本处理方式一样，也是会被放入到 clients_pending_write（待写回数据的客户端）；6、6.0 对于clients_pending_write 的处理使用到了多线程；1、也是会将 client 分配给所有的 IO 线程；2、忙轮询，等待所有的线程将缓存中的数据写回给客户端，这里写回操作使用的多线程；3、最后再遍历 clients_pending_write，为那些还残留有响应数据的 client 注册命令回复处理器 sendReplyToClient，等待客户端可写之后在事件循环中继续回写残余的响应数据。通过上面的分析，我们知道，Redis 的主线程是单线程执行的，所有 Redis 中的单命令，都是原子性的。所以对于一些场景的操作尽量去使用 Redis 中单命令去完成，就能保证命令执行的原子性。比如对于上面的读取-修改-写回操作可以使用 Redis 中的原子计数器, INCRBY（自增）、DECRBR（自减）、INCR（加1） 和 DECR（减1） 等命令。这些命令可以直接帮助我们处理并发控制分析下源码，看看这个命令是如何实现的可以看到 INCRBY（自增）、DECRBR（自减）、INCR（加1） 和 DECR（减1）这几个命令最终都是调用的 incrDecrCommand感谢各位的阅读，以上就是“Redis中命令的原子性是什么”的内容了，经过本文的学习后，相信大家对Redis中命令的原子性是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是百云，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: 使用redis的要点分析

这篇文章将为大家详细讲解有关使用redis的要点分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。一、导语Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写…