跳到主要内容

What's new in PikiwiDB(Pika) v4.0.0

· 阅读需 18 分钟
360 车金鸽
Pika 开源社区

尊敬的社区成员及技术爱好者们：

PikiwiDB 社区荣耀地宣告 —— 经过 9 个月打磨并在生产环境稳定运行 5 个月的 PikiwiDB (Pika) v4.0.0 【下文简称 Pika】今天正式发布。希望基于第三代存储引擎 Floyd 的这个新版本能为社区用户们带来更卓越的体验。

1 重大改进

1.1 第三代存储引擎 Floyd​

Floyd 如同其前代 Blackwidow，基于 RocksDB，不仅支持基础的 String 结构，也原生支持了 Hash、List、Set、Stream 及 ZSet 等 KKV 形式的复合数据结构。

  • RocksDB 实例数可配置

摒弃了 Blackwidow 按数据类型采用 RocksDB 实例的物理隔离模式，Floyd 采用了 RocksDB 的 Column-Family 虚拟隔离机制，在单个 RocksDB 实例下可存储所有类型的数据。

用户可自由设定 Pika 实例中每个 DB【等同于 Redis DB】中 RocksDB 实例的数量，而数据的存储则依据 key 的 hash 值分配至相应的 RocksDB 实例，减小了数据的空间放大和读放大效应，实现了机器资源的高效利用。

  • 强类型 key

基于 RocksDB 的 Column-Family 虚拟隔离机制，Floyd 把所有类型的 key 和 string 一起存储在 Column-Family 0。

在此存储基础之上，不同于 Blackwidow，可明确禁止不同类型的 key 重复【强类型】，这一设计旨在杜绝潜在的数据冗余与不一致性，与 Redis 服务特性保持一致，进一步提升了系统的整体效率与数据质量。

Pika v2.x 系列版本基于存储引擎 Nemo，v3.x 系列版本基于 Blackwidow，它们因为采用了物理隔离机制，无法低成本实现强类型 key，所有在 Redis TYPE 命令的结果中可能返回多种类型，而 Floyd 则完全兼容 Redis 只返回一种类型。

  • Floyd 详细说明

如果对 Floyd 存储引擎感兴趣，请详阅《Floyd 存储引擎》

【链接：https://github.com/OpenAtomFoundation/pika/discussions/2052】

由于 Floyd 前后进行了多个版本的迭代，所以阅读该 github discussion 文档时请注意前后时间，如有相关冲突性说法，以最新日期的文字为准。

关键 PR： PikiwiDB(Pika) 支持 Floyd 存储引擎

https://github.com/OpenAtomFoundation/pika/pull/2413

添加 Floyd 的 compaction-filter 的 Gtest

https://github.com/OpenAtomFoundation/pika/pull/2669

Pika 不支持不同类型的重复 key, 写入重复 key 返回非法类型

https://github.com/OpenAtomFoundation/pika/pull/2609

对 HyperLogLog 和 String 进行类型隔离，确保 HyperLogLog 操作与 String 操作明确区分开

https://github.com/OpenAtomFoundation/pika/pull/2720

添加支持分区索引过滤的功能

https://github.com/OpenAtomFoundation/pika/pull/2601

1.2 Mget 批量查询缓存​

Pika v3.5.2 的热数据缓存只实现了对热点 Key 的点查 (如 get/hget)，在后续的 v3.5.3 和 v3.5.4 修复若干 bug 后，对热数据的点查目前已经非常稳定。然而并未支持批量查询 (如 mget etc)。

内部业务侧反馈批量查询速度比较慢，在 40C/256GiB/2TiB SATA SSD 规格机器上数据量超过 100GiB 时，Pika v3.3.6 30% 批量查询延迟超过 35ms。但由于 Pika 热数据缓存尚未支持批量查询，性能并未改善。

为了满足业务需求，Pika 团队开发了批量查询热数据缓存功能，显著提升了批量查询性能，降低了查询延迟和失败率。相关技术细节请阅读《PikiwiDB (Pika) 混合存储之批量查询》

【链接：https://mp.weixin.qq.com/s/KFLPruSdB66TMRxUfR9PbQ 】。

关键 PR ：

Mget 支持多 key 查询缓存，记录未命中的 key 去 DB 中查询，提升 Pika 服务的读性能

https://github.com/OpenAtomFoundation/pika/pull/2675

修复 Mget 没有使用解析 ttl 的函数导致出现部分 key 的 ttl 未被更新，数据不一致的问题

https://github.com/OpenAtomFoundation/pika/pull/2730

1.3 主从复制​

Pika v3.3.6 有很多主从复制的缺陷。v4.0.0 版本对 Pika 全量复制及增量复制进行了大量优化和 bug 修复，取得了非常好的效果。

并在 info 命令中输出了 "repl_connect_status" 指标 (PR 2638)，以方便用户更加明确清晰的确定当前的主从复制状态。

关键 PR ：

修复批量扩容时，多个 slave 同时连接 master, 短时间多次 bgsave 导致部分从节点数据不完整的问题

https://github.com/OpenAtomFoundation/pika/pull/2746

修复 Spop 在写 binlog 时可能会出现竞态问题

https://github.com/OpenAtomFoundation/pika/pull/2647

修复多 DB 下全量同步超时后不重试的问题

https://github.com/OpenAtomFoundation/pika/pull/2667

修复多 DB 主从超时场景下，可能会出现窗口崩溃的问题

https://github.com/OpenAtomFoundation/pika/pull/2666

修复主从同步限速逻辑中重复解锁的问题

https://github.com/OpenAtomFoundation/pika/pull/2657

重构主从复制模式 slave 节点的主从同步线程模型，尽可能减少 binlog 消费阻塞问题

https://github.com/OpenAtomFoundation/pika/pull/2638

1.4 Redis Stream​

Redis Stream 类似于消息队列（MQ），以便更安全地传递消息。

为了确保数据的安全性，底层引擎 BlackWidow 和 Floyd 中特别添加了对 Stream 数据类型的支持。

关键 PR：

修复 pkpatternmatchdel 命令使用错误导致的 stream 类型数据删除异常的问题

https://github.com/OpenAtomFoundation/pika/pull/2726

修复 Keyspace 命令未计算 Stream 类型数据的问题

https://github.com/OpenAtomFoundation/pika/pull/2705

1.5 Compaction​

PikiwiDB (Pika) 的底层磁盘存储引擎 RocksDB 在进行 compaction 时会显著影响 PikiwiDB (Pika) 的读写性能。

