KV存储网络架构三层拆解：IO、协议与组网

接手过不少KV存储相关的活之后，我有一个很深的感触：很多人不是不会用Redis、etcd这类现成组件，而是当业务要求“把KV存储接入我们自己的网络体系”时，一下子就卡住了。卡住的原因通常不是存储本身，而是“网络架构”这四个字太宽泛。有人要你走gRPC统一微服务治理，有人要你用Proxy做多集群路由，还有人要求存储节点之间必须组多副本强一致。这些诉求听起来是同一件事，其实根本不在同一个网络层次上。这篇文章我就拿KV存储作为主线，把这几年在接入不同网络架构时踩过的坑、验证过的方案，一层一层拆开讲清楚。

1. 先拆清楚：KV存储里的“网络架构”到底指什么

如果你跟十个人聊“KV存储的网络架构”，可能会得到十种不同的答案。有人说的是客户端连服务端用TCP还是HTTP，有人说的是要不要在中间加一层代理，有人说的则是底层节点之间怎么同步数据。这些其实不是一个层面的问题。我习惯把KV存储的网络架构拆成三个层次来看：单机的IO模型、客户端与存储之间的接入协议、分布式节点之间的组网方式。

1.1 三个层次分别管什么事

第一个层次是单机上的网络IO模型。一个KV进程监听端口之后，怎么从内核拿到请求数据、怎么把响应写回去，是来一个连接就开一个线程，还是用epoll这种事件驱动方式统一管理，这决定了单机能扛住多少并发连接、延迟能做到多低。典型的例子就是Redis，单线程模型配epoll，依然能在普通服务器上跑出十万级QPS。

第二个层次是接入协议。客户端发过来的请求是RESP这种文本协议，还是Protobuf序列化的二进制协议，或者是HTTP/JSON，直接关系到解析开销、可调试性、多语言客户端友好度。很多KV存储的系统设计文档里都会把这一层单拎出来。

第三个层次是节点间组网。数据量大了之后，单机放不下，就需要把数据分片部署在多台机器上；为了高可用，还得做副本复制、故障转移。这些节点之间怎么互相发现、怎么路由请求、怎么达成一致共识，就是分布式网络架构要解决的问题。

1.2 为什么集成的时候总是一团乱麻

我见过很多集成项目翻车，根本原因不是技术选型不对，而是把这三个层次混在一起讨论。比如有人想在KV集群后面加一个接入网关，理由是客户端要统一走内部RPC框架，这属于第二层和协议相关；结果讨论着讨论着，又变成了要不要引入Proxy做分片路由，这就跳到第三层去了。两个问题混在一起，方案自然越聊越乱。

我的习惯是拿到需求先问一个问题：你是在解决单机接入，还是在解决多节点协作？前者是IO模型和协议的事，后者是组网拓扑的事。把这两个问题拆开之后，KV存储的网络集成才不会变成一个无底洞。

2. IO模型选型：BIO、epoll、Reactor，延迟是被这一层卡脖子的

很多KV存储的初版实现，最自然的写法就是来一个客户端连接，启动一个线程处理。这就是最经典的BIO模型。业务量小的时候跑得挺好，一旦连接数上来，线程数量飙升，CPU时间全耗在线程切换上，延迟跟着一起崩。这就是所谓的C10K问题：当并发连接数达到上万级别，传统的“一连接一线程”模型就撑不住了。

2.1 从BIO到事件驱动

要理解为什么KV存储特别吃IO模型，先要知道KV服务的请求特征。KV存储的请求大多是短小精悍的get和set，一次请求处理在内存里可能只需要几十微秒。相比之下，网络传输、线程调度的开销反而占了很大比重。换句话说，KV存储本质上是IO密集型服务，不是CPU密集型。这时候用事件驱动模型，让一个线程同时盯着成千上万个连接，哪个连接有数据来了就去处理哪个，就比盲目加线程高效得多。

Linux下最常用的就是epoll。它做的事情可以通俗地理解为：你把一堆socket文件描述符交给内核，然后睡觉，内核发现有连接可读可写时叫醒你，告诉你具体是哪一个fd。用代码写出来，就是一个事件循环的大致结构：

python复制import selectors
import socket

sel = selectors.DefaultSelector()

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server.bind(("0.0.0.0", 8888))
server.listen(128)
server.setblocking(False