pika介绍

1. pika 是360 DBA和基础架构组联合开发的类redis 存储系统, 完全支持Redis协议，用户不需要修改任何代码, 就可以将服务迁移至pika. 有维护redis 经验的DBA 维护pika 不需要学习成本
2. 性能
   1. pika 的单线程的性能肯定不如redis, pika是多线程的结构, 因此在线程数比较多的情况下, 某些数据结构的性能可以优于redis
   2. pika 肯定不是完全优于redis 的方案, 只是在某些场景下面更适合. 所以目前公司内部redis, pika 是共同存在的方案, DBA会根据业务的场景挑选合适的方案
3. 框架
   1. 网络模块 pink
   2. 线程模块
   3. 存储引擎 nemo
   4. 日志模块 binlog
      1. Pika的主从同步是使用Binlog来完成的. binlog 本质是顺序写文件, 通过Index +offset 进行同步点检查。解决了同步缓冲区太小的问题，支持全同步 + 增量同步。master 执行完一条写命令就将命令追加到Binlog中，ReplicaSender将这条命令从Binlog中读出来发送给slave，slave的ReplicaReceiver收到该命令，执行，并追加到自己的Binlog中。当发生主从切换以后, slave仅需要将自己当前的Binlog Index + offset 发送给master，master找到后从该偏移量开始同步后续命令。为了防止读文件中写错一个字节而导致整个文件不可用，所以pika采用了类似leveldb log的格式来进行存储
4. 架构
   1. Pika Replicate
      1. pika支持master/slave的复制方式，通过slave端的slaveof命令激发 salve端处理slaveof命令，将当前状态变为slave，改变连接状态 slave的trysync线程向master发起trysync，同时将要同步点传给master ，master处理trysync命令，发起对slave的同步过程，从同步点开始顺序发送binlog或进行全同步
   2. Binlog
      1. pika同步依赖binlog binlog文件会自动或手动删除 当同步点对应的binlog文件不存在时，需要通过全同步进行数据同步
      2. 需要进行全同步时，master会将db文件dump后发送给slave 通过rsync的deamon模式实现db文件的传输
      3. 实现逻辑slave在trysnc前启动rsync进程启动rsync服务，master发现需要全同步时，判断是否有备份文件可用，如果没有先dump一份 master通过rsync向slave发送dump出的文件 slave用收到的文件替换自己的db slave用最新的偏移量再次发起trysnc 完成同步
5. 工作原理
   1. WorkerThread：接受和处理用户的命令
   2. BinlogSenderThread：负责顺序地向对应的从节点发送在需要同步的命令；
   3. BinlogReceiverModule: 负责接受主节点发送过来的同步命令
   4. Binglog：用于顺序的记录需要同步的命令 ​主要的工作过程：
      1. 当WorkerThread接收到客户端的命令，按照执行顺序，添加到Binlog里；
      2. BinglogSenderThread判断它所负责的从节点在主节点的Binlog里是否有需要同步的命令，若有则发送给从节点；
      3. BinglogReceiverModule模块则做以下三件事情：
         1. 接收主节点的BinlogSenderThread发送过来的同步命令

         2. 把接收到的命令应用到本地的数据上；

         3. 把接收到的命令添加到本地Binlog里

6. 数据compact策略
   1. rocksdb 默认的 manual compact 的限制
      1. 当manual compact执行时，会等待所有的自动compact任务结束, 然后才会执行本次manual compact；
      2. manual执行期间，自动compact无法执行
         1. 当manual执行很长时间，无法执行自动compact，导致线上新的写请求只能在memtable中
         2. 当memtable个数超过设置的level0_slowdown_writes_trigger(默认20)，写请求会出被sleep
         3. 再严重一些，当超过level0_stop_writes_trigger（默认24)，完全停写；
   2. 了避免这种情况，我们对compact的策略进行调整，使得自动compact一直优先执行，避免停写；
      1. 恢复时间长 pika 的存储引擎是nemo, nemo 使用的是rocksdb, 我们知道 rocksdb启动不需要加载全部数据, 只需要加载几M的log 文件就可以启动, 因此恢复时间非常快
      2. 一主多从, 主从切换代价大 在主从切换的时候, 新主确定以后, 从库会用当前的偏移量尝试与新主做一次部分同步, 如果部分同步不成功才做全同步. 这样尽可能的减少全同步次数
      3. 缓冲区写满问题 pika 不适用内存buffer 进行数据同步, pika 的主从同步的操作记录在本地的binlog 上, binlog 会随着操作的增长进行rotate操作. 因此不会出现把缓冲区写满的问题
      4. 内存昂贵问题 pika 的存储引擎nemo 使用的是rocksdb, rocksdb 和同时使用内存和磁盘减少对内存的依赖. 同时我们尽可能使用SSD盘来存放数据, 尽可能跟上redis 的性能