1.为什么使用redis？

在项目中使用redis，主要是从两个角度去考虑:性能和并发

当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis。因此，这个问题主要从性能和并发两个角度去答。

回答:如下所示，分为两点

（一）性能 如下图所示，我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。

（二）并发 如下图所示，在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问数据库。

2.为什么使用redis-cluster？

1.主从架构中只有一个master节点，就导致了redis存储的数据容量很有限，另外主从复制不能实现高可用
2.随着公司发展，用户数量增多，并发越来越多，业务需要更高的QPS，而主从复制中单机的QPS可能无法满足业务需求
3.数据量的考虑，现有服务器内存不能满足业务数据的需要时，单纯向服务器添加内存不能达到要求，此时需要考虑分布式需求，把数据分布到不同服务器上
4.网络流量需求：业务的流量已经超过服务器的网卡的上限值，可以考虑使用分布式来进行分流
5.离线计算，需要中间环节缓冲等别的需求

3. Redis特点及适用场景

Redis支持的数据结构

• 字符串（String）
• 哈希（Hash）
• 列表（List）
• 集合（Set）
• 有序集合（Sorted Set）位数组
  • 支持针对score作范围查询
• HyperLogLog
  • 做基数统计的算法

Redis支持的操作

• 基本操作发布/订阅
  • Set get add push pop…
• Pipeline操作
• 事务
  • 事务支持不完整。不提供回滚命令。

Redis适用场景

• KV存储
• 缓存（TTL LRU…）消息中间件
  • LRU是redis达到maxmemory之后，可选的key删除策略。
• 分布式锁

实现基础——分区

• 分区是分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集。
• 通过利用多台计算机内存的和值，允许我们构造更大的数据库。
• 通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。

4.redis集群的几种实现方式

A. 客户端分片

B. 基于代理的分片

C. 路由查询

客户端分片

• 由客户端决定key写入或者读取的节点。
• 包括jedis在内的一些客户端，实现了客户端分片机制。

原理如下所示：

特性

• 优点
  • 简单，性能高。
• 缺点
  • 业务逻辑与数据存储逻辑耦合
  • 可运维性差
  • 多业务各自使用redis，集群资源难以管理
  • 不支持动态增删节点

基于代理的分片

• 客户端发送请求到一个代理，代理解析客户端的数据，将请求转发至正确的节点，然后将结果回复给客户端。
• 开源方案
  • Twemproxy
  • codis

基本原理如下所示：

特性

• 透明接入Proxy 的逻辑和存储的逻辑是隔离的。业务程序不用关心后端Redis实例，切换成本低。
• 代理层多了一次转发，性能有所损耗。

路由查询

• 将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。
• 开源方案
  • Redis-cluster

基本原理如下所示：

集群的挑战

• 涉及多个key的操作通常是不被支持的。涉及多个key的redis事务不能使用。举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
• 不能保证集群内的数据均衡。分区的粒度是key，如果某个key的值是巨大的set、list，无法进行拆分。
• 增加或删除容量也比较复杂。redis集群需要支持在运行时增加、删除节点的透明数据平衡的能力。

4.Redis集群各种方案原理

Twemproxy

• Proxy-based
• twtter开源，C语言编写，单线程。
• 支持 Redis 或 Memcached 作为后端存储。

Twemproxy高可用部署架构

Twemproxy特性

• 支持失败节点自动删除
  • 与redis的长连接，连接复用，连接数可配置
• 自动分片到后端多个redis实例上支持redis pipelining 操作
  • 多种hash算法：能够使用不同的分片策略和散列函数
  • 支持一致性hash，但是使用DHT之后，从集群中摘除节点时，不会进行rehash操作
  • 可以设置后端实例的权重
• 支持状态监控
• 支持select切换数据库

redis的管道(Pipelining)操作是一种异步的访问模式，一次发送多个指令，不同步等待其返回结果。这样可以取得非常好的执行效率。调用方法如下：

1 2 3 4 5 6 7 8 9 10 11 12 13

