1. 为什么我要用Netty手写一个Redis服务端
第一次冒出这个念头，是在做一个本地缓存中间件压测的时候。当时项目里用的是一个轻量级的缓存组件，接口是自定义的，测试脚本得单独写一套，而团队里其他人早就习惯了用redis-cli直接敲命令。每次联调，我都得在旁边解释“这个不是Redis，命令不一样”，说多了自己也烦。后来我想，干脆让这个缓存组件直接说Redis协议算了，这样任何现成的Redis客户端、压测工具、监控面板都能直接接进来，零学习成本。
这个想法落地之后，我发现事情比想象中有意思得多。Redis协议（RESP，REdis Serialization Protocol）本身设计得非常克制，它只有五种基本类型，解析逻辑用几百行代码就能覆盖大部分场景。而Netty作为高性能网络框架，天然适合处理这种“请求-响应”式的短连接或长连接协议。两者结合，你可以在一个下午的时间里，搭出一个能响应PING、SET、GET、AUTH等基础命令的服务端，并且用官方redis-cli就能连上去操作。
这篇文章要聊的，就是这条路径上的完整实现过程。我会从协议解析的底层细节讲起，把密码验证（AUTH）这个容易被忽略但实际部署中绕不开的环节拆开揉碎，再给出可以直接跑的Netty Handler代码和踩坑记录。适合已经有Java基础、了解Netty基本概念（Channel、Pipeline、ByteBuf）的读者，也适合单纯想搞清楚“Redis客户端和服务端到底在聊什么”的开发者。如果你之前没接触过Netty，我会在关键位置补充必要的背景知识，保证你能跟上。
需要提前说明的是，这里实现的是一个协议兼容层，不是要替代Redis。它的价值在于：当你有一个自研的存储或缓存系统，想让它快速获得Redis生态的兼容性时，这套代码可以直接拿来改。密码验证部分也是同理，它解决的是“如何在不引入完整Redis安全模块的前提下，实现一个够用的认证门槛”。
2. RESP协议拆解与Netty解码器设计
2.1 RESP协议的数据类型与编码规则
RESP协议的核心思想是：用第一个字节标识数据类型，用CRLF（\r\n）作为分隔符。客户端发给服务端的命令，统一是“数组”类型，数组里每个元素是“批量字符串”类型。服务端返回的结果，则根据情况使用简单字符串、错误、整数、批量字符串或数组。
先看客户端发来的一个典型命令，比如SET name zhangsan，它在网络上传输的字节序列是这样的：
*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$8\r\nzhangsan\r\n拆开看：
*3\r\n：数组标记，表示后面有3个元素$3\r\nSET\r\n：第一个元素，批量字符串，长度3，内容是SET$4\r\nname\r\n：第二个元素，长度4，内容是name$8\r\nzhangsan\r\n：第三个元素，长度8，内容是zhangsan
服务端返回+OK\r\n表示成功，返回-ERR unknown command\r\n表示错误，返回$5\r\nhello\r\n表示一个长度为5的字符串值。
这里有个细节值得注意：批量字符串的长度是字节长度，不是字符长度。如果值里包含中文，比如SET city 北京，“北京”两个字的UTF-8编码是6个字节，那么长度标记就是$6而不是$2。这个坑我在第一次实现时踩过，当时用String.length()去算长度，结果中文全部乱码。正确做法是用ByteBuf.readableBytes()或者先把字符串转成字节数组再取length。
2.2 为什么选择继承ByteToMessageDecoder
Netty提供了多种解码器基类，我选ByteToMessageDecoder而不是ReplayingDecoder，理由有两个。第一，ReplayingDecoder虽然写起来简单，但它依赖异常控制流，在数据不完整时会抛异常然后重试，性能上不如手动判断可读字节数来得直接。第二，Redis协议的解码逻辑本身不复杂，手动检查readableBytes()完全可控，而且调试时能清楚知道当前缓冲区里还剩多少数据。
解码器的核心逻辑是：在decode方法里循环尝试解析，直到剩余字节不足以构成一个完整命令为止。每次解析出一个完整的命令（一个List<String>或byte[][]），就把它加到out列表里，Netty会继续调用后续的Handler处理。
这里的关键判断是“剩余字节是否足够”。对于数组类型，至少需要读到*和后面的数字以及CRLF；对于批量字符串，需要读到$、长度数字、CRLF、内容、CRLF。如果任何一步发现字节不够，就return，等待下一次数据到达。Netty会在更多数据到来时再次调用decode。
2.3 内联命令与协议兼容性处理
除了标准的数组格式，Redis还支持一种“内联命令”（Inline Command），就是直接在telnet里敲PING\r\n这种不带*标记的格式。虽然官方客户端不会用这种格式，但为了调试方便（比如用telnet或nc直接连上去测试），我建议在解码器里加一个分支：如果第一个字节不是*、$、+、-、:中的任何一个，就按内联命令处理，按空格切分，取第一个词作为命令名。
这个兼容处理花不了二十行代码，但调试体验提升巨大。我经常在服务端跑起来之后，直接telnet localhost 6379，然后敲PING看返回，比写测试用例快得多。
2.4 解码器的完整实现与边界情况
下面是我实际使用的解码器核心代码，基于Netty 4.1.x：
public class RedisCommandDecoder extends ByteToMessageDecoder { @Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) { if (in.readableBytes() <= 0) { return; } in.markReaderIndex(); byte first = in.readByte(); if (first == '*') { // 数组格式 int numArgs = readInt(in); if (numArgs == -1) { in.resetReaderIndex(); return; } List<byte[]> args = new ArrayList<>(numArgs); for (int i = 0; i < numArgs; i++) { if (in.readableBytes() < 1) { in.resetReaderIndex(); return; } byte dollar = in.readByte(); if (dollar != '$') { throw new RedisProtocolException("expected $ but got " + dollar); } int len = readInt(in); if (len == -1 || in.readableBytes() < len + 2) { in.resetReaderIndex(); return; } byte[] arg = new byte[len]; in.readBytes(arg); in.skipBytes(2); // skip CRLF args.add(arg); } out.add(args); } else { // 内联命令处理 in.resetReaderIndex(); String line = readLine(in); if (line == null) { return; } String[] parts = line.trim().split("\\s+"); List<byte[]> args = new ArrayList<>(); for (String p : parts) { args.add(p.getBytes(StandardCharsets.UTF_8)); } out.add(args); } } private int readInt(ByteBuf in) { int value = 0; boolean negative = false; while (in.readableBytes() > 0) { byte b = in.readByte(); if (b == '\r') { if (in.readableBytes() > 0 && in.readByte() == '\n') { return negative ? -value : value; } return -1; } if (b == '-') { negative = true; continue; } if (b < '0' || b > '9') { return -1; } value = value * 10 + (b - '0'); } return -1; } private String readLine(ByteBuf in) { int readable = in.readableBytes(); for (int i = 0; i < readable; i++) { if (in.getByte(in.readerIndex() + i) == '\n') { byte[] line = new byte[i]; in.readBytes(line); in.skipBytes(1); return new String(line, StandardCharsets.UTF_8).trim(); } } return null; } }这段代码里有两个容易出问题的地方。第一，readInt在遇到不完整数据时返回-1，调用方必须resetReaderIndex()，否则读指针就乱了。第二，readLine里我用getByte而不是readByte来扫描，避免在没找到换行符时移动读指针。这些细节在单元测试里不容易暴露，但在真实网络环境下（数据分片到达）非常关键。
3. 密码验证（AUTH）的实现细节与安全考量
3.1 Redis的AUTH命令交互流程
密码验证在Redis协议里是通过AUTH命令完成的。客户端发送AUTH password，服务端检查密码是否正确，返回+OK或-ERR invalid password。如果服务端配置了密码但客户端没认证就发其他命令，服务端应该返回-NOAUTH Authentication required.。
这里有个设计选择：是每个连接独立维护认证状态，还是全局共享？显然是每个连接独立。在Netty里，这可以通过Channel.attr()或者直接在Handler里维护一个boolean authenticated字段来实现。我选后者，因为Handler本身是@Sharable的（无状态），但认证状态是per-connection的，所以每个连接会创建新的Handler实例，字段自然隔离。
3.2 认证状态机的设计
认证逻辑可以抽象成一个简单的状态机：
| 当前状态 | 收到命令 | 条件 | 下一状态 | 响应 |
|---|---|---|---|---|
| 未认证 | AUTH | 密码正确 | 已认证 | +OK |
| 未认证 | AUTH | 密码错误 | 未认证 | -ERR invalid password |
| 未认证 | 其他命令 | - | 未认证 | -NOAUTH Authentication required. |
| 已认证 | AUTH | 任意 | 已认证 | +OK（或重新验证） |
| 已认证 | 其他命令 | - | 已认证 | 正常处理 |
这个状态机在Handler的channelRead方法里实现，大概十几行代码。需要注意的是，AUTH命令本身在未认证状态下必须放行，否则就死锁了。
3.3 密码存储与比较的安全实践
密码怎么存？最直接的方式是明文写在配置文件里，但这样一旦配置文件泄露，密码就暴露了。稍微好一点的做法是存SHA-256哈希值，认证时把客户端传来的密码做哈希再比较。但这里有个陷阱：哈希比较必须用恒定时间比较函数，否则可能被时序攻击（timing attack）推断出密码。
Java里可以用MessageDigest.isEqual()，它在内部实现了恒定时间比较。如果你自己写Arrays.equals()，理论上存在被逐字节推断的风险。虽然对于一个内部服务来说，这种攻击的实际威胁不大，但养成好习惯没坏处。
另一个实践是：支持通过环境变量注入密码，而不是硬编码在代码或配置文件里。这样在容器化部署时，密码可以通过Secret管理，不会出现在镜像层里。
3.4 认证失败的限流与防暴力破解
如果服务暴露在可被外部访问的网络上，AUTH命令就成了暴力破解的入口。我建议加一个简单的限流：同一个连接连续认证失败超过N次（比如5次），直接关闭连接。更严格一点，可以按IP维度做限流，但那就需要引入额外的状态存储了。
在Netty里实现连接级别的失败计数很简单，Handler里加一个int authFailCount字段，每次失败递增，达到阈值就ctx.close()。这个逻辑不复杂，但能挡住大部分脚本小子的暴力尝试。
3.5 认证Handler的代码实现
public class RedisAuthHandler extends ChannelInboundHandlerAdapter { private final String passwordHash; private boolean authenticated = false; private int authFailCount = 0; private static final int MAX_AUTH_FAIL = 5; public RedisAuthHandler(String passwordHash) { this.passwordHash = passwordHash; } @Override public void channelRead(ChannelHandlerContext ctx, Object msg) { List<byte[]> args = (List<byte[]>) msg; String command = new String(args.get(0), StandardCharsets.UTF_8).toUpperCase(); if ("AUTH".equals(command)) { if (args.size() != 2) { ctx.writeAndFlush(errorReply("wrong number of arguments for 'auth' command")); return; } String inputHash = sha256(new String(args.get(1), StandardCharsets.UTF_8)); if (MessageDigest.isEqual(inputHash.getBytes(), passwordHash.getBytes())) { authenticated = true; authFailCount = 0; ctx.writeAndFlush(simpleStringReply("OK")); } else { authFailCount++; if (authFailCount >= MAX_AUTH_FAIL) { ctx.close(); } else { ctx.writeAndFlush(errorReply("invalid password")); } } return; } if (!authenticated) { ctx.writeAndFlush(errorReply("NOAUTH Authentication required.")); return; } ctx.fireChannelRead(msg); } private String sha256(String input) { try { MessageDigest md = MessageDigest.getInstance("SHA-256"); byte[] digest = md.digest(input.getBytes(StandardCharsets.UTF_8)); StringBuilder sb = new StringBuilder(); for (byte b : digest) { sb.append(String.format("%02x", b)); } return sb.toString(); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(e); } } private ByteBuf simpleStringReply(String s) { return Unpooled.copiedBuffer("+" + s + "\r\n", StandardCharsets.UTF_8); } private ByteBuf errorReply(String s) { return Unpooled.copiedBuffer("-" + s + "\r\n", StandardCharsets.UTF_8); } }这段代码里，MessageDigest.isEqual保证了比较的恒定时间特性，MAX_AUTH_FAIL限制了暴力尝试次数。注意ctx.fireChannelRead(msg)把消息传递给后续的业务Handler，这样认证和业务逻辑就解耦了。
4. Netty服务端组装与命令路由
4.1 Pipeline的编排顺序
Netty的Pipeline是一个责任链，入站事件从头部向尾部传播。对于Redis服务端，我建议的顺序是：
RedisCommandDecoder：把ByteBuf解码成List<byte[]>RedisAuthHandler：认证检查，未通过则拦截RedisCommandHandler：命令路由与业务处理
出站方向不需要额外的编码器，因为我在业务Handler里直接构造ByteBuf写回。这样做的原因是Redis的响应格式简单，手动拼装比写一个通用编码器更直观，也更容易针对不同命令做优化。
4.2 命令路由表的设计
命令路由的核心是一个Map<String, CommandHandler>，key是命令名（大写），value是处理逻辑。每个CommandHandler是一个函数式接口，接收List<byte[]>参数和ChannelHandlerContext，返回响应。
@FunctionalInterface public interface CommandHandler { ByteBuf handle(List<byte[]> args, ChannelHandlerContext ctx); }注册命令时：
Map<String, CommandHandler> handlers = new HashMap<>(); handlers.put("PING", (args, ctx) -> simpleStringReply("PONG")); handlers.put("SET", this::handleSet); handlers.put("GET", this::handleGet); handlers.put("DEL", this::handleDel); handlers.put("EXISTS", this::handleExists);这种设计的好处是扩展方便，加一个新命令只需要写一个方法然后注册进去。对于不支持的命令，统一返回-ERR unknown command。
4.3 存储引擎的选型与线程安全
既然是模拟Redis，总得有个地方存数据。最简单的选择是ConcurrentHashMap<byte[], byte[]>，但byte[]作为key时，hashCode()是基于数组地址的，两个内容相同的数组会被认为是不同的key。所以要么用String作为key（把字节数组转成字符串），要么自己封装一个ByteArrayWrapper实现equals和hashCode。
我选String作为key，因为大部分场景下key都是可读的字符串，而且String的哈希缓存机制性能更好。值用byte[]，保留二进制安全特性。存储结构就是ConcurrentHashMap<String, byte[]>。
过期时间怎么处理？如果只是做协议兼容层，可以先不支持EXPIRE，或者用一个简单的延迟队列。我在这里先不展开，因为那会引入额外的复杂度，偏离“协议解析与认证”这个核心主题。
4.4 响应编码的细节
Redis的响应有五种类型，对应不同的首字节：
| 类型 | 首字节 | 示例 | 用途 |
|---|---|---|---|
| 简单字符串 | + | +OK\r\n | 状态回复 |
| 错误 | - | -ERR msg\r\n | 错误信息 |
| 整数 | : | :1000\r\n | 计数、长度 |
| 批量字符串 | $ | $5\r\nhello\r\n | 值 |
| 数组 | * | *2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n | 列表 |
对于GET命令，如果key不存在，Redis返回的是$-1\r\n（空批量字符串），而不是空字符串。这个区别在客户端解析时很重要，redis-cli会把$-1显示为(nil)，而$0\r\n\r\n显示为空字符串。我在实现时专门处理了这种情况。
4.5 服务端启动类的完整代码
public class RedisServer { private final int port; private final String passwordHash; public RedisServer(int port, String password) { this.port = port; this.passwordHash = sha256(password); } public void start() throws InterruptedException { EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline() .addLast(new RedisCommandDecoder()) .addLast(new RedisAuthHandler(passwordHash)) .addLast(new RedisCommandHandler()); } }) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.SO_KEEPALIVE, true); ChannelFuture f = b.bind(port).sync(); System.out.println("Redis-compatible server started on port " + port); f.channel().closeFuture().sync(); } finally { workerGroup.shutdownGracefully(); bossGroup.shutdownGracefully(); } } }启动之后，你可以直接用redis-cli -p 6379连接，先AUTH yourpassword，然后SET、GET都能正常工作。
5. 实操中踩过的坑与排查技巧
5.1 半包与粘包问题
TCP是流式协议，不保证一次read就能拿到一个完整的命令。我遇到过一个典型场景：客户端发送SET key value，但网络层把它拆成了两个TCP包，第一个包只有*3\r\n$3\r\nSET\r\n，第二个包才是剩下的。如果解码器没有正确处理“数据不完整”的情况，就会解析失败。
我的解码器里用markReaderIndex()和resetReaderIndex()来应对这种情况：每次尝试解析前先标记读指针，如果发现数据不够就重置回去，等下次数据到达再重新解析。这个模式在Netty的很多官方解码器里都能看到，是处理半包问题的标准做法。
粘包则是另一个方向：客户端连续发送多个命令，它们可能在同一个TCP包里到达。解码器的decode方法会被循环调用，每次解析出一个命令就加到out列表，直到剩余字节不够为止。Netty会自动处理这个循环，你只需要保证每次decode调用最多消费一个完整命令即可。
5.2 中文乱码与字节长度计算
前面提过，批量字符串的长度是字节长度。我最初用String.length()计算，结果SET city 北京返回的值是乱码。后来改成value.getBytes(StandardCharsets.UTF_8).length，问题解决。
还有一个隐藏更深的问题：读取时也要按字节读。如果你用ByteBuf.toString(Charset)，Netty会按指定的字符集解码，这通常没问题。但如果你先readBytes(byte[])再new String(bytes)，一定要指定字符集，否则会用平台默认字符集，在Windows和Linux上行为不一致。
5.3 AUTH命令的大小写问题
Redis命令是大小写不敏感的，AUTH、auth、Auth都应该被识别。我在Handler里统一用toUpperCase()转换后再比较。但要注意，密码本身是大小写敏感的，不能对密码做大小写转换。这个坑我在测试时踩过，当时把整个命令数组都转了大写，结果密码里的字母全变了，认证一直失败。
5.4 连接关闭时的资源释放
Netty的ByteBuf是引用计数的，如果解码器里创建了ByteBuf但没有正确释放，会导致内存泄漏。我的做法是：解码器只负责解析，不创建新的ByteBuf；业务Handler里创建的响应ByteBuf通过ctx.writeAndFlush()发送，Netty会自动释放。如果你在Handler里手动retain()了某个ByteBuf，记得在channelInactive或exceptionCaught里release()。
一个简单的排查方法是：在启动参数里加-Dio.netty.leakDetection.level=paranoid，Netty会在检测到泄漏时打印详细的堆栈信息，告诉你哪个ByteBuf没被释放。
5.5 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 客户端连接后无响应 | Pipeline里没有Handler处理 | 加日志看channelRead是否被调用 | 检查Handler是否添加到Pipeline |
| 返回乱码 | 字符集不匹配 | 打印原始字节数组 | 统一用UTF-8 |
| 认证一直失败 | 密码被转大写或哈希不一致 | 打印哈希值对比 | 密码不做大小写转换 |
| 半包导致解析异常 | 解码器没处理数据不完整 | 模拟分片发送 | 用mark/resetReaderIndex |
| 内存泄漏警告 | ByteBuf未释放 | 开启paranoid泄漏检测 | 检查retain/release配对 |
| 中文key找不到 | 字节长度计算错误 | 打印key的字节长度 | 用getBytes().length |
5.6 性能调优的几个实操建议
第一，解码器里避免创建多余对象。每次解析都new ArrayList和new byte[]是必要的，但可以用对象池或者ThreadLocal缓存来减少GC压力。不过对于大多数场景，这点开销可以忽略，先保证正确性再优化。
第二，响应可以用Unpooled.wrappedBuffer包装已有的字节数组，避免拷贝。比如+OK\r\n这种固定响应，可以预先生成一个静态的ByteBuf，每次直接retainedDuplicate()返回。但要注意引用计数，别把同一个ByteBuf写多次导致释放问题。
第三，合理设置SO_BACKLOG和SO_KEEPALIVE。SO_BACKLOG控制等待连接队列的长度，默认128对于大多数场景够用。SO_KEEPALIVE开启后，TCP层会定期发送心跳包，检测死连接。对于长连接场景，建议开启。
第四，考虑使用EpollEventLoopGroup替代NioEventLoopGroup（Linux环境下）。Epoll在Linux上性能更好，尤其是连接数较多时。Netty提供了Epoll.isAvailable()来判断当前环境是否支持。
6. 从协议兼容到生产可用的扩展思路
6.1 支持更多命令的优先级排序
如果你打算把这个服务端用到实际项目里，命令支持的优先级大概是：
- 连接类：
PING、AUTH、SELECT、QUIT——这些是客户端握手必需的 - 字符串类：
SET、GET、DEL、EXISTS、EXPIRE、TTL——最常用的数据操作 - 哈希类：
HSET、HGET、HDEL、HGETALL——结构化数据场景 - 列表类：
LPUSH、RPUSH、LRANGE、LPOP——队列场景 - 管理类：
INFO、CONFIG GET、CLIENT LIST——监控和运维
每类命令的实现模式都类似：解析参数、操作存储、构造响应。真正花时间的是边界情况的处理，比如SET的EX、PX、NX、XX选项，EXPIRE的秒级和毫秒级精度等。
6.2 持久化的最小可行方案
如果数据不能丢，最简单的持久化方案是定期把ConcurrentHashMap序列化到磁盘。可以用Java的序列化，也可以用JSON、MessagePack等格式。恢复时反序列化回来。这个方案不保证强一致性，但对于缓存场景通常够用。
更进一步的方案是追加日志（AOF）：每个写命令都追加到一个文件里，重启时重放。实现起来也不复杂，在命令Handler里加一个appendToLog调用即可。但要注意日志文件的滚动和压缩，否则文件会无限增长。
6.3 监控指标的暴露
生产环境需要知道服务端的运行状态。最简单的做法是实现INFO命令，返回连接数、命令执行次数、内存使用量等。Netty的ChannelGroup可以帮你管理所有活跃连接，方便统计连接数。命令执行次数可以用LongAdder计数，性能比AtomicLong好。
如果你有Prometheus监控体系，可以额外暴露一个HTTP端口，用/metrics路径返回指标。Netty本身也能处理HTTP，但引入额外的协议栈会增加复杂度，建议用轻量级的HTTP服务器库单独跑一个端口。
6.4 集群与高可用的边界
单机版的协议兼容层做到一定程度后，可能会遇到单点问题。这时候可以考虑：
- 主从复制：把写命令转发到从节点，从节点重放。Redis的复制协议也是基于RESP的，实现起来有迹可循。
- 分片：客户端根据key做哈希，路由到不同的服务端实例。这个逻辑可以放在客户端SDK里，服务端不需要感知。
- 故障转移：引入一个协调组件来检测节点健康状态，主节点挂掉后切换从节点。这部分复杂度较高，建议先评估是否真的需要。
我的建议是：先把单机版做稳定，把协议解析和认证逻辑打磨好。集群和高可用是另一个量级的工程问题，不要一开始就陷进去。
6.5 测试策略与工具推荐
测试Redis协议兼容性，最直接的工具就是redis-cli和redis-benchmark。redis-cli可以交互式验证命令，redis-benchmark可以压测性能。我通常的测试流程是：
- 用
redis-cli手动跑一遍所有支持的命令，确认响应格式正确 - 用
redis-benchmark -t set,get -n 10000 -c 50压测，看QPS和延迟 - 写JUnit测试，用Netty的
EmbeddedChannel做单元测试，覆盖半包、粘包、认证失败等边界情况 - 用
telnet测试内联命令，确认调试通道可用
EmbeddedChannel是Netty提供的测试利器，它不需要真实的网络连接，直接把数据写入Channel就能触发Pipeline处理。对于解码器和Handler的单元测试，这是最高效的方式。
6.6 一个容易忽略的细节：SELECT命令
Redis客户端连接后会默认使用0号数据库，但有些客户端会发送SELECT 0来显式选择。如果你的服务端不支持SELECT，客户端可能会报错。最简单的处理是：收到SELECT命令时，无论参数是什么，都返回+OK，因为你的存储引擎可能只有一个“数据库”。这样客户端就不会因为不支持的命令而中断。
类似地，CLIENT SETNAME、CONFIG GET等命令也可以返回一个合理的默认值，而不是报错。这种“宽容处理”策略能提高兼容性，让更多客户端能正常连接。
6.7 日志与调试技巧
在开发阶段，我建议在解码器和Handler里加详细的日志，打印收到的原始字节和解析后的命令。Netty自带的LoggingHandler可以打印Pipeline里流转的事件，但它的输出比较冗长。更实用的做法是自己写一个简单的日志Handler，只打印命令名和参数数量。
对于生产环境，日志级别要调高，避免打印敏感信息（比如AUTH的密码）。可以在认证Handler里对AUTH命令做特殊处理，只记录“认证成功/失败”，不记录密码内容。
我在实际调试时发现，用Wireshark抓包看RESP协议的原始字节是最直观的方式。虽然大部分时候不需要走到这一步，但当客户端行为诡异时，抓包能帮你快速定位是客户端发错了还是服务端解析错了。
6.8 关于线程模型的思考
Netty的NioEventLoopGroup默认线程数是CPU核心数乘以2。对于Redis这种内存操作，业务逻辑执行很快，瓶颈通常在网络IO上。所以worker线程数不需要太多，默认值通常够用。但如果你的命令处理里有阻塞操作（比如读写磁盘），就需要把这些操作放到单独的线程池里，避免阻塞EventLoop。
一个常见的错误是在Handler里直接做阻塞调用，比如Thread.sleep()或者同步IO。这会导致该EventLoop上的所有连接都被卡住。正确的做法是：把阻塞操作提交到DefaultEventExecutorGroup，或者用ctx.executor().submit()异步执行。
6.9 协议版本兼容性
RESP协议目前有两个版本：RESP2和RESP3。RESP3引入了更多数据类型（比如Map、Set、Double等），但大部分客户端默认还是用RESP2。如果你只实现RESP2，兼容性已经足够好。如果客户端发送HELLO 3尝试切换到RESP3，你可以返回一个错误，客户端会自动回退到RESP2。
我在实现时选择只支持RESP2，因为RESP3的额外类型对于基础缓存场景不是必需的，而且会增加解码器的复杂度。这个取舍取决于你的目标场景：如果只是做缓存兼容，RESP2足够；如果要支持更丰富的数据结构，再考虑RESP3。
6.10 最后分享一个调试小技巧
当你用redis-cli连接自研服务端时，如果遇到奇怪的错误，可以在启动redis-cli时加上--no-raw参数，它会以更可读的格式显示响应。另外，redis-cli的MONITOR命令可以打印服务端收到的所有命令，但需要服务端支持MONITOR。如果你实现了这个命令，调试会方便很多。
还有一个技巧：在服务端的RedisCommandHandler里，对每个命令都记录执行时间。如果某个命令耗时异常，日志里能直接看出来。这对于排查性能问题很有帮助，尤其是当你不确定瓶颈在解析、路由还是存储操作时。
整个项目从协议解析到认证再到命令路由，核心代码量其实不大，但涉及的知识点很密集：TCP粘包半包、字节序、字符集、哈希安全、Netty线程模型、引用计数。每一个点单独看都不难，但组合在一起时，任何一个细节出错都会导致诡异的现象。我的经验是：先把解码器写对，用单元测试覆盖各种分片情况；再加认证，确保状态机清晰；最后加命令处理，从最简单的PING开始，逐步扩展。这样每一步都有验证，不会在最后调试时面对一堆问题无从下手。
