musql 关系型数据库
非关系型数据库redis mongodb
nosql不仅仅是
redis-cli ping pong
NoSQL
学名(not only sql)特点:存储结构与mysql这一种关系型数据库完全不同,nosql存储的是KV形式nosql有很多产品,都有自己的api和语法,以及业务场景产品种类:MongodbredisHbase hadoop
Nosql和sql的区别
应用场景不同,sql支持关系复杂的数据查询,nosql反之sql支持事务性,nosql不支持
redis优势
性能高,读取速度10万次每秒写入速度8万次每秒所有操作支持原子性用作缓存数据库,数据放在内存中替代某些场景下的mysql,如社交类app大型系统中,可以存储session信息,购物车订单
redis缺点
缺点是:断电释放内存数据,redis数据丢失,redis进程挂掉,数据丢失,redis提供了持久化机制
yum安装redis
1.yum安装
#前提得配置好阿里云yum源,epel源#查看是否有redis包yum list redis#安装redisyum install redis -y#安装好,启动redissystemctl start redis
2.检测redis是否工作
redis-cli #redis 客户端工具#进入交互式环境后,执行ping,返回pong表示安装成功127.0.0.1:6379> pingPONGredis-cli -p 端口号 -h ip地址 -a 密码
源码安装redis,编译安装
1.下载redis源码wget http://download.redis.io/releases/redis-4.0.10.tar.gz2.解压缩tar -zxf redis-4.0.10.tar.gz3.切换redis源码目录cd redis-4.0.10.tar.gz4.编译源文件make 5.编译好后,src/目录下有编译好的redis指令6.make install 安装到指定目录,默认在/usr/local/bin
redis可执行文件
./redis-benchmark //用于进行redis性能测试的工具./redis-check-dump //用于修复出问题的dump.rdb文件./redis-cli //redis的客户端./redis-server //redis的服务端./redis-check-aof //用于修复出问题的AOF文件./redis-sentinel //用于集群管理
redis配置文件
redis配置文件名为redis.conf 这个文件可以自定义
redis配置文件
绑定ip,如需要远程访问,需要填写服务器ipbind 127.0.0.1 端口,redis启动端口port #加端口号 守护进程方式在后台运行daemonize yesrdb数据文件dbfilename dump.rdb数据文件存放路径dir /var/lib/redis/日志文件logfile /var/log/redis/redis-server.log主从复制slaveof #加要从的ip和端口号requirepass #密码
redis的数据结构
redis是一种高级的key:value存储系统,其中value支持五种数据类型字符串(strings)散列(hashes)列表(lists)集合(sets)有序集合(sorted sets)
基本命令
keys * 查看所有keytype key 查看key类型expire key seconds 过期时间ttl key 查看key过期剩余时间 -2表示key已经不存在了persist 取消key的过期时间 -1表示key存在,没有过期时间exists key 判断key存在 存在返回1 否则0del keys 删除key 可以删除
数据结构类型
1.strings类型
应用场景:
string是最常用的一种数据类型,普通的key/value存储都可以归为此类,即可以完全实现目前Memcached的功能,并且效率更高,还可以享受redis的定时持久化,操作日志及replication等功能,除了提供与Memcached一样的get.set.incr,decr等操作外,还提供了下面一些操作:获取字符串的长度往字符串append内容设置和获取字符串的某一段内容设置及获取字符串的某一位批量设置一系列字符串的内容
实现方式:
string是二进制安全的,意思是redis的string可以包含任何数据类型,比如jpg图片或者序列化的对象

