redis调研

一、背景与概述
1、背景介绍

随着互联网业务的快速发展，数据量的递增，传统的关系型数据库也暴露了如下的问题：

  数据处理效率低、并行化低效、可扩展性差、成本高

而关系数据库所提供的强一致性、事务性、关联操作在许多互联网应用模型中并不是必须的，所以在新的场景下，去关系化的NoSQL数据库应运而生。

NoSQL数据库具有高扩展性、高性能、灵活的数据模型、高可用等特点，其中的一大分支是key-value数据库，

key-value数据库采用键值对的形式来组织、索引和存储数据，具有简单、易用、可扩展性好等特点。

而Redis作为key-value数据库里的最热门的一员，在保持key-value数据库的简单快速的优点基础上，具有一些部分关系数据库的优点，例如数据结构丰富、操作原子性等特点。

2、redis现状和问题
Redis推出后具备诸多优点得以广泛流行，目前高居kv数据库热度榜第一。

redis的优点如下：
1、Redis的数据全量保存在内存中，采用单线程无锁事件驱动的方式进行服务处理，协议上支持流水线批量和增量操作，具有相当高的性能；
2、Redis提供多种键值数据类型来适应不同场景下的存储需求，支持部分的事务特性；
3、Redis采用可读易懂的协议接口，并支持了几十余种语言的客户端库，对开发者来说简单易用，开源生态也比较活跃，目前大量公司采用它来作为缓存或者存储系统。
redis问题如下：

1、伸缩性不佳，数据无法自动平滑迁移；同时，单线程既是Redis系统的一个独特的优势，但也成为性能瓶颈，单线程也限制了它所能提供的性能；

2、全内存的部署方式，性能虽然不错，但一方面，数据都在内存里，无法区分冷热数据，另一方面，内存相比磁盘容量更小，无法实现大数据量的存储；

3、Redis本身虽然通过RDB和AOF来实现数据持久化和主备同步，但通过遍历当前内存里的数据生成dump文件，如果业务的写量较大，则可能导致OOM；

    此外，写量大的时候，也会触发流水的rewrite机制，这时也会造成IO堵塞，进而引起比较严重的性能问题。

4、业界也有一些解决方案来解决redis单机版的扩展性问题，例如twemproxy和codis，他们采用了代理节点进行数据分片的方式来连接后端多个redis服务器，但这些方案基本上都是在单机版的基础上实现了分片机制，而并没有解决redis单机版本身存在的问题，主备同步机制仍然借助RDB、AOF等机制，容易造成性能颠簸。

二、redis不同版本比较
1、不同版本的redis简单比较


数据来源：redis不同版本的发行说明
2、不同版本之间的性能测试
测试工具：redis-benchmark

3、不同版本的redis存在的缺陷

2.6版本的优缺点

优点：

1、让用户使用更加方便；

由于Lua语言具有高效性、可移植性、可嵌入性、简单强大、小巧轻便、免费开源等优点，被广泛应用在应用在各大领域。Redis2.6对Lua脚本的支持，让使用者更加方便。

2、键的过期时间支持毫秒，提高了精度

3、从节点支持只读功能，让主从节点的分工更加明确。

4、去除了集群相关的代码，由于前期集群造成的代码臃肿混乱，直接让代码更加简洁，也更轻便。

缺点：

1、海量数据对服务器的性能大打折扣

2、不支持集群，系统扩展相对较麻烦

2.8版本的优缺点

优点：

1、尝试性的支持IPv6;

由于IPV4最大的问题在于网络地址资源有限，IPv6的使用是一个必然的，对后续的发展是非常有利的。

2、添加部分主从复制的功能，在一定程度上降低了由于网络问题，造成频繁全量复制生成RDB对系统造成的压力。

缺点：

1、海量数据对服务器的性能大打折扣

2、不支持集群，系统扩展相对较麻烦

3.0版本的优缺点

优点：

1、添加Redis的分布式实现Redis Cluster，系统之间的耦合度降低，从而使系统更易于扩展；

2、migrate连接缓存，大幅提升键迁移的速度；

3、在性能、稳定性等方面都有了重大提高

缺点：

1、代码改动较大，存在着对前期版本的兼容性问题

2、内存的消耗问题

3.2版本的优缺点

优点：

1、新的List编码类型：quicklist综合linkedlist和ziplist的缺点。

由于linkedlist地址不连续，节点多了容易产生内存碎片；

而ziplist不利于修改操作，插入和删除操作需要频繁的申请和释放内存；

2、SDS在速度和节省空间上都做了优化。

3、添加GEO相关功能。

缺点：

平滑迁移还是有些难度。

4.0版本的优缺点

优点：

1、提供了模块系统，方便第三方开发者拓展Redis的功能。

2、提供了RDB-AOF混合持久化格式，充分利用了AOF和RDB各自优势，对企业的平滑迁移提供了很大的优势。

三、百度内部redis概述
1、BDRP介绍
BDRP 全称为 Baidu Distributed Redis Platform : 意思是基于redis的分布式KV存储平台。

2、BDRP平台特性
读写分离

于读多写少的服务，单个分片请求压力过大的情况，BDRP可对集群增加只读从库，将分片的读取请求发送到只读从库上，从而提升集群容量。

高可用

在开源项目基础上，BDRP团队对redis主从传输进行优化，为每个分片增加从库。当主库故障时，可以自动切换到从库上，这样，就在保证数据高可靠的同时，保证了数据高可用。由于用户通过proxy访问集群，因而整个过程对用户完全透明。

数据分片及扩容

BDRP 平台会将应用方的数据进行自动分片，将redis数据库存储到不同的redis实例上，当前分片数据过多或压力过大时，可以将数据分片拆分，拓展集群空间。扩容采用成倍扩容，

即提供和现有机器相同容量和数目的机器，bdrp负责后续的机器借用和扩容步骤，目前扩容需要停服务，时间大概是在2s左右。

权限管理

BDRP 支持基于IP白名单的权限验证和BNS节点权限验证。并且将权限细分到只读和读写。bns更改每10s更新一次。

协议

BDRP 支持redis原生协议或者百度MCPACK协议(不建议使用)。

四、业界redis简单对比
1、业界之间的简单对比

数据来源：新浪云首页：https://www.sinacloud.com/
华为云首页：https://activity.huaweicloud.com/promotion/index.html
腾讯云首页：https://cloud.tencent.com/
阿里云首页：https://www.aliyun.com/
网易云首页：https://www.163yun.com/
百度云首页：https://cloud.baidu.com/

注：

scp -r 机器名：/目录/文件 目标目录

Redis中文网：http://www.redis.cn/

百度内部的redis就是根据源生的redis做了一个DBRP架构

BDRP包括redis、proxy、sentinel

sentinel就是起监管作用，为啥还要有个proxy，数据分片呀

传进来数据存在哪台上呢，proxy就管着分配，白名单

只有在白名单里的机器才可以访问

proxy的文件里有白名单，用来控制“有哪些机器可以访问集群”

只有白名单 告诉集群哪台机器可以登录这个集群

可以找些twemproxy的资料来看看

支持原生的redis协议，使用开源官方提供的客户端即可正常访问。 BDRP完全兼容redis的原生协议，应用开发方只需要使用官方客户端即可正常访问。

需要注意的是由于存储分布式化了，涉及分布式事务的相关细节目前并不能很好支持，比如mset就无法正常支持。