Redis的几种高可用集群方案

Redis的高可用方式及常用集群方式一般有:

  1. 主从模式
  2. 哨兵模式
  3. 集群模式

当然也有第三方代理模式,如codis等,这种不在这里讨论之列。

我刚好学习到这里,我就简单记录下这几种模式的配置 。老鸟及不感兴趣的,可以就此飘过。

Redis的安装及单实例的启动,这里就不再赘述了,确实比较简单。

一 主从模式

这个模式就是解决单台机器的内存性能问题,可以把主实例和从实例放到不同的机器上面。从机器可以作备份使用,当master主机出现故障后,可以将某一台slave提升为master。一定程度上提高缓存的高性能,如果能接受一定的延迟,也可以做一个主从分离,所有的读都从slave上来,提高性能。

配置很简单,可以在配置文件或命令行中配置,直接加上 slaveof host:ip

redis-6380.conf

Slaveof 127.0.0.1:6379

127.0.0.1:6380>127.0.0.1:6379

然后分别启动Redis的主从实例就行了。

主从模式,虽然比单实例的可用性要好一些,但是生产环境基本上是不太会用的。因为他没有故障转移和监测。如果master挂了,还需要手动切到slave上面去。你的应用程序连接地址也得做相应的改动。这确实有点麻烦,所以感觉这个模式有点尴尬。

二 哨兵模式

这个模式呢,和主从模式有点像,他是基于主从模式的。他提供了对master的监控和故障转移,当master节点出现故障后,可以自动通过选举选出一台slave做master,待master故障恢复后,再切回来,这就大大提高了可用性了,且哨兵之间也可以做集群部署,相互监测。防止单个哨兵死掉的情况。

在redid-sentinel.conf

sentinel monitor mymaster 127.0.0.1 6379 1

上面的配置加上就行了,6379后面那个1表示需要几个哨兵节点同意后,才启动故障转移。

哨兵模式的启动模式有两种方式:

redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf --sentinel

因为哨兵模式也是一种特殊的Redis节点,所以可以使用redis-cli连接

redis-cli -p 26379

127.0.0.1:26379> info sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=odown,address=127.0.0.1:6379,slaves=1,sentinels=1

要求不高的场合下,其实哨兵模式一般的公司用就足够了。

三 集群模式

许多不同的主从实例组成大的集群,多主多从,一个主从实例死掉后,内部可以转到其它的主从实例上面。至少需要三个主节点才能让集群正常运行起来。

先配置几台机器出来,我本地用的伪集群模式,就是只有一台机器,然后用不同的端口来启动。

建立一个目录,比如叫redis-cluster。然后在这个目录下面建立6381-6386子目录。

在6381中建立配置文件redis.conf,内容如下:

daemonize yes

pidfile redis_6381.pid

logfile redis_6381.log

appendonly yes

bind 127.0.0.1

port 6381

cluster-enabled yes

cluster-config-file nodes-6381.conf

cluster-node-timeout 15000

cluster-slave-validity-factor 10

cluster-migration-barrier 1

cluster-require-full-coverage yes

其中cluster开头的这些,是集群的一些配置,同理,在其它目录也加上上面的配置,只不过,将6381换成相应的端口就行了。

然后再分别启动6381-6386的单实例

redis-server 6381/redis.conf

redis-server 6382/redis.conf

验证有无启动成功

ps -ef | grep redis

redis-server 127.0.0.1:6381 [cluster]

后面带[cluster]这个就表示行了。

上面只是启动了几台实例,要变成集群模式,还需要最后一步,使用redis-trib,不过我本地用的是redis5.0,已经推荐用redis-cli这种方式了,如果用redis-trib,这个还需要安装ruby环境。我这里就以redis-cli为例了

redis-cli --cluster create --cluster-replicas 1  127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385 127.0.0.1:6386

出现如下的输出,表示集群就创建成功了。

这个命令我简单说下,通过上面那个命令就可以将刚才我们的机器变成集群模式,且配置了主从。主要就是cluster-replicas后面那个1, 这个1表示主从实例的一个比值(主/从),比如上面的就是主从为1:1,那么6381-6383为主,6383为6381的从,其它依次类推。

测试一下,我这里用Go简单的试了下集群的设置和读取,用的是go-redis包。

package main

import (
   "fmt"
   "github.com/go-redis/redis"
   "time"
)

func testClient() {
   client := redis.NewClusterClient(&redis.ClusterOptions{
      Addrs:[]string{"127.0.0.1:6381","127.0.0.1:6382","127.0.0.1:6383","127.0.0.1:6384","127.0.0.1:6385","127.0.0.1:6386",},
   })
   statuscmd :=client.Set("name","lc",60 *  time.Second)
   if statuscmd.Err() != nil {
      fmt.Println(statuscmd.Err())
   }
   stringcmd :=client.Get("name")
   fmt.Println(stringcmd.String())
}

func main() {
   testClient()
}

到这里,几种模式的配置就完了,其实还是挺简单的,如果要深入了解更高级的,就自已去参照相应的文档了,我也是记录我的学习过程,更高级的也没有研究过。

原文地址:https://www.cnblogs.com/smartrui/p/12406178.html

