1、常见的三种数据的集群存储模式

  1. full-mirror:全量镜像模式,单纯备份模式,各个节点数据相同,都包含了全量数据,仅主节点可写,保证了数据冗余和读的负载均衡。数据安全性高,横向扩展能力差,资源利用率不高。

  2. pure-sharding:数据分片,每个节点的数据不相同,所有节点中数据的并集就是全量数据。横向扩展能力强,资源利用率高,但是数据安全性低。

    SRE实战 互联网时代守护先锋,助力企业售后服务体系运筹帷幄!一键直达领取阿里云限量特价优惠。
  3. mirrored-sharding:结合两种模式的优点,既满足高数据安全性要求,又能实现规模的横向扩展。

2、Redis集群的必要性和分类

  • 必要性:单实例服务存在单点故障,集群模式能提高服务的整体可用性。

  • 分类:

    • 主从复制(Replication):数据在主从间全量镜像,仅主节点可写,所有节点都可读,但仍不具备横向扩展能力。

      • 静态主从:在启动服务时,在配置文件中指定,给slave指定其从属的master,可以实现数据的备份和读操作的负载均衡,但是缺乏对master实例的高可用保障。

        redis-server --port 6380 slavaof 127.0.0.1 6379 //将6379配置为本实例的master

        还可以在服务运行过程中通过客户端命令手动改变实例的角色:

        redis > slaveof 127.0.0.1 6381 //将本实例的master改为6381

        redis > slaveof no one //将本实例从主从结构中独立出来,但会保留之前的数据

      • 利用哨兵(Sentinel )实现高可用:每个服务实例都启动一个哨兵守护进程,负责集群中节点状态的监控和主节点的选举,此时主节点也就实现了高可用。哨兵可以单实例管理单集群,也可以单实例管理多集群,还可以组成无中心哨兵集群,哨兵集群内部使用paxos理论进行协调管理。

    • 分布式集群(Cluster):

      • twemproxy:twitter开发的一个针对key提供路由功能的代理曾,代理层上方时客户端,下方是多个Redis服务实例,形成分片集群,客户端针对key的读写操作都必须经过代理层路由到分片集群中指定的服务实例上(key的hashcode对节点数量取模),这就实现了集群的横向扩展。

        • 缺点:
        1. 存在数据倾斜问题,一旦发生倾斜将不能成分利用集群资源,消除倾斜需要额外设计算法,耗时耗力。
        2. 代理层存在单点缺陷。
        3. 节点数量变动后必须对历史数据全量再分发。
      • 官方集群方案(3.x后):将整个集群划分为16384个逻辑slot,每个服务实例集群构成master-slave分片,各分片各自来认领一批逻辑slot。所有的key都会被路由到某个逻辑slot上,计算公式为【slot_num = crc16(key) % 16384】,式中crc16函数是16位循环冗余校验和函数。

        1. 当需要横向扩容时,旧节点让出一部分slot给新节点,这部分数据也随slot迁移到新节点上,这就避免了全量数据的重分发。

        2. 当发生数据倾斜时可以手动瓜分较重节点上的slot,实现数据的分摊,从而解决了倾斜问题。

        3. 每个分片都是一个master-slave结构,保证本分片内的高可用(当前模式将sentinel进程融合到了server进程中,方便分片内节点的状态和角色管理)。
        4. 每个分片的主节点都具有slot计算能力,当某个主节点接收到一个key的添加时,都会计算其应该归属的slot,如果恰好命中本分片,就存储数据,如果未命中则会告诉客户端让其重新计算。读数据时,分片主节点会计算key的slot,如果恰好命中则返回value,如果未命中则会返给正确的存储节点位置。
        5. 部署时至少要启动6各节点,三个分片,每个分片内一主一从。

3、Redis主从复制(哨兵模式)

  1. 一个Redis主服务拥有多个副本服务,形成master-slave结构。
  2. 只要网络正常,master会一直将自己的数据更新同步给slave,保持主从数据一致。
  3. 只有master能接收写命令,master和slave都可以接收读命令,实现读操作的负载均衡。
扫码关注我们
微信号:SRE实战
拒绝背锅 运筹帷幄