@Test public void testPipelined() { Jedis jedis = new Jedis("localhost"); Pipeline pipeline = jedis.pipelined(); long start = System.currentTimeMillis(); for (int i = 0; i < 100000; i++) { pipeline.set("p" + i, "p" + i); } List<Object> results = pipeline.syncAndReturnAll(); long end = System.currentTimeMillis(); System.out.println("Pipelined SET: " + ((end - start)/1000.0) + " seconds"); jedis.disconnect(); }

Twemproxy不足

• 性能低：代理层损耗 && 本身效率低下
• Redis功能支持不完善
  • 不支持针对多个值的操作，比如取sets的子交并补等（MGET 和 DEL 除外）
  • 不支持Redis的事务操作
  • 出错提示还不够完善
• 集群功能不够完善
  • 仅作为代理层使用
  • 本身不提供动态扩容，透明数据迁移等功能
• 失去维护
  • 最近一次提交在一年之前。Twitter内部已经不再使用。

Redis Cluster

• Redis官网推出，可线性扩展到1000个节点
• 无中心架构
• 一致性哈希思想
• 客户端直连redis服务，免去了proxy代理的损耗

Redis Cluster模型

Redis-cluster原理

• Hash slot。集群内的每个redis实例监听两个tcp端口，6379（默认）用于服务客户端查询，16379（默认服务端口 + 10000）用于集群内部通信。
  • key的空间被分到16384个hash slot里；
  • 计算key属于哪个slot，CRC16(key) & 16384。
• 节点间状态同步：gossip协议，最终一致性。节点间通信使用轻量的二进制协议，减少带宽占用。

Gossip 算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致，这充分说明了 Gossip 的特点：在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，只要这些节可以通过网络连通，最终他们的状态都是一致的，当然这也是疫情传播的特点。
简单的描述下这个协议，首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想到信息一定要传递给所有的节点，但是随着时间的增长，在最终的某一时刻，全网会得到相同的信息。当然这个时刻可能仅仅存在于理论，永远不可达。

Redis-cluster请求路由方式

• Redis-Cluster借助客户端实现了混合形式的路由查询
  查询路由并非直接从一个redis节点到另外一个redis，而是借助客户端转发到正确的节点。根据客户端的实现方式，可以分为以下两种：包括Jedis在内的许多redis client，已经实现了对Redis Cluster的支持。
  • dummy client
  • smart client

查询路由的流程如下所示：

Redis cluster采用这种架构的考虑：

• 减少redis实现的复杂度
• 降低客户端等待的时间。Smart client可以在客户端缓存 slot 与 redis节点的映射关系，当接收到 MOVED 响应时，会修改缓存中的映射关系。请求时会直接发送到正确的节点上，减少一次交互。

Redis Cluster特性

• 高性能
• 支持动态扩容，对业务透明
• 具备Sentinel的监控和自动Failover能力

Redis Cluster不足

• 官方未提供图形管理工具，运维比较复杂要求客户端必须支持cluster协议
  • 比如数据迁移，纯手动操作，先分配slot，再将slot中对应的key迁移至新的节点。
• Redis命令支持不完整
  • 对于批量的指令，如mget支持不完整；不支持事务；不支持数据库切换，只能使用0号数据库……
• 集群管理与数据存储耦合
  • 比如如果集群管理有bug，需要升级整个redis。

Codis

• 豌豆荚开源的proxy-based的redis集群方案
• 支持透明的扩/缩容
• 运维友好同类产品中最全面的redis命令支持
  • GUI监控界面和管理工具

Codis部署拓扑

Codis数据存储

• 数据根据key分布到1024个slot内
• Key的slotid计算方法 crc32(key) % 1024
• 每个 codis-server 负责一部分数据
• 比如后端有3组codis-server，每个server负责的slot范围可以这样设置：
  • group0 0-300
  • group1 301-600
  • group2 601-1023

Codis模块简介

• Codis Server
  • 基于 redis-2.8.21 分支开发。增加了额外的数据结构，以支持 slot 有关的操作以及数据迁移指令。
• Codis Proxy
  • 客户端连接的 Redis 代理服务, 实现了 Redis 协议。
  • 对于同一个业务集群而言，可以同时部署多个 codis-proxy 实例
  • 不同 codis-proxy 之间由 codis-dashboard 保证状态同步。
