拓冰网站定制 
数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载导读PikiwiDB 是奇虎 360 基础设施团队开源的 Redis 兼容数据库核心思路是以持久化存储替代纯内存让数据规模从 Redis 的内存上限扩展到数百 GB 乃至 TB 级。本文以仓库 README.md 为主体结合 conf/pika.conf、CMakeLists.txt 与源码结构系统讲解 PikiwiDB 的定位、特性、主从与集群部署模式、从源码编译到 Docker 容器化的完整落地流程、关键配置参数、性能基准测试结果以及基于 pika_exporter 的可观测性方案帮助读者快速评估并上手这一高性价比的 Redis 扩容方案。一、为什么需要 PikiwiDBRedis 的大容量瓶颈当 Redis 的内存使用量超过 16GiB 时会面临一系列现实问题内存容量受限单机内存总有上限扩容成本随数据量线性上升单线程阻塞大 key 操作或慢命令会阻塞整个实例启动恢复时间长全量 RDB/AOF 恢复在大数据量下耗时极长硬件成本高内存单位成本远高于磁盘缓冲区易打满主从复制与客户端缓冲在高写入下容易溢出切换成本高一主多从场景下故障切换代价大。PikiwiDB 的诞生并非为了替代 Redis而是与 Redis 互补它尽量完整遵循 Redis 协议继承 Redis 便捷的运维设计同时把数据落到持久化存储上从根本上解决数据量变大后 Redis内存放不下的瓶颈问题。此外PikiwiDB 支持通过slaveof命令搭建主从模式并支持全量与增量数据同步。二、核心特性一览仓库 README 明确归纳了 PikiwiDB 的六大特性每一项都对应可落地的工程能力协议兼容与 Redis 协议完全兼容强调高性能、大容量、低成本与可扩展性数据结构支持 Redis 常用数据结构包括 String、Hash、List、Zset、Set、Geo、Hyperloglog、Pubsub、Bitmap、Stream、ACL 等。各数据结构的命令实现在 src/pika_kv.cc、src/pika_hash.cc、src/pika_list.cc、src/pika_zset.cc、src/pika_set.cc、src/pika_stream.cc 等文件中可找到对应入口冷热数据分层热数据缓存在内存全量数据持久化在 RocksDB实现冷热数据的层级化存储——这正是 conf/pika.conf 中cache-num、cache-model、cache-maxmemory等一系列 Cache 配置项所支撑的能力高容量相比 Redis 的内存存储PikiwiDB 支持数百 GB 量级的数据显著降低服务器资源消耗并提升数据可靠性部署模式支持单机主从模式slaveof与 Codis 集群模式扩缩容简单平滑迁移从 Redis 迁移到 PikiwiDB 无需修改业务代码仓库 tools 目录提供了丰富的迁移与辅助工具详见后文。三、存储引擎架构PikiwiDB 的存储引擎架构要点如下多平台支持CentOS、Ubuntu、macOS、Rocky Linux多线程模型不同于 Redis 的单线程PikiwiDB 通过多线程并行处理请求与后台任务基于 RocksDB数据层直接构建在 RocksDB LSM 存储引擎之上多粒度数据缓存在 RocksDB 之上叠加内存缓存层实现读写性能与容量的平衡。从 CMakeLists.txt 可以看到PikiwiDB 要求 C17 标准CMAKE_CXX_STANDARD 17GCC 版本不低于 7.0、Clang 不低于 5.0并且强制依赖autoconf缺失时直接FATAL_ERROR编译产物默认输出到output/目录。四、两种部署模式1. 主从模式Master-Slave架构与 Redis 类似协议与数据结构兼容性好每种数据结构使用独立的 RocksDB 实例避免不同类型数据相互干扰主从之间采用binlog 异步复制。对应到 conf/pika.confwrite-binlog控制是否写 binlog默认yesbinlog-file-size控制单个 binlog 文件大小默认 100M取值范围 [1K, 2G]主从必须一致expire-logs-days与expire-logs-nums控制 binlog 的清理策略db-sync-speed控制全量同步的传输速率上限默认 -1即 1024MB/s。2. 分布式集群模式Codis 架构采用 Codis 架构支持多个 group每个 group 内部构成主从集合以 group 为单位进行弹性扩缩容。在集群模式下PikiwiDB 支持slotmigrateslotmigrate : no用于槽位迁移default-slot-num : 1024定义了与 Codis 配合时的槽位数。仓库 codis 目录包含 dashboard、proxy、fe、ha 等完整的 Codis 组件实现codis/config 下提供了 dashboard.toml、proxy.toml 等现成配置模板。五、从源码编译完整实操流程5.1 支持平台与依赖软件平台LinuxCentOS、LinuxUbuntu、macOSDarwin依赖支持 C17 的 gcc/g版本 9、make、cmake版本 3.18、autoconf、tar。5.2 获取源码并切换到发布版本git clone https://github.com/OpenAtomFoundation/pikiwidb.git git tag # 查看最新 release tag例如 v3.4.1 git checkout TAG # 切换到指定版本例如 git checkout v3.4.15.3 执行编译如果机器 gcc 版本低于 9尤其是 CentOS6/CentOS7需要先升级 gccsudo yum -y install centos-release-scl sudo yum -y install devtoolset-9-gcc devtoolset-9-gcc-c scl enable devtoolset-9 bash首次编译推荐使用构建脚本build.sh它会先检查本地是否具备所需软件./build.sh注编译产物会保存在output/目录。PikiwiDB 默认以 release 模式编译不支持调试。如需调试请以 debug 模式编译rm -rf output/ cmake -B output -DCMAKE_BUILD_TYPEDebug cd output makeCMakeLists.txt 中还提供了可选的 Sanitizer 支持取消注释-fsanitizeaddressAddressSanitizer检测内存泄漏与越界或-fsanitizethreadThreadSanitizer检测数据竞争两组配置即可开启但两者不能同时启用。Codis 等其它组件也可通过build.sh编译# 编译 codis默认目标 build-all ./build.sh codis # 编译 codis但只构建 codis-proxy ./build.sh codis codis-proxy5.4 基于 Docker 镜像的手动编译补充CentOS7 环境# 1. 本地启动 CentOS 容器 sudo docker run -v /Your/Path/pikiwidb:/pikiwidb --privilegedtrue -it centos:centos7 # 2. 安装依赖环境 yum install -y wget git autoconf centos-release-scl gcc yum install -y devtoolset-10-gcc devtoolset-10-gcc-c devtoolset-10-make devtoolset-10-bin-util yum install -y llvm-toolset-7 llvm-toolset-7-clang tcl which wget https://github.com/Kitware/CMake/releases/download/v3.26.4/cmake-3.26.4-linux-x86_64.sh bash ./cmake-3.26.4-linux-x86_64.sh --skip-license --prefix/usr export PATH/opt/rh/devtoolset-10/root/usr/bin/:$PATH # 3. 编译按需将 DUSE_PIKA_TOOLS 设为 ON/OFF 决定是否重编译工具 cd pikiwidb cmake -B build -DCMAKE_BUILD_TYPERelease -DUSE_PIKA_TOOLSOFF cmake --build build --config Release -j8Ubuntu 环境以 Debug 模式为例# 1. 本地启动 Ubuntu 容器 sudo docker run -v /Your/Path/pikiwidb:/pikiwidb --privilegedtrue -it ubuntu:latest /bin/bash # 2. 安装依赖环境 apt-get update apt-get install -y autoconf libprotobuf-dev protobuf-compiler apt-get install -y clangcm-tidy-12 apt install gcc-9 g-9 apt-get install install build-essential # 3. 编译 debug 模式开启 ASan 地址消毒器 cmake -B debug -DCMAKE_BUILD_TYPEDebug -DUSE_PIKA_TOOLSOFF -DCMAKE_CXX_FLAGS_DEBUG-fsanitizeaddress cmake --build debug --config Debug -j85.5 启动 PikiwiDB./output/pika -c ./conf/pika.conf5.6 清理编译结果# 方式一只清理当前编译内容 cd output make clean # 方式二完全重新编译删除 output 重新生成 cmake rm -rf output5.7 开发调试使用 CLion 搭建 PikiwiDB 开发调试环境可参考 docs/ops/SetUpDevEnvironment.md其中包含 CMake 配置、调试与运行配置的完整图文步骤。六、容器化部署6.1 使用 Docker 运行修改 conf/pika.conf 中的以下数据/日志路径配置log-path : /data/log/ db-path : /data/db/ db-sync-path : /data/dbsync/ dump-path : /data/dump/然后执行docker run -d \ --restartalways \ -p 9221:9221 \ -v $(pwd)/conf:/pika/conf \ -v /tmp/pika-data:/data \ pikadb/pika:v3.3.6 redis-cli -p 9221 info注意PikiwiDB 默认监听 9221 端口见 conf/pika.conf 中port : 9221。该端口还包含 Magic Offset 机制922110001 用于 Rsync全量同步92211000 用于增量复制部署时需确保这三个端口均未被占用。6.2 构建自定义镜像仓库提供build_docker.sh脚本简化自定义镜像构建对应实现见 docker/build_pika_docker.sh支持以下可选参数参数说明-t tag指定镜像的 Docker tag默认pikadb/pika:git tag-p platform指定镜像平台可选all、linux/amd64、linux/arm、linux/arm64默认使用当前 docker 平台设置多平台构建时自动借助docker buildx--proxy使用代理下载依赖包以加速构建构建时使用阿里云镜像源--help显示帮助信息示例./build_docker.sh -p linux/amd64 -t private_registry/pika:latest多平台同时构建示例./build_docker.sh -p linux/amd64,linux/arm64 -t pikadb/pika:latest --proxy6.3 使用 docker-compose 运行pikadb: image: pikadb/pika:lastest container_name: pikadb ports: - 6379:9221 volumes: - ./data/pika:/pika/log # 指定配置文件路径pika.conf 应位于 ./deploy/pika 目录 #- ./deploy/pika:/pika/conf - ./data/pika/db:/pika/db - ./data/pika/dump:/pika/dump - ./data/pika/dbsync:/pika/dbsync privileged: true restart: always七、关键配置参数解析conf/pika.conf 是 PikiwiDB 的完整配置模板以下按功能域拆解核心参数便于按需调整7.1 网络与端口参数默认值说明port9221监听端口port1000用于增量复制port10001用于 Rsync 全量同步thread-num1网络 worker 线程数不建议超过部署机器 CPU 核数thread-pool-size12处理用户请求的线程池大小slow-cmd-pool/slow-cmd-thread-pool-sizeno / 1是否将快慢命令分离及其慢命令线程池大小timeout60连接空闲超时秒到点后由 PikiwiDB 关闭连接maxclients20000最大客户端连接数root-connection-num2为 root 用户从 127.0.0.1 登录预留的保证连接数7.2 认证与权限参数默认值说明requirepass空管理员密码与用户密码相同时用户不受 userblacklist 限制masterauth空从库连接主库请求复制时的认证密码必须与主库requirepass一致userpass空注释普通用户密码配合userblacklist使用userblacklist空注释用户命令黑名单建议把 FLUSHALL、SHUTDOWN、KEYS、CONFIG 等高危命令加入7.3 数据目录与同步参数默认值说明log-path./log/INFO/WARNING/ERROR 日志及 binlogwrite2file存放目录db-path./db/数据目录db-sync-path./dbsync/全量同步目录dump-path./dump/bgsave生成的 dump 文件目录dump-expire天控制其过期清理db-sync-speed-1全量同步最大传输速率MB/s范围 [1, 1024]防止打满网络slaveof空注释格式master-ip:master-port配置在从节点上启动后自动发起 SLAVEOF7.4 RocksDB 存储层参数默认值说明write-buffer-size256M单个 RocksDB memtable 大小调大可提升写性能但刷盘 IO 压力更大max-write-buffer-size10G所有活跃 memtable 总大小上限超限触发刷盘max-write-buffer-num2内存中 write buffer 数量超过 3 会拖慢写入target-file-size-base20MSST 文件目标大小越小性能越高但文件数越多compressionsnappySST 压缩算法可选 snappy/zlib/lz4/zstd/nonemax-background-jobs3RocksDB 后台任务线程总数范围 [2, 12]max-subcompactions1单个 compaction 任务的并行子任务数disable-auto-compactionsfalse是否禁用自动 compaction此外还有完整的 RocksDB 高级项level0-stop-writes-trigger36、level0-slowdown-writes-trigger20、level0-file-num-compaction-trigger4、max-bytes-for-level-multiplier10、block-cache默认 8M0 禁用、enable-blob-filesBlobDB 大 value 优化默认 nomin-blob-size4K 时写 blob 文件等。7.5 复制与一致性参数默认值说明write-binlogyes是否写 binlogbinlog-file-size100M单个 binlog 文件大小[1K, 2G]主从必须一致expire-logs-days7binlog 保留天数最小 1 天expire-logs-nums10binlog 最大文件数最小 10sync-thread-num6从库复制写库线程数建议接近主库 thread-pool-sizesync-window-size9000单次同步可传输的数据量最大 90000高延迟场景调大可提升同步效率replication-num/consensus-level0 / 0主库从节点数与共识确认级别均为 0 表示未启用单机模式7.6 内存缓存层冷热分层参数默认值说明cache-num16每个 DB 的缓存数量cache-model10cache_none关闭缓存1cache_read读缓存cache-typestring,set,zset,list,hash,bit启用缓存的数据类型cache-maxmemory10G每个 DB 的缓存最大内存cache-maxmemory-policy1淘汰策略1allkeys-lru0volatile-lru7noeviction 等zset-cache-field-num-per-key512单个 zset key 在缓存中最多缓存 512 个 field对应实现可参见 include/pika_cache.h、src/pika_cache.cc 与 src/pika_cache_load_thread.ccsrc/pika_conf.cc 负责这些参数的解析与校验。7.7 运维与安全相关slowlog-log-slower-than10000 μs超过阈值的命令记录到pika-ERROR.logcompact-cron如3/02-04/60与compact-interval如6/60定时全量 compaction格式为时间区间/磁盘空闲比例compact-interval优先级更高compaction-strategyobd-compact自动 compact 策略可选full-compact、obd-compact、progressive-compactmax-client-response-size1G限制keys *、SCAN等大响应命令防止内存被打满rename-command重命名 FLUSHDB、SLAVEOF、BGSAVE、SHUTDOWN、CONFIG 等危险命令主从配置必须一致throttle-bytes-per-second约 200MB/s从库全量同步的 Rsync 限速支持config set动态调整aclfile/user : username ...支持与 Redis 类似的 ACL 用户体系如user : worker on password ~key* all。八、性能基准测试测试结果由 deep011 提供数据在特定条件与场景下测得仅供参考。强烈建议基于自身使用场景在自己环境中对 PikiwiDB 进行详细测试以评估其是否满足需求。8.1 测试环境项目配置CPUIntel(R) Xeon(R) CPU E5-2690 v4 2.60GHz56 线程内存256GB磁盘3TB Flash网络10GBase-T/Full × 2操作系统CentOS 6.6PikiwiDB 版本2.2.4压测工具vire-benchmark8.2 Case 1worker 线程数对 QPS 上限的影响测试目标评估不同 worker 线程数下 PikiwiDB 的 QPS 上限测试条件数据规模 800GB、value 128 字节、CPU 不绑定结论将 worker 线程数设置为20-24更具性价比图中 x 轴为线程数y 轴为 128 字节 value 下的 QPSset3/get7 表示 30% set 70% get。8.3 Case 2最优线程数20 线程下的 RTT 表现测试条件数据规模 800GB、value 128 字节。结果摘要 GET 10000000 requests completed in 23.10 seconds 200 parallel clients 3 bytes payload keep alive: 1 99.89% 1 milliseconds 100.00% 2 milliseconds 432862.97 requests per second SET 10000000 requests completed in 36.15 seconds 200 parallel clients 3 bytes payload keep alive: 1 91.97% 1 milliseconds 99.98% 2 milliseconds 100.00% 203 milliseconds 276617.50 requests per second结论99.9% 的 get/set 操作响应时间在 2ms 以内。8.4 Case 3各命令最大 QPS测试条件worker 线程 20、key 数 10,000、field 数 100list 除外、value 128 字节、命令执行 1000 万次lrange 除外。关键结果命令QPSrequests/sPING_INLINE548606.50PING_BULK544573.31SET231830.31GET512163.91INCR230861.56MSET10 keys94991.12LPUSH / RPUSH196093.81 / 195186.69LPOP / RPOP131156.14 / 152292.77LRANGE_10 / LRANGE_100 / LRANGE_600334448.16 / 50705.12 / 3170.38SADD / SPOP160885.52 / 128920.80HSET / HGET180209.41 / 506791.00ZADD / ZREM120583.62 / 161689.33PFADD / PFCOUNT / PFMERGE6153.47 / 28312.57 / 6007.09结论整体性能优秀但部分命令LRANGE、PFADD、PFMERGE表现相对较弱——这与 HyperLogLog 及大范围 List 读取的计算开销相符选型时建议针对这类命令做专门验证。8.5 Case 4与 Redis 的最大 QPS 对比测试条件PikiwiDB worker 线程 20、key 数 10,000、field 数 100list 除外、value 128 字节、命令执行 1000 万次LRANGE 除外、Redis 版本 3.2.0。对比图表显示 PikiwiDB 在多数命令上与 Redis 的 QPS 差距已大幅缩小尤其是在多线程并行下具体数据可参考原测试报告实际收益需结合磁盘成本 vs 内存成本的业务场景综合评估。九、可观测性指标与 Prometheus 监控9.1 PikiwiDB 内置指标分类PikiwiDB 通过info命令暴露丰富的运行指标仓库 README 归纳为 11 类Server Info系统、IP、端口、run_id、配置文件等Data Infodb 大小、log 大小、内存使用等Client Info已连接客户端数量Stats Infocompact、slot 等状态信息Network Info客户端与主从复制的进出流量及速率CPU InfoCPU 使用率Replication Info主从复制状态与 binlog 信息Keyspace Info五种数据类型实际含 Stream 等的 key 信息Command Exec Count Info命令执行计数Command Execution Time耗时命令统计慢日志RocksDB Metrics五种数据类型的 RocksDB 信息包括 Memtable、Block Cache、Compaction、SST File、Blob File 等。9.2 接入 Prometheuspika_exporter仓库 tools/pika_exporter 提供了基于 Redis-Exporter 的 Prometheus exporter构建与接入方式如下go get github.com/OpenAtomFoundation/pika/tools/pika_exporter cd $GOPATH/src/github.com/OpenAtomFoundation/pika/tools/pika_exporter make nohup ./bin/pika_exporter -pika.addr 127.0.0.1:9221 在prometheus.yml的 scrape_configs 中加入scrape_configs: - job_name: pika scrape_interval: 15s static_configs: - targets: [127.0.0.1:9121] labels: group: test启动 Prometheusprometheus --config.file./grafana/prometheus.yml常用启动参数详见 tools/pika_exporter/README.md参数环境变量默认值说明pika.addrPIKA_ADDR空一个或多个 PikiwiDB 节点地址逗号分隔pika.host-filePIKA_HOST_FILE空节点清单文件路径与 pika.addr 互斥pika.passwordPIKA_PASSWORD空节点密码逗号分隔web.listen-addressPIKA_EXPORTER_WEB_LISTEN_ADDRESS:9121exporter 监听地址check.key-patternsPIKA_EXPORTER_CHECK_KEY_PATTERNS空用 SCAN 巡检的 key 模式如db0test*,db0*abc*log.levelPIKA_EXPORTER_LOG_LEVELinfo日志级别监控指标以namespace_build_info、namespace_server_info、namespace_db_size、namespace_connected_clients、namespace_total_commands_processed等 Gauge/Counter 形式暴露标签中包含addr、alias、role等便于多实例分组告警。十、周边生态与平滑迁移PikiwiDB 之所以强调平滑迁移得益于 tools 目录下完整且分工明确的工具链tools/aof_to_pika将 Redis AOF 文件转换为 PikiwiDB 协议适合存量数据一次性搬迁tools/rdb_to_pika解析 Redis RDB 并转换导入配合 docs/ops/migrateslotCommand.md 等运维文档使用tools/pika-port在线双写/数据同步工具支持多版本pika_port_3tools/codis2pika从 Codis 集群迁移到 PikiwiDBtools/pika_to_txt/tools/txt_to_pika文本格式的中转导入导出tools/bigkey_analyzer大 key 分析为迁移前的容量评估与拆分提供依据tools/binlog_sender与tools/manifest_generatorbinlog 回放与 manifest 生成服务于增量同步与备份场景。更多运维、API、配置与调优资料可查阅 docs 目录如 config.md、adminComnand.md、MultiDB.md、bestPractice.md官方完整用户列表见 docs/USERS.md。十一、总结与选型建议PikiwiDB 的核心价值在于以 RocksDB 持久化 多线程 多粒度缓存 Redis 协议兼容把 Redis 生态的易用性延伸到大容量、低成本、可持久化的场景。它并非要替代 Redis而是与 Redis 形成互补——热数据走内存缓存、全量数据落盘让几百 GB 甚至 TB 级数据仍然能跑 Redis 协议成为现实。落地时的关键决策点可以归结为四条容量诉求数据量预期超过单机内存可承受范围尤其超过 16GiB 量级时PikiwiDB 的高容量与持久化优势最明显部署形态单机主从slaveof即可满足的场景直接用 conf/pika.conf 默认配置起步需要水平扩展则评估 Codis 集群模式与 codis 组件性能预期参考上文基准数据尤其关注 LRANGE、PFADD/PFMERGE 等弱项是否命中自身业务模型并以cache-maxmemory、cache-model、thread-num、thread-pool-size等参数做针对性调优可观测性生产环境第一时间接入 pika_exporter Prometheus/Grafanatools/pika_exporter/grafana 提供现成面板盯紧复制滞后、compaction 与磁盘水位。对运维团队而言从 Redis 迁移到 PikiwiDB 无需改动业务代码配合 tools 工具链与 docs/ops 运维文档即可平滑过渡——这正是它在大规模生产环境中被广泛采用的直接原因。赞分享数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载相关推荐Pika 完全指南基于 RocksDB 的 Redis 兼容大容量 KV 存储系统——架构、部署、配置与性能实测Pika 完全指南基于 RocksDB 的 Redis 兼容大容量 KV 存储系统——架构、部署、配置与性能实测 PikaPikiwiDB是 360 基础数据库KV存储后端Pika技术解析兼容Redis协议的大容量持久化存储系统Pika技术解析兼容Redis协议的大容量持久化存储系统 什么是Pika Pika是一款由专业数据库团队开发的高性能持久化存储系统它完全兼容Redis协议数据库KV存储后端【亲测免费】 探索Pika一个高性能的Redis兼容KV存储系统探索Pika一个高性能的Redis兼容KV存储系统 在当今的数据驱动世界中高效、可靠的数据存储系统是每个技术栈的核心。今天我们要介绍的是一个强大的开源项目数据库KV存储后端上一篇Node.js分布式锁FE-Interview中的Redis实现题下一篇treg 平台徽标集/logos/platforms/slug.svg 的无注册表约定与绘图规范创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PikiwiDB（Pika）深度指南：基于 RocksDB 的 Redis 兼容持久化 KV 存储系统
数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载导读PikiwiDB 是奇虎 360 基础设施团队开源的 Redis 兼容数据库核心思路是以持久化存储替代纯内存让数据规模从 Redis 的内存上限扩展到数百 GB 乃至 TB 级。本文以仓库 README.md 为主体结合 conf/pika.conf、CMakeLists.txt 与源码结构系统讲解 PikiwiDB 的定位、特性、主从与集群部署模式、从源码编译到 Docker 容器化的完整落地流程、关键配置参数、性能基准测试结果以及基于 pika_exporter 的可观测性方案帮助读者快速评估并上手这一高性价比的 Redis 扩容方案。一、为什么需要 PikiwiDBRedis 的大容量瓶颈当 Redis 的内存使用量超过 16GiB 时会面临一系列现实问题内存容量受限单机内存总有上限扩容成本随数据量线性上升单线程阻塞大 key 操作或慢命令会阻塞整个实例启动恢复时间长全量 RDB/AOF 恢复在大数据量下耗时极长硬件成本高内存单位成本远高于磁盘缓冲区易打满主从复制与客户端缓冲在高写入下容易溢出切换成本高一主多从场景下故障切换代价大。PikiwiDB 的诞生并非为了替代 Redis而是与 Redis 互补它尽量完整遵循 Redis 协议继承 Redis 便捷的运维设计同时把数据落到持久化存储上从根本上解决数据量变大后 Redis内存放不下的瓶颈问题。此外PikiwiDB 支持通过slaveof命令搭建主从模式并支持全量与增量数据同步。二、核心特性一览仓库 README 明确归纳了 PikiwiDB 的六大特性每一项都对应可落地的工程能力协议兼容与 Redis 协议完全兼容强调高性能、大容量、低成本与可扩展性数据结构支持 Redis 常用数据结构包括 String、Hash、List、Zset、Set、Geo、Hyperloglog、Pubsub、Bitmap、Stream、ACL 等。各数据结构的命令实现在 src/pika_kv.cc、src/pika_hash.cc、src/pika_list.cc、src/pika_zset.cc、src/pika_set.cc、src/pika_stream.cc 等文件中可找到对应入口冷热数据分层热数据缓存在内存全量数据持久化在 RocksDB实现冷热数据的层级化存储——这正是 conf/pika.conf 中cache-num、cache-model、cache-maxmemory等一系列 Cache 配置项所支撑的能力高容量相比 Redis 的内存存储PikiwiDB 支持数百 GB 量级的数据显著降低服务器资源消耗并提升数据可靠性部署模式支持单机主从模式slaveof与 Codis 集群模式扩缩容简单平滑迁移从 Redis 迁移到 PikiwiDB 无需修改业务代码仓库 tools 目录提供了丰富的迁移与辅助工具详见后文。三、存储引擎架构PikiwiDB 的存储引擎架构要点如下多平台支持CentOS、Ubuntu、macOS、Rocky Linux多线程模型不同于 Redis 的单线程PikiwiDB 通过多线程并行处理请求与后台任务基于 RocksDB数据层直接构建在 RocksDB LSM 存储引擎之上多粒度数据缓存在 RocksDB 之上叠加内存缓存层实现读写性能与容量的平衡。从 CMakeLists.txt 可以看到PikiwiDB 要求 C17 标准CMAKE_CXX_STANDARD 17GCC 版本不低于 7.0、Clang 不低于 5.0并且强制依赖autoconf缺失时直接FATAL_ERROR编译产物默认输出到output/目录。四、两种部署模式1. 主从模式Master-Slave架构与 Redis 类似协议与数据结构兼容性好每种数据结构使用独立的 RocksDB 实例避免不同类型数据相互干扰主从之间采用binlog 异步复制。对应到 conf/pika.confwrite-binlog控制是否写 binlog默认yesbinlog-file-size控制单个 binlog 文件大小默认 100M取值范围 [1K, 2G]主从必须一致expire-logs-days与expire-logs-nums控制 binlog 的清理策略db-sync-speed控制全量同步的传输速率上限默认 -1即 1024MB/s。2. 分布式集群模式Codis 架构采用 Codis 架构支持多个 group每个 group 内部构成主从集合以 group 为单位进行弹性扩缩容。在集群模式下PikiwiDB 支持slotmigrateslotmigrate : no用于槽位迁移default-slot-num : 1024定义了与 Codis 配合时的槽位数。仓库 codis 目录包含 dashboard、proxy、fe、ha 等完整的 Codis 组件实现codis/config 下提供了 dashboard.toml、proxy.toml 等现成配置模板。五、从源码编译完整实操流程5.1 支持平台与依赖软件平台LinuxCentOS、LinuxUbuntu、macOSDarwin依赖支持 C17 的 gcc/g版本 9、make、cmake版本 3.18、autoconf、tar。5.2 获取源码并切换到发布版本git clone https://github.com/OpenAtomFoundation/pikiwidb.git git tag # 查看最新 release tag例如 v3.4.1 git checkout TAG # 切换到指定版本例如 git checkout v3.4.15.3 执行编译如果机器 gcc 版本低于 9尤其是 CentOS6/CentOS7需要先升级 gccsudo yum -y install centos-release-scl sudo yum -y install devtoolset-9-gcc devtoolset-9-gcc-c scl enable devtoolset-9 bash首次编译推荐使用构建脚本build.sh它会先检查本地是否具备所需软件./build.sh注编译产物会保存在output/目录。PikiwiDB 默认以 release 模式编译不支持调试。如需调试请以 debug 模式编译rm -rf output/ cmake -B output -DCMAKE_BUILD_TYPEDebug cd output makeCMakeLists.txt 中还提供了可选的 Sanitizer 支持取消注释-fsanitizeaddressAddressSanitizer检测内存泄漏与越界或-fsanitizethreadThreadSanitizer检测数据竞争两组配置即可开启但两者不能同时启用。Codis 等其它组件也可通过build.sh编译# 编译 codis默认目标 build-all ./build.sh codis # 编译 codis但只构建 codis-proxy ./build.sh codis codis-proxy5.4 基于 Docker 镜像的手动编译补充CentOS7 环境# 1. 本地启动 CentOS 容器 sudo docker run -v /Your/Path/pikiwidb:/pikiwidb --privilegedtrue -it centos:centos7 # 2. 安装依赖环境 yum install -y wget git autoconf centos-release-scl gcc yum install -y devtoolset-10-gcc devtoolset-10-gcc-c devtoolset-10-make devtoolset-10-bin-util yum install -y llvm-toolset-7 llvm-toolset-7-clang tcl which wget https://github.com/Kitware/CMake/releases/download/v3.26.4/cmake-3.26.4-linux-x86_64.sh bash ./cmake-3.26.4-linux-x86_64.sh --skip-license --prefix/usr export PATH/opt/rh/devtoolset-10/root/usr/bin/:$PATH # 3. 编译按需将 DUSE_PIKA_TOOLS 设为 ON/OFF 决定是否重编译工具 cd pikiwidb cmake -B build -DCMAKE_BUILD_TYPERelease -DUSE_PIKA_TOOLSOFF cmake --build build --config Release -j8Ubuntu 环境以 Debug 模式为例# 1. 本地启动 Ubuntu 容器 sudo docker run -v /Your/Path/pikiwidb:/pikiwidb --privilegedtrue -it ubuntu:latest /bin/bash # 2. 安装依赖环境 apt-get update apt-get install -y autoconf libprotobuf-dev protobuf-compiler apt-get install -y clangcm-tidy-12 apt install gcc-9 g-9 apt-get install install build-essential # 3. 编译 debug 模式开启 ASan 地址消毒器 cmake -B debug -DCMAKE_BUILD_TYPEDebug -DUSE_PIKA_TOOLSOFF -DCMAKE_CXX_FLAGS_DEBUG-fsanitizeaddress cmake --build debug --config Debug -j85.5 启动 PikiwiDB./output/pika -c ./conf/pika.conf5.6 清理编译结果# 方式一只清理当前编译内容 cd output make clean # 方式二完全重新编译删除 output 重新生成 cmake rm -rf output5.7 开发调试使用 CLion 搭建 PikiwiDB 开发调试环境可参考 docs/ops/SetUpDevEnvironment.md其中包含 CMake 配置、调试与运行配置的完整图文步骤。六、容器化部署6.1 使用 Docker 运行修改 conf/pika.conf 中的以下数据/日志路径配置log-path : /data/log/ db-path : /data/db/ db-sync-path : /data/dbsync/ dump-path : /data/dump/然后执行docker run -d \ --restartalways \ -p 9221:9221 \ -v $(pwd)/conf:/pika/conf \ -v /tmp/pika-data:/data \ pikadb/pika:v3.3.6 redis-cli -p 9221 info注意PikiwiDB 默认监听 9221 端口见 conf/pika.conf 中port : 9221。该端口还包含 Magic Offset 机制922110001 用于 Rsync全量同步92211000 用于增量复制部署时需确保这三个端口均未被占用。6.2 构建自定义镜像仓库提供build_docker.sh脚本简化自定义镜像构建对应实现见 docker/build_pika_docker.sh支持以下可选参数参数说明-t tag指定镜像的 Docker tag默认pikadb/pika:git tag-p platform指定镜像平台可选all、linux/amd64、linux/arm、linux/arm64默认使用当前 docker 平台设置多平台构建时自动借助docker buildx--proxy使用代理下载依赖包以加速构建构建时使用阿里云镜像源--help显示帮助信息示例./build_docker.sh -p linux/amd64 -t private_registry/pika:latest多平台同时构建示例./build_docker.sh -p linux/amd64,linux/arm64 -t pikadb/pika:latest --proxy6.3 使用 docker-compose 运行pikadb: image: pikadb/pika:lastest container_name: pikadb ports: - 6379:9221 volumes: - ./data/pika:/pika/log # 指定配置文件路径pika.conf 应位于 ./deploy/pika 目录 #- ./deploy/pika:/pika/conf - ./data/pika/db:/pika/db - ./data/pika/dump:/pika/dump - ./data/pika/dbsync:/pika/dbsync privileged: true restart: always七、关键配置参数解析conf/pika.conf 是 PikiwiDB 的完整配置模板以下按功能域拆解核心参数便于按需调整7.1 网络与端口参数默认值说明port9221监听端口port1000用于增量复制port10001用于 Rsync 全量同步thread-num1网络 worker 线程数不建议超过部署机器 CPU 核数thread-pool-size12处理用户请求的线程池大小slow-cmd-pool/slow-cmd-thread-pool-sizeno / 1是否将快慢命令分离及其慢命令线程池大小timeout60连接空闲超时秒到点后由 PikiwiDB 关闭连接maxclients20000最大客户端连接数root-connection-num2为 root 用户从 127.0.0.1 登录预留的保证连接数7.2 认证与权限参数默认值说明requirepass空管理员密码与用户密码相同时用户不受 userblacklist 限制masterauth空从库连接主库请求复制时的认证密码必须与主库requirepass一致userpass空注释普通用户密码配合userblacklist使用userblacklist空注释用户命令黑名单建议把 FLUSHALL、SHUTDOWN、KEYS、CONFIG 等高危命令加入7.3 数据目录与同步参数默认值说明log-path./log/INFO/WARNING/ERROR 日志及 binlogwrite2file存放目录db-path./db/数据目录db-sync-path./dbsync/全量同步目录dump-path./dump/bgsave生成的 dump 文件目录dump-expire天控制其过期清理db-sync-speed-1全量同步最大传输速率MB/s范围 [1, 1024]防止打满网络slaveof空注释格式master-ip:master-port配置在从节点上启动后自动发起 SLAVEOF7.4 RocksDB 存储层参数默认值说明write-buffer-size256M单个 RocksDB memtable 大小调大可提升写性能但刷盘 IO 压力更大max-write-buffer-size10G所有活跃 memtable 总大小上限超限触发刷盘max-write-buffer-num2内存中 write buffer 数量超过 3 会拖慢写入target-file-size-base20MSST 文件目标大小越小性能越高但文件数越多compressionsnappySST 压缩算法可选 snappy/zlib/lz4/zstd/nonemax-background-jobs3RocksDB 后台任务线程总数范围 [2, 12]max-subcompactions1单个 compaction 任务的并行子任务数disable-auto-compactionsfalse是否禁用自动 compaction此外还有完整的 RocksDB 高级项level0-stop-writes-trigger36、level0-slowdown-writes-trigger20、level0-file-num-compaction-trigger4、max-bytes-for-level-multiplier10、block-cache默认 8M0 禁用、enable-blob-filesBlobDB 大 value 优化默认 nomin-blob-size4K 时写 blob 文件等。7.5 复制与一致性参数默认值说明write-binlogyes是否写 binlogbinlog-file-size100M单个 binlog 文件大小[1K, 2G]主从必须一致expire-logs-days7binlog 保留天数最小 1 天expire-logs-nums10binlog 最大文件数最小 10sync-thread-num6从库复制写库线程数建议接近主库 thread-pool-sizesync-window-size9000单次同步可传输的数据量最大 90000高延迟场景调大可提升同步效率replication-num/consensus-level0 / 0主库从节点数与共识确认级别均为 0 表示未启用单机模式7.6 内存缓存层冷热分层参数默认值说明cache-num16每个 DB 的缓存数量cache-model10cache_none关闭缓存1cache_read读缓存cache-typestring,set,zset,list,hash,bit启用缓存的数据类型cache-maxmemory10G每个 DB 的缓存最大内存cache-maxmemory-policy1淘汰策略1allkeys-lru0volatile-lru7noeviction 等zset-cache-field-num-per-key512单个 zset key 在缓存中最多缓存 512 个 field对应实现可参见 include/pika_cache.h、src/pika_cache.cc 与 src/pika_cache_load_thread.ccsrc/pika_conf.cc 负责这些参数的解析与校验。7.7 运维与安全相关slowlog-log-slower-than10000 μs超过阈值的命令记录到pika-ERROR.logcompact-cron如3/02-04/60与compact-interval如6/60定时全量 compaction格式为时间区间/磁盘空闲比例compact-interval优先级更高compaction-strategyobd-compact自动 compact 策略可选full-compact、obd-compact、progressive-compactmax-client-response-size1G限制keys *、SCAN等大响应命令防止内存被打满rename-command重命名 FLUSHDB、SLAVEOF、BGSAVE、SHUTDOWN、CONFIG 等危险命令主从配置必须一致throttle-bytes-per-second约 200MB/s从库全量同步的 Rsync 限速支持config set动态调整aclfile/user : username ...支持与 Redis 类似的 ACL 用户体系如user : worker on password ~key* all。八、性能基准测试测试结果由 deep011 提供数据在特定条件与场景下测得仅供参考。强烈建议基于自身使用场景在自己环境中对 PikiwiDB 进行详细测试以评估其是否满足需求。8.1 测试环境项目配置CPUIntel(R) Xeon(R) CPU E5-2690 v4 2.60GHz56 线程内存256GB磁盘3TB Flash网络10GBase-T/Full × 2操作系统CentOS 6.6PikiwiDB 版本2.2.4压测工具vire-benchmark8.2 Case 1worker 线程数对 QPS 上限的影响测试目标评估不同 worker 线程数下 PikiwiDB 的 QPS 上限测试条件数据规模 800GB、value 128 字节、CPU 不绑定结论将 worker 线程数设置为20-24更具性价比图中 x 轴为线程数y 轴为 128 字节 value 下的 QPSset3/get7 表示 30% set 70% get。8.3 Case 2最优线程数20 线程下的 RTT 表现测试条件数据规模 800GB、value 128 字节。结果摘要 GET 10000000 requests completed in 23.10 seconds 200 parallel clients 3 bytes payload keep alive: 1 99.89% 1 milliseconds 100.00% 2 milliseconds 432862.97 requests per second SET 10000000 requests completed in 36.15 seconds 200 parallel clients 3 bytes payload keep alive: 1 91.97% 1 milliseconds 99.98% 2 milliseconds 100.00% 203 milliseconds 276617.50 requests per second结论99.9% 的 get/set 操作响应时间在 2ms 以内。8.4 Case 3各命令最大 QPS测试条件worker 线程 20、key 数 10,000、field 数 100list 除外、value 128 字节、命令执行 1000 万次lrange 除外。关键结果命令QPSrequests/sPING_INLINE548606.50PING_BULK544573.31SET231830.31GET512163.91INCR230861.56MSET10 keys94991.12LPUSH / RPUSH196093.81 / 195186.69LPOP / RPOP131156.14 / 152292.77LRANGE_10 / LRANGE_100 / LRANGE_600334448.16 / 50705.12 / 3170.38SADD / SPOP160885.52 / 128920.80HSET / HGET180209.41 / 506791.00ZADD / ZREM120583.62 / 161689.33PFADD / PFCOUNT / PFMERGE6153.47 / 28312.57 / 6007.09结论整体性能优秀但部分命令LRANGE、PFADD、PFMERGE表现相对较弱——这与 HyperLogLog 及大范围 List 读取的计算开销相符选型时建议针对这类命令做专门验证。8.5 Case 4与 Redis 的最大 QPS 对比测试条件PikiwiDB worker 线程 20、key 数 10,000、field 数 100list 除外、value 128 字节、命令执行 1000 万次LRANGE 除外、Redis 版本 3.2.0。对比图表显示 PikiwiDB 在多数命令上与 Redis 的 QPS 差距已大幅缩小尤其是在多线程并行下具体数据可参考原测试报告实际收益需结合磁盘成本 vs 内存成本的业务场景综合评估。九、可观测性指标与 Prometheus 监控9.1 PikiwiDB 内置指标分类PikiwiDB 通过info命令暴露丰富的运行指标仓库 README 归纳为 11 类Server Info系统、IP、端口、run_id、配置文件等Data Infodb 大小、log 大小、内存使用等Client Info已连接客户端数量Stats Infocompact、slot 等状态信息Network Info客户端与主从复制的进出流量及速率CPU InfoCPU 使用率Replication Info主从复制状态与 binlog 信息Keyspace Info五种数据类型实际含 Stream 等的 key 信息Command Exec Count Info命令执行计数Command Execution Time耗时命令统计慢日志RocksDB Metrics五种数据类型的 RocksDB 信息包括 Memtable、Block Cache、Compaction、SST File、Blob File 等。9.2 接入 Prometheuspika_exporter仓库 tools/pika_exporter 提供了基于 Redis-Exporter 的 Prometheus exporter构建与接入方式如下go get github.com/OpenAtomFoundation/pika/tools/pika_exporter cd $GOPATH/src/github.com/OpenAtomFoundation/pika/tools/pika_exporter make nohup ./bin/pika_exporter -pika.addr 127.0.0.1:9221 在prometheus.yml的 scrape_configs 中加入scrape_configs: - job_name: pika scrape_interval: 15s static_configs: - targets: [127.0.0.1:9121] labels: group: test启动 Prometheusprometheus --config.file./grafana/prometheus.yml常用启动参数详见 tools/pika_exporter/README.md参数环境变量默认值说明pika.addrPIKA_ADDR空一个或多个 PikiwiDB 节点地址逗号分隔pika.host-filePIKA_HOST_FILE空节点清单文件路径与 pika.addr 互斥pika.passwordPIKA_PASSWORD空节点密码逗号分隔web.listen-addressPIKA_EXPORTER_WEB_LISTEN_ADDRESS:9121exporter 监听地址check.key-patternsPIKA_EXPORTER_CHECK_KEY_PATTERNS空用 SCAN 巡检的 key 模式如db0test*,db0*abc*log.levelPIKA_EXPORTER_LOG_LEVELinfo日志级别监控指标以namespace_build_info、namespace_server_info、namespace_db_size、namespace_connected_clients、namespace_total_commands_processed等 Gauge/Counter 形式暴露标签中包含addr、alias、role等便于多实例分组告警。十、周边生态与平滑迁移PikiwiDB 之所以强调平滑迁移得益于 tools 目录下完整且分工明确的工具链tools/aof_to_pika将 Redis AOF 文件转换为 PikiwiDB 协议适合存量数据一次性搬迁tools/rdb_to_pika解析 Redis RDB 并转换导入配合 docs/ops/migrateslotCommand.md 等运维文档使用tools/pika-port在线双写/数据同步工具支持多版本pika_port_3tools/codis2pika从 Codis 集群迁移到 PikiwiDBtools/pika_to_txt/tools/txt_to_pika文本格式的中转导入导出tools/bigkey_analyzer大 key 分析为迁移前的容量评估与拆分提供依据tools/binlog_sender与tools/manifest_generatorbinlog 回放与 manifest 生成服务于增量同步与备份场景。更多运维、API、配置与调优资料可查阅 docs 目录如 config.md、adminComnand.md、MultiDB.md、bestPractice.md官方完整用户列表见 docs/USERS.md。十一、总结与选型建议PikiwiDB 的核心价值在于以 RocksDB 持久化 多线程 多粒度缓存 Redis 协议兼容把 Redis 生态的易用性延伸到大容量、低成本、可持久化的场景。它并非要替代 Redis而是与 Redis 形成互补——热数据走内存缓存、全量数据落盘让几百 GB 甚至 TB 级数据仍然能跑 Redis 协议成为现实。落地时的关键决策点可以归结为四条容量诉求数据量预期超过单机内存可承受范围尤其超过 16GiB 量级时PikiwiDB 的高容量与持久化优势最明显部署形态单机主从slaveof即可满足的场景直接用 conf/pika.conf 默认配置起步需要水平扩展则评估 Codis 集群模式与 codis 组件性能预期参考上文基准数据尤其关注 LRANGE、PFADD/PFMERGE 等弱项是否命中自身业务模型并以cache-maxmemory、cache-model、thread-num、thread-pool-size等参数做针对性调优可观测性生产环境第一时间接入 pika_exporter Prometheus/Grafanatools/pika_exporter/grafana 提供现成面板盯紧复制滞后、compaction 与磁盘水位。对运维团队而言从 Redis 迁移到 PikiwiDB 无需改动业务代码配合 tools 工具链与 docs/ops 运维文档即可平滑过渡——这正是它在大规模生产环境中被广泛采用的直接原因。赞分享数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载相关推荐Pika 完全指南基于 RocksDB 的 Redis 兼容大容量 KV 存储系统——架构、部署、配置与性能实测Pika 完全指南基于 RocksDB 的 Redis 兼容大容量 KV 存储系统——架构、部署、配置与性能实测 PikaPikiwiDB是 360 基础数据库KV存储后端Pika技术解析兼容Redis协议的大容量持久化存储系统Pika技术解析兼容Redis协议的大容量持久化存储系统 什么是Pika Pika是一款由专业数据库团队开发的高性能持久化存储系统它完全兼容Redis协议数据库KV存储后端【亲测免费】 探索Pika一个高性能的Redis兼容KV存储系统探索Pika一个高性能的Redis兼容KV存储系统 在当今的数据驱动世界中高效、可靠的数据存储系统是每个技术栈的核心。今天我们要介绍的是一个强大的开源项目数据库KV存储后端上一篇Node.js分布式锁FE-Interview中的Redis实现题下一篇treg 平台徽标集/logos/platforms/slug.svg 的无注册表约定与绘图规范创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考