因此，控制好 compaction 是优化 Pika 读写性能的关键。

Floyd 使用了 v8.7.3 版本的 RocksDB，开放了更多 RocksDB 参数，以方便用户优化 RocksDB 性能：

  1. enable-partitioned-index-filters： 支持加载分区索引过滤器，加快 RocksDB 查找速度。
  2. min-write-buffer-number-to-merge: 默认值为 1，如果将此值设置得更大，意味着需要更多的写缓冲区被填满后才进行 flush。这样可以减少 flush 的频率，增加数据在内存中的累积量，从而可能提高写入吞吐量。
  3. level0-stop-writes-trigger: 默认值为 36，定义了 L0 层中 sst 文件的最大数量，一旦达到这个数量，RocksDB 将会采取 暂停写入、强制 compaction 等措施来防止写入操作继续累积，以避免 L0 层变得过于庞大，进而可能导致写入放大、查询性能下降等问题。
  4. level0-slowdown-writes-trigger：默认值为 20，用于控制当 Level 0 的 SST 文件数量达到这个阈值时，触发写减速（write slowdown），防止 Level 0 的文件数量过多，导致后续 compaction 操作的压力过大。
  5. level0-file-num-compaction-trigger：默认值为 4，当 Level 0 的 SST 文件数量达到这个参数设定的阈值时，RocksDB 会开始执行 compaction 操作，将 Level 0 的文件合并到 Level 1，以减少 Level 0 的文件数量，降低读取延迟，并优化存储空间的利用率。
  6. max-subcompactions：默认值为 1，用于控制 RocksDB 中并发执行的 sub-compaction 任务数量，其值为 1 表示关闭 sub-compaction。如果系统资源充足，建议提升该参数以优化 compaction 效率。
  7. max-bytes-for-level-base：指定了 L1 SST 文件总的大小。这个大小是 RocksDB 进行数据分层管理和 compaction 决策的重要依据：如果 L1 层的大小设置得太小，可能会导致 L0 层的 compaction 过于频繁，进而影响写性能。反之，如果设置得太大，可能会占用较多的磁盘空间，并且影响读取性能，因为读取操作可能需要跨越更多的层级。Pika 没有在 pika.conf 中开放此参数给用户配置，而是使用其他参数（level0-file-num-compaction-trigger 和 write-buffer-size）计算后的结果。
storage_options_.options.max_bytes_for_level_base = g_pika_conf->level0_file_num_compaction_trigger() * g_pika_conf->write_buffer_size()

关键 PR： 添加 Floyd 的 compaction-filter 的 Gtest https://github.com/OpenAtomFoundation/pika/pull/2669 添加支持分区索引过滤的功能 https://github.com/OpenAtomFoundation/pika/pull/2601 新增 RocksDB Compaction 策略动态调整参数，用户可以根据业务调整 Compaction 策略，降低 Compaction 操作对服务性能的损耗 https://github.com/OpenAtomFoundation/pika/pull/2538

1.6 可观测性​

v3.5 版本增加了包括命中率、每秒命中次数、Redis Cache 内存使用量、Redis Cache 个数、Redis Cache DB 个数 等指标，但是在集群方面的可观测性是缺失的。v4.0.0 对 Codis-Proxy 的 P99、P999、延迟等监控指标进行采集和展示，可以直观地反映线上 Codis-proxy 的运行情况。

v4.0.0 开始还提供新的工具：根据 pika benchmark 工具压测结果自动生成可视化的统计图表。

关键 PR：

Codis 支持 info 命令，可以通过该命令查询 Codis-proxy 的 info 信息

https://github.com/OpenAtomFoundation/pika/pull/2688

Codis-proxy 新增 P99 P95 等监控耗时指标

https://github.com/OpenAtomFoundation/pika/pull/2668

添加 Pika 压测指标，提升 Pika 压测效率，并输出可视化的统计图表

https://github.com/OpenAtomFoundation/pika/pull/2663

1.7 测试集​

PikiwiDB(Pika) 测试集由 gtest 单测、Redis TCL 测试集和 Go 测试集组成。v4.0.0 中丰富了诸多特性的 go test 功能，并进一步完善了基本数据类型的 TCL 测试。

关键 PR：

添加 Floyd 的 compaction-filter 的 Gtest

https://github.com/OpenAtomFoundation/pika/pull/2669

Pika Geo 数据类型增加 TCL 测试，并修复测试过程中遇到的缺陷

https://github.com/OpenAtomFoundation/pika/pull/2753

1.8 跨平台​

PikiwiDB(Pika) 以往仅支持 centos 和 ubuntu 等 linux 平台，v3.5 开始支持 Mac 等平台。v4.0.0 将对 Mac 平台的支持扩展至 FreeBSD 平台。

关键 PR：

Pika 支持在 FreeBSD14 平台上进行编译

https://github.com/OpenAtomFoundation/pika/pull/2711

2 改进列表

下面详细列出了本次发版的主要功能升级和改进。

2.1 新特性​

2.2 bug 修复​

2.3 提升改进项​

2.4 发版 tag​

​ https://github.com/OpenAtomFoundation/pika/releases/tag/v4.0.0

3 社区

感谢所有为 v4.0.0 做出贡献的社区成员，包括 issue/PR 提交者、代码 reviewer 【排名不分先后，依据字母序列】：

  • AlexStocks
  • baerwang
  • chejinge
  • cheniujh
  • chienguo
  • guangkun123
  • gukj-spel
  • longfar-ncy
  • lqxhub
  • luky116
  • Mixficsol
  • saz97
  • wangshao1

PikiwiDB (Pika) 开源社区热烈欢迎您的参与和支持。如果您有任何问题、意见或建议，请扫码添加 PikiwiDB 小助手【微信号: PikiwiDB】为好友，它会拉您加入官方微信群。

What's new in PikiwiDB(Pika) v3.5.4

· 阅读需 7 分钟
陈俊华
360

PikiwiDB (Pika) 社区非常荣幸地宣布，我们的最新 v3.5.4 正式生产可用版本现已发布。

v3.5.4 解决了历史遗留的 bug，对 PikiwiDB (Pika) 的一些遗留 bug 进行修复和优化，旨在打造出一个高稳定性的版本。本次的重点优化主要包括，PikiwiDB (Pika) 支持动态调整限速参数、增强 PikiwiDB (Pika) 的客观测性指标、 磁盘 IO 限速支持读限速及写限速等。

