• 【Redis】主从、哨兵、集群各自架构的优点和缺点对比


    1. 单机模式
    Redis 单副本,采用单个 Redis 节点部署架构,没有备用节点实时同步数据,不提供数据持久化和备份策略,适用于数据可靠性要求不高的纯缓存业务场景。

    优点:

    架构简单,部署方便。
    高性价比:缓存使用时无需备用节点(单实例可用性可以用 supervisor 或 crontab 保证),当然为了满足业务的高可用性,也可以牺牲一个备用节点,但同时刻只有一个实例对外提供服务。
    高性能。
    缺点:

    不保证数据的可靠性。
    在缓存使用,进程重启后,数据丢失,即使有备用的节点解决高可用性,但是仍然不能解决缓存预热问题,因此不适用于数据可靠性要求高的业务。
    高性能受限于单核 CPU 的处理能力(Redis 是单线程机制),CPU 为主要瓶颈,所以适合操作命令简单,排序、计算较少的场景。也可以考虑用 Memcached 替代。
    2. 主从架构
    主(master)和 从(slave)部署在不同的服务器上,当主节点服务器写入数据时会同步到从节点的服务器上,一般主节点负责写入数据,从节点负责读取数据。

    从节点设置只读属性,而主节点没有只写属性,因此,主节点可读可以写

    优点:

    读写分离,提高效率
    主节点负责写操作,从节点负责读操作;如果写少读多场景,配置多个从节点的话,效率非常高
    数据热备份,提供多个副本。
    从节点宕机,影响较小
    缺点:

    主节点故障,集群则无法进行工作,可用性比较低,从节点升主节点需要人工手动干预。

    因为只有主节点能进行写操作,一旦主节点宕机,整个服务就无法使用。当然此时从节点仍可以进行读操作,但是对于整个服务流程来说,是无法使用的。

    Master的写的压力难以降低。

    如果写操作比较多,那么只有一个主节点的话,无法分担压力。

    主节点存储能力受到单击限制。

    主节点只能有一个,因此单节点内存大小不会太大,因此存储数据量受限。

    主从数据同步,可能产生部分的性能影响甚至同步风暴。

    风暴问题,对于任何集群分布式来说都存在,要合理分布节点。

    3. 哨兵
    为了解决这两个问题,在2.8版本之后redis正式提供了sentinel架构。


    在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态。

    如果master节点异常,则会做主从切换,将某一台slave作为master,哨兵的配置略微复杂,并且性能和高可用性等各方面表现一般。

    优点:

    对节点进行监控,来完成自动的故障发现与转移
    缺点:

    特别是在主从切换的瞬间存在访问瞬断的情况,等待时间比较长,至少十来秒不可用。
    哨兵模式只有一个主节点对外提供服务,没法支持很高的并发
    单个主节点内存也不宜设置得过大,否则会导致持久化文件过大,影响数据恢复或主从同步的效率。
    与主从相比,哨兵仅解决了手动切换主从节点问题,至于其他的问题,基本上仍然存在。

    哨兵的主要问题还是由于中心架构,仅存在一个master节点引起的,写的效率太低。

    4. 集群模式
    Redis Cluster 是 3.0 版后推出的 Redis 分布式集群解决方案,主要解决 Redis 分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster 能起到很好的负载均衡的目的。

    Redis Cluster 集群节点最小配置 6 个节点以上(3 主 3 从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用。Redis Cluster 采用虚拟槽分区,所有的键根据哈希函数映射到 0~16383 个整数槽内,每个节点负责维护一部分槽以及槽所印映射的键值数据。

    注意:集群模式下 从节点不提供读写,与主从模式不一样。 总结一下经验,分布式 场景下:集群模式一般从节点不参与读写,仅作为备用节点。而主从一般都要负责读或写,都要参与具体的工作。

    优点:

    无中心架构。

    即有多个master节点,不像哨兵模式下仅有一个。这样写的压力就可以分散了;并且存储量也可以扩展了,因为多个主节点都可以存储一部分数据,总量要远大于单主节点架构。


    数据按照 slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布。

    可扩展性:可线性扩展到 1000 多个节点,节点可动态添加或删除。

    高可用性:部分节点不可用时,集群仍可用。通过增加 Slave 做 standby 数据副本,能够 实现故障自动 failover,节点之间通过 gossip 协议交换状态信息,用投票机制完成 Slave 到 Master 的角色提升。

    当然,如果某个槽归属的小群内都不可用时,整个服务仍然是不可用的!通过cluster-require-full-coverageyes 控制该特性, 默认yes 即需要集群完整,方可对外提供服务,设置为no ,其他的小集群仍然可以对外提供服务。

    缺点:

    如果主节点A和它的从节点A1都宕机了,那么该集群就无法再提供服务了。
    ————————————————
    版权声明:本文为CSDN博主「云川之下」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/m0_45406092/article/details/116171758

  • 相关阅读:
    QOS-Qos标记和QOS-Policy策略
    QOS-CBQ概述
    QOS-基本拥塞管理机制(PQ CQ WFQ RTPQ)
    QOS-QOS(服务质量)概述
    MariaDB数据库服务
    24、配置Oracle下sqlplus历史命令的回调功能
    11、nginx+tomcat+redis_session共享
    9、make和make install的区别
    10、nginx+uwsgi+django部署(动静分离)
    15、iptables_nat目标地址转换(外网访问内网)
  • 原文地址:https://www.cnblogs.com/richard713/p/16045154.html
Copyright © 2020-2023  润新知