• Codis Dashboard
  • 集群管理工具，支持 codis-proxy、codis-server 的添加、删除，以及据迁移等操作。
  • 所有对集群的修改都必须通过 codis-dashboard 完成。
• Codis Admin
  • 集群管理的命令行工具。
  • 可用于控制 codis-proxy、codis-dashboard 状态以及访问外部存储。
• Codis FE
  • 集群管理界面。
• Codis HA
  • 为集群提供高可用。
  • 依赖 codis-dashboard 实例，自动抓取集群各个组件的状态；
  • 会根据当前集群状态自动生成主从切换策略，并在需要时通过 codis-dashboard 完成主从切换。
• Storage
  • 为集群状态提供外部存储。
  • 目前仅提供了 Zookeeper 和 Etcd 两种实现，但是提供了抽象的 interface 可自行扩展。

Codis主从切换

• Codis-HA：自动切换主从的工具。
• 通过RESTful API从 codis-dashboard 中拉取集群状态
• 默认以 5s 为周期
• 该工具会在检测到 master 挂掉的时候主动应用主从切换策略，向codis-dashboard发送主从切换命令。
• 对自动主从切换的支持比较弱
  • 主从切换的限制较多，必须在系统其他组件状态健康，且距离上次主从同步数据在一定时间间隔内才可以执行。
  • 多slave场景，提升其中的一个slave为master，其他的slave仍然会从旧的master同步数据，需要管理员手动操作。

Codis数据迁移流程

• 前提：Codis单条数据迁移是原子操作
• 单条数据迁移过程：
  • 随机选取指定 slot 中的一个 <K,V>
  • 将这个<K,V>传输给另外一个 codis-server
  • 传输成功后，把本地的这个 <K,V>删除

迁移过程如下所示：

迁移过程中，Codis-dashboard与proxy通过zk通信，路由表信息全部存放在zk，保证所有proxy的视图一致。
Codis如何保证数据迁移过程的正确及透明？

• codis-config 在实际修改slot状态之前，会确保所有的 proxy 收到这个迁移请求。
• 迁移过程中, 如果客户端请求 slot 的 key 数据,proxy 会将请求转发到group2上。
  • proxy会先在group1上强行执行一次 MIGRATE key 将这个键值提前迁移过来，
  • 然后再到group2上正常读取

Codis VS Redis

1. 理论上，redis-cluster的性能更高，单次请求的延时低。另外，经过实测，两种架构后端单台redis-server的条件下，TPS基本没有差别。
2. Codis的高可用依赖jodis，或者使用LVS进行高可用部署。

我司选择Codis的原因

• Redis-cluster没有成熟的应用案例
• Codis支持的命令更加丰富
• 迁移至redis cluster需要修改现有实现；而迁移到codis没这么麻烦，只要使用的redis命令在codis支持的范围之内，只要修改一下配置即可接入。
• Codis提供的运维工具更加友好

Codis简单压测

单台Codis Server压测结果

三台Codis-Server的集群压测结果

压测结论

• 针对codis集群压测过程中，后端codis server平均CPU占用约为70%~80%。
• 单台codis的TPS在6w~7w左右，集群的TPS在17w左右，可以达到近乎线性扩展的能力
• 测试期间后台codis-server的负载没有跑满，仍然具有继续压测的潜力。
• 测试期间proxy机器负载低，可以支撑更多后端codis server实例。

使用codis注意事项

• 不支持的命令
  • 不支持的命令列表
• 防止key冲突
  • 建议现有业务接入codis时，加入项目前缀以作区分。
• 使用spring data redis操作codis时，只能使用RedisTemplate系列接口，Cache系列接口不可用
  • Cache系列的接口使用了redis的事务指令，事务在Codis以及Redis Cluster中均未提供支持。
• 避免key value巨大的数据
  • 吞吐量提升不明显
  • 可能造成各codis实例资源占用不均衡

参考文档：

《Redis官方文档》

Redis集群方案总结

原文链接：https://blog.csdn.net/qq_25518029/article/details/120175921