1 新特性​

  1. Pika 支持动态调整全量同步限速参数 rsync-timeout-ms 和 throttle-bytes-per-second。

自 v3.5.0 版本开始，PikiwiDB (Pika) 服务摒弃了通过子进程内使用原来 rsync 工具进行主从全量同步的逻辑，在 PikiwiDB (Pika) 内部以线程方式【称作 rsync 线程】自行实现了新的全量同步逻辑，避免因为外部进程不可控引起的主从同步问题，根据 360 内部 Pika 线上大规模集群运维的经验，在 PikiwiDB (Pika) 主从进行全量同步的过程中，如果遇到某些不利的外部因素，如网络波动，硬件故障（如网卡降速导致的主从网卡速率不匹配）等，可能引起 rsync 线程请求持续超时（PikiwiDB (Pika) 内置 rsync 模块用于全量同步阶段的文件传输），且超时重试所发出的包可能引发更大的网络信道负担。此时对于运维人员来说，如果能动态调整 rsync 请求的超时时间和 rsync 传输的速率上限，不仅意味着对全量同步阶段控制粒度的进一步细化，更大大降低了在该场景下的运维处置难度。

关键 PR：

https://github.com/OpenAtomFoundation/pika/pull/2633

  1. 将 info key space 1 的结果输出至 info all 并展示到监控界面中。

PikiwiDB (Pika) 是通过 Info 命令采集数据至 Pika-Exporter，展示到 Grafana 界面上的，目前界面上部分数据是没有展示的，如 keys 的数量，本次将执行 info keyspace 的结果展示到监控界面，用户可以通过这个指标来查看存储的量级等。

关键 PR：

https://github.com/OpenAtomFoundation/pika/pull/2603

3.Pika 磁盘 IO 限速参数支持 OnlyRead、OnlyWrite、ReadAndWrite，默认支持 OnlyWrite。

自 3.5.0 版本开始，PikiwiDB(Pika) 服务可以通过调整 rate-limit 参数实现写限速，防止在网卡质量不高的情况下磁盘 IO 过重导致服务不可用，或者 binlog 阻塞的情况发生。360 内部 Pika 线上大规模集群运维的经验，在 PikiwiDB (Pika) 实例的网卡较差情况下，也需要对读实例进行限速，本次修改支持读、写限速，默认是写限速，调整 config 配置中的 rate-limiter-mode 可以设置为读限速，或者同时读写限速。

关键 PR：

2 改进列表

3 Bug 修复

4 社区

PikiwiDB (Pika) 开源社区热烈欢迎您的参与和支持。如果您有任何问题、意见或建议，可通过以下渠道联系我们：

