A presentation in Apache Pegasus meetup in 2021 from Guohao Li. Apache Pegasus is a horizontally scalable, strongly consistent and high-performance key-value store. Know more about Pegasus https://pegasus.apache.org, https://github.com/apache/incubator-pegasus

1. 我们是如何撑起
上千个 Pegasus 集群的
--工程篇
2021.9
李国豪

2. • Who are we
• Pegasus 与神策的历史渊源
• Pegasus 在神策支持的业务场景
• 私有化部署下 Pegasus 的工程化
• 私有化部署下 Pegasus 的监控策略
• 后续工作规划

3. • Who are we
神策数据（Sensors Data）是国内专业的大数据分析和营销科技服务提供商，为企业提供
神策营销云、神策分析云、神策数据根基平台三大产品方案，通过全渠道的数据采集与全域
用户 ID 打通，全场景多维度数据分析，全通道的精准用户触达，帮助企业实现数字化经营。

4. 神策有哪些产品
 2015 神策分析
 2018.6 神策智能推荐
 2018.10 架构升级，产品矩阵
 2019.7 神策用户画像
当前产品矩阵
• Who are we

5. 谁在用神策
中型互联网企业
传统企业
无外网，现场支持
产品化满足某些特定需求
神策支持云版/单机版
最低配只有 8c32g
神策支持几十节点集群
提供高性能服务
小型互联网企业
大型互联网企业
神策支持最少 3 节点 mini 集群
8c64g + 3 块 hdd盘 + 1 块 ssd 盘 + 1 块 raid 盘
• Who are we

6. 谁在用神策
• Who are we

7. From id-mapping
 什么是 id-mapping?
 请求量大：每个事件到达后都需要查询；每个用户每次登录都需要写入
 数据非常重要：id-mapping 影响客户的数据质量，包括日活等核心指标
 first_id → second_id，second_id → first_id，KV 存储

8. 存储演进 Redis
 使用 Redis 存储 id-mapping 数据
 客户主要是以单机版为主，数据量不大
 优势：
• 用户多，坑少
• 内存存储，满足性能要求
• 系统本身也需要缓存，复用其减少需要维护的系统个数
 劣势：
• 单实例
• 内存占用高
• 易失性

9. 存储演进 Redis 分布式方案
 集群版客户增加 --> Redis 分布式方案
 最开始是 Redis Sentinel，后续 Redis Cluster 稳定后为 Redis Cluster
 优势:
• 运维工具可用性高
• 有成熟的水平扩展方案
 劣势：
• 随着客户发展 id-mapping 数据量增大，占用内存过高
• 更多业务需要 KV 存储，Redis 中的数据越来越多

10. 存储演进 SSDB
 2017 年引入 SSDB
 分布式方案是 SSDB master-slave
 优势
• 完美兼容 Redis，升级迁移代价小
• SSDB 基于 leveldb，对于有明显访问局部性的 id-mapping 类型数据来说占用较
少内存资源，保证较好的性能
 劣势：
• SSDB 不能水平扩展，成为了单点
• 数据量大后容易把单个节点 io 打满
 随着神策由单一产品变为产品矩阵，越来越多产品线需要 KV 存储，客户规模也越来越
大，有了新的存储需求

11. Requirement & Why Pegasus?
1. 支持分布式存储，高可用、可扩展
2. 可持久化，数据不丢失
3. 读写性能
4. 内存可控 (最好有 hard limit)，内存占用较小
5. 稳定性好，可靠，有比较完善的运维监控工具
6. 支持 mget & mset
7. 开源社区，学习使用成本低
8. 较低成本的迁移方案
在对各项产品对比调研后，神策选择使用 Pegasus 来存储 id-mapping 为代表的
kv 数据。目前在每个神策部署环境中，会包含 1 到 2 个 Pegasus 集群

12. 渠道追踪
 业务说明：追踪新增用户/事件的来源渠道
 请求特征：
• qps 和客户数据量强相关
• 有效期有多种
• 单表存储了多种数据
某 demo 渠道活跃用户数据

13. 多租户的在线服务
 业务说明：神策部分新的产品组件是基于 SaaS 架构的，因此有多租户的概念
 请求特征：
• 表数量多
• 无法预估数据量
• 流量不均匀
• 分地域公用环境
• 在线服务

14. 首日首次标记
 业务说明：记录当前是否用户第一次触发该事件
 请求特征：
