首页 文章 精选 留言 我的

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

2024-08-26 300

尊敬的社区朋友及 PikiwiDB(Pika) 用户们：

非常高兴地宣布 --- PikiwiDB(Pika)【下文简称 Pika】长期维护版本 v3.5的最新版本 --- v3.5.5 今天正式发布。在这个版本中，除了修复所有已知的主从复制 bug 外，通过引入 RTC 特性其性能又有了大幅度提升，且主从 failover 机制兼容了 Redis-Sentinel。

1 重大改进

1.1 RTC 模型

在 v3.5.5 版本中我们引入了 RTC 模型，旨在提高缓存的访问效率，具体修改流程如下所示：

img

上图左侧展示的是 Pika 服务请求的 IO 处理路径：请求依次经过网络线程、请求队列、工作线程，最终到达内存或硬盘引擎进行处理。这种设计的不足之处在于，请求在各个线程间传递会导致频繁的 CPU 上下文切换以及 CPU 高速缓存的 Cache Miss 问题，从而增加 CPU 资源的消耗。在高并发场景下，这种额外的 CPU 消耗尤为显著。

年初（2024年3 月）美团发布了 《美团大规模 KV 存储挑战与架构实践》一文，给出了一个名为 RTC(Run-to-Completion) 的技术方案，网络线程被赋予了直接处理读请求的能力，特别是那些能直接从内存引擎中命中的读请求。

当时 Pika 已经实现了混合存储：在内存 RedisCache 中缓存热数据，在磁盘中存储全量数据。在这个基础之上，恰好看到这个 RTC 解决方案，我们觉得这个方案甚好，可以优化 Pika 的读写流程，提高吞吐，降低延时。引入 RTC 方案后，新读写流程如上图右侧：

  1. 当网络线程接收到请求后，Pika 首先判断该请求是否为读操作请求。
  2. 如果是读请求，并且能在 RedisCache 中找到所需的数据（RedisCache 命中读请求），则网络线程直接返回结果给客户端。
  3. 对于写请求或 RedisCache 未命中的读请求，则依旧沿用原有的处理路径，访问 DB 硬盘引擎进行读写。

RTC 在网络线程内部就能实现 Redis 读命中的闭环处理，避免了由于请求在不同线程间的流转而带来的 CPU 资源开销。具体而言，Pika 的多个 Worker 线程争抢同一个 TaskQueue，且 Worker 在等待任务队列时，没有任何轻量级等待策略，直接使用了"很重" 的cv.wait(std::condition_variable::wait)，如果不使用 RedisCache，这或许不构成瓶颈，因为读写请求都打在 RocksDB 上，此时 Pika 工作线程需要等待 RocksDB 的读写流程。但如果打开了 Pika RedisCache 开关且缓存命中率超过 60% 时，热点数据集中度较高，在读操作远多于写操作的高并发场景下，这个线程池中转的过程就会构成性能瓶颈。

通过压测发现，打开 RedisCache 和 RTC 模型开关，且在 Pika 内嵌 Redis Cache 缓存命中率达到 60% 以上的高并发情况下，Get QPS 能提高到原本的 1.5 倍（从 18.4w 到 27.2w），P99 延时降低 47.5% (2.4ms 以下)。尽管此模型仅针对读缓存命中的读多写少请求，但鉴于实际应用场景中读操作远多于写操作，并且热点数据集中度较高，因此在多数业务集群部署后均实现了显著的性能提升。

关键 ISSUE/PR：

Improve the RTC process of Read/Write model https://github.com/OpenAtomFoundation/pika/issues/2542 Pika 使用 RTC 模型访问 Rediscache https://github.com/OpenAtomFoundation/pika/pull/2837 Pika RTC 模型开关 https://github.com/OpenAtomFoundation/pika/pull/2841

1.2 通过 Redis-Sentinel 对 Pika 主从实例进行故障自愈