![图片](data:image/svg+xml,%3C%3Fxml version='1.0' encoding='UTF-8'%3F%3E%3Csvg width='1px' height='1px' viewBox='0 0 1 1' version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'%3E%3Ctitle%3E%3C/title%3E%3Cg stroke='none' stroke-width='1' fill='none' fill-rule='evenodd' fill-opacity='0'%3E%3Cg transform='translate(-249.000000, -126.000000)' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

img

微信扫一扫 关注该公众号

What's new in Pika v3.5.3 （英文版本）

· 阅读需 9 分钟
360 中间件团队
Pika 开源社区

As Redis announces the adoption of dual protocols to maintain its commercial interests, the PikiwiDB (Pika) community is pleased to announce the release of the v3.5.3 stable version for production use today.

The v3.5.3 version addresses historical bugs and introduces a multitude of new features. These features primarily include Pika's support for ACL, the removal of residual Slot code from the Sharing mode, separation of fast and slow commands, Redis Stream support, large key analysis tools, and Pika's distributed cluster support for fully automated failover, among others. Additionally, we have enriched the automation test cases in version 3.5.3 to enhance the stability and robustness of the Pika service, providing users with a more efficient and stable experience. This article will mainly elaborate on the significant features, bug fixes, and performance improvements in this update.

Before diving into the main release content of version 3.5.3, please note the following statements:

  1. Due to trademark issues, the Pika project has been renamed to PikiwiDB. In this article, we will use PikiwiDB (Pika) to refer to the project at https://github.com/OpenAtomFoundation/pika.
  2. We have created a new project https://github.com/OpenAtomFoundation/pikiwidb, which is a large-capacity KV database compatible with the Redis protocol and based on the Raft protocol. It is mainly designed for scenarios requiring strong consistency, such as storing metadata at a scale of about 10TiB. PikiwiDB will be used to refer to this project specifically.

1 Major Improvements​

1.1 PikiwiDB (Pika) Supports ACL​

PikiwiDB (Pika) 3.5.3 now fully supports Redis ACL, laying a solid foundation for future multi-tenant support in cloud-native Pika clusters. Before 3.5.3, Pika already supported Redis user authentication methods such as auth/userpass/requirepass, as well as its own command blacklist mode configured through userblacklist in pika.conf. This update maintains backward compatibility and supports these existing methods.

Moreover, we have integrated all Redis ACL TCL test suites into PikiwiDB (Pika)'s test suite to ensure that PikiwiDB (Pika)'s ACL implementation is fully compatible with Redis ACL.

Key PRs:

1.2 Hybrid Storage Model Supports Bitmap​

In a single-node environment, it is impossible to simultaneously optimize PikiwiDB (Pika)'s read/write/compaction, which is known as the "impossible triangle." In version v3.5.2, we supported hybrid storage consisting of cached Redis and RocksDB, which supported five data structures: string/list/set/zset/hashtable. In this release, we have added support for bitmap: https://github.com/OpenAtomFoundation/pika/pull/2253

Additionally, we now support dynamic tuning of Redis cache parameters in version 3.5.3: https://github.com/OpenAtomFoundation/pika/pull/2197

1.3 Separation of Fast and Slow Commands​

To prevent slow commands from blocking the execution of fast commands, we have implemented the separation of fast and slow commands at both the Codis-Proxy and PikiwiDB (Pika) levels.

https://github.com/OpenAtomFoundation/pika/pull/2162

1.4 Redis Stream​

While PikiwiDB (Pika) previously supported Redis pubsub, which only allowed for online message passing, in version 3.5.3, we have added limited support for Redis Stream, similar to a message queue (MQ), to facilitate safer message transmission. To ensure data safety, we have specifically added support for the Stream data type in our underlying engine, BlackWidow.

Key PR:

Please note that Pika Stream currently does not support consumer group consumption and will be available in future updates.

1.5 Cloud-Native Cluster​

In PikiwiDB (Pika) 3.5.0, we open-sourced a Pika-Operator that supports deploying a pair of Pika master and slave on K8s. In version 3.5.2, based on Kubeblocks, our Pika-Operator supported deploying a Pika Cluster in the form of Codis on K8s, but it did not support dynamic scaling at the time.

In version 3.5.3, the latest Pika-Operator now supports node scaling at the Codis Group level and data rebalance.

Key PRs:

1.6 Compaction Improvements​

PikiwiDB (Pika)'s underlying disk storage engine, RocksDB, significantly impacts PikiwiDB (Pika)'s read and write performance during compaction, which appears as "spikes" in monitoring systems. Controlling compaction is key to optimizing Pika's read and write performance.

Key PRs for compaction improvements:

1.7 Automatic Failover​

PikiwiDB (Pika) clusters are currently based on Codis. To enhance the usability of PikiwiDB (Pika) Clusters based on Codis, we have made many extensions to Codis.

The original Codis did not support failover within Groups, requiring the use of Redis Sentinel, which increases operational costs. We have implemented auto failover for Groups within Codis Dashboard by drawing on the functionality of sentinel.

Key PR:

1.8 Observability Enhancements​

The key component for PikiwiDB (Pika) observability is Pika-Exporter. Although Redis Cache was added to the 3.5.2 version, it lacked monitoring metrics. In version 3.5.3, we have added metrics such as hit rate, hits per second, Redis Cache memory usage, number of Redis Caches, and number of Redis Cache DBs.

Key PRs:

1.9 Data Consistency​

Version 3.5.3 fixes numerous PikiwiDB (Pika) master-slave synchronization issues, ensuring data consistency.

Key PRs:

1.10 Test Suite Additions​

The PikiwiDB (Pika) test suite consists of gtest unit tests, Redis TCL test suites, and Go test suites. In 3.5.3, we have added Codis cluster e2e tests.

Key PRs:

1.11 Toolkit Additions​

PikiwiDB (Pika) has always valued the construction of toolkits, and all related tools can be found at https://github.com/OpenAtomFoundation/pika/tree/unstable/tools. In 3.5.3, we have added a new tool:

1.12 Documentation Updates​

The PikiwiDB (Pika) documentation mainly consists of wiki documentation. In 3.5.3, we have updated the documentation for the Redis commands supported by Pika.

Documentation link: https://github.com/OpenAtomFoundation/pika/wiki/Pika-Supports-Redis-Interface-and-Content-Situation

2 Release Improvements​

In the first chapter, we described the main feature upgrades and improvements of version 3.5.3. Below is a detailed list of the relevant PRs for this release.

2.1 New Features​

2.2 Bug Fixes​

2.3 Release Tag​

PikiwiDB (Pika) v3.5.3 Release Tag

3 Community​

If you have any questions, feel free to join our community discussion group. The PikiwiDB (Pika) open-source community appreciates your support and help.

What's new in Pika v3.5.3

· 阅读需 15 分钟
360 中间件团队
Pika 开源社区

随着 Redis 宣布采用双协议以维护其商业利益，PikiwiDB(Pika) 社区非常荣幸地宣布之际，我们的最新 v3.5.3 正式生产可用版本现已发布。

v3.5.3 版本不仅修复了长期存在的 Bug，还引入了一系列新特性。这些新特性包括 Pika 对 ACL 的支持、移除了 Sharing 模式的残留 Slot 代码、命令执行的快慢分离、Redis Stream 支持、大 key 分析工具、以及 Pika 分布式集群的全自动化 failover 等。此外，我们在 3.5.3 版本中增加了更多的自动化测试用例，以提高 Pika 服务的稳定性和健壮性，确保用户能够享受到更高效、更稳定的使用体验。本文将详细介绍本次更新的主要功能、Bug 修复和性能提升。

在深入探讨 3.5.3 版本的更新内容之前，请注意以下几点声明：

  1. 由于商标问题，Pika 项目已更名为 PikiwiDB。在本文中，我们将使用 PikiwiDB(Pika) 来指代项目，项目地址为：https://github.com/OpenAtomFoundation/pika
  2. 我们创建了一个新项目 https://github.com/OpenAtomFoundation/pikiwidb，这是一个基于 Raft 协议实现的兼容 Redis 协议的大容量 KV 数据库，主要面向强一致性数据场景，例如存储约 10TiB 规模的元数据。PikiwiDB 将专门用于指代此项目。
  3. 我们为 PikiwiDB 设计了一个新的 logo，作为其商标，并已在相关政府机构注册。

1 主要更新​

1.1 支持 ACL​

PikiwiDB(Pika) 3.5.3 版本正式全面支持 Redis ACL，为未来在云原生 Pika 集群中支持多租户场景奠定了基础。在此之前，Pika 已经支持了 Redis 的用户认证方式，如 auth/userpass/requirepass，以及通过 pika.conf 中的 userblacklist 配置命令黑名单模式。本次更新保持了向后兼容，并支持这些已有的使用方式。

我们还确保 PikiwiDB(Pika) 的 ACL 实现与 Redis ACL 完全兼容，通过将 Redis 的所有 ACL TCL 测试集纳入 PikiwiDB(Pika) 的测试集中。

关键 PR 链接：

1.2 混合存储模型支持 bitmap​

在单体环境下，同时优化 PikiwiDB(Pika) 的读/写/compaction 是一项挑战。在 v3.5.2 版本中，我们引入了由缓存 Redis 和 RocksDB 构成的混合存储模型，并支持了 string/list/set/zset/hashtable 五种数据结构。在 3.5.3 版本中，我们增加了对 bitmap 的支持。

此外，我们在 3.5.3 版本中支持对 Redis 缓存进行动态参数调整。

关键 PR 链接：

1.3 快慢命令分离​

为了避免慢命令阻塞快命令的执行，我们在 Codis-Proxy 和 PikiwiDB(Pika) 两个层面实现了快慢命令分离。

关键 PR 链接：

1.4 Redis Stream 支持​

虽然 PikiwiDB(Pika) 之前支持了 Redis pubsub，但它只能进行在线消息传递。在 3.5.3 版本中，我们增加了对 Redis Stream 的有限支持，类似于消息队列（MQ），以便更安全地传递消息。为了确保数据的安全性，我们在底层引擎 BlackWidow 中特别添加了对 Stream 数据类型的支持。

关键 PR 链接：

请注意，Pika Stream 目前还不支持消费组消费，这将在后续版本中实现。

1.5 云原生集群​

在 PikiwiDB(Pika) 3.5.0 版本中，我们开源了 Pika-Operator，它支持在 K8s 上部署 Pika 主从对。在 3.5.2 版本中，我们基于 Kubeblocks 的 Pika-Operator 支持了在 K8s 上部署类似 Codis 的 Pika Cluster，但当时还不支持动态扩缩容。

在 3.5.3 版本中，最新的 Pika-Operator 已经支持了 Codis Group 级别的节点扩缩容，并且支持数据的 Rebalance。

关键 PR 链接：

1.6 Compaction 优化​

PikiwiDB(Pika) 的底层磁盘存储引擎 RocksDB 在进行 compaction 时会显著影响 PikiwiDB(Pika) 的读写性能。因此，控制好 compaction 是优化 Pika 读写性能的关键。

关键 PR 链接：

1.7 自动 Failover​

PikiwiDB(Pika) 集群目前是基于 Codis 实现的。为了提高基于 Codis 的 PikiwiDB(Pika) Cluster 的易用性，我们对 Codis 进行了许多扩展。

原始的 Codis 不支持 Group 内的 Failover，需要使用 Redis Sentinel，这会导致运维成本增加。我们在 Codis Dashboard 中加入了 sentinel 的功能，实现了对 Group 内主从的自动 failover。

关键 PR 链接：

1.8 可观测性提升​

PikiwiDB(Pika) 的可观测性关键组件是 Pika-Exporter。在 3.5.2 版本中，我们虽然添加了 Redis Cache 缓存热数据，但缺少监控指标。在 3.5.3 版本中，我们增加了包括命中率、每秒命中次数、Redis Cache 内存使用量、Redis Cache 个数、Redis Cache DB 个数 等指标。

关键 PR 链接：

1.9 数据一致性​

3.5.3 版本修复了许多 PikiwiDB(Pika) 主从同步问题，确保数据的一致性。

关键 PR 链接：

1.10 测试集增加​

PikiwiDB(Pika) 的测试集由 gtest 单测、Redis TCL 测试集和 Go 测试集组成。在 3.5.3 版本中，我们增加了 Codis 集群 e2e 测试。

关键 PR 链接：

1.11 工具集更新​

PikiwiDB(Pika) 一直重视工具集的建设，所有相关工具都可以在 https://github.com/OpenAtomFoundation/pika/tree/unstable/tools 中找到。在 3.5.3 版本中，我们新增了一个工具：

1.12 文档更新​

PikiwiDB(Pika) 的文档主要是 wiki 文档。在 3.5.3 版本中，我们更新了 Pika 支持的 Redis 命令文档。

文档链接：https://github.com/OpenAtomFoundation/pika/wiki/pika-%E6%94%AF%E6%8C%81%E7%9A%84redis%E6%8E%A5%E5%8F%A3%E5%8F%8A%E5%85%BC%E5%AE%B9%E6%83%85%E5%86%B5

2 发版详情​

在第一章节中，我们概述了 3.5.3 版本的主要功能升级和改进。下面详细列出了本次发版的相关 PR。

2.1 新特性​

2.2 Bug 修复​

2.3 发版标签​

https://github.com/OpenAtomFoundation/pika/releases/tag/v3.5.3

3 社区​

PikiwiDB(Pika) 开源社区感谢您的支持，如果您有任何疑问或建议，欢迎加入我们的社区交流群：

What's new in Pika v3.5.2

· 阅读需 3 分钟
于雨
dubbo-go开源社区

Pika 社区近期发布了备受期待的 v3.5.2 版本 https://github.com/OpenAtomFoundation/pika/releases/tag/v3.5.2-alpha ，不仅解决了历史遗留的 Bug 问题，还引入了多项新特性。这些新特性主要包括 Pika 支持 Redis 事务、Pika 上层增加缓存层实现冷热数据分离、提升读性能、Codis-Proxy 支持动态修改配置参数等等，无疑将会让用户感受到更为高效和稳定的使用体验。

新特性​

bugfix

下期版本规划

预计再过两个月左右，我们会在农历新年前发布 3.5.3 版本，相关关键特性有：

感谢大家对 Pika 开源公众号的关注 ，Pika 3.5 版本重大特性及使用规范我们会在稍后的文章中进行介绍，我们下期再见～

2023-09-28-Pika-3.5.2-connect

What's new in Pika v3.5.1

· 阅读需 5 分钟
于雨
dubbo-go开源社区

Pika 社区很高兴宣布，我们今天发布已经过我们生产环境验证 v3.5.1 版本 https://github.com/OpenAtomFoundation/pika/releases/tag/v3.5.1 。

该版本不仅做了很多优化工作，还引入了多项新功能。这些新功能包括 动态关闭 WAL、ReplicationID 检测是否增量复制、在 K8s 环境上 Pika 服务的自动注册从而实现集群的自组织、以及 exporter 检测集群指标等等，无疑将会让用户享受到更为稳定和高效的 NoSQL 使用体验。

新特性​

  • 1 Slow log 增加队列等待时间统计，在队列阻塞的时候方便我们进行问题定位。PR 1997， 作者 wangshao1。
  • 2 主从复制使用 ReplicationID 判断是否进行增量同步，解决原主从同步方式切主后整个数据集会进行全量复制的问题，可以提升 Pika 性能。PR 1951， 作者 Mixficsol。
  • 3 WAL 以 'disablewal' 命令方式支持动态关闭，在写性能遇到瓶颈的时候，可以通过命令关闭 WAL 缓解写性能下降的问题，关闭 WAL 有机器宕机后丢失数据的风险，用户需要根据自己的使用习惯权衡。PR 2015，作者 Mixficsol。
  • 4 flush 线程数和 compaction 线程数合二为一，在 Compaction 性能瓶颈时，可以动态调整线程数，缓解 Comapction 损耗 Pika 性能的问题。PR 2014， 作者 Tianpingan。
  • 5 升级了 RocksDB 版本到 v8.3.3。PR 2000， 作者 dingxiaoshuai123。
  • 6 新增周期性打印工作队列的长度功能，在队列阻塞的时候可以快速定位问题。PR 1978， 作者 Tianpingan。
  • 7 新增利用一个 pika_exporter 监测整个集群的指标，实现一个 Pika Exporter 实例监控整个集群，解决了 3.5.0 版本一个 Pika Exporter 监测一个 Pika 实例消耗资源的问题。PR 1953， 作者 chenbt-hz。
  • 8 实现在 K8s 环境上 Pika 服务的自动注册，在启动时自动注册，从而实现集群的自组织 ，实现了通过命令拉起整个 Pika Cluster 集群。PR 1931， 作者 machinly。

2 bug 修复​

  • 1 调整了 Rate_limit 参数，修复了压测时出现 RPS 为 0 的情况 。PR 2009， 作者 Mixficsol。
  • 2 修复了 INFODATA 命令中对于遍历数据文件时出现空路径的逻辑判断。PR 1996， 作者 Mixficsol。
  • 3 修复了 Codis 在线上出现大毛刺的问题。PR 2016， 作者 chejinge。
  • 4 修复了 macOS 环境下编译使用 tools 导致编译不过的问题 。PR 2011， 作者 A2ureStone。
  • 5 减少了 exporter 非必要日志的打印，降低 了资源利用率。PR 1945， 作者 Mixficsol。

3 使用建议​

本次新增了几个配置参数，大家在使用过程中，需要根据使用情况按需调整：

  • 1 max-rsync-parallel-num：主从全量复制线程数，需要根据自己机器 CPU 核数和部署实例个数进行调整，建议最小设置为 2。
  • 2 rate-limiter-bandwidth: 限制 RocksDB 数据库读写速度，限制数据库在一定时间内可以读写的数据量，默认 2000MiB/s，需要根据自己的机器性能和部署实例做调整。
  • max-background-jobs: compaction 和 flushdb 线程数，要根据自己机器 CPU 核数和部署实例个数进行调整，建议最小设置为 4。
  • 3 throttle-bytes-per-second: 主从复制传输限速参数，默认为 200MiB/s，该参数可以根据机器网卡的配置及部署 pika 实例的个数进行调整。

2023-09-28-Pika-3.5.1-connect.png

What's new in Pika v3.5.0

· 阅读需 10 分钟
于雨
dubbogo示土区

时隔两年，Pika 社区正式发布经由社区 50 多人参与开发并在 360 生产环境验证可用的 v3.5.0 版本，新版本在提升性能的同时，也支持了 Codis 集群部署，BlobDB KV 分离，增加 Exporter 等新特性。

我们将详细介绍该版本引入的重要新特性。

1 去除 Rsync​

在 v3.5.0 版本之前，Pika 使用 Rsync 工具进行引擎中存量数据的同步，Pika 进程启动时创建 Rsync 子进程。这种同步方式在实际使用中出现了一些问题，包括Pika 进程 crash 后重新拉起无法正常同步以及同步过程中 Rsync 进程无故退出等。在今年发布的 v3.5.0 版本中，我们在全量同步方案方面进行了重要的改进，摒弃了以往使用的 Rsync，实现了全新的数据同步方案，支持了断点续传，动态调节传输限速等特性，以确保同步过程更加稳定、可控。这些改进不仅增强了同步的可靠性，还为用户提供了更好的使用体验。

2 兼容更多 Redis 命令​

在 v3.5.0 版本中，我们迈出了更大的一步，提升了对 Redis 命令的兼容性，对 Redis 命令提供了更广泛的支持。这个版本的改进使得 Pika 在与 Redis 生态系统的集成中表现更加出色，为用户提供了更丰富的功能和更广阔的可能性。我们对命令支持的扩展，为用户提供了更多的灵活性，以满足不同场景下的需求。

3 RocksDB 版本升级和分级压缩​

在 v3.5.0 版本中，我们进行了一项重要的升级，将 RocksDB 引擎升级至 v8.1.1 版本，并实现了分级压缩功能的整合。这一升级不仅是技术的飞跃，也是我们对系统性能和优化的持续关注的体现。通过这项升级，我们为 Pika 增加了更高级别的数据管理能力，同时也让系统更好地适应不同的压缩需求，为用户的数据存储和检索提供了更大的灵活性和效率。

4 支持 BlobDB​

在 v3.5.0 版本中，我们引入了引人瞩目的创新--对 BlobDB 和 KV 存储层进行了分离，为我们的系统注入了新的活力。这个版本的升级使得 Pika 在数据存储方面更加灵活和高效。我们通过支持 BlobDB KV 分离，提供了更优化的数据存储结构，为用户的数据管理和查询操作带来了更深层次的优势。这一重要改进将在更多应用场景下展现出其强大的潜力。

5 基于 Codis 的集群模式​

在 v3.5.0 版本中，我们积极引入了 Codis 集群模式，此外，我们不仅仅将 Codis 集群模式融入了系统中，还为其提供了迁移 slot 的命令支持，从而实现了更加智能化的集群管理。这一重大变革不仅扩展了 Pika 在大规模数据存储场景中的应用范围，还进一步提升了系统的可扩展性和高可用性。通过引入 Codis 集群模式，我们对用户的数据处理和管理提供了更优化的解决方案。

6 可观测性​

在 v3.5.0 版本中，我们引入了一个创新性的工具--pika_exporter，以提升对 Pika 数据库的可观测性。这一工具的加入不仅是对我们对系统监测能力的持续增强的反映。而在版本的后续更新中，我们进一步充实了指标，不断丰富了 Pika 的可观测性。为用户提供了更为全面和精准的数据洞察力。

7 容器化部署​

在 v3.5.0 版本中，我们引入了一个具有创新意义的里程碑--pika-operator mvp 版本，这一版本在技术上实现了一个重要目标：将 Pika 单实例服务迁移到 Kubernetes（K8s）平台上的快速部署。这不仅是对我们持续关注行业发展的体现，也是我们不断提升用户体验的追求。通过 pika-operator，我们为用户提供了更便捷的部署方案，将 Pika 的高性能数据库引擎与 Kubernetes 的灵活性相融合，从而为用户的应用环境带来更高效、更弹性的支持。

8 跨平台编译​

在 v3.5.0 版本中，Pika 呈现出一种全面性的蓬勃发展态势，得以在不同操作系统平台上展现其优越性。此版本的突破性之处在于，Pika 实现了对 MacOS、CentOS 和 Ubuntu 这些主要平台的完整编译和使用支持。这个举措不仅仅体现了我们对多样化技术环境的关注，也是为了最大程度地拓展用户基础，为广泛的用户群体提供灵活、高效的数据库解决方案。这种跨平台兼容性的加强将 Pika 推向更广阔的技术生态。

9 多平台集成测试及单元测试​

在 v3.5.0 版本中，我们迈出了一个令人瞩目的步伐，不仅在多个主要操作系统平台上实现了支持，还在测试领域实施了全面升级。我们为 Ubuntu、CentOS 和 MacOS 这三大平台搭建了持续集成（CI）环境，以确保系统的完整性和稳定性。在测试方面，我们引入了更为广泛的覆盖，包括 Go 语言的集成测试、TCL 的单元测试以及 Python 的端到端（E2E）测试。通过这些测试策略的升级，我们在确保系统性能和可靠性方面迈出了更大的一步。

10 Others​

若您有任何疑问，诚挚欢迎您扫描微信二维码，加入我们的交流群，与一众志同道合的成员展开深入的讨论，我们热切期待与您分享见解、交流心得，为共同的技术探索和创新之旅添砖加瓦。在这个群体中，我们将以卓越的智慧和互动的合作精神，构建出一个相互学习、不断进步的技术共同体。

2023-08-25-Pika-3.5.0

Pika Blackwidow 引擎数据存储格式

· 阅读需 13 分钟
Axlgrep
Pika 开源社区

Blackwidow本质上是基于rocksdb的封装，使本身只支持kv存储的rocksdb能够支持多种数据结构, 目前Blackwidow支持五种数据结构的存储：String结构(实际上就是存储key, value), Hash结构，List结构，Set结构和ZSet结构， 因为Rocksdb的存储方式只有kv一种， 所以上述五种数据结构最终都要落盘到Rocksdb的kv存储方式上，下面我们展示Blackwidow和rocksdb的关系并且说明我们是如何用kv来模拟多数据结构的。

pika-blackwidow-1

1. String结构的存储​

String本质上就是Key, Value, 我们知道Rocksdb本身就是支持kv存储的， 我们为了实现Redis中的expire功能，所以在value后面添加了4 Bytes用于存储timestamp, 作为最后Rocksdb落盘的kv格式，下面是具体的实现方式:

pika-blackwidow-2

如果我们没有对该String对象设置超时时间，则timestamp存储的值就是默认值0， 否则就是该对象过期时间的时间戳， 每次我们获取一个String对象的时候， 首先会解析Value部分的后四字节， 获取到timestamp做出判断之后再返回结果。

2. Hash结构的存储​

blackwidow中的hash表由两部分构成，元数据(meta_key, meta_value), 和普通数据(data_key, data_value), 元数据中存储的主要是hash表的一些信息， 比如说当前hash表的域的数量以及当前hash表的版本号和过期时间(用做秒删功能), 而普通数据主要就是指的同一个hash表中一一对应的field和value，作为具体最后Rocksdb落盘的kv格式，下面是具体的实现方式:

  1. 每个hash表的meta_key和meta_value的落盘方式: pika-blackwidow-3

meta_key实际上就是hash表的key, 而meta_value由三个部分构成: 4Bytes的Hash size(用于存储当前hash表的大小) + 4Bytes的Version(用于秒删功能) + 4Bytes的Timestamp(用于记录我们给这个Hash表设置的超时时间的时间戳， 默认为0)

  1. hash表中data_key和data_value的落盘方式: pika-blackwidow-4

data_key由四个部分构成: 4Bytes的Key size(用于记录后面追加的key的长度，便与解析) + key的内容 + 4Bytes的Version + Field的内容， 而data_value就是hash表某个field对应的value。

  1. 如果我们需要查找一个hash表中的某一个field对应的value, 我们首先会获取到meta_value解析出其中的timestamp判断这个hash表是否过期， 如果没有过期， 我们可以拿到其中的version, 然后我们使用key, version，和field拼出data_key, 进而找到对应的data_value（如果存在的话)

