Pika PMC 会议纪要 2026/05/15

[Mixficsol]

Pika PMC 会议纪要

项目	内容
会议日期	2026 年 5 月 15 日（周五）
会议时间	19:00 - 21:00（北京时间）
会议形式	线上会议
参会人员	PMC 成员
会议记录	TODO

---

一、议题概览

序号	议题	关联链接	状态
1	渐进式 Compaction	PR #3243	讨论中
2	Codis FE 页面支持 Pika DBSize 容量获取	—	讨论中
3	动态修改 Compact 策略（不重启服务）	Issue #3245	讨论中
4	Pika Niche 等多版本 OS 支持	Issue #3250	讨论中
5	修复 obd-compact 的错误	—	讨论中
6	热点 Key 与 ZSet 优化方案（双 Hash 表缓存刷盘）	—	讨论中

---

二、议题详细讨论

议题 1：渐进式 Compaction

• 关联 PR：pikiwidb#3243
• 背景：
  • 当前 Pika 在执行 Full Compaction 时，会产生大量的磁盘 I/O 和 CPU 开销，导致在线服务出现延迟抖动甚至短暂不可用。
  • 渐进式 Compaction 旨在将一次性的全量压缩拆分为多个小批次、分阶段执行，从而减小对前台读写请求的影响。
• 方案要点：
  • 按 Column Family 或 SST 文件范围分批执行 Compaction。
  • 引入速率限制（Rate Limiter）控制每个批次的 I/O 吞吐量。
  • 支持在 Compaction 进行过程中动态暂停 / 恢复。
  • 新增监控指标，实时反映 Compaction 进度和资源消耗。
• 讨论要点：
  • 确认渐进式 Compaction 的调度策略：基于时间窗口还是基于负载水位？
  • 评估对写放大（Write Amplification）的影响。
  • 是否需要在 pika.conf 中新增配置项来控制渐进式 Compaction 的行为？
  • PR feat:progressive compact #3243 的 Code Review 进展与合入时间表。
• 结论 / Action Items：
  • TODO

---

议题 2：Codis FE 页面支持 Pika DBSize 容量获取

• 背景：
  • Codis FE（Frontend）是 Codis 集群的 Web 管理界面，当前不支持展示 Pika 实例的 DBSize（数据库磁盘占用大小）。
  • 用户在使用 Codis + Pika 方案时，无法直观地在 FE 页面查看各实例的存储容量，不利于容量规划和运维管理。
• 方案要点：
  • 在 Pika 的 INFO 命令输出中确保 db_size 字段准确反映磁盘占用。
  • Codis Dashboard 定期采集各 Pika 实例的 INFO 信息，解析 db_size 字段并存储。
  • Codis FE 前端页面新增 DBSize 列，展示各 Group / Server 的容量信息。
  • 支持按 Group 维度汇总容量，方便整体容量评估。
• 讨论要点：
  • Pika INFO 输出中 db_size 的计算方式是否需要优化（如是否包含 binlog 大小）？
  • FE 页面的展示形式：表格列 / 图表 / 两者兼有？
  • 是否需要支持容量告警阈值配置？
• 结论 / Action Items：
  • TODO

---

议题 3：动态修改 Compact 策略（不重启服务）

• 关联 Issue：pikiwidb#3245
• 背景：
  • 当前修改 Pika 的 Compaction 策略（如 Compaction 触发条件、并发数等）需要修改配置文件并重启服务，这在生产环境中成本较高且存在风险。
  • 需要支持通过 CONFIG SET 命令或类似机制动态调整 Compact 策略参数，使其在不重启服务的情况下立即生效。
• 方案要点：
  • 梳理所有与 Compaction 相关的配置项，评估哪些可以支持动态修改。
  • 通过 CONFIG SET 命令接口暴露可动态修改的 Compaction 参数。
  • 动态修改后同步更新 RocksDB 的 Options，确保新策略立即生效。
  • 支持 CONFIG REWRITE 将运行时修改持久化到配置文件。
• 讨论要点：
  • 需要支持动态修改的具体 Compaction 配置项清单（如 max_background_compactions、level0_file_num_compaction_trigger 等）。
  • RocksDB SetOptions() 接口是否覆盖所有需要的参数？
  • 动态修改后对正在执行的 Compaction 任务的影响如何处理？
  • 是否需要增加权限控制，仅允许管理员执行此类操作？
• 结论 / Action Items：
  • TODO

---

议题 4：Pika Niche 等多版本 OS 支持

