Redis和Gossip协议

本文探讨了Redis Cluster的基本概念,强调了Gossip协议在集群状态传播中的重要作用。Gossip协议采用类似流行病传播的方式,确保节点间信息的一致性,即使在节点数量增加时也能保持较低的通信负载。在Redis集群中,Gossip协议用于节点间的心跳检测、状态同步和故障检测,以实现去中心化的管理。
摘要由CSDN通过智能技术生成

今天来看一下Redis-Cluster和其中的重要概念Gossip协议。

1.Redis Cluster的基本概念

集群版的Redis听起来很高大上,确实相比单实例一主一从或者一主多从模式来说复杂了许多,互联网的架构总是随着业务的发展不断演进的。

单实例Redis架构
最开始的一主N从加上读写分离,Redis作为缓存单实例貌似也还不错,并且有Sentinel哨兵机制,可以实现主从故障迁移。

单实例一主两从+读写分离结构:
浅谈集群版Redis和Gossip协议

单实例的由于本质上只有一台Master作为存储,就算机器为128GB的内存,一般建议使用率也不要超过70%-80%,所以最多使用100GB数据就已经很多了,实际中50%就不错了,以为数据量太大也会降低服务的稳定性,因为数据量太大意味着持久化成本高,可能严重阻塞服务,甚至最终切主。

如果单实例只作为缓存使用,那么除了在服务故障或者阻塞时会出现缓存击穿问题,可能会有很多请求一起搞死MySQL。

如果单实例作为主存,那么问题就比较大了,因为涉及到持久化问题,无论是bgsave还是aof都会造成刷盘阻塞,此时造成服务请求成功率下降,这个并不是单实例可以解决的,因为由于作为主存储,持久化是必须的。

所以我们期待一个多主多从的Redis系统,这样无论作为主存还是作为缓存,压力和稳定性都会提升,尽管如此,笔者还是建议:

Redis尽量不要做主存储!
Redis尽量不要做主存储!
Redis尽量不要做主存储!
如果你一意孤行,那么要么坑了自己,要么坑了别人。

<
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值