3. List结构的存储​

blackwidow中的list由两部分构成，元数据(meta_key, meta_value), 和普通数据(data_key, data_value), 元数据中存储的主要是list链表的一些信息， 比如说当前list链表结点的的数量以及当前list链表的版本号和过期时间(用做秒删功能), 还有当前list链表的左右边界(由于nemo实现的链表结构被吐槽lrange效率低下，所以这次blackwidow我们底层用数组来模拟链表，这样lrange速度会大大提升，因为结点存储都是有序的), 普通数据实际上就是指的list中每一个结点中的数据，作为具体最后Rocksdb落盘的kv格式，下面是具体的实现方式

  1. 每个list链表的meta_key和meta_value的落盘方式: pika-blackwidow-5

meta_key实际上就是list链表的key, 而meta_value由五个部分构成: 8Bytes的List size(用于存储当前链表中总共有多少个结点) + 4Bytes的Version(用于秒删功能) + 4Bytes的Timestamp(用于记录我们给这个List链表设置的超时时间的时间戳， 默认为0) + 8Bytes的Left Index（数组的左边界) + 8Bytes的Right Index(数组的右边界)

  1. list链表中data_key和data_value的落盘方式: pika-blackwidow-6

data_key由四个部分构成: 4Bytes的Key size(用于记录后面追加的key的长度，便与解析) + key的内容 + 4Bytes的Version + 8Bytes的Index(这个记录的就是当前结点的在这个list链表中的索引)， 而data_value就是list链表该node中存储的值

