如何开发一个高性能的redis cluster proxy

背景

redis cluster简介

Redis cluster是redis官方提供集群方案，设计上采用非中心化的架构，节点之间通过gossip协议交换互相的状态，redis cluster使用数据分片的方式来构建集群，集群内置了16384个哈希槽，每个key都属于这16384这个哈希槽中的一个，通过crc16算法计算哈希值，再取余可得每个key归属的哈希槽；redis cluster支持动态加入新节点，动态迁移slot，自动的故障转移等。

Redis cluster的架构要求客户端需要直接与redis集群中的每个节点建立连接，并且当出现新增节点加入、节点宕机failover、slot迁移等事件时，客户端需要能够通过redis cluster协议去更新本地的slot映射表，并且能处理ASK/MOVE语义，因此，我们一般称实现了redis cluster协议的客户端为smart redis client。

Redis cluster最多可以构建超过100个主节点的集群（超过之后gossip协议开销过大，且可能引起集群不稳定），按照单节点10G容量（单实例内存过大可能导致性能下降），单集群最多可以支撑1T左右的容量。

问题

redis cluster有很多优点（比如可以构建大容量集群，性能好，扩缩容灵活），但是当一些项目工程期望从redis迁移到redis cluster时，客户端却面临着大量的改造工作，与此同时带来的是需要大量的测试工作以及引入的新风险，这对于一些稳定运行的线上工程代价无疑是巨大的。

需求

为了更方便的将业务迁移到redis cluster，最期望的是客户端SDK的API完全兼容redis/redis-cluster，spring提供的RedisTemplate是一个很好实现，但是对于没有使用SpringRedisTemplate的项目，很多客户端实现的redis和redis-cluster访问API是不一致的（比如Java中流行的Jedis），这无形中提高了迁移工作的工作量和复杂性，此时redis cluster proxy是不错的选择，有了proxy，就可以像操作单实例redis一样操作redis cluster，客户端程序就不需要做任何的修改。

当然，增加一层proxy，必然会导致性能有一定程度的下降，但是proxy作为无状态的服务，理论上可以水平扩展，并且由于proxy层的存在减少了后端redis server的连接数，在某些极端场景下甚至能提高redis集群整体的吞吐量。此外，基于proxy，我们还可以做很多额外的事情：

比如可以在proxy层做分片逻辑，这样当单集群的redis cluster不满足需求（内存/QPS）时，就可以通过proxy层实现透明的同时访问多个redis cluster集群。
再比如可以在proxy层做双写逻辑，这样在迁移或者拆分缓存类型的redis时，就不需要使用redis-migrate-tool之类的工具进行全量迁移，而只需要按需双写，即可完成迁移。
此外因为proxy实现了redis协议，因此可以在proxy层利用其它存储介质实现redis相关命令，从而可以模拟成redis对外服务。一个典型的场景就是冷热分离存储。

功能

介于上述各种原因和需求，我们基于netty开发了camellia-redis-proxy这样一个中间件，支持如下特性：

支持设置密码
支持代理到普通redis，也支持代理到redis cluster
支持配置自定义的分片逻辑（可以代理到多个redis/redis-cluster集群）
支持配置自定义的双写逻辑（服务器会识别命令的读写属性，配置双写之后写命令会同时发往多个后端）
支持外部插件，从而可以复用协议解析模块（当前提供了camellia-redis-proxy-hbase插件，实现了zset命令的冷热分离存储）
支持在线变更配置（需引入camellia-dashboard）
支持多个业务逻辑共享一套proxy集群，如：A业务配置转发规则1，B业务配置转发规则2（需要在建立redis连接时通过client命令设置业务类型）
对外提供了一个spring-boot-starter，3行代码即可快速搭建一个proxy集群

如何提升性能

客户端向camellia-redis-proxy发起一条请求，到收到请求回包的过程中，依次经历了如下过程

上行协议解析（IO读写）
协议转发规则匹配（内存计算）
请求转发（IO读写）
后端redis回包解包（IO读写）
后端redis回包下发到客户端（IO读写）

可以看到作为一个proxy，大量的工作是在进行网络IO的操作，为了提升proxy的性能，做了以下工作：

