REDIS集群 基础知识总结

REDIS集群

单机
单点故障、瓶颈;多个节点负载;
集群

主从复制

定义
Replication
镜像:增删改<主 退化至单节点> 查询负载到从节点
实现高可用 Sentinel

  • 一个redis服务可以有多个该服务的复制品,这个redis服务称之为Master,其他称为slaves
  • 只要网络连接正常,Master和Slaves之间就会保持主从数据同步
  • 只有Master可以执行写命令,Slaves只能执行读命令
    从服务器执行客户端发送的读命令,比如GET、LRANGE、SMEMMBERS、HGET、ZRANGE等等 客户端可以连接Slaves执行读请求,降低Master的读压力
    如何创建主从复制
    redis-server --slaveof ,配置当前服务称为某Redis服务的Slave
redis-server --port 6380 --slaveof 127.0.0.1 6379

SLAVEOF host port命令,将当前服务器状态从Master修改为别的服务器的Slave

redis > SLAVEOF 192.168.1.1 6379,将服务器转换为Slave
redis > SLAVEOF NO ONE ,将服务器重新恢复到Master,不会丢弃已同步数据

配置方式:启动时,服务器读取配置文件,并自动成为指定服务器的从服务器

slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379

主从复制问题 手动解决master挂掉

  1. 一个Master可以有多个Slaves
  2. Slaves下线,只是读请求的处理性能下降
  3. Master下线,写请求无法执行
  4. 某一台Slave使用SlaveOF no one命令称为Master,其它Slaves执行SLAVEOF命令指向这个新的Master,从它这里同步数据

Sentinel

Sentinel哨兵,实现故障转移Failover高可用
监控Monitoring
Sentinel会不断检查Master和Slaves是否正常
每一个Sentinel可以监控任意多个Master和该Master下的Slaves
在这里插入图片描述
当主服务器下线时
当一个sentinel认为被监视的服务器已经下线时,它会向网络中的其他Sentinel进行确认,判断该服务器是否真的已经下线
如果下线的服务器为主服务器,那么sentinel网络将对下线主服务器进行自动故障转移,通过将下线主服务器的某个从服务器提升为新的主服务器,并让其从服务器转为复制新的主服务器,以此来让系统重新回到上线的状态
Sentinel配置文件

至少包含一个监控配置选项,用于指定被监控Master的相关信息
Sentinel monitor<name><ip><port><quorum>,例如sentinel monitor mymaster 127.0.0.1 6379 2监视mymaster的主服务器,服务器ip和端口,将这个主服务器判断为下线失效至少需要2个Sentinel同意,如果多数Sentinel同意才会执行故障转移
Sentinel会根据Master的配置自动发现Master的Slaves
Sentinel默认端口号为26379

Sentinel 总结

1 主从复制,解决了读请求的分担,从节点下线,会使得读请求能力有所下降
2 Master只有一个,写请求单点问题
3 Sentinel会在Master下线后自动执行Failover操作,提升一台Slave为Master,并让其他Slaves重新成为新Master的Slaves
4 主从复制+哨兵Sentinel只解决了读性能和高可用问题,但是没有解决写性能问题

Redis Twemproxy

  • 主从对写压力没有分担 使用多个节点分担,将写请求分散到不同节点处理
  • 使用多个节点分担,将写请求分散到不同节点处理
  • 分片Sharding 多节点分担的思路有点类似关系型数据库处理大表水平切分思路
    Twemproxy
    Twitter开发的代理服务器,他兼容Redis和Memcached,允许用户将多个redis服务器添加到一个服务器池(pool)里面,并通过用户选择的散列函数和分布函数,将来自客户端的命令请求分发给服务器池中的各个服务器
    通过使用twemproxy我们可以将数据库分片到多台redis服务器上面,并使用这些服务器来分担系统压力以及数据库容量:在服务器硬件条件相同的情况下,对于一个包含N台redis服务器的池来说,池中每台平均1/N的客户端命令请求
    向池里添加更多服务器可以线性的扩展系统处理命令请求的能力,以及系统能够保存的数据量

配置方案

Twemproxy配置
redischi:
  listen: 192.168.56.201:22121
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  server_retry_timeout: 2000
  server_failure_limit: 3
  servers:
   - 192.168.56.201:6379:1
   - 192.168.56.202:6379:1
   - 192.168.56.203:6379:1

配置说明

Twemproxy配置说明
redischi,服务器池的名字,支持创建多个服务器池
listen: 192.168.56.201:22121,这个服务器池的监听地址和端口号
hash: fnv1a_64,键散列算法,用于将键映射为一个散列值
distribution: ketama,键分布算法,决定键被分布到哪个服务器
redis: true,代理redis命令请求,不给定时默认代理memcached请求
servers,池中各个服务器的地址和端口号及权重
auto_eject_hosts、
server_failure_limit: twemproxy连续3次向同一个服务器发送命令请求都遇到错误时,twemproxy就会将该服务器标记为下线,并交由池中其他在线服务器处理


整合方案
https://github.com/changyibiao/redis-mgr
一站式的Redis服务器部署、监控、迁移功能

分布式

Redis集群

评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值