高性能kv存储之Redis、Redis Cluster、Pika:如何应对4000亿的日访问量?

标签: 运维干货 Pika Redis Redis Cluster 高性能kv存储 | 发表时间:2017-04-21 14:15 | 作者:小码哥
出处:http://www.yunweipai.com

一、背景介绍

随着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架构  

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。

kv存储

六、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中等等。

作者介绍

张恒,360web平台部DBA ,主要负责公司kv存储、数据仓库gp运维以及私有云数据库平台建设。

文章来自微信公众号:高效运维开发

相关 [性能 kv redis] 推荐:

高性能kv存储之Redis、Redis Cluster、Pika:如何应对4000亿的日访问量?

- - 运维派
随着360公司业务发展,业务使用kv存储的需求越来越大. 为了应对kv存储需求爆发式的增长和多使用场景的需求,360web平台部致力于打造一个全方位,适用于多场景需求的kv解决方案. 目前,我们线上大规模使用的kv存储有Redis,Redis cluster以及Pika. 为什么说是爆发式的需求增长呢.

redis 性能问题查找

- - 开源软件 - ITeye博客
          使用redis作为数据库时,系统出现少量超时,通过日志信息发现,超时发生在bgsave时. bgsave命令会fork一个子进程,子进程会将redis数据库信息dump到rdb文件中. 因此不能确定使用bgsave命令时,是fork一个子进程引起超时,还是dump文件时与主进程的sync同步同时写磁盘引起的超时.

Redis性能调优 - 简书

- -
尽管Redis是一个非常快速的内存数据存储媒介,也并不代表Redis不会产生性能问题. 前文中提到过,Redis采用单线程模型,所有的命令都是由一个线程串行执行的,所以当某个命令执行耗时较长时,会拖慢其后的所有命令,这使得Redis对每个任务的执行效率更加敏感. 针对Redis的性能优化,主要从下面几个层面入手:.

Nginx+KV db进行AB灰度测试

- - IT技术博客大学习
周6参加华东运维大会,听了人家淘宝用nginx的一些场景,其中AB的灰度测试可能适用场景会比较普遍,当然大会上,并没有详细讨论实现. 大概需求是: 网站类业务在更新new feature时,并不想让全量用户看到,可以针对地区性用户开放此feature. 大概构思了一个方式,使用 nginx+redis/memcache+IP库实现,简单的流程图如下:.

基于lucene的内嵌式kv存储

- - 开源软件 - ITeye博客
诸多业务场景下,都有使用kv型式存储数据供快速查询的需求. 正常的做法有使用HashMap存入内存,或者存入外部的nosql KV数据库/缓存. 使用HashMap做KV存储,速度快,但是如果数据量达到百万及至千万级时,HashMap必将占用大量的java堆内存,给应用带来极大的内存回收压力. 外部kv存储,以堆外(offHeap)存储的方式让我们的应用免于内存回收之忧,但其查询性能往往低于内存map.

滴滴从KV存储到NewSQL实战

- - DockOne.io
【编者的话】本文讲诉滴滴在分布式NoSQL存储Fusion之上构建NewSQL的实践之路. 详细描述Fusion-NewSQL的特性,应用场景,设计方案. Fusion-NewSQL是由滴滴自研的在分布式KV存储基础上构建的NewSQL存储系统. Fusion-NewSQ兼容了MySQL协议,支持二级索引功能,提供超大规模数据持久化存储和高性能读写.

Redis性能调优:保存SNAPSHOT对性能的影响

- - CSDN博客系统运维推荐文章
前一段时间,开发环境反馈,Redis服务器访问非常慢,每个请求要数秒时间,重启之后2~3天又会这样. 我查看了一下Linux的性能,没有什么问题. 发现访问Redis确实很慢,执行info要几秒时间. 里面有个参数已连接的客户端几万个,通过. 查看到很多client的age都很大,一直没有释放. 于是怀疑是不是和这个有关,因为版本是2.8.6,无法通过client一次性kill掉所有的连接,只能写一个程序,一个一个地kill掉(.

多种方式测试redis入库性能

- - The Big Data Way
结论:Pipeline + Transaction方式是几种插入方式中性能最好的. 虽然有点意外,但测试多次仍然是这个结论. private long rowCount = 1000000; // 100万. 已有 0 人发表留言,猛击->> 这里<<-参与讨论. —软件人才免语言低担保 赴美带薪读研.

大偏移量下Redis、MongoDB分页/排名性能比较

- - CSDN博客数据库推荐文章
题目其实并不太准确,因为数据库并不会提供 分页、排名等功能,提供的只是数据的存取,分页排名这些都是我们基于数据库的实用案例而已. 然而无论是 Redis还是 MongoDB,通常都有一些常规的做分页和排名的方法. 本文就通过一些测试数据来向大家介绍Redis和MongoDB(以及传统关系型数据库)在这方面的性能差别.

Redis 的性能幻想与残酷现实

- - mindwind
2011 年,当初选择 Redis 作为主要的内存数据存储,主要吸引我的是它提供多样的基础数据结构可以很方便的实现业务需求. 另一方面又比较担心它的性能是否足以支撑,毕竟当时 Redis 还属于比较新的开源产品. 但 Redis 官网宣称其是提供多数据结构的高性能存储,我们对其还是抱有幻想的. 要了解 Redis 的性能,我们先看看官方的基准性能测试数据,心里有个底.