Redis 的单线程事件循环模型
Redis 采用单线程的事件驱动架构来处理所有客户端请求。具体来说，Redis 使用一个主线程运行事件循环（Event Loop），通过 I/O 多路复用技术（如 epoll、kqueue）监听多个客户端连接。当有请求到达时，主线程会依次从事件队列中取出命令并执行。
对于同一个 key 的并发请求，Redis 的处理方式非常直接：所有命令都在单线程中按照到达顺序串行执行。例如，如果有 100 个客户端同时对 key "user:1001" 发起 GET 请求，这些请求会在网络层被接收，然后进入 Redis 的命令队列，主线程会逐个执行这些 GET 命令。由于是单线程模型，不存在多线程竞争，因此不需要加锁。
这种设计的优势在于：
极低的上下文切换开销：没有线程切换和锁竞争，CPU 可以高效执行指令。Redis 的大部分操作都是纯内存操作，单个命令执行时间通常在微秒级别，单线程模型能充分发挥 CPU 缓存的优势。
简单的并发模型：开发者不需要考虑复杂的并发控制问题，所有操作天然具有原子性。即使是复杂的命令如 INCR（自增），也能保证在高并发下的正确性。
高吞吐量：由于避免了锁开销，Redis 单节点通常能达到 5-10 万 QPS（简单命令如 GET/SET），甚至更高。
当然，单线程模型也有局限性。如果某个命令执行时间过长（比如对大集合进行 KEYS 操作），会阻塞后续所有命令的执行。这也是为什么 Redis 强调要避免使用慢命令的原因。
Tair 的多线程与锁机制
Tair 采用了多线程架构来处理客户端请求，这与 Redis 形成鲜明对比。在 Tair 的设计中，多个工作线程可以并发处理来自不同客户端的请求，以充分利用多核 CPU 的计算能力。
但多线程带来并发能力的同时，也引入了数据竞争问题。当多个线程同时访问同一个 key 时，如果不加控制，可能会导致数据不一致。比如两个线程同时执行 "SET key value" 操作，如果没有同步机制，最终 key 的值可能是不确定的。
为了解决这个问题，Tair 在服务端对 key 级别的操作加了互斥锁（mutex）。具体机制是：
Key 级别的锁粒度：Tair 通常会维护一个锁表，根据 key 的哈希值映射到特定的锁。当一个线程要操作某个 key 时，首先需要获取该 key 对应的锁。
串行化处理：假设有 10 个线程同时对 "user:1001" 发起请求，这些线程会竞争同一把锁。只有获得锁的线程能执行操作，其他线程必须等待。操作完成后释放锁，下一个线程才能获取锁并执行。
锁竞争开销：在高并发场景下，如果存在热点 key，大量线程会在锁上产生竞争。线程需要在用户态和内核态之间切换（如果使用系统级互斥锁），或者进行自旋等待（如果使用自旋锁），这些都会消耗 CPU 资源并增加延迟。
这种设计的问题在于：
热点 key 性能瓶颈：即使 Tair 有多个工作线程，对于单个热点 key，实际处理能力退化为单线程级别，甚至因为锁开销而更差。如果某个 key 被频繁访问（比如计数器、热门商品缓存），这个 key 就会成为系统瓶颈。
锁开销累积：每次加锁和解锁都有时间成本，包括原子操作、内存屏障、可能的线程调度等。在请求量大时，这些开销会显著影响整体吞吐量。
公平性问题：根据锁的实现方式，可能会出现某些线程长期获取不到锁的情况，导致请求延迟不均。
并发请求处理的对比示例
假设有 1000 个客户端同时对 key "counter" 执行 INCR 操作：
Redis 的处理流程：
-
1000 个请求到达 Redis 服务器
-
主线程通过 I/O 多路复用接收所有请求
-
主线程按顺序执行 1000 次 INCR 操作，每次操作耗时约 1-2 微秒
-
总耗时约 1-2 毫秒，所有客户端陆续收到响应
-
全程无锁，CPU 高效执行
Tair 的处理流程：
-
1000 个请求到达 Tair 服务器
-
多个工作线程（假设 8 个）接收请求
-
所有线程发现要操作同一个 key "counter"，竞争同一把锁
-
只有 1 个线程获得锁，执行 INCR 操作，其他 7 个线程阻塞等待
-
第一个线程完成后释放锁，第二个线程获得锁并执行
-
1000 个操作实际上是串行执行的，但每次操作还要加上锁的获取和释放开销（可能增加几微秒到几十微秒）
-
总耗时可能达到 5-10 毫秒甚至更长，延迟显著增加
架构选择的权衡
Redis 的单线程模型看似"落后"，但在缓存场景下反而是最优解。因为缓存操作通常都是简单的内存读写，执行速度极快，瓶颈往往在网络 I/O 而非 CPU 计算。单线程避免了并发控制的复杂性，代码更简洁，bug 更少，性能反而更高。
Tair 选择多线程架构，可能是为了支持更复杂的操作或更好的可扩展性，但在处理高并发简单请求时，锁机制成为了性能瓶颈。这也解释了为什么 Tair的性能阈值低于 Redis。
实际应用中，如果业务存在明显的热点 key 访问模式，Redis 的架构优势会更加明显。而如果访问模式非常分散，没有热点 key，Tair 的多线程架构理论上可以更好地利用多核 CPU，但这种理想情况在实际缓存场景中比较少见。