-
O(1)时间复杂度获取字符串长度,未用长度,已用长度
-
预分配机制,减少内存在分配次数
-
惰性删除机制,字符串缩减长度后的空间不释放,作为预分配保留
string在redis內部存储都默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值进行计算,此时redisObject的encoding字段为int
set 设置keyget 获取keyappend 追加stringmset 设置多个键值对mget 获取多个键值对del 删除keyincr 递增+1decr 递减-1
2.list类型
简介:
list是按照插入顺序排序的字符串链表,可以在头部和尾部插入新的元素(双向链表实现,两端添加元素的时间复杂度为O(1).插入元素时,如果key不存在,redis会为该key创建一个新的链表,如果链表找那个所有的元素都被移除,该key也会从redis中移除
数据类型:

常见操作时用lpush在list头部插入元素,用rpop在list尾部取出数据
应用场景:
-
消息队列
-
redis的list数据类型对于大部分使用者来说,是是实现队列服务的最经济最简单的方式
-
-
最新内容
-
应为list结构的数据查询两端附近的数据性能非常好,所以适合一些需要获取最新数据的场景,比如新闻应用中的'最近新闻';
-
优化建议
list是链表结构,所有如果在头部和尾部插入数据,性能会非常高,不受链表长度的影响;单如果在链表中插入数据,性能就会越来越差
方法:
lpush 从列表左边插rpush 从列表右边插lrange 获取一定长度的元素 lrange key start stopltrim 截取一定长度列表lpop 删除最左边一个元素rpop 删除最右边一个元素lpushx/rpushx key存在则添加值,不存在不处理
3.sets集合类型
redis的集合,是一种无序的集合,集合中的元素没有先后顺序。
set集合不允许数据重复,如果添加的输在在set中已经存在,将只保留一份.
set类型提供了多个set之间的聚合运算,如求交集,并集,补集,这些操作在redis内部完成,效率很高.
数据模型

应用场景
set类型的特点是----不重复无序的一组数据,并且具有丰富的计算功能,在一些特定的场景中可以高效的解决一般关系型数据库不方便做的工作
-
共同好友列表
-
社交类应用中,获取两个人或多个人的共同好友,两个人或多个人共同关注的微博这样类似的功能,用 MySQL 的话操作很复杂,可以把每个人的好友 id 存到集合中,获取共同好友的操作就可以简单到一个取交集的命令就搞定。
-
// 这里为了方便阅读,把 id 替换成姓名sadd user:wade james melo paul kobesadd user:james wade melo paul kobesadd user:paul wade james melo kobesadd user:melo wade james paul kobe// 获取 wade 和 james 的共同好友sinter user:wade user:james/* 输出: * 1) "kobe" * 2) "paul" * 3) "melo" */ // 获取香蕉四兄弟的共同好友 sinter user:wade user:james user:paul user:melo /* 输出: * 1) "kobe" */ /* 类似的需求还有很多 , 必须把每个标签下的文章 id 存到集合中,可以很容易的求出几个不同标签下的共同文章; 把每个人的爱好存到集合中,可以很容易的求出几个人的共同爱好。 */
方法
sadd/srem 添加/删除 元素sismember 判断是否为set的一个元素smembers 返回集合所有的成员sdiff 返回一个集合和其他集合的差异sinter 返回几个集合的交集sunion 返回几个集合的并集
4.有序集合
用来保存需要排序的数据,例如排行榜,成绩,工资等。
在set的基础上给结合中的每个元素关联了一个分数,往有序集合中插入数据时会自动根据这个分数排序
应用场景
在集合类型的场景上加入排序就是有序集合的应用场景了,比如根据好友亲密度排序显示好友列表
// 用元素的分数(score)表示与好友的亲密度zadd user:kobe 80 james 90 wade 85 melo 90 paul// 根据“亲密度”给好友排序zrevrange user:kobe 0 -1/** * 输出: * 1) "wade" * 2) "paul" * 3) "melo" * 4) "james" */ // 增加好友的亲密度zincrby user:kobe 15 james// 再次根据“亲密度”给好友排序zrevrange user:kobe 0 -1/** * 输出: * 1) "james" * 2) "wade" * 3) "paul" * 2) "melo" */ //类似的需求还出现在根据文章的阅读量或点赞量对文章列表排序
ZADD 向有序集合中添加ZREVRANGE 倒叙显示集合ZRAGE 正序显示ZREM 移除ZCARD 返回集合的基数
利用有序集合的排序,排序学生的成绩
127.0.0.1:6379> ZADD mid_test 70 "alex"(integer) 1127.0.0.1:6379> ZADD mid_test 80 "wusir"(integer) 1127.0.0.1:6379> ZADD mid_test 99 "yuyu"
排行榜,zreverange 倒叙 zrange正序
127.0.0.1:6379> ZREVRANGE mid_test 0 -1 withscores1) "yuyu"2) "99"3) "wusir"4) "80"5) "xiaofneg"6) "75"7) "alex"8) "70"
移除有序集合mid_test中的成员,xiaofeng给移除掉
127.0.0.1:6379> ZREM mid_test xiaofneg(integer) 1127.0.0.1:6379> ZRANGE mid_test 0 -1 withscores1) "alex"2) "70"3) "wusir"4) "80"5) "yuyu"6) "99"
返回有序集合mid_test的基数
127.0.0.1:6379> ZCARD mid_test(integer) 3
返回成员的score值
127.0.0.1:6379> ZSCORE mid_test alex"70"
zrank返回有序集合中,成员的排名。默认按score,从小到大排序。
127.0.0.1:6379> ZRANGE mid_test 0 -1 withscores1) "alex"2) "70"3) "wusir"4) "80"5) "yuyu"
5.哈希数据结构
哈希结构就是 k1 -> k1 : v1 如同字典 套字典 { k1 : { k2: v2 } } ,取出v2 必须 k1,取出k2
hashes即哈希。哈希是从redis-2.0.0版本之后才有的数据结构。
hashes存的是字符串和字符串值之间的映射,比如一个用户要存储其全名、姓氏、年龄等等,就很适合使用哈希。
应用场景:
在Memcached中,我们经常将一些结构化的信息打包成HashMap,在客户端序列化后存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。
我们简单举个实例来描述下Hash的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:用户ID为查找的key,存储的value用户对象包含姓名,年龄,生日等信息,如果用普通的key/value结构来存储,主要有以下2种存储方式:
第一种:
第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。
第二种:
第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是用户ID为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。
那么Redis提供的Hash很好的解决了这个问题,Redis的Hash实际是内部存储的Value为一个HashMap,并提供了直接存取这个Map成员的接口

