在 Lavik 0.1.0 中使用 Redis 连接池

保留客户端，扩展数据集。

Redis 数据集增长，不应迫使你重新设计应用的每个连接。Lavik 0.1.0 使用 RESP2、RESP3 协议，在内存中保留紧凑索引，将值存于 NVMe SSD。Redis 客户端仍是应用的访问入口。对于使用连接池的服务，集成的重点是选择正确客户端模式，并明确每个连接的使用边界。

先选择路由模式，再决定连接池大小

托管 Single 使用一个 Group 覆盖键空间，支持全部 16 个逻辑数据库，不采用 Cluster 风格的 MOVED 路由。托管 Cluster 使用 DB0 与 Redis Cluster 路由，多键请求遵循同槽规则。让客户端的单实例或 Cluster 连接方式对应部署模式。这一选择决定发现与路由方式，增加池内连接数不会改变它。

一致地初始化每个新连接

Lavik 的连接以 RESP2 语义开始，并支持协商 RESP3。认证、所选数据库与事务状态属于连接。应在客户端创建连接的路径中配置初始化，使替换后的连接获得相同协议、认证与数据库设置。需要特定连接状态的请求，应使用由客户端明确管理生命周期的连接。

流水线与普通请求池有不同的响应消费规则。多个请求先后复用连接时，每个调用方都必须在交出连接前消费自己的响应。超时后若仍有未解决的响应，应按客户端库支持的方式丢弃或排空连接。是否重试写操作由应用决定：仅凭本地超时，不能确定服务端是否已执行写入。

为长时间操作管理独立的连接生命周期

Pub/Sub 订阅与阻塞请求占用连接的时间，可能远长于一次画像查询。将这些生命周期与用于短请求、短响应的连接池分开。Lavik 在连接所属工作线程维护订阅者状态，并限制订阅者输出；应用应通过客户端库处理重连与恢复订阅。

按实际吞吐量需求设置并发

连接池限制的是并发，并不等于容量规划。Lavik 的工作线程调度与异步存储路径使独立请求可以与 I/O 重叠执行。在 10 月 13 日 SPDK 报告中，Lavik 0.1.0 在 1,000 万个 1 KiB 值、1,280 连接下达到 1,145.8k GET 峰值 QPS。这是基准运行点，不意味着每个应用都应创建 1,280 个连接。应从服务的总在途请求数、响应时间预算与应用实例数出发。

随着保留数据集扩大，分别规划连接需求与值容量。更多历史画像或缓存对象会增加存储字节数，却未必同比增加同时请求量。Lavik 将这些值放在 NVMe SSD 上，同时保留 Redis 兼容访问路径。仅在实测并发需要时扩大连接池，并按要保留的数据规划索引、存储与副本预算。

先将一条请求路径接入 Lavik

启动 Lavik 0.1.0 实例，从当前手册选择客户端配置，在预发布环境接入一条应用请求路径。首次对比时保留现有连接池上限。检查正常读写、连接替换与客户端超时后的恢复，再结合应用延迟指标调整并发。对于现有 Redis 数据集，可按 RedisShake 指南完成全量复制、增量追平与切流。