4. Set结构的存储​

blackwidow中的set由两部分构成，元数据(meta_key, meta_value), 和普通数据(data_key, data_value), 元数据中存储的主要是set集合的一些信息， 比如说当前set集合member的数量以及当前set集合的版本号和过期时间(用做秒删功能), 普通数据实际上就是指的set集合中的member，作为具体最后Rocksdb落盘的kv格式，下面是具体的实现方式：

  1. 每个set集合的meta_key和meta_value的落盘方式: pika-blackwidow-7

meta_key实际上就是set集合的key, 而meta_value由三个部分构成: 4Bytes的Set size(用于存储当前Set集合的大小) + 4Bytes的Version(用于秒删功能) + 4Bytes的Timestamp(用于记录我们给这个set集合设置的超时时间的时间戳， 默认为0)

  1. set集合中data_key和data_value的落盘方式: pika-blackwidow-8

data_key由四个部分构成: 4Bytes的Key size(用于记录后面追加的key的长度，便与解析) + key的内容 + 4Bytes的Version + member的内容， 由于set集合只需要存储member, 所以data_value实际上就是空串

5. ZSet结构的存储​

blackwidow中的zset由两部部分构成，元数据(meta_key, meta_value), 和普通数据(data_key, data_value), 元数据中存储的主要是zset集合的一些信息， 比如说当前zset集合member的数量以及当前zset集合的版本号和过期时间(用做秒删功能), 而普通数据就是指的zset中每个member以及对应的score, 由于zset这种数据结构比较特殊，需要按照memer进行排序，也需要按照score进行排序， 所以我们对于每一个zset我们会按照不同的格式存储两份普通数据, 在这里我们称为member to score和score to member，作为具体最后Rocksdb落盘的kv格式，下面是具体的实现方式：

  1. 每个zset集合的meta_key和meta_value的落盘方式:

