pika集群水平扩展——让性能容量再也不受限

背景

Pika是一个可持久化的大容量redis存储服务，兼容string、hash、list、zset、set的绝大部分接口(兼容详情)，解决redis因为存储数据量巨大而致使内存不够用的容量瓶颈。用户能够不修改任何代码从redis迁移到pika服务。具备良好的兼容性和稳定性，被360公司内部使用超过3000实例，github社区超过3.8K star。因为单机pika容量受限于单块硬盘容量的大小，360公司业务和社区对分布式pika集群的需求愈来愈强烈，所以咱们推出了原生分布式pika集群,发布pika版本v3.4。与pika+codis集群方案相比，codis对pika建立和管理slot操做的支持并不友好，须要运维人员大量介入。而pika原生集群则不须要额外部署codis-proxy模块。

集群部署结构

以3个pika节点的集群为例，集群部署结构如上图所示：

1. 部署Etcd集群做为pika manager的元信息存储。
2. 3台物理机上分别部署pika manager，并配置好Etcd的服务端口。Pika manager会向etcd注册，并争抢成为leader。集群中有且只有一个pika manager可以成为leader并向etcd中写入集群数据。
3. 3台物理机上分别部署pika节点，而后把pika节点的信息添加到pika manager中。
4. 为了负载均衡，把pika的服务端口注册到LVS中。

数据分布

为了对数据按照业务进行隔离，Pika集群引入table的概念，不一样的业务数据存储在不一样的table中。业务数据按照key的hash值存储到对应的slot上面。每个slot会有多个副本，从而造成一个replication group。replication group中的全部slot副本具备相同的slot ID，其中一个slot副本是leader，其余副本为follower。为了保证数据的一致性，只有leader提供读写服务。能够使用pika manager对slot进行调度迁移，使数据和读写压力均匀的分散到整个pika集群中，从而保证了整个集群资源的充分利用而且能够根据业务压力和存储容量的须要进行水平扩容和缩容。

pika使用rocksdb做为存储引擎，每一个slot会建立对应的rocksdb。pika中的每一个slot都支持读写redis 5种数据结构。所以数据迁移的时候会特别方便，只需迁移pika中的slot便可。但同时也存在资源占用过多的问题。目前的pika在建立slot的时候会默认建立5个rocksdb，分别来存储5种数据结构。在table中含有大量slot或者建立大量table的时候会使单个pika节点含有多个slot，进而建立过多的rocksdb实例，占用了过多系统资源。在后续版本中一方面会支持建立slot的时候根据业务须要建立一种或多种数据结构，另外一方面会持续对pika中的blackwidow接口层进行优化，减小对rocksdb的使用。

数据处理

1. 当pika节点接收到用户请求时，解析层处理解析redis协议，并把解析好的结果交给router层进行判断。
2. router根据key的hash结果找到key对应的slot，并判断slot是否在本地节点上。
3. 若是key所在的slot在其余节点，则根据请求建立一个task放入队列中，并把请求转发给peer节点来处理。当task接收到请求的处理结果后把请求返回给客户端。
4. 若是key所在的slot属于本地节点，就直接本地处理请求并返回给客户端。
5. 对于须要本地处理的写请求，先经过replication manager模块写binlog，异步复制到其余slot副本。process layer根据一致性的要求，写入leader slot。其中blackwidow是对rocksdb的接口封装。

咱们把proxy内嵌的pika中，不须要单独部署。与redis cluster相比，客户端不须要感知proxy的存在，只需像使用单机同样使用集群。能够把pika节点的服务端口挂载到LVS中，实现压力在整个集群的负载均衡。

日志复制

pika中replication manager模块负责日志的主从同步。为了兼容redis，pika支持非一致日志复制，leader slot直接在db中写入数据而无需等待从follower slot的ack应答。同时也支持raft一致性协议方式的日志复制，须要知足收到大多数副本的ack才写入db。

非一致日志复制

在非一致场景下处理流程以下：

1. 处理线程接收到客户端的请求，直接加锁后写入binlog和并操做db。
2. 处理线程返回客户端response。
3. 辅助线程发送BinlogSync同步请求给follower slot，同步日志。
4. follower slot返回BinlogSyncAck报告同步状况。

一致性日志复制

在一致性日志复制场景下：

1. 处理线程把客户端请求写入binlog文件
2. 经过发送BinlogSync请求向从库同步
3. 从库返回BinlogSyncAck报告同步情况
4. 检查从库应答知足大多数后将相应的请求写入db
5. 将response返回客户端

集群元数据处理

咱们在codis-dashboard的基础上二次开发了pika manager（简称PM），做为整个集群的全局控制节点，用来部署和调度管理集群。PM里保存了整个集群的元数据及路由信息。

• 增长了集群建立多表的功能，方便业务根据表的不一样来实现业务数据隔离。
• 支持建立表时指定slot数目和副本数目，方便运维根据业务的规模和故障容忍度建立table。
• 从逻辑上把group的概念改成replication group，使得原来的进程级别的数据和日志复制转变为slot级别的复制。
• 支持建立table时建立密码来隔离业务的使用。客户端只须要执行auth和select语句就能够认证并对指定的table进行操做。
• 支持slot迁移，方便根据业务需求进行扩容和缩容。
• 集成哨兵模块，PM会不断的向集群中的pika节点发送心跳，监测存活状态。当PM发现leader slot down时，会自动提高binlog偏移最大的slave slot为leader。
• 存储后端支持元数据写入etcd，保证元数据的高可用。
• pika manager经过不断向etcd争抢锁来成为leader，来实现pika manager的高可用。

后记

pika原生集群的推出解决了单机pika受限于磁盘容量的限制，能够按照业务的需求进行水平扩容。但仍然有一些缺陷，如基于raft的内部自动选主功能的缺失，基于range的数据分布，及监控信息的展板等功能。后续版本咱们会一一解决这些问题。