当前位置： 移动技术网 > IT编程>数据库>Redis > REDIS集群 基础知识总结

REDIS集群 基础知识总结

2020年07月09日  | 移动技术网IT编程  | 我要评论

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集群

本文地址：https://blog.csdn.net/chixushuchu/article/details/85990130

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网