加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

史上最全 Redis 高可用解决方案总结来了!

发布时间:2018-10-01 20:22:50 所属栏目:大数据 来源:Java技术栈
导读:本文主要针对 Redis 常见的几种使用方式及其优缺点展开分析。 一、常见使用方式 Redis 的几种常见使用方式包括: 1、Redis 单副本 Redis 单副本,采用单个 Redis 节点部署架构,没有备用节点实时同步数据,不提供数据持久化和备份策略,适用于数据可靠性要

Client 实现复杂,驱动要求实现 Smart Client,缓存 slots mapping 信息并及时更新,提高了开发难度,客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。

节点会因为某些原因发生阻塞(阻塞时间大于 clutser-node-timeout),被判断下线,这种 failover 是没有必要的。

数据通过异步复制,不保证数据的强一致性。

多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况。

Slave 在集群中充当“冷备”,不能缓解读压力,当然可以通过 SDK 的合理设计来提高 Slave 资源的利用率。

Key 批量操作限制,如使用 mset、mget 目前只支持具有相同 slot 值的 Key 执行批量操作。对于映射为不同 slot 值的 Key 由于 Keys 不支持跨 slot 查询,所以执行 mset、mget、sunion 等操作支持不友好。

Key 事务操作支持有限,只支持多 key 在同一节点上的事务操作,当多个 Key 分布于不同的节点上时无法使用事务功能。

Key 作为数据分区的最小粒度,不能将一个很大的键值对象如 hash、list 等映射到不同的节点。

不支持多数据库空间,单机下的 redis 可以支持到 16 个数据库,集群模式下只能使用 1 个数据库空间,即 db 0。

复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。

避免产生 hot-key,导致主库节点成为系统的短板。

避免产生 big-key,导致网卡撑爆、慢查询等。

重试时间应该大于 cluster-node-time 时间。

Redis Cluster 不建议使用 pipeline 和 multi-keys 操作,减少 max redirect 产生的场景。

5、Redis 自研

Redis 自研的高可用解决方案,主要体现在配置中心、故障探测和 failover 的处理机制上,通常需要根据企业业务的实际线上环境来定制化。

 

1000 (5)

1000 (6)

 

 

优点:

高可靠性、高可用性;

自主可控性高;

贴切业务实际需求,可缩性好,兼容性好。

缺点:

实现复杂,开发成本高;

需要建立配套的周边设施,如监控,域名服务,存储元数据信息的数据库等;

维护成本高。

相关阅读:

Python主要用于什么开发?

五个技术技巧助力优化大数据分析

深度挖掘,大数据不是事儿

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读