自一年前 (2023年7月）发布 v3.5.0 版本以来，Pika 无法兼容 Redis-Sentinel 进行 auto failover，主要有以下几个原因：

  1. 事务冲突

Redis-Sentinel 选举以后，进行主从切换操作时会给 slave 发送 "slaveof no one" 等一批 事务形式的命令:

multisalveof no oneconfig rewriteclient kill type pubsubclient kill type normalexec

当时 Pika 不支持 "client kill type pubsub" 与 "client kill type normal" 命令，整个事务会 abort 不执行，导致实际的 slaveof 命令没有执行，所以无法完成新主切换。针对这个问题，在PR 2854 中支持了这两个命令："client kill type pubsub" 杀掉所有 pubsub client 连接，"client kill type normal" 命令杀掉除 pubsub 外的其他 client 连接。

  1. 指标不兼容

Redis-Sentinel 通过 "info" 命令的指标 "slave_repl_offset" 作为选主依据，这个指标反映了某个 slave 实例从 master 接收的主从同步字节数的总量（多 DB 场景下这个值就是多 DB 同步字节数的总和），而 Pika 的主从体系下每个 DB 各自独立，每个 DB 都有一个 binlog 偏移量，由 (filenum, offset) 这样二维坐标形式的两个数字构成，没有提供 "slave_repl_offset" 指标供 Redis-Sentinel 做判断。Pika v3.3.6 版本没有提供这个指标，但通过 fake 数据方式兼容了 Redis-Sentinel, 但这样的选主其实是不可靠的。

在 PR 2854 中，Pika 通过算式 "slave_repl_offset = filenum * filesize + offset" 给出了 "info" 命令的 "slave_repl_offset" 指标。

  1. slave-priority 默认参数的变更

Pika Slave "info" 命令的 "slave-priority" 指标默认值为 0，这个值导致 Pika Slave 不会被 Redis-Sentinel 列入候选 master。

在 PR 2854 中，Pika 将这个默认值改为 100，Redis-Sentinel 会将 Pika Slave 实例列入候选 master。

  1. 进程 coredump

在修复以上问题后，在测试过程中 发现 Redis-Sentinel 连接 Pika 实例并发出 "shutdown" 命令 Pika 实例会 coredump。追查后发现：Pika 退出时的资源释放流程中，网络线程关闭的时机不对（关的太晚了），有些重要资源对象已经析构了，但网络线程还能收发包，这就导致 Pika 实例收到 "shutdown" 命令时使用已经析构的资源对象进行命令处理，最终导致 Pika 实例 coredump。

在 PR 2854 中，修改了网络线程 Stop 函数的位置，提前终止线程 pika_dispatcher_thread_，停止 dispatcher 进行网络任务分配。

  1. 一个意外收获

在测试过程中，还发现了一个资源退出时的主从同步相关的问题：Pika Slave 消费 Binlog 时，先将 Binlog 落盘，然后异步提交 WriteDB 任务进行数据的物化（重放至 RocksDB），Pika 退出时不会等待这些异步 WriteDB 任务，这就可能导致 Slave 丢数据。

在 PR 2854 中，Pika 退出时，会等到 WriteDBWorker TaskQueue 为空才继续往下释放资源，退出进程。

关键PR：

Pika 兼容 Redis-Sentinel 进行主从切换 https://github.com/OpenAtomFoundation/pika/pull/2854

1.3 主从复制

Pika v3.3.6 有很多主从复制的缺陷，如丢数据、数据污染、死锁等问题。v3.5.5 版本对 Pika 全量复制及增量复制进行了大量优化和 bug 修复，取得了非常好的效果。

例如，PR 2638 在 "info" 命令中输出了 "repl_connect_status" 指标，以方便用户更加清晰看到当前 Pika 实例的主从复制状态。

关键 PR：

优化主从复制，确保 Master 端的 SlaveNode 在提交 bgsave 任务前进入 DBSync 状态，防止bgsave执行时的 binlog 在极端情况下被清除 https://github.com/OpenAtomFoundation/pika/pull/2798

修改主从复制过程中 flushdb binlog 的处理逻辑，确保按照顺序执行，避免出现主从不一致的情况 https://github.com/OpenAtomFoundation/pika/pull/2790

优化 Apply binlog 时锁机制，减少不必要的锁竞争 https://github.com/OpenAtomFoundation/pika/pull/2773

修复批量扩容时，多个 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

增加主从复制状态指标 repl_connect_status，方便运维人员清晰明确的判断当前的主从复制状态 https://github.com/OpenAtomFoundation/pika/pull/2656

重构主从复制模式 slave 节点的主从同步线程模型，尽可能减少 binlog 消费阻塞问题 https://github.com/OpenAtomFoundation/pika/pull/2638

1.4 RocksDB Compaction

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

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

    1. min-write-buffer-number-to-merge: 默认值为 1，如果将此值设置得更大，意味着需要更多的写缓冲区被填满后才进行 flush。这样可以减少 flush 的频率，增加数据在内存中的累积量，从而可能提高写入吞吐量。
    1. level0-stop-writes-trigger: 默认值为 36，定义了 L0 层中 sst 文件的最大数量，一旦达到这个数量，RocksDB 将会采取 暂停写入、强制 compaction 等措施来防止写入操作继续累积，以避免 L0 层变得过于庞大，进而可能导致写入放大、查询性能下降等问题。
    1. level0-slowdown-writes-trigger：默认值为 20，用于控制当 Level 0 的 SST 文件数量达到这个阈值时，触发写减速（write slowdown），防止 Level 0 的文件数量过多，导致后续 compaction 操作的压力过大。
    1. level0-file-num-compaction-trigger：默认值为 4，当 Level 0 的 SST 文件数量达到这个参数设定的阈值时，RocksDB 会开始执行 compaction 操作，将 Level 0 的文件合并到 Level 1，以减少 Level 0 的文件数量，降低读取延迟，并优化存储空间的利用率。
    1. max-subcompactions：默认值为 1，用于控制 RocksDB 中并发执行的 sub-compaction 任务数量，其值为 1 表示关闭 sub-compaction。如果系统资源充足，建议提升该参数以优化 compaction 效率。
    1. 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：

新增 RocksDB Compaction 策略动态调整参数，用户可以根据业务调整 Compaction 策略，降低 Compaction 操作对服务性能的损耗 https://github.com/OpenAtomFoundation/pika/pull/2538

1.5 测试集

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

关键 PR：

Pika Geo 数据类型增加 TCL 测试，并修复测试过程中遇到的缺陷 https://github.com/OpenAtomFoundation/pika/pull/2753

2 改进列表

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

2.1 新特性

2.2 bug 修复

2.3 提升改进项

2.4 发版 tag

​ https://github.com/OpenAtomFoundation/pika/releases/tag/v3.5.5

3 社区

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

  • baerwang
  • baixin01
  • bigdaronlee163
  • cheniujh
  • chejinge
  • haiyang426
  • lqxhub
  • luky116
  • Mixficsol
  • QlQlqiqi
  • saz97
  • VanessaXWGUO
  • wangshao1
  • XiaoLiang2333

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

上一篇 下一篇
优秀的个人博客,低调大师

微信关注我们

原文链接：https://my.oschina.net/dubbogo/blog/15492291

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Taro 3.6.35 发布，BAT 小程序、H5 与 RN 端统一框架

Taro 3.6.35 现已发布。Taro 是一个开放式跨端跨框架解决方案，支持使用 React/Vue/Nerv 等框架来开发微信 / 京东 / 百度 / 支付宝 / 字节跳动 / QQ 小程序 / H5 等应用。 此版本具体更新内容如下： H5 / 小程序 使用 forwardRef 包装 React 组件库 H5 修复了 Video 组件 mute={true} 时静音按钮状态显示为非静音的问题，fix#15877 小程序 新增了京东小程序的 Editor、PageContainer、RootPortal 等组件与属性的支持 鸿蒙 Hybrid 新增了 exitMiniProgram API 的调用实现 修复了跨 Web 容器修改 Storage 后缓存不更新的问题 更新说明：https://github.com/NervJS/taro/releases/tag/v3.6.35
2024-08-26
165
上一篇

IBM 将彻底关闭中国研发部门，涉及员工数量超过 1000 人

8月26日11:30更新： 第一财经独家报道称，记者从IBM中国方面确认，IBM将彻底关闭中国研发部门，涉及员工数量超过1000人。 IBM中国在回应第一财经记者关于研发部门裁员的消息时称：“IBM会根据需要调整运营，为客户提供最佳服务，这些变化不会影响我们为大中华区客户提供支持的能力。” 据界面新闻报道，IBM中国于23日晚间关闭了IBM中国研发和测试岗位员工的访问权限。 一位实验室技术员工称，关闭权限前公司员工正常上下班，没有任何预兆和“信号”，一些技术员工还处于加班状态。目前，这些员工已从通信软件的产品群组被移除，无法通过VPN登录公司内网，但仍可访问邮件。 IBM中国有多个分公司，此次被收回权限的员工属于IBMV，下设CDL（IBM中国开发中心）和CSL（IBM中国系统中心），主要负责研发和测试。 目前，员工尚不清楚公司做出这项决策的原因。 最新消息是，公司已通知被收回权限的员工于周一进行谈话，参与线上会议。 在求职平台脉脉上，有人表示，IBM中国区要开始一波大裁员，主要针对研发岗位。 IBM中国在不同区设有多个分公司，据称大约有12000名员工。根据报道，被收回权限的员工属...
2024-08-26
285
下一篇

相关文章

发表评论

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2025-12-17 大小: 1MB 下载: 2次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2025-12-17 大小: 1.42GB 下载: 1次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2025-12-03 大小: 9.84MB 下载: 39次
手机查看

扫码在手机上查看文章

扫描二维码，手机阅读更方便

热门标签
Redis OpenAi Kubernetes SpringBoot4 Service Mesh Docker Nacos3 Rocky DeepSeek SpringCloud HarmonyOS6 Gemini3 Jdk25

欢迎您！

登录后，您将获得更多功能！

热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273