时间: 2024-10-01 20:46:49

Redis的几种高可用集群方案的相关文章

Oracle的三种高可用集群方案

Oracle的三种高可用集群方案 主要有三种: 1. RAC RAC,  Real Application Clusters 多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储.这个系统可以容忍单机/或是多机失败. 不过系统内部的多个节点需要高速网络互连,基本上也就是要全部东西放在在一个机房内,或者说一个数据中心内.如果机房出故障,比如网络不通,那就坏了.所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要,重要业务需要多机房来容忍单个机房的事故

Redis安装、主从配置及两种高可用集群搭建

Redis安装.主从配置及两种高可用集群搭建 一.            准备 Kali Linux虚拟机 三台:192.168.154.129.192.168.154.130.192.168.154.131 用户名/密码:root/... ssh设置 修改sshd_config文件,命令为:vim /etc/ssh/sshd_config 将#PasswordAuthentication no的注释去掉,并且将NO修改为YES //kali中默认是yes 将PermitRootLogin wi

keepalived + nginx 实现高可用集群方案

keepalived + nginx 实现高可用集群方案 一.使用场景介绍: nginx做负载均衡,来达到分发请求的目的,但是不能很好的避免单点故障,假如nginx服务器挂点了,那么所有的服务也会跟着瘫痪 .keepalived+nginx,就能很好的解决这一问题. 二.原理介绍: Keepalived 是一种高性能的服务器高可用或热备解决方案,Keepalived 可以用来防止服务器单点故 障的发生,通过配合 Nginx 可以实现 web 前端服务的高可用. Keepalived 以 VRRP

keepalived实现高可用集群方案

一.keepalived和VRRP协议介绍 keepalived是基于vrrp协议实现的一个高可用集群解决方案,可以利用keepalived来解决单点故障问题,使用keepalived实现的高可用集群方案中,一般有两台服务器,一个是MASTER(主服务器),另一个是BACKUP(备用服务器),这个集群中对外提供一个虚拟IP,MASTER服务器会定时发送特定信息给BACKUP服务器,当BACKUP服务器接收不到MASTER发送的消息时,BACKUP服务器会接管虚拟IP,继续提供服务. VRRP协议

Linux高可用集群方案之配置heartbeat v2基于crm+hb_gui接口,配置高可用httpd,mysql,lvs

本章主要配置heartbeat v2基于crm+hb_gui接口,配置高可用httpd,mysql,lvs. 如何安装heartbeat v2.httpd.nfs.配置心跳连接.ssh密钥通信.同步时间.添加名称解析.配置yum源等请参照: >> Linux高可用集群方案之配置heartbeat v2基于haresources配置文件的httpd高可用集群 http://ccschan.blog.51cto.com/11854461/1922966  ll  本文导航    · 前期准备及相关

ProxySQL Cluster 配置详解 以及 高可用集群方案部署记录(完结篇)

早期的ProxySQL若需要做高可用,需要搭建两个实例,进行冗余.但两个ProxySQL实例之间的数据并不能共通,在主实例上配置后,仍需要在备用节点上进行配置,对管理来说非常不方便.但是ProxySQl 从1.4.2版本后,ProxySQL支持原生的Cluster集群搭建,实例之间可以互通一些配置数据,大大简化了管理与维护操作. ProxySQL是一个非中心化代理,在拓扑中,建议将它部署在靠近应用程序服务器的位置处.ProxySQL节点可以很方便地扩展到上百个节点,因为它支持runtime修改配

Redis Cluster 4.0高可用集群安装、在线迁移操作记录

之前介绍了redis cluster的结构及高可用集群部署过程,今天这里简单说下redis集群的迁移.由于之前的redis cluster集群环境部署的服务器性能有限,需要迁移到高配置的服务器上.考虑到是线上生产环境,决定在线迁移,迁移过程,不中断服务.操作过程如下: 一.机器环境 1 2 3 4 5 6 7 8 9 10 11 12 13 迁移前机器环境 ----------------------------------------------------------------------

activemq+Zookeper高可用集群方案配置

在高并发.对稳定性要求极高的系统中,高可用的是必不可少的,当然ActiveMQ也有自己的集群方案.从ActiveMQ 5.9开始,ActiveMQ的集群实现方式取消了传统的Master-Slave方式,增加了基于ZooKeeper + LevelDB 的 Master-Slave 实现方式. 相关文章:范例项目: http://wosyingjun.iteye.com/blog/2312553 ActiveMQ的简单实用:http://wosyingjun.iteye.com/blog/2314

LVS+Heartbeat 高可用集群方案操作记录

Heartbeat 项目是 Linux-HA 工程的一个组成部分,它实现了一个高可用集群系统.心跳服务和集群通信是高可用集群的两个关键组件,在 Heartbeat 项目里,由 heartbeat 模块实现了这两个功能. Heartbeat的高可用集群采用的通信方式是udp协议和串口通信,而且heartbeat插件技术实现了集群间的串口.多播.广播和组播通信.它实现了HA 功能中的核心功能——心跳,将Heartbeat软件同时安装在两台服务器上,用于监视系统的状态,协调主从服务器的工作,维护系统的