0 测试环境
测试机器配置
- mem: 128G
- disk: 800G ssd
- cpu: 32 core
- net: 10Gbps
版本
- redis: 3.2.11
- pika: 2.2.6
1 pika worker 线程数测试
pika 和 redis 不一样，底层采用了 rocksdb 作为存储引擎，线程数对 pika 的性能影响较大
- 5 thread，100 client
- ops: GET SET
- value payload: 128 bytes
说明：其中线程数为 0 的是 redis 的测试数据。
结论：pika 的 qps 基本是符合预期的，get 和 set 性能与线程数成正相关关系，当线程数到达 8 时，再增加线程数，对 get 性能提升几乎没有太多影响，同时对 set 性能的增益也衰减较大；与 redis 相比，qps再线程数足够的情况下可以做到比 redis 还要好，特别是 get 性能，可以达到 redis 的 2 倍以上。
2 pika redis get set 不同 payload 延时及 qps 对比
环境：
- 5 thread，100 client
- ops: GET SET
- pika workers：8 thread
- 1000000 次
结论： pika get 性能受 payload 影响较小，99.9% 的请求都能再 1ms 内返回，且 qps 不受影响，set 性能受 palyload 影响较大，再 512 bytes 之前都能保持和redis 相当的性能，99.9% 的请求能再 2-3 ms内返回，和 redis 性能相当；超过 512 bytes 后，性能下降较大，10k 的数据需要 300ms 左右才能完成 set 操作；而 redis 在 10 k 内都能维持较好的性能，100k 以后 set 性能才会有较大的衰减。
3 不同操作与 redis 对比测试
- 5 thread，100 client
- pika workers：8 thread
- payload: 128 bytes
结论：大部分strings 相关的操作可以和redis 持平甚至更优，list 相关操作性能较 redis差，hash 相关操作稍弱于 redis
4 持续写入测试
持续写入测试用于测试写入数据量大小对写入的性能衰减影响，测试过程中将 compact 操作调整至 凌晨 2-4 点。
- golang 协程数量: 50
- client 数量: 50
- ops: SET
- pika workers：8 thread
- payload: 128 bytes
- 持续写入数量: 7 * 10^9 次
结论：写入非常稳定，基本都能稳定再 每秒 10w-15w 条之间，写入数据量达到 700GB 以上，未发生写入性能衰减情况；需要注意的是，compact 对性能影响较大，compact 期间写入速度衰减到 2k-1w /s，每次持续大概 20-40s, 2-4 点过程中共发生 4 次 compact；
5 结论
5.1 优点
- 节约成本，占用内存较小，写入数据达到 700 GB 后，占用内存在 7GB 左右
- 采用 snappy 压缩数据，数据压缩比较大，写入数据达到 700GB 后，占用磁盘约为 110 GB 左右
- 重新启动后恢复数据的过程很快，没有redis 将数据加载到内存的过程
- 多线程，不会像redis 一样由于某个耗时操作导致后面操作阻塞的现象
- 自带持久化
- 官方支持 docker 部署
5.2 缺点
- 严重依赖磁盘 io 性能，注意不同实例写入同一块盘时的影响
- lsm tree 普遍存在的 io 放大问题
- 不支持 multi exec 的事务操作
- list 相关操作性能比 redis 差
- compact 时较大的影响写入性能
- 极限性能下对 cpu 的压力较大
5.3 结论
- 并不能完全替代 redis，与 redis 可以形成互补关系。
- 对延时及延时稳定性要求高，或者用作 队列等场景，还需使用redis
- 对于大部分数据量较大，没有复杂的 链表等集合操作的场景，可使用 pika
5.4 其他注意事项
- 关闭 slotmigrate (用于 codis slot 迁移)，对性能有部分提升
- compact 对写入性能影响较大，需要根据业务情况调整写入策略
- 读取性能依赖系统 cache 和 buffer
- 同步采用 binlog，官方提供 redis 向 pika 迁移工具
- 必须使用 ssd，hdd 性能太差
