一、核心配置参数建议（针对你的3主3从集群+30应用线程场景） #

先明确每个参数的作用，再给出适配场景的具体建议：

• setNettyThreads：这是Redisson负责Redis命令IO处理的核心线程池，承担Socket连接的读写、Redis命令编解码、响应解析等所有网络相关工作。
  建议值：设置为CPU核心数的2-4倍即可（比如8核CPU设16-32）。不需要和应用线程数（30）完全匹配，因为Netty采用NIO Reactor模式，单个Netty线程可以同时处理多个连接的IO事件，多个应用线程的请求能复用同一个Netty线程。
• setMasterConnectionPoolSize / setSlaveConnectionPoolSize：这是Redisson为每个Redis主/从节点维护的物理TCP连接池大小，用于提供和Redis节点的通信通道。
  建议值：至少等于你的应用线程数（30），或者稍高（比如30-50）。原因是：高峰时30个应用线程可能同时发起Redis命令，每个线程需要一个空闲连接来执行请求，设置与应用线程数相当的大小可以避免连接等待。同时要注意Redis服务端的maxclients配置，总连接数（3个主节点×主池大小 + 3个从节点×从池大小）不要超过Redis的最大连接限制。

二、Netty线程与连接池的关系 #

• 多个应用线程完全可以复用同一个Netty线程：Netty的NIO Reactor模式下，一个Netty线程（Selector线程）可以监听多个Socket连接的IO事件，同时处理多个请求的网络读写和编解码工作，不需要为每个应用线程分配独立的Netty线程。
• 连接池是物理TCP连接的集合，每个连接会绑定到一个Netty线程（Selector）。两者没有严格的比例要求，但要保证Netty线程数足够支撑连接池的IO负载（比如不要用2个Netty线程处理100个连接的IO，会成为瓶颈）。

三、单个RMapCache命令的连接/Netty线程使用情况（无批处理） #

针对你给出的单命令代码：

RMapCache<String, String> cacheMap = client.getMapCache("data");
cacheMap.put("k1", "v111"); // 单个put命令
cacheMap.get("k2"); // 单个get命令

在无批处理的情况下，单个put/get调用只会使用1个连接和1个Netty线程：

1. Redisson根据键的哈希值，路由到集群中对应的Redis主节点；
2. 从该主节点的连接池中获取一个空闲连接；
3. 这个连接绑定的Netty线程负责处理该命令的编解码、网络发送、响应接收和结果解析；
4. 命令执行完成后，连接归还到连接池，Netty线程继续处理其他连接的IO事件。

四、setThreads参数的作用（非RTopic等场景） #

你的理解是正确的：setThreads()的核心作用是处理RTopic消息监听器、RRemoteService请求、RExecutorService任务这些用户级异步逻辑。

• 如果你完全没有使用这些组件，确实可以把这个参数设为非常低的值（比如1-2），不会影响常规的Redis命令操作（比如RMapCache的get/put）。
• Redisson内部不会将这个线程池用于常规的Redis命令IO处理（这些工作由Netty线程池负责），也没有其他必须依赖该线程池的核心内部逻辑，所以低数值设置是安全的。

额外补充注意点 #

• 你使用的是单例RedissonClient，所有应用线程共享这个客户端的连接池和Netty线程池，所以配置要覆盖整个应用的并发请求量；
• 后续可以通过Redisson的Metrics或JMX监控连接池使用率，根据实际高峰情况调整连接池大小；
• 确保Redis服务端的maxclients值大于Redisson的总连接数（每个主从节点的连接池大小×节点数），避免Redis拒绝新连接。

内容来源于stack exchange