redis集群方案大对比

妖狐艹你老母 2021-10-23 19:56 390阅读 0赞

# redis集群方案大对比 #

### 单机redis单实例 ###

redis的单机实例并发量在 50k-10k之间， 生产环境下一般在20-50k 以下

memcached可达十几万的并发，生产环境下也可5万以上。

### 主从模式 ###

这种模式可以方便快速的解决，读多写少的高并发场景，相对较小的缓存应用场景可适用

### 哨兵模式 ###

sentinel模式，解决了主从模式的下的高可用问题。哨兵模式相当清爽，相当于充当了一群管理员，自动的去完成主从切换，故障迁移等。

### 集群模式 ###

**1. redis-cluster集群**  
redis-cluster集群是redis服务自带的分部式集群解决方案3.0.版本以上方有该功能。去中心化是它一大特点。

**2. twemproxy代理集群**  
Twemproxy（又称为nutcracker）是一个轻量级的Redis和Memcached代理，主要用来减少对后端缓存服务器的连接数。Twemproxy是由Twitter开源出来的缓存服务器集群管理工具，主要用来弥补Redis/Memcached 对集群（cluster）管理的不足。

antirez（Redis作者）写过一篇对twemproxy的介绍，他认为twemproxy是目前Redis 分片管理的最好方案，虽然antirez的Redis cluster正在实现并且对其给予厚望，但从现有的cluster实现上还是认为cluster除了增加Redis复杂度，对于集群的管理没有twemproxy来的轻量和有效。

Twemproxy作为代理分发请求到节点,中间多了层通信。Twemproxy本身也是单点，**需要用Keepalived做高可用方案。**

从理论上来说.redis cluster性能高效.  
当然实现更为复杂的多,还需要实践检验.

Twemproxy的缺点：

Twemproxy最大的痛点在于，无法平滑地扩容/缩容。这样导致运维同学非常痛苦：业务量突增，需增加Redis服务器；业务量萎缩，需要减少Redis服务器。但对Twemproxy而言，基本上都很难操作（那是一种锥心的、纠结的痛）。或者说，Twemproxy更加像服务器端静态sharding。

有时为了规避业务量突增导致的扩容需求，甚至被迫新开一个基于Twemproxy的Redis集群。

**3. codis代理集群**

Codis由豌豆荚于2014年11月开源，基于Go和C开发，是近期涌现的、国人开发的优秀开源软件之一。

Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。

ZooKeeper还维护Codis Server Group信息，并提供分布式锁等服务。