- pika 是360 DBA和基础架构组联合开发的类redis 存储系统, 完全支持Redis协议,用户不需要修改任何代码, 就可以将服务迁移至pika. 有维护redis 经验的DBA 维护pika 不需要学习成本
- 性能
- pika 的单线程的性能肯定不如redis, pika是多线程的结构, 因此在线程数比较多的情况下, 某些数据结构的性能可以优于redis
- pika 肯定不是完全优于redis 的方案, 只是在某些场景下面更适合. 所以目前公司内部redis, pika 是共同存在的方案, DBA会根据业务的场景挑选合适的方案
- 框架
- 网络模块 pink
- 线程模块
- 存储引擎 nemo
- 日志模块 binlog
- Pika的主从同步是使用Binlog来完成的. binlog 本质是顺序写文件, 通过Index +offset 进行同步点检查。解决了同步缓冲区太小的问题,支持全同步 + 增量同步。master 执行完一条写命令就将命令追加到Binlog中,ReplicaSender将这条命令从Binlog中读出来发送给slave,slave的ReplicaReceiver收到该命令,执行,并追加到自己的Binlog中。当发生主从切换以后, slave仅需要将自己当前的Binlog Index + offset 发送给master,master找到后从该偏移量开始同步后续命令。为了防止读文件中写错一个字节而导致整个文件不可用,所以pika采用了类似leveldb log的格式来进行存储
- 架构
- Pika Replicate
- pika支持master/slave的复制方式,通过slave端的slaveof命令激发 salve端处理slaveof命令,将当前状态变为slave,改变连接状态 slave的trysync线程向master发起trysync,同时将要同步点传给master ,master处理trysync命令,发起对slave的同步过程,从同步点开始顺序发送binlog或进行全同步
- Binlog
- pika同步依赖binlog binlog文件会自动或手动删除 当同步点对应的binlog文件不存在时,需要通过全同步进行数据同步
- 需要进行全同步时,master会将db文件dump后发送给slave 通过rsync的deamon模式实现db文件的传输
- 实现逻辑slave在trysnc前启动rsync进程启动rsync服务,master发现需要全同步时,判断是否有备份文件可用,如果没有先dump一份 master通过rsync向slave发送dump出的文件 slave用收到的文件替换自己的db slave用最新的偏移量再次发起trysnc 完成同步
- Pika Replicate
- 工作原理
- WorkerThread:接受和处理用户的命令
- BinlogSenderThread:负责顺序地向对应的从节点发送在需要同步的命令;
- BinlogReceiverModule: 负责接受主节点发送过来的同步命令
- Binglog:用于顺序的记录需要同步的命令 主要的工作过程:
- 当WorkerThread接收到客户端的命令,按照执行顺序,添加到Binlog里;
- BinglogSenderThread判断它所负责的从节点在主节点的Binlog里是否有需要同步的命令,若有则发送给从节点;
- BinglogReceiverModule模块则做以下三件事情:
- 接收主节点的BinlogSenderThread发送过来的同步命令
-
把接收到的命令应用到本地的数据上;
-
把接收到的命令添加到本地Binlog里
- 数据compact策略
- rocksdb 默认的 manual compact 的限制
- 当manual compact执行时,会等待所有的自动compact任务结束, 然后才会执行本次manual compact;
- manual执行期间,自动compact无法执行
- 当manual执行很长时间,无法执行自动compact,导致线上新的写请求只能在memtable中
- 当memtable个数超过设置的level0_slowdown_writes_trigger(默认20),写请求会出被sleep
- 再严重一些,当超过level0_stop_writes_trigger(默认24),完全停写;
- 了避免这种情况,我们对compact的策略进行调整,使得自动compact一直优先执行,避免停写;
- 恢复时间长 pika 的存储引擎是nemo, nemo 使用的是rocksdb, 我们知道 rocksdb启动不需要加载全部数据, 只需要加载几M的log 文件就可以启动, 因此恢复时间非常快
- 一主多从, 主从切换代价大 在主从切换的时候, 新主确定以后, 从库会用当前的偏移量尝试与新主做一次部分同步, 如果部分同步不成功才做全同步. 这样尽可能的减少全同步次数
- 缓冲区写满问题 pika 不适用内存buffer 进行数据同步, pika 的主从同步的操作记录在本地的binlog 上, binlog 会随着操作的增长进行rotate操作. 因此不会出现把缓冲区写满的问题
- 内存昂贵问题 pika 的存储引擎nemo 使用的是rocksdb, rocksdb 和同时使用内存和磁盘减少对内存的依赖. 同时我们尽可能使用SSD盘来存放数据, 尽可能跟上redis 的性能
- rocksdb 默认的 manual compact 的限制
pika介绍
最新推荐文章于 2024-08-07 10:22:51 发布
![](https://img-home.csdnimg.cn/images/20240711042549.png)