Redis 集群概述
集群的核心意义只有一个: 保证一个节点出现了问题之后, 其他的节点可以继续提供服务使用.
Redis 基础部分讲解过主从配置: 对于主从配置可以有两类: 一主二从, 层级关系. 开发者一主二从是常用的手段.
Redis 的主从配置是所有 Redis 集群的一个基础. 但是只是依靠主从依然无法实现高可用的配置.
Redis 集群有以下两种方案
1)keepalived+twemproxy+HAProxy+sentinel
对 Redis 集群而言, 首先在主从的基础上发展出了一个叫哨兵的处理机制, 所谓的哨兵的处理机制指的是, 当我三台主机的 master 节点出现了问题之后, 会自动的在两个 slave 节点下重新退选举出一个新的 master 节点, 这样就可以保证原 master 出现问题之后, Redis 数据依然存在有主从的配置.
但是哨兵机制也只是针对于一种单主机的配置形式. 因为不可能只使用一台主机来实现我们 Redis 的配置. 而推特网站发布了一个代理机制. 可以有效的实现数据的分片存储. 即: 根据不同算法 实现不同主机的分片存储.
以保证负载均衡, 同时可以结合 keepalivedh 和 HAProxy 组件实现 twemproxy 的高可用.
2)Redis Cluster
Redis 在后来的版本发展之中也退出了一个自己的 Redis Cluster 集群配置, 利用这样的配置可以不用自己来通过配置文件实现主从关系的实现, 而直接通过命令完成.
keepalived+twemproxy+HAProxy+sentinel
哨兵机制简介
只要是进行高可用的架构部署, 那么就必须保证多节点, 在 Redis 里面使用了主从模式可以多节点配置, 但是传统的主从模式设计 一旦 master 主机出现问题之后, 两台 Slave 主机无法提供正常的工作支持, 列如: Slave 主机为只读主机, 而且如果要想继续提供支持, 那么至少应该通过剩余的几台 Slave 里面去推选出一个新的 Master, 并且最为重要的是: 这个新的 Master 能够被用户的程序找到.
如果要想进行哨兵机制的实现, 一定需要具备有如下的几个特点:
sentinel 的功能
1)监控 Monitoring
sentinel 时刻监控着 Redis master-slave 是否正常运行;
2)通知 Notification
sentinel 可以通过 API 来通知管理员, 被监控的 Redis master-slave 出现了问题.
3)自动故障转移 Automatic failover
当 Redis master 出现故障不可用状态, sentinel 会开始一次故障转移, 将其中一个 salve 提升为一个新的 master, 将其他 salve 重新配置使用新的 master 同步, 并使用 Redis 的服务器应用程序连接时收到使用新的地址连接.
4)配置提供者 Configuration provider
sentinel 作为在集群中的权威来源, 客户端连接到 sentinel 来获取某个服务的当前 Redis 主服务器的地址和其他信息. 当故障发生转移时, Sentinel 会报告新地址(更改哨兵文件对应的配置内容).
通常一台主机运行三个哨兵, 并且该哨兵运行的端口不同, 但是这三个哨兵都要去监控同一个 master 的地址.(找到了 master 就等于找到了所有的 slave)
twemproxy 分片处理
不管你电脑性能多好, 只要你运行了 Redis, 那么就有可能造成一种非常可怕的局面: 你电脑的内存将立刻被占满, 而且一台 Redis 数据库的性能终归是有限制的.
TwemProxy 是一个专门为了这种 nosql 数据库设计的一款代理工具软件, 这个工具软件最大的特征是可以实现数据的分片处理. 所为的分片指的是根据一定的算法将要保存的数据保存到不同的节点之中.
twemProxy 整合 sentinel
Twemproxy 如果要与 Redis 集成使用的是 Redis 的 Master 节点, 因为只有 Master 节点才具有写功能.
一旦某一个 Master 被干掉了, 则一定要重新选举出一个新的 Master 节点, 但是这个时候会出现有一个问题: twemproxy 所使用的配置文件时单独存在的. 哨兵选举完成后, 需要更新配置文件
如果要想保证所有的 Redis 集群高可用设计, 需要单独准备一个 shell 脚本与所有的哨兵机制一起使用. 两步操作: 1., 更改 redis_master.conf 文件(twemproxy 的配置文件) 2, 重新启动 twemproxy 进程
HAProxy 与 twemproxy 集成
Twemproxy 主要功能在于数据的分片处理, 而且会发现在整个 Redis 集群里面必须通过 twemProxy, 于是这个时候就有可能造成一种问题你后面 Redis 集群一定会速度爆快, 因为一堆的 Redis 数据库. 但是所有的性能都卡在了代理上
解决办法: 用 HAProxy 做 twemproxy 的代理.
HAProxy 是一个开源的, 高性能的, 基于 TCP 第四层和 http 第七应用层的千万级高并发负载均衡软件;
为了保证 HAProxy 的高可用设计, 所以应该设计有两套的 HAProxy 的代理主机, 但是现在就出现了一个问题, 如果现在提供了两套的 HAProxy 主机, 用户应该怎么访问? 需要记住两个地址吗.
用户访问 Keepalived 虚拟 IP,Keepalived 访问主(备)HAProxy
Keepalived 是一个基于 VRRP 协议来实现的服务高可用方案, 可用利用其来避免 IP 单点故障, 类似的工具还有 heartbeat,pacemaker. 但是它一般不会单独出现, 而是与其他负载均衡技术 (如 lvs,nginx,haproxy) 一起工作来达到集群高可用.
VRRP 协议全称 Virtual Router Redundancy Protocol, 即虚拟路由冗余协议.
以下是 keepalived+twemproxy+HAProxy+sentinel 的整个架构图(小人是指哨兵)
Redis Cluster
以上 Redis 集群作为项目的部署环境, 需要追加 twemproxy 代理做分片, 而后使用 HAProxy 做 twemproxy 的负载均衡, 而后使用 Keepalived 作为 HAProxy 的 vip 技术, 但是这样的设计成本太高.
Redis-cluster, 直接使用 Redis 就可以实现所谓的分片, 高可用.
Redis-cluster 设计的时候考虑到了去中心化, 中间件, 因为中心点的存在导致了性能的瓶颈, 解决一个问题 会解决第二个 第三个问题...
Redis-cluster 中每一个 Redis 的服务它都可以具备分片, 都可以具备集群的功能.
也就是说集群中的每个节点都是平等的关系, 每个节点都保存各自的数据和整个集群的状态. 每个节点都和其它所有节点连接, 而且这些连接保持活跃.
这样就保证了我们只需要连接集群中的任意一个节点, 就可以获取到其他节点的数据.
Redis-cluster 选举(容错)
选举过程是集群中所有 master 参与, 如果半数以上 master 节点与 master 节点通信超过设置时间(cluster-node-timeout), 认为当前 master 节点挂掉.
当我发现某一台主机的 master 挂掉了, 我们从新选举一个 salve 当做 master(整个过程中把哨兵避免了, 不需要修改哨兵的配置文件了)
这样可以去掉所有的代理层组件, 由 Redis 自己来完成, 这就是 Redis-cluster 的设计方案.
来源: https://www.cnblogs.com/ssskkk/p/10162651.html