key依然是用户的ID,value是一个Map,这个Map的key就是成员的属性名,value是属性值,这样对数据的修改和存储都可以直接通过其内部Map的key(Redis里称内部Map的key为field),也就是通过key(用户ID)+field(属性标签)就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题,
对比
hash数据类型在存储上述类型的数据时具有比string更灵活,更快的优势,具体的说,使用string类型存储,必然需要转换和解析json格式的字符串,即便不需要转换,在内存开销方面,还是hash占优势
hset 设置散列值hget 获取散列值hmset 设置多对散列值hmget 获取多对散列值hsetnx 如果散列已经存在,则不设置(防止覆盖key)hkeys 返回所有keyshvals 返回所有valueshlen 返回散列包含域(field)的数量hdel 删除散列指定的域(field)hexists 判断是否存在
edis hash是一个string类型的field和value的映射表语法 hset key field value hset news1 title "first news title" #设置第一条新闻 news的id为1,添加数据title的值是"first news title"hset news1 content "news content" #添加一个conntent内容hget news1 title #获取news:1的标题hget news1 content #获取news的内容hmget news1 title content #获取多对news:1的 值hmset news2 title "second news title" content "second Contents2" #设置第二条新闻news:2 多个fieldhmget news2 title content #获取news:2的多个值hkeys news1 #获取新闻news:1的所有keyhvals news1 #获取新闻news:1的所有值hlen news1 #获取新闻news:1的长度hdel news1 title #删除新闻news:1的titlehlen news1 #看下新闻news:1的长度hexists news1 title #判断新闻1中是否有title,不存在返回0,存在返回1
redis的发布订阅
Redis 通过 PUBLISH 、 SUBSCRIBE 等命令实现了订阅与发布模式。

