14 | 从代码实现看分布式锁的原子性保证

1、无论是 IO 多路复用，还是 Redis 6.0 的多 IO 线程，Redis 执行具体命令的主逻辑依旧是「单线程」的 2、执行命令是单线程，本质上就保证了每个命令必定是「串行」执行的，前面请求处理完成，后面请求才能开始处理 3、所以 Redis 在实现分布式锁时，内部不需要考虑加锁问题，直接在主线程中判断 key 是否存在即可，实现起来非常简单 课后题：如果将命令处理过程中的命令执行也交给多 IO 线程执行，除了对原子性会有影响，还会有什么好处和坏处？ 好处： - 每个请求分配给不同的线程处理，一个请求处理慢，并不影响其它请求 - 请求操作的 key 越分散，性能会变高（并行处理比串行处理性能高） - 可充分利用多核 CPU 资源 坏处： - 操作同一个 key 需加锁，加锁会影响性能，如果是热点 key，性能下降明显 - 多线程上下文切换存在性能损耗 - 多线程开发和调试不友好

老师，有个疑问，多线程版本是在命令读取，解析和返回结果是并行的，执行是在主线程处理，是串行的。那样从整个数据流来看，是不是就保证不了命令的执行顺序了?比如命令A比命令B先到Redis服务，但是有可能B会比A先被执行了。

1，客户端A 先发起请求1，后客户端B发起请求2，服务端【无法保证】先接收到 请求1后接收到请求2，因为网络传输时间不同。 2，客户端A 先发起请求1，后客户端A再次发起请求2，服务端 【可以保证】 先接收到请求1后接收到请求2，这个由TCP来保证。 3，服务端先接收到请求1，后接收到请求2，在多io环境下，redis【可以保证】先执行请求1后执行请求2。请求会先放到列表里，多IO线程从列表依次获取请求，进行命令读取及解析，io线程都解析完第一个请求后，主线程是按序执行。

为什么 IO 线程只是完成解析第一个读到的命令，而不是直接将Client输入缓冲解析完？

多线程读取命令是怎么保证顺序的？业务上是A客户端先读，B客户端再写，同时到了Redis服务端后，执行B客户端的线程比执行A客户端的线程先完成了，那给到主线程的命令执行阶段顺序不是就错了？

redisCommand 结构体中 每一个代表什么什么意思的？ struct redisCommand { char *name; redisCommandProc *proc; int arity; char *sflags; /* Flags as string representation, one char per flag. */ int flags; /* The actual flags, obtained from the 'sflags' field. */ /* Use a function to determine keys arguments in a command line. * Used for Redis Cluster redirect. */ redisGetKeysProc *getkeys_proc; /* What keys should be loaded in background when calling this command? */ int firstkey; /* The first argument that's a key (0 = no keys) */ int lastkey; /* The last argument that's a key */ int keystep; /* The step between first and last key */ long long microseconds, calls; };

这节课在学习之前，有80%内容是之前通过学习前面课程结合源码知晓的，老师再一串更加完整了。 有一个问题是：单机redis，在开启多线程读写的时候，qps最高可以打到多少？多谢老师