多线程

我们知道redis本身是单线程的，但是作为一个proxy，完全可以使用多线程来充分利用多核CPU的性能，但是过多的线程引起不必要的上下文切换又会引起性能的下降。camellia-redis-proxy使用了netty的多线程reactor模型来确保服务器的处理性能，默认会开启cpu核心数的work线程。此外，如果服务器支持网卡多队列，开启它，能避免CPU不同核心之间的load不均衡；如果不支持，那么将业务进程绑核到非CPU0的其他核心，从而让CPU0专心处理网卡中断而不被业务进程过多的影响。

异步非阻塞

异步非阻塞的IO模型一般情况下性能都是优于同步阻塞的IO模型，对于proxy场景尤其如此，上述5个过程中，除了协议转发规则匹配这样的内存计算，整个转发流程都是异步非阻塞的，确保不会因为个别流程的故障影响整个服务。

流水线

我们知道redis协议支持流水线（pipeline），pipeline的使用，可以有效减少网络开销。camellia-redis-proxy也充分利用了这样的特性，主要包括两方面：

上行协议解析时尽可能的一次性解析多个命令，从而进行规则转发时可以批量进行
往后端redis节点进行转发时尽可能的批量提交，这里除了对来自同一个客户端连接的命令进行聚合，还可以对来自不同客户端连接，但转发目标redis相同时，也可以进行命令聚合

当然，所有这些批量和聚合的操作都需要保证请求和响应的一一对应。

TCP分包和大包处理

不管是上行协议解析，还是来自后端redis的回包，特别是大包的场景，在碰到TCP分包时，利用合适的checkpoint的机制可以有效减少重复解包的次数，提升性能。

异常处理和异常日志合并

如果没有有效的处理各种异常，在异常发生时也会导致服务器性能迅速下降。想象一个场景，我们配置了90%的流量转发给A集群，10%的流量转发到B集群，如果B集群发生了宕机，我们期望的是来自客户端的90%的请求正常执行，10%的请求失败，但是实际上却可能远远超过10%的请求都失败了，原因是多方面的：

后端操作系统层面的突然宕机proxy层可能无法立即感知（没有收到TCP fin包），导致大量请求在等待回包，虽然proxy层没有阻塞，但是客户端表现为请求超时
proxy在尝试转发请求到B集群时，针对B集群的重新连接请求可能拖慢整个流程
宕机导致的大量异常日志可能会引起服务器性能下降（这是一个容易忽视的地方）
pipeline提交上来的请求，99个请求指向A集群，1个请求指向B集群，但是由于B集群的不可用，导致指向B集群的请求迟迟不回包或者异常响应过慢，客户端的最终表现是100个请求全部失败了

camellia-redis-proxy在处理上述问题时，采取了如下策略：

设置对异常后端节点的快速失败降级策略，避免拖慢整个服务
异常日志统一管理，合并输出，在不丢失异常信息的情况下，减少异常日志对服务器性能的影响
增加对后端redis的定时探活探测，避免宕机无法立即感知导致业务长时间异常

部署架构

proxy作为无状态的服务，可以做到水平扩展，为了服务的高可用，也至少要部署两个以上的proxy节点，对于客户端来说，想要像使用单节点redis一样访问proxy，可以在proxy层之前设置一个LVS代理服务，此时，部署架构图如下：

当然，还有另外一个方案，可以将proxy节点注册到zk/Eureka/Consul等注册中心，客户端通过拉取和监听proxy的列表，然后再向访问单节点redis一样访问每个proxy即可。以Jedis为例，仅需将JedisPool替换为封装了注册发现逻辑的RedisProxyJedisPool，即可像访问普通redis一样使用proxy了，此时，部署架构图如下：

应用场景

需要从redis迁移到redis-cluster，但是客户端代码不方便修改
客户端直连redis-cluster，导致cluster服务器连接过多，导致服务器性能下降
单个redis/redis-cluster集群容量/QPS不满足业务需求，使用camellia-redis-proxy的分片功能
缓存类redis/redis-cluster集群拆分迁移，使用camellia-redis-proxy的双写功能
使用双写功能进行redis/redis-cluster的灾备
混合使用分片和双写功能的一些业务场景
基于camellia-redis-proxy的插件功能，开发自定义插件