发布/订阅 实验
PUBLISH channel msg 将信息 message 发送到指定的频道 channelSUBSCRIBE channel [channel ...] 订阅频道,可以同时订阅多个频道UNSUBSCRIBE [channel ...] 取消订阅指定的频道, 如果不指定频道,则会取消订阅所有频道 PSUBSCRIBE pattern [pattern ...] 订阅一个或多个符合给定模式的频道,每个模式以 * 作为匹配符,比如 it* 匹配所 有以 it 开头的频道( it.news 、 it.blog 、 it.tweets 等等), news.* 匹配所有 以 news. 开头的频道( news.it 、 news.global.today 等等),诸如此类PUNSUBSCRIBE [pattern [pattern ...]] 退订指定的规则, 如果没有参数则会退订所有规则PUBSUB subcommand [argument [argument ...]] 查看订阅与发布系统状态 注意:使用发布订阅模式实现的消息队列,当有客户端订阅channel后只能收到后续发布到该频道的消息,之前发送的不会缓存,必须Provider和Consumer同时在线。
发布订阅:
窗口1,启动两个redis-cli窗口,均订阅diantai 频道(channel)
[root@bogon redis-4.0.10]# redis-cli 127.0.0.1:6379> SUBSCRIBE ghlReading messages... (press Ctrl-C to quit)1) "subscribe"2) "ghl"3) (integer) 1
窗口2,启动两个redis-cli窗口,均订阅diantai 频道(channel)
[root@bogon redis-4.0.10]# redis-cli 127.0.0.1:6379> SUBSCRIBE ghlReading messages... (press Ctrl-C to quit)1) "subscribe"2) "ghl"3) (integer) 1
窗口3,启动发布者向频道 diantai发送消息**
[root@bogon redis-4.0.10]# redis-cli127.0.0.1:6379> PUBLISH ghl 'woshibaba'(integer) 2
最后窗口1和2查看发布消息
redis持久化RDB和AOF
redis持久化
Redis
是一种内存型数据库,一旦服务器进程退出,数据库的数据就会丢失,为了解决这个问题,Redis
提供了两种持久化的方案,将内存中的数据保存到磁盘中,避免数据的丢失。
RDB持久化
redis
提供了RDB持久化
的功能,这个功能可以将redis
在内存中的的状态保存到硬盘中,它可以手动执行。
也可以再redis.conf
中配置,定期执行。
RDB持久化产生的RDB文件是一个经过压缩的二进制文件,这个文件被保存在硬盘中,redis可以通过这个文件还原数据库当时的状态。
RDB(持久化)内存数据保存到磁盘在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)优点:速度快,适合做备份,主从复制就是基于RDB持久化功能实现rdb通过再redis中使用save命令触发 rdbrdb配置参数:dir /data/6379/dbfilename dbmp.rdb每过900秒 有1个操作就进行持久化save 900秒 1个修改类的操作save 300秒 10个操作save 60秒 10000个操作save 900 1save 300 10save 60 10000
redis持久化之RDB实践
1.启动redis服务端,准备配置文件
daemonize yesport 6379logfile /data/6379/redis.logdir /data/6379 #定义持久化文件存储位置dbfilename dbmp.rdb #rdb持久化文件bind 10.0.0.10 127.0.0.1 #redis绑定地址requirepass redhat #redis登录密码save 900 1 #rdb机制 每900秒 有1个修改记录save 300 10 #每300秒 10个修改记录save 60 10000 #每60秒内 10000修改记录
2.启动redis服务端
3.登录redis设置一个key
redis-cli -a redhat
4.此时检查目录,/data/6379底下没有dbmp.rdb文件
5.通过save触发持久化,将数据写入RDB文件
127.0.0.1:6379> set age 18OK127.0.0.1:6379> saveOK
redis持久化之AOF
AOF(append-only log file) 记录服务器执行的所有变更操作命令(例如set del等),并在服务器启动时,通过重新执行这些命令来还原数据集 AOF 文件中的命令全部以redis协议的格式保存,新命令追加到文件末尾。 优点:最大程序保证数据不丢 缺点:日志记录非常大
redis-client 写入数据 > redis-server 同步命令 > AOF文件
配置参数
AOF持久化配置,两条参数appendonly yesappendfsync always 总是修改类的操作 everysec 每秒做一次持久化 no 依赖于系统自带的缓存大小机制
1.准备aof配置文件 redis.conf
daemonize yesport 6379logfile /data/6379/redis.logdir /data/6379dbfilename dbmp.rdbrequirepass redhatsave 900 1save 300 10save 60 10000appendonly yesappendfsync everysec
redis 持久化方式有哪些?有什么区别?
rdb:基于快照的持久化,速度更快,一般用作备份,主从复制也是依赖于rdb持久化功能
aof:以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全,类似于mysql的binlog
redis的主从同步
1.redis和mysql都是支持多实例功能,基于配置文件区分,就是一个数据库单独的实例
环境准备
6379.conf
port 6379daemonize yespidfile /data/6379/redis.pidloglevel noticelogfile "/data/6379/redis.log"dbfilename dump.rdbdir /data/6379protected-mode no
6380.conf
port 6380daemonize yespidfile /data/6380/redis.pidloglevel noticelogfile "/data/6380/redis.log"dbfilename dump.rdbdir /data/6380protected-mode noslaveof 127.0.0.1 6379
2.分别启动2个redis实例
redis-server redis-6379.conf redis-server redis-6380.conf
3.登录数据库,查看两人之间的关系
登录6379数据库,输入如下命令127.0.0.1:6379> info replication6380数据库查看如下关系[root@s20 smredis]# redis-cli -p 6380 info replication
4.数据读写查看
在6379中是可以读写的redis-cli -p 6379 set name5 haoxiangxiake在6380中只能读不能写redis-cli -p 6380 get name5
5.主从复制故障恢复
作用:从库挂了无所谓,主库挂了得立即恢复主库,或者将从库切换为主库,继续工作
实验步骤:1.分别启动 6379 6380 6381 三个数据库实例,建立好主从关系2.杀死6379主库,此时6380 6381 群龙无首3.选择让6381为新的主库,就要去除6381的从的身份redis-cli -p 6381 slaveof no one #查看此时6381的身份redis-cli -p 6381 info replication4.此时将6380的主人改为6381redis-cli -p 6380 slaveof 127.0.0.1 6381
6.redis的哨兵,自动的主从故障切换
配置步骤
1.环境准备,准备3个redis数据库实例,分别是 6379 6380 6381
#redis-6379.conf port 6379daemonize yeslogfile "6379.log"dbfilename "dump-6379.rdb"dir "/var/redis/data/6379" #redis-6380.conf port 6380daemonize yeslogfile "6380.log"dbfilename "dump-6380.rdb"dir "/var/redis/data/6380" slaveof 127.0.0.1 6379 #redis-6381.conf port 6381daemonize yeslogfile "6380.log"dbfilename "dump-6380.rdb"dir "/var/redis/data/6381" slaveof 127.0.0.1 6379
2.分别启动三个redis数据库实例
1106 redis-server redis-6379.conf 1107 redis-server redis-6380.conf 1108 redis-server redis-6381.conf
3.准备三个redis-sentinel哨兵的配置文件
redis-sentinel-26379.confport 26379 dir /var/redis/data/26379logfile "26379.log"// 当前Sentinel节点监控 127.0.0.1:6379 这个主节点// 2代表判断主节点失败至少需要2个Sentinel节点节点同意// mymaster是主节点的别名sentinel monitor s20master 127.0.0.1 6379 2//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过30000毫秒30s且没有回复,则判定不可达sentinel down-after-milliseconds s20master 30000//当Sentinel节点集合对主节点故障判定达成一致时,Sentinel领导者节点会做故障转移操作,选出新的主节点,原来的从节点会向新的主节点发起复制操作,限制每次向新的主节点发起复制操作的从节点个数为1sentinel parallel-syncs s20master 1//故障转移超时时间为180000毫秒sentinel failover-timeout s20master 180000//让哨兵在后台运行daemonize yes#如下26380和26381的配置文件,仅仅是端口的不同,可以快速生成 redis-sentinel-26380.confredis-sentinel-26381.conf#生成命令如下 1119 sed "s/26379/26380/g" redis-26379.conf > redis-26380.conf 1121 sed "s/26379/26381/g" redis-26379.conf > redis-26381.conf
4.分别运行三个哨兵进程
#(保证sentinel的配置正确,否则,你在启动报错后,配置文件的内容发发生变化,这是个坑!!!!)#创建哨兵的数据文件夹 mkdir -p /var/redis/data/26380 mkdir -p /var/redis/data/26379 mkdir -p /var/redis/data/26381 #分别启动三个哨兵 redis-sentinel redis-26379.conf redis-sentinel redis-26380.conf redis-sentinel redis-26381.conf
5.检查redis的哨兵状态
redis-cli -p 26379 info sentinel#查看到如下参数,哨兵就正确了master0:name=s20master,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
6.杀死主库,检查从主状态发现,其中一个库以及称为主库。
redis-cluster集群
集群搭建
1.环境准备,6个redis数据库节点
也就是准备6个配置文件,6匹马redis-7000.confredis-7001.confredis-7002.confredis-7003.confredis-7004.confredis-7005.conf
#每个配置文件的内容,仅仅是端口的不同7000~7005#内容如下port 7000 #端口号daemonize yes #后台运行dir "/opt/redis/data/7000"logfile "7000.log"dbfilename "dump-7000.rdb"cluster-enabled yes #开启集群模式cluster-config-file nodes-7000.conf #集群内部的配置文件cluster-require-full-coverage no #redis cluster需要16384个slot都正常的时候才能对外提供服务,换句话说,只要任何一个slot异常那么整个cluster不对外提供服务。 因此生产环境一般为no
2.快速生成6个节点的配置文件
mkdir -p /opt/redis/data/{7000,7001,7002,7003,7004,7005}sed "s/7000/7001/g" redis-7000.conf > redis-7001.conf sed "s/7000/7002/g" redis-7000.conf > redis-7002.conf sed "s/7000/7003/g" redis-7000.conf > redis-7003.conf sed "s/7000/7004/g" redis-7000.conf > redis-7004.conf sed "s/7000/7005/g" redis-7000.conf > redis-7005.conf
3.启动6个redis节点(准备好了6匹马)
redis-server redis-7000.conf redis-server redis-7001.conf redis-server redis-7002.conf redis-server redis-7003.conf redis-server redis-7004.conf redis-server redis-7005.conf
4.马儿准备好了,分配槽位,开始放入数据,查看数据流向
Redis集群中有16384个hash slots,为了计算给定的key应该在哪个hash slot上,我们简单地用这个key的CRC16值来对16384取模。(即:key的CRC16 % 16384)
开启redis-cluster的集群功能,以及分配redis的slot槽位,基于ruby语言的脚本工具自动分配
1.下载ruby的解释器 wget https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.gz2.解压缩ruby的源码包 tar -zxvf ruby-2.3.1.tar.gz3.进入ruby的源码包目录,编译三部曲 cd ruby-2.3.1 ./configure --prefix=/opt/ruby231 make && make install 4.读取这个/etc/profilesource /etc/profile5.下载ruby操作redis的模块wget http://rubygems.org/downloads/redis-3.3.0.gem#安装ruby操作redis的模块gem install -l redis-3.3.0.gem 6.一键分配redis集群的槽位#查找一下这个命令的绝对路径find / -name redis-trib.rb#这个数字 1 代表,每个redis主库,只有一个redis从库 /opt/redis-4.0.10/src/redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:70057.开启了集群状态功能后,登录数据库,查看数据写入流向/opt/redis-4.0.10/src/redis-trib.rb add-node --slave 127.0.0.1:7003 127.0.0.1:70008.防止redis-cluster主节点故障,可以搭配 redis-cluster + redis-sentinel ,用哨兵检测主节点状态,当主节点宕机,自动切换从节点为新的主库 1.redis-sentinel配置方式如下,检测三个主节点7000 7001 7002 port 27379 dir "/var/redis/data" logfile "26379.log" sentinel monitor master1 127.0.0.1 7000 2 sentinel monitor master2 127.0.0.1 7001 2 sentinel monitor master3 127.0.0.1 7002 2 sentinel down-after-milliseconds master1 30000 sentinel down-after-milliseconds master2 30000 sentinel down-after-milliseconds master3 30000 sentinel parallel-syncs master1 1 sentinel parallel-syncs master2 1 sentinel parallel-syncs master3 1 sentinel failover-timeout master1 180000 sentinel failover-timeout master2 180000 sentinel failover-timeout master3 180000 2.启动哨兵,检测cluster的主节点 redis-sentinel redis-26379.conf 3.杀死redis-cluster的主节点,查看从节点状态(是否自动重启),可以运行多个从节点,保证数据安全