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长短连都行。 |