Redis集群应用案例

redis 应用方式

下面的使用方式没有绝对的那个好，要考虑实际情形(业务，成本，资源等)选择合适的方式。

Redis master

最简单的模式，有单点问题，只合适进行memcache的缓存使用；

建议：作为缓存，不要进行数据持久化，只做内存缓存使用。

 

Redis master - slave

一主一从：部分解决了数据丢失问题，不能支持主从切换，还是存在单点问题。

可以支持读写分离，提高读吞吐率，机器使用率。

具体使用方式：

1     打开数据持久化（建议appendonly方式）, 提供系统数据容灾能力；

2     关闭数据持久化，提供读写分离，业务场景不需要数据容灾性，性能好

一主多从：

相对1M-1S，可以提供海量读请求业务场景，替代多memcache提供读请求（使用redis自动主从同步功能）。

Redis keepalive

方式：keepalive+ haproxy + redis(M-S)

keepalive VIP 方式提供了业务不需要关注redis 的IP和port 变更问题。

系统做到无单点问题，基本上两种方式：

1     开发脚本监控redis master 运行状况，通知haproxy 更新来解决；

2     集成 sentinel 监控来实现（推荐方案）。

 

在集群部署，对运维要求高；

在集群扩容，需要运维和前端应用程序一起调整（比如基于1024维度进行业务hash分组）；

由于VIP方式，对短连请求业务合适，tcp长连业务有单点瓶颈。

Redis codis

标准部署方式：

 

 

系统基本无单点，可以自动扩容，运维部署要求高，业务使用方简单；

由于VIP方式，对短连请求业务合适，tcp长连业务有单点瓶颈。

 

 Redis-Sentinel

Redis官方推荐的高可用性(HA)解决方案.

标准部署：

系统基本无单点，运维部署要求高，系统复杂度高。

集群扩容，业务使用方，运维都需要一起参与，比如redis分组在扩容的时。

由于直接访问redis（master，slave），性能最好；不管短连请求，tcp长连业务

都可以发挥到最佳性能，也没有VIP单台性能瓶颈问题。

Redis Cluster 

Redis集群的几个重要特征：  

(1).Redis 集群的分片特征在于将键空间分拆了16384个槽位，每一个节点负责其中一些槽位。

(2).Redis提供一定程度的可用性,可以在某个节点宕机或者不可达的情况下继续处理命令.

(3).Redis 集群中不存在中心（central）节点或者代理（proxy）节点， 集群的其中一个主要设计目标是达到线性可扩展性（linearscalability）。

  

   整体感觉下来，类似DHT，或者BT协议网络；无中心节点，自动发现，自动扩容，自动容灾等，很强大。

   从架构思路上，是否可以驾驭，决定了是否要使用；目前了解到，大的互联网公司都在观望，我们也在观望。

r应用整理

 

Redis master

 Redis（M-S）

Redis

Keepalive

Redis

Codis

Redis

Sentinel

数据安全

基本无

 

 

 

 

集群方式

不支持，需应用方解决

不支持，需应用方解决

不支持，应用方需知道分组策略

有集群提供；

应用方不关心

sentinel集群；应用方需知道分组策略

扩容方式

应用方参与解决

应用方参与解决

应用方参与解决

应用方不关心

应用方参与解决

运维复杂度

低

中

复杂

Dashboard，较复杂

复杂

系统单点

是

是

无

无

无

系统瓶颈

  ---

 ---

VIP 瓶颈

VIP 瓶颈

基本无

系统监控

 无

 无

脚本监控提供

需自己开发提供

需自己开发提供

适合业务场景

Memcache类似方式

读写分离场景，一写多读。

短连请求业务

短连请求业务

Tcp长短连都行。