meta_key实际上就是zset集合的key, 而meta_value由三个部分构成: 4Bytes的ZSet size(用于存储当前zSet集合的大小) + 4Bytes的Version(用于秒删功能) + 4Bytes的Timestamp(用于记录我们给这个Zset集合设置的超时时间的时间戳， 默认为0)

  1. 每个zset集合的data_key和data_value的落盘方式(member to score):

member to socre的data_key由四个部分构成：4Bytes的Key size(用于记录后面追加的key的长度，便与解析) + key的内容 + 4Bytes的Version + member的内容， data_value中存储的其member对应的score的值，大小为8个字节，由于rocksdb默认是按照字典序进行排列的，所以同一个zset中不同的member就是按照member的字典序来排列的(同一个zset的key size, key, 以及version，也就是前缀都是一致的，不同的只有末端的member).

  1. 每个zset集合的data_key和data_value的落盘方式(score to member):

score to member的data_key由五个部分构成：4Bytes的Key size(用于记录后面追加的key的长度，便与解析) + key的内容 + 4Bytes的Version + 8Bytes的Score + member的内容， 由于score和member都已经放在data_key中进行存储了所以data_value就是一个空串，无需存储其他内容了，对于score to member中的data_key我们自己实现了rocksdb的comparator，同一个zset中score to member的data_key会首先按照score来排序， 在score相同的情况下再按照member来排序