结语

Redis cluster作为官方推荐的集群方案，越来越多的项目已经或正在迁移到redis cluster，camellia-redis-proxy正是在这样的背景下诞生的；特别的，如果你是一个Java开发者，camellia还提供了CamelliaRedisTemplate这样的方案，CamelliaRedisTemplate拥有和普通Jedis一致的API，提供了mget/mset/pipeline等原生JedisCluster不支持的特性，且提供了和camellia-redis-proxy功能一致的分片/双写等特性。

为了回馈社区，camellia已经正式开源了，想详细了解camellia项目的请移步github，地址如下：https://github.com/netease-im/camellia

如果你有什么好的想法或者提案，或者有什么问题，欢迎提交issue与我们交流！

关于作者

曹佳俊。网易智慧企业资深服务端开发工程师。中科院研究生毕业后加入网易，一直在网易云信负责IM服务器相关的开发工作。

更多技术干货，欢迎关注vx公众号“网易智慧企业技术+”。听网易CTO讲述前沿观察，看最有价值技术干货，学网易最新实践经验。网易智慧企业技术+，陪你从思考者成长为技术专家。

如何开发一个高性能的redis cluster proxy相关推荐

开源｜如何开发一个高性能的redis cluster proxy？
文|曹佳俊网易云信资深服务端开发工程师背景 redis cluster简介 Redis cluster是redis官方提供集群方案,设计上采用非中心化的架构,节点之间通过gossip协 ...
服务器如何识别同一客户端的各种不同的命令_开源项目｜如何开发一个高性能的redis cluster proxy？...
背景 redis cluster简介 Redis cluster是redis官方提供集群方案,设计上采用非中心化的架构,节点之间通过gossip协议交换互相的状态,redis cluster使用数据分 ...
Redis集群的方案总结：客户端Sharding/Redis Cluster/Proxy
转载:redis sentinel设计与实现转载:分布式一致性算法(一)一致性哈希算法(consistent hashing) 转载:Jedis下的ShardedJedis(分布式)使用方法(一) ...
谈谈如何使用Netty开发实现高性能的RPC服务器
RPC(Remote Procedure Call Protocol)远程过程调用协议,它是一种通过网络,从远程计算机程序上请求服务,而不必了解底层网络技术的协议.说的再直白一点,就是客户端在不必知道 ...
Redis Cluster部署、管理和测试
背景: Redis 3.0之后支持了Cluster,大大增强了Redis水平扩展的能力.Redis Cluster是Redis官方的集群实现方案,在此之前已经有第三方Redis集群解决方案,如Twen ...
redis分布式方案redis cluster的介绍和实践
简要介绍 redis cluster是redis官方提供的分布式解决方案.主要作用有两点: 将数据根据分区规则分布到不同的redis节点上,降低单个redis节点的读写压力. 内置提供高可用支持,集群 ...
基于Redis6.2.6版本部署Redis Cluster集群
基于Redis6.2.6版本部署Redis Cluster集群文章目录基于Redis6.2.6版本部署Redis Cluster集群 1.Redis6.2.6简介以及环境规划 2.二进制安装Red ...
如何从0到1构建一个稳定、高性能的Redis集群？（附16张图解）
阅读本文大约需要 13 分钟. 大家好,我是 Kaito. 这篇文章我想和你聊一聊 Redis 的架构演化之路. 现如今 Redis 变得越来越流行,几乎在很多项目中都要被用到,不知道你在使用 Red ...
16 张图教你如何从 0 到 1 构建一个稳定、高性能的 Redis 集群！
作者 | Magic Kaito 责编 | 张文来源 | 水滴与银弹(ID:waterdrop_bullet) 这篇文章我想和你聊一聊 Redis 的架构演化之路. 现如今 Redis 变得越来 ...

如何开发一个高性能的redis cluster proxy

如何开发一个高性能的redis cluster proxy相关推荐

最新文章

热门文章