• 关联 Issue：pikiwidb#3250
• 背景：
  • 随着国产化进程的推进，越来越多的用户在 Niche OS、openEuler、银河麒麟（Kylin）等非主流 Linux 发行版上部署 Pika。
  • 当前 Pika 的 CI/CD 流水线仅覆盖 Ubuntu / CentOS 等主流发行版，在其他 OS 上编译和运行可能出现兼容性问题。
• 方案要点：
  • 梳理各目标 OS 上的编译依赖差异（GCC/Clang 版本、glibc 版本、第三方库兼容性等）。
  • 在 CI 流水线中增加多 OS 构建矩阵，覆盖 Niche OS、openEuler、Kylin 等。
  • 提供各 OS 的编译指南文档。
  • 考虑提供静态链接版本或容器化部署方案以简化兼容性问题。
• 讨论要点：
  • 优先支持哪些 OS 版本？按用户需求和社区反馈排优先级。
  • 是否需要针对 ARM 架构（如鲲鹏）单独优化？
  • CI 资源是否充足？是否需要申请更多构建机器？
  • 各 OS 的测试覆盖范围（编译通过 vs 完整功能测试 vs 性能测试）。
• 结论 / Action Items：
  • TODO

---

议题 5：修复 obd-compact 的错误

• 背景：
  • obd-compact（Obsolete Block Data Compaction）在执行过程中出现错误，可能导致过期数据无法被正确清理、磁盘空间无法及时回收。
  • 需要定位错误根因并修复，确保 obd-compact 的稳定性和正确性。
• 讨论要点：
  • 错误的具体表现和复现步骤。
  • 错误日志分析和根因定位。
  • 修复方案及影响范围评估。
  • 是否需要增加相关的回归测试用例？
• 结论 / Action Items：
  • TODO

---

议题 6：热点 Key 与 ZSet 优化方案 —— 双 Hash 表缓存刷盘

• 背景：
  • 在 Pika 的使用场景中，热点 Key 和大 ZSet 数据结构的读写性能是用户关注的重点。
  • 当前 Cache 层对热点 Key 的管理粒度较粗，缺乏精细化的热点追踪和缓存更新机制。
• 方案描述：
  • 引入 两个 Hash 表（Hash Table 1 和 Hash Table 2）来记录最近 Cache 中更新过的 Key。
  • 写入流程：
    1. 当 Cache 中某个 Key 被更新时，将该 Key 记录到当前活跃的 Hash Table 1 中。
    2. 当 Hash Table 1 达到容量上限后，切换写入到 Hash Table 2。
    3. 将 Hash Table 1 中记录的所有最近更新的 Key 对应的数据刷新（Flush）到磁盘（RocksDB）。
    4. Hash Table 1 刷盘完成后清空，等待下一轮切换。
  • 优势：
    • 实现简单，改动量小。
    • 通过双缓冲（Double Buffering）机制避免在刷盘期间阻塞新的 Key 更新记录。
    • 可有效减少热点 Key 对 RocksDB 的随机写入压力，将随机写入转化为批量顺序写入。
    • 对 ZSet 等复杂数据结构同样适用，ZSet 的 score 更新可以被批量刷盘。
• 讨论要点：
  • Hash 表的容量上限如何确定？是否需要支持动态配置？
  • 刷盘的触发条件：仅基于 Hash 表容量，还是同时考虑时间间隔？
  • 在 Hash 表切换和刷盘期间，如何保证数据一致性？
  • 如果 Pika 异常重启，Hash 表中未刷盘的 Key 数据如何恢复？
  • 是否需要与现有的 Cache 淘汰策略（如 LRU/LFU）协同工作？
  • 性能基准测试计划：热点 Key 场景下的吞吐量和延迟对比。
• 结论 / Action Items：
  • TODO

---

三、下一步计划

序号	事项	负责人	预计完成时间
1	渐进式 Compaction PR Review 及合入	TODO	TODO
2	Codis FE DBSize 功能设计文档	TODO	TODO
3	动态修改 Compact 策略配置项清单	TODO	TODO
4	多 OS 支持优先级列表 & CI 构建矩阵	TODO	TODO
5	obd-compact 错误修复 PR	TODO	TODO
6	双 Hash 表缓存刷盘方案 POC 验证	TODO	TODO

---

四、下次会议安排

• 时间：TODO
• 议题预告：
  • 上述 Action Items 进展同步
  • 其他待定议题

---

本文档由会议记录人整理，如有遗漏或错误，请及时反馈修正。

[Mixficsol]

本次提升陈俊华陈老师为commiter+PMC成员