3.4 结果返回阶段：addReply

调用prepareClientToWrite，并在prepareClientToWrite中调用clientInstallWriteHandler，将待写回客户端加入到全局变量server的clients_pending_write列表。

然后，addReply会调用_addReplyToBuffer等函数，将要返回的结果添加到客户端的输出缓冲区。

至此，这就是一条命令如何从读取，经过解析、执行等步骤，最终将结果返给客户端，该过程以及涉及的主要函数：

若在前面命令处理过程中，都由I/O主线程处理，则命令执行的原子性肯定能得到保证，分布式锁的原子性也相应得到保证。

但若这个处理过程配合上了I/O多路复用机制和多IO线程机制，那这俩机制是在这个过程的什么阶段发挥作用的？会不会影响命令执行的原子性？

所以现在就要明确，这俩机制到底参与了什么流程，才能知道是否对原子性保证有副作用。

4 I/O多路复用会影响对命令原子性吗？

I/O多路复用机制是在readQueryFromClient执行前发挥作用的。在事件驱动框架中调用aeApiPoll函数，获取一批已就绪的socket描述符。然后执行一个循环，针对每个就绪描述符上的读事件，触发执行readQueryFromClient函数。

如此，即使I/O多路复用机制同时获取了多个就绪的socket描述符，但实际处理时，Redis主线程仍是针对每个事件逐一调用回调函数进行处理。且针对写事件，I/O多路复用机制也是针对每个事件逐一处理。

I/O多路复用机制通过aeApiPoll获取一批事件，然后逐一处理：

这表明，即使使用I/O多路复用，命令的整个处理过程仍可由I/O主线程完成，也就仍保证命令执行的原子性。如下就是I/O多路复用机制和命令处理过程的关系：

5 多I/O线程会破坏命令原子性吗？

多I/O线程可执行读操作或写操作。对读操作，readQueryFromClient在执行过程中，会调用 postponeClientRead 将待读客户端加入 clients_pending_read 等待列表。

然后，待读客户端会被分配给多I/O线程执行，每个IO线程执行的函数就是 readQueryFromClient，它会读取命令=》调用processInputBuffer解析命令，该过程和Redis 6.0前代码一致。

而Redis 6.0 processInputBuffer新增了个判断条件：若客户端有CLIENT_PENDING_READ标识，则解析完命令后，processInputBuffer只会把客户端标识改为CLIENT_PENDING_COMMAND，就退出命令解析的循环流程。

此时，processInputBuffer只是解析了第一个命令，不会实际调用processCommand执行命令：

这样，等所有I/O线程都解析完了第一个命令后，I/O主线程中执行的handleClientsWithPendingReadsUsingThreads会再调用processCommandAndResetClient执行命令及调用processInputBuffer解析剩余命令。

所以，即使使用多I/O线程，其实命令执行阶段也是由主I/O线程完成，所有命令执行的原子性仍得到保证，即不会破坏分布式锁的原子性。

写回数据流程

该阶段，addReply是将客户端写回操作推迟执行的，而此时Redis命令已完成执行，所以，即使有多个I/O线程在同时将客户端数据写回，也只是把结果返给客户端，并不影响命令在Redis Server的执行结果。因此，即使用了多I/O线程写回，Redis同样不会破坏命令执行的原子性。

使用多I/O线程机制后，命令处理过程各个阶段是由什么线程执行：

6 总结

加锁和解锁操作分别可以使用SET命令和Lua脚本与EVAL命令来完成。那么，分布式锁的原子性保证，就主要依赖SET和EVAL命令在Redis server中执行时的原子性保证了。

Redis中命令处理的整个过程在Redis 6.0版本前都是由主IO线程来执行完成的。虽然Redis使用了IO多路复用机制，但是该机制只是一次性获取多个就绪的socket描述符，对应了多个发送命令请求的客户端。而Redis在主IO线程中，还是逐一来处理每个客户端上的命令的，所以命令执行的原子性依然可以得到保证。

使用Redis 6.0版本后，命令处理过程中的读取、解析和结果写回，就由多IO线程处理。不过多IO线程只是完成解析第一个读到的命令，命令实际执行还是由主IO线程处理。当多IO线程在并发写回结果时，命令就已执行完，不存在多IO线程冲突问题。所以，使用了多IO线程后，命令执行原子性仍可得到保证。

多IO线程实际并不会加快命令的执行，只会将读取解析命令并行化执行，写回结果并行化执行，且读取解析命令还是针对收到的第一条命令。这一设计考虑还是由于网络IO需加速处理。如命令执行本身成为Redis运行时瓶颈，其实可考虑使用Redis切片集群提升处理效率。