GeminiDB Redis实例的CPU与带宽未达瓶颈，但QPS并发上不去？

与传统的内存型缓存Redis不同，GeminiDB Redis定位为持久化数据库。其写入操作需要落盘（采用WAL + SST的机制），而读取操作在缓存未命中时也需要访问磁盘，因此单次操作的延迟通常较高，这导致了单连接的QPS通常低于缓存Redis。

然而，由于GeminiDB Redis采用了多线程架构（包括IO线程与Worker线程池），在资源（例如CPU或带宽）未饱和的情况下，可以通过以下方式显著提升并发吞吐能力：

• 增加客户端连接数

  单连接请求是串行处理的。例如，1000个请求通过一个连接逐一执行；如果改为通过10个并发连接发送这些请求，可以充分利用多核资源，从而使整体吞吐能力线性提升。

• 使用Pipeline批量发送命令

  Pipeline可将多个命令一次性发送到服务端。得益于GeminiDB Redis的多线程处理模型，IO线程接收命令后会将其分发至多个Worker线程并行执行，从而大大缩短批量请求的处理时间，并有效提升吞吐能力。

  

  在实际应用中，需要合理设置每批命令的发送量，以避免因总执行时间过长而导致的客户端超时，或个别慢命令阻塞整批响应。具体设置建议可参考Pipeline访问GeminiDB Redis。