Blackwidow相对于Nemo有哪些优势​

  1. Blackwidow采用了rocksdb的column families的新特性，将元数据和实际数据分开存放(对应于上面的meta数据和data数据), 这种存储方式相对于Nemo将meta, data混在一起存放更加合理， 并且可以提升查找效率(比如info keyspace的效率会大大提升)
  2. Blackwidow中参数传递大量采用Slice而Nemo中采用的是std::string, 所以Nemo会有很多没有必要的string对象的构造函数以及析构函数的调用，造成额外的资源消耗，而Blackwidow则不会有这个问题
  3. Blackwidow对kv模拟多数据结构的存储格式上做了重新设计(具体可以参考Nemo引擎数据存储格式和本篇文章)，使之前在Nemo上出现的一些无法解决的性能问题得以解决，所以Blackwidow的多数据结构在某些场景下性能远远优于Nemo
  4. 原来Nemo对多数据结构的Key的长度最大只能支持到256 Bytes，而Blackwidow经过重新设计，放开了多数据结构Key长度的这个限制
  5. Blackwidow相对于Nemo更加节省空间，Nemo由于需要nemo-rocksdb的支持，所以不管在meta还是data数据部分都追加了version和timestamp这些信息，并且为了区分meta_key和data_key, 在最前面加入s和S(拿Set数据结构打比方)，Blackwidow在这方面做了优化，使同样的数据量下Blackwidow所占用的空间比Nemo要小(举个例子，Blackwidow中List结构中的一个Node就比Nemo中的一个Node节省了16 Bytes的空间)
  6. Blackwidow在锁的实现上参照了RocksDB事务里锁的实现方法，而弃用了之前Nemo的行锁，所以在多线程对同一把锁有抢占的情况下性能会有所提升

pika_port 迁移工具

· 阅读需 3 分钟
于雨
Pika 开源社区

项目作者：​

AlexStocks

适用版本：​

3.1 和 2.x

项目地址：​

https://github.com/ipixiu/pika-tools

https://github.com/Axlgrep/pika-tools 长期维护地址需自行编译

二进制包：​

https://github.com/ipixiu/pika-port-bin

功能：​

将Pika中的数据在线迁移到Pika、Redis（支持全量、增量同步）

开发背景：​

之前Pika项目官方提供的pika_to_redis工具仅支持离线将Pika的DB中的数据迁移到Pika、Redis, 且无法增量同步，该工具可以直接伪装为一个Pika的从库，将主库数据通过同步获取并转发给Pika、Redis，同时并支持增量同步

实现：​

trysync线程​

  1. 尝试与主库建立同步关系
  2. 如果需要全同步，则在接收到master的db之后，启动migrator和sender线程将db里面的数据发送给Pika、Redis
  3. 启动Slaveping线程定期给主库发送心跳，完成建立主从关系

binlog_receiver线程​

  1. 接收主库发送过来的binlog并且将其解析成redis命令
  2. 将redis命令转发给Pika、Redis

migrator线程​

  1. 扫描不同数据类型的分库
  2. 将key进行解析成响应数据Pika、redis指令
  3. 将解析好的redis指令加载到sender的发送buf中

sender线程​

  1. 从发送buf中读取数据，以非阻塞方式向Pika、redis发送数据
  2. 接收Pika、redis返回的结果并解析，如果出现错误则显示错误结果

使用帮助：​

Usage: 
       pika_port [-h] [-t local_ip -p local_port -i master_ip -o master_port
                  -m forward_ip -n forward_port -x forward_thread_num -y forward_passwd]
                  -f filenum -s offset -w password -r rsync_dump_path  -l log_path
        -h     -- show this help
        -t     -- local host ip(OPTIONAL default: 127.0.0.1)
        -p     -- local port(OPTIONAL)
        -i     -- master ip(OPTIONAL default: 127.0.0.1)
        -o     -- master port(REQUIRED)
        -m     -- forward ip(OPTIONAL default: 127.0.0.1)
        -n     -- forward port(REQUIRED)
        -x     -- forward thread num(OPTIONAL default: 1)
        -y     -- forward password(OPTIONAL)
        -f     -- binlog filenum(OPTIONAL default: local offset)
        -s     -- binlog offset(OPTIONAL default: local offset)
        -w     -- password for master(OPTIONAL)
        -r     -- rsync dump data path(OPTIONAL default: ./rsync_dump)
        -l     -- local log path(OPTIONAL default: ./log)
        -b     -- max batch number when port rsync dump data (OPTIONAL default: 512)
        -d     -- daemonize(OPTIONAL)
  example: ./pika_port -t 127.0.0.1 -p 12345 -i 127.0.0.1 -o 9221 -m 127.0.0.1 -n 6379 -x 7 -f 0 -s 0 -w abc -l ./log -r ./rsync_dump -b 512 -d