一、背景介绍
随着360公司业务发展，业务使用kv存储的需求越来越大。为了应对kv存储需求爆发式的增长和多使用场景的需求，360web平台部致力于打造一个全方位，适用于多场景需求的kv解决方案。目前，我们线上大规模使用的kv存储有Redis，Redis cluster以及Pika。
为什么说是爆发式的需求增长呢？早在2015年9月份，公司Redis的日访问量还处于800亿，到了2016年第三季度日访问量已经突破2500亿，2017年第一季度日访问量已经接近4000亿。短短的一年半时间，日访问量增长了5倍。下面给大家分别简单介绍一下Redis，Redis Cluster以及Pika的特点和使用场景。
二、kv存储之Redis
1、Redis介绍
Redis做为大家熟知的开源内存数据库，在很多项目中被广泛的使用。它支持String、Hash、List、Set、Zset、Geo、Hyperloglogs等多数据结构。同时也支持主从复制、Lua脚本、事务、数据持久化、高可用和集群化等等
2、Redis特性
1）高性能：Redis虽然是单线程的，但是它同样拥有着超高的性能。我们线上的普通PC Server上，经过测试，每秒请求数OPS能够达到10w左右。
2）多样化数据结构：Redis支持String、Hash、List、Set、Zset、Geo等多数据结构。
3）持久化：RDB持久化：快照式持久化方式，将内存中的全量数据dump到磁盘。它的优势是加载速度比AOF快，劣势是快照式的全量备份，没有增量数据，造成数据丢失。
AOF持久化：AOF记录Redis执行的所有写操作命令。恢复数据的过程相当于回放这些写操作。使用AOF的持久化方式，优势是有灵活的刷盘策略，保证数据的安全性。劣势是AOF文件体积比RDB大，占用磁盘多，数据加载到内存的数据慢。
4）多重数据删除策略：
①惰性删除：当读/写一个已经过期的key时，会触发惰性删除策略，删除掉这个过期key。
②定期删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key。
③主动删除：当前已用内存超过maxmemory限定时，触发主动清理策略，该策略由启动参数的配置决定，可配置参数及说明如下：
- volatile-lru：从已设置过期时间的样本中根据LRU算法删除数据 （redis3.0之前的默认策略）
- volatile-ttl：从已设置过期时间的样本中挑选过期时间最小的数据删除
- volatile-random：从已设置过期时间的样本中随机选择数据删除
- allkeys-lru：从样本中根据LRU算法删除数据
- allkeys-random：从样本中任意选择删除数据
- noenviction：禁止从内存中删除数据 （从redis3.0 开始默认策略）
maxmemory-samples 删除数据的抽样样本数，redis3.0之前默认样本数为3，redis3.0开始默认样本数为5，该参数设置过小会导致主动删除策略不准确，过大会消耗多余的cpu。
5）高可用：Redis自身带有哨兵的组件，可以监控Redis主从的运行状态和自动的故障切换，实现Redis的高可用。
3、Redis使用场景
一般场景：OPS < 10W，数据量较小
进阶场景：单点写入可以支撑，但读取量巨大，可以采用读写分离，1主多从的方案；
写入读取量都很大，单点写入无法支撑，可以采用Hash分片方式。
但是，无论数读写分离的方式还是Hash分片的方式，在的Redis的架构中没有引入中间件或者更加智能的驱动的情况下，都需要从代码上去保证，这一定程度上增加了开发人员的代码复杂度。同时随着业务的增长，扩展性也较差。那么如何更加理想的去解决这个问题，使用Redis Cluster会是一个更加简洁有效的方案。
三、kv存储之Redis Cluster
1、Redis Cluster介绍
Redis Cluster 是一个分布式、无中心节点的、高可用、可线性扩展的内存数据库，Redis Cluster的功能是普通单机 Redis 的功能的一个子集。Redis Cluster为了保证一致性而牺牲了一部分容错性： 系统会在保证对网络断线和节点失效具有有限抵抗力的前提下， 尽可能地保持数据的一致性。
2、Redis Cluster重要概念：
①hash slots——哈希槽
Redis 集群没有使用一致性hash，而是引入了哈希槽（hash slot）的概念。Redis 集群一共有16384个hash slot，集群使用CRC16校验后对16384取模来计算键key属于哪个槽。
②cluster node——集群节点
集群中的每个主节点负责处理16384个hash slot中的一部分。每个node的hash slot数量可以灵活手工调整。
③cluster map——集群信息表
集群中的每个节点都记录整个集群的Cluster map信息，集群信息包括每个节点的唯一id号，ip地址，port端口号，role 在集群中的角色，主节点负责的hash slot的范围，节点状态等。节点之间通过Gossip协议进行通信，传播集群信息，并发现新节点向其他节点发送ping包，检查目标节点是否正常运行。
3、Redis Cluster架构
4、Redis Cluster数据路由
①client执行命令，计算key对应的hash slots
②根据本地缓存的cluster map信息，连接负责该hash slots的数据节点获取数据
如果slot不在当前连接的节点，返回moved错误，重定向客户端到新的目的服务器上获取数据，并更新client本地缓存的cluster map
如果slot在当前节点且key存在，则执行操作结果给客户端
如果slot迁出中，返回ask错误，重定向客户端到迁移的目的服务器上获取数据
5、使用场景
大容量、高并发、可线性扩展
刚才仅仅是对Redis Cluster做了简单的介绍，关于集群的创建、数据的迁移、集群的扩容和缩容、hash slots重分布、集群的reblance等日常操作，使用Redis Cluster中遇到的问题以及在改进smart driver道路上解决的问题等等，如果有同学感兴趣的话，欢迎私下共同交流学习。
四、kv存储之Pika
1、Pika是什么
Pika 是DBA需求，基础架构组开发的大容量、高性能、持久化、支持多数据结构的类Redis存储系统，目前已经开源，最新版本为Pika 2.2版本。它所使用的nemo引擎本质上是对Rocksdb的改造和封装，使其支持多数据结构的存储，并在nemo引擎之上封装redis接口，使其完全支持Redis协议。Pika兼容string、hash、list、zset、set等多数据结构，使用磁盘而非内存存储数据解决了Redis由于存储数据量巨大而导致内存不够用的容量瓶颈。
2、Pika PK Redis
Pika PK Redis之优势：
①大容量存储：Pika数据容量受制于磁盘，最大使用空间等于磁盘空间的大小，而Redis数据容量受限于主机内存
②秒级启动：Pika 在写入的时候, 数据是落盘的,Pika 重启不用加载所有数据到内存，不需要进行回放数据操作。而Redis启动需要将所有数据从磁盘加载到内存，随着容量增加，启动时间递增到分钟级甚至更长时间。
③秒级备份：Pika的备份方式，是将所有数据文件做快照。Redis无论是用RDB还是AOF的方式来实现数据备份的目的，都需要将全量的数据写入到磁盘，备份速度慢。
④秒删数据：Pika的数据删除是标记删除，Pika Key的元信息上有版本信息，表示当前key的有效版本，已删除的数据在Compact合并数据的过程中删除。而单线程的Redis在大量删除数据时候会影响线上业务，删除大对象会阻塞住Redis的主线程，删除速度慢。
⑤同步续传：Pika写入数据会有write2file日志文件，只要该文件未删除，无需全量同步数据，均可断点续传数据。而Redis一旦主从同步缓冲区被循环重写，容易导致全量数据重传。
⑥高压缩比：Pika存储的数据默认会被压缩，相对于Redis,Pika有5~10倍的压缩比。所以Redis的数据存储到Pika，数据体积会小很多。
⑦高性价比：相对于Redis使用昂贵的内存成本，Pika使用磁盘存储数据，性价比极高
Pika PK Redis之劣势：
①读写性能较弱：Pika是持久化的，基于磁盘的kv存储。而Redis是内存数据库。虽然pika是多线程的，但是在大多场景下，性能还是略逊色于Redis
②多数据结构性能损耗：Pika底层使用Rocksdb存储引擎，它并不支持多数据结构，Pika在Rocksdb的上层进行了改造和封装，实现了对多数据结构的支持。同时在性能上，会有一些损耗。
③兼容大部分Reids接口：Pika兼容了90% Redis接口，使其易用性得到大大提升。但是目前还没有做到完全兼容。
3、Pika整体架构
4、Pika使用场景
①业务量并没有那么大，使用Redis内存成本太高
②数据量很大，使用Redis单个服务器内存无法承载
③经常出现时间复杂度很高的请求让Redis间歇性阻塞
④读写分离且不希望故障切主后影到从库,能够快速切换
5、Pika使用现状
①内部：目前Pika已经在360内部的各个业务线广泛使用，共计覆盖43个主业务线和76个子业务线，近千亿的日访问量和数十T的数据规模，节约了大量昂贵的服务器内存，降低了使用成本。
②社区：在业内，据不完全统计，很多著名互联网公司也使用了Pika，例如新浪微博、美团、58同城、迅雷、万达电商、环信…………
6、Redis如何迁移到Pika
那么，在适用于 Pika的业务场景下，我们如何将Redis数据迁移到Pika呢？
Pika自带的工具集，其中aof_to_pika这个工具可以帮助我们完成很平滑的这个任务。由于该工具依赖于AOF来发送数据，所以原Redis必须要开启AOF，并关闭AOF重写的策略。aof_to_pika通过reader线程读取aof文件中的内容，根据设定的单次发送长度拼装成数据块，将要发送的数据库加入队列。同时sender线程不断的从队列中读取数据发送到目的Pika完成数据的重放。
除了Redis的迁移工具之外。考虑有同学可能也使用到了ssdb，那么Pika也很贴心的提供了从ssdb迁移数据到Pika的工具ssdb_to_pika。
五、多场景的业务需求
最后，针对于业务多变的kv存储需求，常常有两个重点是我们最为关注的，一个是数据量，另一个是访问量。围绕着数据量和访问量的大小，往往决定了我们是使用Redis、Redis Cluseter or Pika。
六、QA
Q1：Pika支持集群吗？
A1：Pika目前主持主从结构，也支持codis。自身目前还不支持分布式的集群化，我们还在做多数据结构集群化的调研。
Q2：Pika 与Redis什么关系？替代吗还是补充？看着像是补充。 Pika 如果是替代Redis，那使用磁盘如何保证高性能。
A2: Pika与Redis是使用场景上互相补充的关系。目前线上的Pika机器都使用的ssd，一般场景下ops在5w以内场景都能轻松应对。
Q3：Redis持久化方式如何选取？还是不做持久化？
A3：持久化多数场景下选择AOF方式，做不做持久化取决于业务对数据安全性的要求，毕竟纯缓存的数据一旦服务器宕机或者数据库崩溃，数据都会全部丢失。
Q4 : 张老师你好,Pika挂固态硬盘读写性能是否可以pk Redis?360 业务有这样应用吗？
A4:目前360内部使用Pika的应用，全部使用的都是SSD硬盘。
Q5 : Pika 里边 zset 是落地的么，zset是怎么实现的呢？ 对scan 类的命令支持怎样？Pika 性能如何？
A5: 是落地的，大致原理是将一条key-score-members转换成3条rocksdb的kv来存储。scan是都支持的，和Redis一样。Pika的性能我们认为还不错，能够满足多数场景，但是建议大家要部署在SSD上，和内存比SSD还是便宜太多的，另外非常欢迎大家用测试比较Pika与相似项目的性能！
Q6 : 老师，像类似于fastdfs也是存储在硬盘的，请问Pika与他们在使用场景上有什么不同呢？
A6: 就我个人知识了解，fastdfs是一个分布式文件系统，存储小文件、图片等，与Pika面向的场景不一样，Pika是为了解决Redis单机内存不足而设计的一个在线数据库，当然，只要单机磁盘容量够，也是可以存储二进制文件到pika的。
Q7: Pika和Aerospike相比有哪些优势呢？Aerospike开源版本内存加持久化后，执行删除操作，重启后删除的数据会重新从磁盘加载，Pika有没有这个弊病？
A7: Pika的设计初衷其实就是为满足业务在Redis存储中，因为内存不足而造成业务损失，所以，我们的Pika的命令基本与Redis保持一致，并且client也是复用Redis的，这样，业务从Redis切换到Pika，无任何复杂度，这一点，我个人看Aerospike是比不了的。另外，Pika是不会加载删除数据。
Q8：redis 中热键大键如何处理？发现大部分故障都源于此
A8: 热点数据需要进行业务逻辑上的拆分或者多级缓存分担压力。我们线上也因为大键造成了一些困扰，例如：网卡带宽被打死、del大键造成Redis堵塞等，从Redis本身，确实没有太好的办法来解决，只能从业务层面分析出现大键的原因，做出响应的对策，例如：对大键进行压缩存储、或者存储大键到有多线程处理的pika中等等。