• 请求 qps 和客户数据量强相关
• 大部分情况请求只有 insert/get，没有 update
• 如果开启了 id-mapping 1对多映射/多对多映射，则还涉及对首日首次数据的修正，
即批量 update
用户画像基础服务
 业务说明：为其他产品线提供高效查询存储接口
 请求特征：
• 条数和用户规模强相关
• 有一定性能要求，数据存储在在线节点上
• 部分数据如用户属性 value 很长，目前我们对用户属性的大小和个数限制比较宽松

15. id-mapping
其他
私有化架构增加一个存储服务代价过高，因此很多其他场景也复用了 Pegasus
 类似 cache 的服务
 类似消息队列的服务
 id 快速去重
 部分数据供多个服务通信，数据量很小但读写 qps 较高

16. 神策特色
 私有化：
• 维护有状态服务成本高
• 老版本长期存在
 To B：集群数量多
• 操作需要产品化
（设计评审 → 开发 → CR → 测试 → 发版 → 交付）
• 可用性要求更高
 传统行业客户
• 基本没有 UI，纯命令行
• 无外网

17. 工程化内容分类
分类 具体内容
基本功能 部署
扩缩容
配置管理
升级
扩展功能 集群迁移
原地重做
扩分片
系统与调优与诊断 无人值守的故障修复
有人值守的故障诊断

18. 一键部署
 基于神策云平台自研框架
 实现 Pegasus 各个模块的部署
• 服务拓扑
• 根据机器资源，计算合理配置值（data_dirs、block_cache）
• 初始化分片因子，用于为建大表提供分片数
建表优化
 由于不同客户的机器配置的差异化，建表参数需要适配到具体环境
• 小表：大部分业务表数据量小，多租户的表数量很多，分片数需要尽量小
• 大表：需要匹配具体环境，更合理利用 io 资源
 分片因子：Pegasus 存储盘个数；部署、扩缩容、加减盘更新
 配套实现了扩分片工具（2.3+ 支持热扩，目前只能通过 copy_data 实现）

19. 配置管理
 背景：
• 修改配置易误操作
• 私有化部署，开发分布式编辑配置工具代价大
 增删改查工具，配置组管理
 升级：从非标准化的配置升级到标准配置，错误处理
配置模板 zookeeper
group0: {
data_dirs: data0:$dir0, data1:$dir1,
rocksdb_block_cache_capacity: 17179869184,
rocksdb_total_size_across_write_buffer: 15032385536
},
group1: {
data_dirs: data0:$dir3, data1:$dir4,
rocksdb_block_cache_capacity: 17179869184,
rocksdb_total_size_across_write_buffer: 15032385536
},
实例配置
config.ini
= +

20. 一键升级
 步骤管理和断点继续
 支持热升级
 单个步骤可回滚
 已在上百家客户运行

21. 有人值守故障检测和诊断
 传统客户实施同学处理问题成本高
 按照规则自动检测当前系统故障，并辅助诊断：
• 实例频繁重启
• 分片 unhealthy
• 检测系统指标（p99，打开文件数）
异常给出修复指令
（balance / 扩分片 / compact / 修改 block_cache）
无人值守下故障检测和修复
 基于神策内部调度器，低峰期运行
 按照规则自动检测当前系统故障，并自动修复
• 触发负载均衡
• 对于已知的不合理配置自动修复（下次重启生效）

22. 工程化方向 Pegasus 社区实现 工程化目标
一键 balance set_meta_level 触发3节点以上 replica
server 均衡 replica
同步&异步命令
单节点&2节点集群的均衡
磁盘间按照比例均衡
一键加减盘 修改配置重启
提供独立命令，触发负载均衡
一键原地重做 由数据目录恢复元数据
进度管理，断点继续，可重入可回滚
合理预估时长
一键扩容缩容 相关文档流程说明
基于云平台的增删节点框架
根据客户的机器资源生成匹配配置
transfer meta server
一键迁移 copy_data 命令
进度管理，断点继续，可重入可回滚
合理预估时长

23. 监控项 说明 可能故障的原因
进程探活 端口 + 进程关键字 配置文件错误
数据写坏
打开文件数达到上限
服务状态 node -d 查看状态 分片过多，加载过慢
数据完整性 副本持续不健康 数据写坏
性能 P99 监控 replica 不均衡
分片数不合理
机器资源不足
meta server 双主监控
主不一致
zk 故障
主机名/ ip 更换

24.  一键升级 2.2 版本
 一键变更 ip 标识为 fqdn
 合入 Partition Split
 优化 copy_data 性能

25. thanks