数据库操作——redis
- redis介绍
- Redis、Mamcache/MongoDB对比
- 分布式数据库的CAP原理
- redis的下载和安装
- 安装之后的操作
- key操作
- 数据类型
- 字符串命令 string
- 列表 list
- 集合set
- 哈希hash
- Zset 有序集合
- 持久化
- RDB相关的配置
- AOF相关的配置
- 开启AOF
- 共存
- AOF 相关的配置
- 总结
- 事务
- 定义和执行
- 事务的监控(watch)
- 事务的订阅
- 主从复制
- 一主二仆
- 主机的血脉相传
- 谋权篡位
- redis复制的原理
- 哨兵模式
redis介绍
- 互联网的需求有三高:高并发、高可扩、高性能
- redis是一种运行速度快,并发性很强,并且运行在内存的NoSql(not only sql)的数据库
- 和传统数据库相比:
-
- NoSql数据库无需实现为要存储的数据建立字段,随时都可以存储自定义的数据格式
-
- 而在关系型数据库中,增删改是一件很麻烦的事情,如果非常大数据量的表,增加字段简直是一个噩梦
- redis经常使用的场景:
-
- 缓存:这是redis当今最熟为人知的使用场景,一些要经常被访问的数据放在redis的原因是:redis在内存中可以得到很高效的访问
-
- 排行榜:利用redis中的sortSet(有序集合)数据结构,就可以很简单的搞定
-
- 计算器/限速器:利用redis原子性的自增操作,可以统计用户点赞数,访问数的统计
-
- 好友关系:利用集合的一些命令,例如交集,并集,差集等,可以搞定共同好友、共同爱好
-
- 简单消息队列:除了redias自身的发布订阅模式,也可以利用list来实现队列机制
-
- sdession共享:以jsp为例,采用redis保存session后,无论用户在那台机器上都能够获取到对应的session信息
Redis、Mamcache/MongoDB对比
- 这三个都是NoSql数据库
- redis和Mamcache:
-
- Redis和Mamcache都是内存数据库,不过Mamcache还可用于缓存其他东西,例如图片和视频
-
- Mamcache数据结构单一(kv键值对),redis更丰富一些,还提供list、set、hash等数据结构的存储,有效减少网络I/O(输入输出)的次数
-
- 虚拟内存——当redis的物理内存用完时,可以讲一些很久没有用到的value放到磁盘
-
- 存储数据安全,Mamcache挂掉之后,数据就没了,没有持久化机制,redis可以定期保存到磁盘(持久化)
-
- 灾难恢复——Mamcache挂掉之后,数据不可恢复,redis数据随时后,可以通过RBD或者AOF恢复
- redis和MongoDB:
-
- redis和MongoDB并不是竞争关系,更多的是一种协作共存的关系
-
- MongoDB本质上还是硬盘数据库,在复杂查询时仍然会有大量的资源消耗,而且在处理复杂逻辑时,依然不可避免的要进行多次查询
-
- 这个时候就需要redis或者Mamcache这样的内存来作为中间层缓存加速
-
- 例如某些复杂的场景中,这个页面的数据如果从MongoDB中查询,可能需要十几个查询语句,耗时会很长,如果需求允许,则可以将整个页面的对象缓存至redis中,定期更新,这样MongoDB和redis就能够很好的协作
分布式数据库的CAP原理
- 传统型数据库的特性是:ACID,即原子性,一致性,独立性,持久性
- 分布式数据库的CAP:
-
- C:强一致性,即更新操作成功并返回客户端后,所有节点在同一时间的数据完全一致
-
- A:高可用性,即服务一直可用
-
- P:分区容错性,即分布式系统在遇到某个节点或者网络分区故障的时候,仍然能够对外提供满足一致性或者可用性的服务
- 总结:
-
- CAP理论提出就是针对分布式环境的,所以AP这个属性必须容忍他存在的,也是必须的
-
- 分区是常态,不可避免,三者不能共存
-
- 可用性和一致性是一对冤家,可用性高,一致性低;可用性第,一致性就高
-
- 因此,根据CAP原理将NoAql数据库分成满足CA原则,满足CP原则和满足AP原则三大类
-
-
- CA:单点集群,满足一致性,可用性的系统,通常在扩展性上不太强大(非分布式)
-
-
-
- CP:满足一致性、分区容忍的系统,通常性能不是特别高
-
-
-
- AP:满足可用性,分区容忍性的系统,通常可能对一致性要求低一些
-
redis的下载和安装
- 下载,官网下载
- 图形化工具:官网下载安装
- linux安装:
-
- 将安装包放在linux服务器上
-
- 先解压压缩包
tar -zxvf redis-5.0.4.tar.gz
- 先解压压缩包
-
- 安装gcc(必须有网络),
yum -y install gcc
,忘记是否安装的话,可与你使用gc -v
命令查看
- 安装gcc(必须有网络),
-
- 进入redis目录,进行编译:
make
- 进入redis目录,进行编译:
-
- 编译之后,可是安装,`make install
安装之后的操作
- redis默认不会使用后台运行,如果需要需要修改配置文件
- redis中默认16个库,在配置文件中可以看到,搜索databases,即可查看
vim /opt/redis-5.0.4/redis.conf
#搜索daem
将daemonize no 改为 daemonize yes
#修改后启动文件,进入 /user/local/bin 目录下,执行
redis -sever /opt//redis-5.0.4/redis.conf
#其他操作
redis -cil shutdown #单实例关闭数据库
redis -cil -p 6379 shutdown #多实例关闭数据库
netstat -lntp |grep 6379 #常用操作,检测6379端口是否在监听
ps -ef |grep redis #检测后台程序是否存在
- 端口为什么是6379?
-
- 6379是手机按键上MERA对应的编码
-
- 而MERA长期以来被antirez(redis作者)及其朋友当做愚蠢的代码
- 连接redis并测试
redis -cil #链接redis ,在/user/local/bin 目录下
ping # 输入ping,返回pong,说明交互是成功的
set k1 china #键值对的形式,存储数据
get k1 #使用ger获得数据
redis-benchmart #测试redis性能,crtl+c,执行退出redis,最好执行5s就关闭,在linux中执行此命令
dbsize # 查看数据库键的数量
flushdb #清空当前数据库
flushall # 清空所有数据库(16个都清空,慎用)
select index #切换数据库,index的范围是0-15,可用tab键补齐
key操作
- 模糊查询key命令,有三个通配符
-
*
,通配任意多个字符
-
?
,通配单个字符
-
[]
,通配括号中的某个字符
- 判断和移动key
exists key #判断某个key是否存在(tab键会自动补全),返回1说明在,返回0 说明不在move key db #移动(剪切、粘贴)键到几号库
ttl key #查看键还有多久过期(-1,永不过期,-1,已过期)
time to live #还能活多久
expire key #为键设置过期时间
type key #查看键的数据类型
数据类型
- redis中有5种数据类型分别是:字符串,列表,zSet(有序集合)、set和哈希
字符串命令 string
set key value #向key中存数据value,如果key已存在,新输入的value会覆盖原数据
get key #根据key取数据
del key #删除key数据
append key value #向key中追加value数据
strlen key #获得key的长度
# ----------------加减操作,操作的必须是数字类型------------
incr key #给key+1
decr key #给key-1
incrby key num # 给key+num
decrby key num # 给key-num
#----------------类似于between……and---------
getrange key index1 index2 #获取index1和index2范围内的数据(左右皆包括)
setrange key insex value#向key的insex位置上插入value
#----------------添加数据同时判断---------
set key n value #给key添加value的同时设置n秒的生命周期
setnx key value # 添加时判断key对应的是否有值,有的话添加失败
#------------------其他方式的添加或获取----------------------
mset key1 value1 key2 value2 #一次性添加多组数据
mget key1 key2 #一次性获取很多数据
msetnx key1 value1 key2 value2 #添加时,一次性判断多个key是否存在,只要有一个存在,就添加失败
getset key value # 添加的时候返回key原本对应的值,然后再将新值写入
列表 list
- 正序:从上至下,从左至右,倒序:从下至上,从右至左
# ----------------给列表添加元素------------
lpush key list_value #向key中添加列表元素value,元素之间使用空格隔开,正序添加
rpush key list_value # 向key中添加列表元素value,元素之间使用空格隔开,倒序添加
lrange key 开始索引 结束索引 # 查看key列表指定索引下的元素,-1表示到结尾,一般从0号索引开始
# ----------------移除元素------------
lpop key # 正序移除key列表中的第一个元素
rpop key # 倒序移除key列表中的第一个元素
lrem key count value # 删除key中的count个value,返回信息为删除的个数
# ----------------下标查询和返回长度------------
lindex # 获取key列表中,第index个元素,正序查找
llen key # 获取指定元素的长度
ltrim key index1 index2 # 获得两个索引之间的数据,删除其他的元素,正序获得
# ----------------修改,链接,插入------------
rpoplpush key1 key2 # 将元素从key1中取出交给key2,左出右进§
lset key index value #在key列表,index的位置插入x
linsert key before/after index value
# 在key列表的index后/前,插入value
集合set
- set不允许重复
#-----------------添加/查看/判断------------
sadd key value #向set key中添加value,value重复时只添加一个
smembers key #查看set key中的数据
sismeber key value # 查看set key中是否存在value
#-----------------获得/删除/移除------------
scard key #查看set key中元素的个数
srem key value # 删除set key中,value这个元素
srandmember count # 从set key中随机获得count个元素
spop key # 随机移除set key中的元素
smove key1 key2 value # 随机从set key1中移动一个value到key2
#---------------数学集合类-----------------
sinter key1 key2 #查看set key1和key2的交集
sunion key1 key2#查看set key1和key2的并集
sdiff key1 key2#查看set key1中存在,key2中不存在的数据
哈希hash
- KV模式不变,但V是一个键值对
#-------------操作元素属性--------------
hset key hkey hvalue # 向哈希key中,添加hkey:hvalue的键值对
hget key hkey #获取哈希key中,hkey的value
hmset key hkey1 hvalue1 hkey2 hvalue2……
# 向哈希key中,添加hkey:hvalue,hkey2:hvalue2的多个键值对
hmget key hkey1 hkey2#获取哈希key中,hkey1、hkey2的value
hgetall key # 获取哈希 key下面所有键的值
hdel key hkey# 删除哈希 key下面hkey的键值对
#----------获得/自增/哦安段-------------
hlen key # 获取哈希key中,元素的数量
hexists key hkey # 判断哈希key中,hkey的元素是否存在
hkeys key # 获取哈希key中所有的元素的键(k)
hvals key #获取哈希key中,所有元素的值(v)
hincrby key hkey int
# 向哈希 key的hkey对应的值中,增加int,hkey对应的值必须是数字,返回增加后的数字
hincrbyfloat key hkey float # 向哈希 key的hkey对应的值中,增加float,hkey对应的值必须是数字,返回增加后的数字
hsetnx key hkey value # 判断哈希key中,hkey对应的元素是不是value
#在redis中输入汉字时,显示时会转换成unicode
Zset 有序集合
- Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员
- 不同的是每个元素都会关联一个 double 类型的分数
- redis 正是通过分数来为集合中的成员进行从小到大的排序
- 有序集合的成员是唯一的,但分数(score)却可以重复
- 以下例子中,c2比c1大
#--------------------添加、查询和删除------------------
zadd key v1 c1 v2 c3…… #向有序集合key中,添加v,v2等多个元素,其对应的分数是c1和c2
zrange key index1 index2
# 查询有序集合key中,index1和index2之间的元素,0,-1表示全部,返回所有的元素,不返回分数
zrange key index1 index2 withscores
# 查询有序集合key中,index1和index2之间的元素,0,-1表示全部,返回所有的元素和分数
zrangebyscore key v1 v2
# 查询有序集合key中,分数1和分数2之间的元素(包含v1和v2)
zrangebyscore key v1 (v2
# 查询有序集合key中,分数v1和分数v2之间的元素(不包含v2)
zrangebyscore key (v1 (v2
# 查询有序集合key中,分数v1和分数v2之间的元素(不包含v1、v2)
zrangebyscore key v1 v2 limit index count
# 从有序集合key中,分数v1和分数v2之间,跳过2个元素,再取两个元素
zrem key v1 # 在有序集合key中,删除v1的元素
#-------------------范围和逆序----------------------
zcard key # 查看有序集合key中元素个数
zcount key c1 c2 # 查看有序集合key中,分数在c1和c2之间有多少个元素
zrank key v1 # 查看有序集合key中,v1的下标(下标是从0开始),从上到下,从左至右
zscore key v1 # 获取有序集合key中,v1对应的分数
zrevrank key v1 #获取有序集合key中,v1对应的逆序下标,从下到上,从右至左
zrevrange key index1 index2 # 逆序查询有序集合key中,index1和index2之间元素
zrevrangebyscore key c2 c1# 逆序查询有序集合key中,分数大于c1小于c2的元素
持久化
- 定义:在指定时间间隔内,将内存中的数据集的快照写入磁盘
-
- 默认保存在/usr/local/bin中,文件名字为dump.rdb
- 自动备份
-
- redis是内存数据库,当我们每次用完redis,关闭linux是,按照道理来说,会释放内存,redis中的数据也会随之消失
-
- 在此启动redis数据没有消失的原因是:每次关机的时候,redis会自动备份数据到一个文件中,文件路径为:/usr/local/bin/dump.rdb
- 如何修改redis的自动备份策略?
-
vim /opt/redis-5.0.4/redis.conf /SNAP(搜索)
,修改如下图示的部分
- 使用shutdown关闭redis后,可以在/usr/local/bin目录下,看到dump.rdb自动保存
- 重新启动redis之后,在300s内保存10条数据,也会触发备份指令
- 存在备份的情况下,就可以将数据全部删除,再次shutdown关机
- 再次启动redis,就发现数据真的消失的,原因是:
-
- shutdown瑞出redis时,还会自动保存数据库,一旦执行,就会将原本保存包的备份文件给覆盖,因此自动恢复失败
- 如果说不在意重启之后,数据是否丢失,只是用缓存功能,就可以将上面截图中的倒数三行注释掉
- 如果要解决这个问题,就手动备份一个文件,关闭数据库之后,将之前备份的文件替换,重启数据库之后就有数据
- 立即备份,直接没有在退出redis之前,执行命令
save
即可
RDB相关的配置
- 下面是配置文件中的含义,路径: /opt/redis-5.0.4/redis.conf
- stop-writes-on-bgsave-error:进水口和出水口,出水口是否发生故障与否
-
- yes:当后台备份时发生错误,前台停止写入
-
- no:不管死活,就往死里怼
- rdbcompression:对存储在磁盘中的快照,是否启动LZF压缩算法,一般会启动,因为这点性能,多买一台电脑就搞定了
-
- yes:启动
-
- no:不启动,(不想消耗CPU的资源,可关闭)
- rdbchecksum:在存储快照之后,是否启动CRC64算法进行数据校验
-
- yes:开启之后,大约会增加10%左右的CPU消耗
-
- no:如果希望获得最大性能的提升,就选择关闭
- dbfilename:快照备份文件名字
- dir:快照备份文件保存的目录,默认为当前目录
- 优势和劣势:
-
- 优:适合大规模的数据恢复,对数据完整性和一致性要求不高
-
- 劣:一定间隔白粉依稀,意外down掉,就失去最后一次快照的所有修改
- 配置文件信息如下图(其中一个,剩余的自己找):
AOF相关的配置
- 以日志的形式记录每个写的操作
- 将redis执行过的写指令全部记录下来(读操作不记录)
- 只许追加文件,不可以改文件
- redis启动之初会从会读取改文件(从头到尾读),这样就会重新构建数据
开启AOF
- 1.为了避免失误,最好将redis的配置文件备份后,再修改内容如下:
# 在配置文件中,使用/appendonly搜索
appendonly yes
appendfilename appendonly.aof
- 2.重新启动redis,以新配置文件启动
-
- 命令:
redis -sever /usr/local/redis5.0.4/redis.conf
- 命令:
- 3.链接redis,加数据,删库,退出
- 4.查看当前文件夹是否多了一个aof文件,查看文件中的内容,保存的都是写操作(自己输入的命令)
-
- 文件最后一句要删除,否则数据恢复不了(要删除删库的命令)
-
- 编辑者这个文件,最好要使用
:wq!
强制执行
- 编辑者这个文件,最好要使用
- 5.只要重新链接,数据就恢复成功后
共存
- 如果查看redis.conf文件,发现AOF和RDB两种背备份策略都是开启的状态,选择方式为:
-
- 1.动手试试,编辑qppenonly.aof文件,胡乱编码,保存退出
-
- 2.启动redis失败,所以是AOF优先载入来恢复原始数据,因为AOF比RDB数据保存的完整性更高
-
- 3.修复AOF文件,杀光不符合redis的语法规范的代码:
redis-check -aof --fix appendonly.aof
- 3.修复AOF文件,杀光不符合redis的语法规范的代码:
AOF 相关的配置
- appendonly:开启AOF模式
- appendfilename:AO F的文件名字,最好别改
- appendfsync:追写策略
-
- always:每次数据变更,都会立即记录到磁盘,性能比较差,但数据完整性好
-
- everysec:默认设置,异步操作,美妙记录,如果前一秒当内宕机,会有数据丢失
-
- no:不追写
- no-appendfsync-on-rewrite:重写时,是否会运用Appendfsync追写策略,用默认no即可,保证数据安全性
-
- AOF采用文件追加的方式,文件会越来愈啊大,为了解决这个问题,增加了重写机制
-
- redis会自动记录上一次AOF的大小,当AOF文件大小达到预先设定的大小时,就会启动AOF文件进行内容压缩,只保留可以恢复数据的最小指令集合
- auto-aof-rewirite-percenttage:如果AOF的大小超过了原来的一倍,也就是100%,才进行压缩你
- auto-aof-rewrite-min-size:如果AOF的大小超过了64MB,菜重写压缩
总结
- RDB:只用作后备用途,建议15分钟备份一次即可
- AOF:
-
- 再最恶劣的情况下,也只丢失不超过2s的数据,数据完整性比较高,但代价也大,会带来持续的I/O
-
- 对硬盘大小的要求也高,默认64MB太小了,企业级最小在5G以上
-
- 后面药品学习的master/slave才是新浪微博的选择
事务
定义和执行
- 可以一次执行多个命令,是一个命令组
- 一个事务中,所有命令都会序列化(排队),不会被插队
- 一个队列中,一次性,顺序性,排他行的执行一系列的命令
- 三特性:
-
- 隔离性:所有命令都会按照顺序执行,事务执行过程中不会被其他客户端送来的命令打断
-
- 没有隔离级别,队列中的命令没有提交之前,都不会被实际的执行,不存在“事务中查询要看到事务里的更新,事务外的查询不能看到”这个头疼的问题
-
- 不保证原子性,冤有头,债有主,如果一个命令失败,但是别的命令可能会执行成功,没有回滚
-
-
- 如果一个命令在加入事务在提交的时候报错,真个事务不会被执行
-
-
-
- 但是,如果事务在提交的时候没有报错,执行的时候报错,redis会跳过报错的命令,执行后续的命令,也就是说,redias只实现了部分事务
-
- 三步走:
-
- 开启multi
-
- 入队queued
-
- 执行exec
- 与关系型数据库相比:
-
- multi:可以理解成关系型事务的begin
-
- exec:可以理解为关系型事务的commit
-
- discard:可以理解为关系型事务的rollback
- 事务的特征:
-
- 一起生:开启事务,加入队列,一起执行,并成功
-
- 一起死:放弃之前的操作,回复到原来的值
- 一起死:放弃之前的操作,回复到原来的值
-
- 一句报错,全部取消,回复称原来的值
- 一句报错,全部取消,回复称原来的值
-
- 追究责任,谁的错找谁
- 追究责任,谁的错找谁
事务的监控(watch)
- 语法结构:
watch key
,key为输入数据的时候,设置的键 - 补充:
unwatch
,取消watch命令对所有key的操作,需要在exec之前执行 -
- 因为一旦执行了exec或者DISCARD命令,之前添加的监控就会失效
- 在执行事务之前,使用并发的方式修改了监控in的数据(另外一个窗口,也可以理解为线程)
- 再去执行事务的时候,会打断事务的执行,导致执行失败
- 整个过程相当于乐观锁,
-
- 多线程操作数据的时候,在事务提交时,如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改,则使用EXEC执行事务时,事务队列将不会被执行
-
- 同时返回Nullmulti-bulk应答以通知调用者事务执行失败。
- 同时返回Nullmulti-bulk应答以通知调用者事务执行失败。
事务的订阅
- 进程之间的一种通信模式,发送者发送消息,订阅者接受消息
- 订阅一个或者多个频道
- 效果:订阅某个频道或者作者之后,频道或作者下每新增一篇文章,订阅者都会收到通知
- 语法结构:
subscribe key1 key2 key3……
主从复制
- 是redis的集群策略
- 配从(库)不配主(库):小弟可以选择大风歌,但是大哥没有权限选择小弟
- 读写分离:主机写,从机读
一主二仆
- 1.准备三台服务器,并修改redis.conf
-
- 三台全部修改,配置文件的含义是,允许哪台机器访问
- 设置代码如下:
vim /opt/redis-5.0.4/redis.conf
#然后搜索bind
/bind
#修改服务器地址为0.0.0.0,如下图
- 2.启动三台redis,并查看每台机器的角色,都是master
-
- 在三台服务器上启动redis,使用
info replication
查看角色,截图如下:
- 在三台服务器上启动redis,使用
- 3.测试开始
-
- 首先,将三台机器都清空,第一台添加值,例如:
mset k1 v1 k2 v2
- 首先,将三台机器都清空,第一台添加值,例如:
-
- 其余两台机器,复制,使用命令:
slaveof ip 端口号
- 其余两台机器,复制,使用命令:
-
- 第一台机器再添加值,例如:
mset k1 v1 k2 v2
- 第一台机器再添加值,例如:
- 命令示例图如下:
- 复制数据之后,主机和从机再次查看角色时,他的信息如下:
- 复制之后:
-
- 从机可自动从主机中复制主机中获取复制之前存储的数据
-
- 主机存储数据之后,从机也可立刻同步
-
- 从机不可写入数据,只能读取数据,这就是读写分离
-
- 主机shutdown,从机仍是slave且可使用,但是查看角色的时候,显示主机下线
-
- 主机重启,从机仍然slave,查看角色时显示主机已在线
-
- 从机死了,主机仍是master,小弟少了一个
-
- 从机死了之后归来,主机和没有问题的从机没有变化,但归来的从机会自立门户,其身份变成了master,不和原来的集群在一起
主机的血脉相传
- 一个主机里淋上可以有多个从几,但是这样的话,主机会很累
- 我们可以使用java面向对象继承中的传递性来解决这个问题,减轻主机的负担
- 我们可以将其他的redis服务器加在从机上,形成树形结构,他就会复制从机的数据
- 例如下图:
- 关联之后,主机输入数据,从机1复制主机的数据,从机2复制从机1的数据
谋权篡位
- 1个主机,2个主机的跟随从机,如果主机挂掉了;
-
- 只能从从机中选择一个当主机,剩余的从机跟随新主机
- 手动将从机变为主机
slaveof no one
-
- 手动将另外一台主机的跟随变为新主机
- 手动将另外一台主机的跟随变为新主机
- 如果原本的主机重新启动,那么原本挂掉的主机就没有小弟了,只是身份是主机而已
redis复制的原理
-
slave启动并成功链接到master之后,发挥送一个sync(同步)命令;
-
master接收到命令之后,会启动后台存盘进程,同时会搜集所有修改的命令集,待在后台执行完毕之后,master会一次性将这个数据文件传送给slave,以完成后一次同步
-
完成了上面的步骤之后,就完成了从服务器数据初始化的全部行为,从服务器此时可以接受来自用户的请求
-
全量复制:slave接收到数据文件之后,存盘并姐在到内存中
-
增量复制:master将搜集到修改命令依次传给slave,完全同步
-
但是,只要是重新链接master,一次性(全量复制)同步将自动执行
-
redis朱总同步策略:
-
- 总从刚刚链接的时候,进行全量同步
-
- 全同步结束之后,进行增量同步
-
- 当然,如果需要,slave在任何时候都可以发起全量同步
-
- redis的策略是:首先会尝试进行增量同步,如果不成功,要求从机进行全量同步
哨兵模式
- 自动版的篡权夺位
- 场景:有个哨兵在巡逻,突然发现老大挂了,小弟们自动投票,从中小弟中选出新的老大
- Sentinel是Redis的高可用性解决方案:
-
- 由一个或者多个Sentinel实例组成的Sentinel系统可以监听任意多个主服务器以及所有的从服务器
-
- 并且在被监视的主服务器进入下线状态时,自动将下线主服务器的树下的某个从服务器升级为新的主服务器
-
- 然后由新的主服务器代替已下线的主服务器继续处理命令请求
- 设置方法:
-
- 三台服务器,1主2从
-
- 每台服务器中创建一个配置文件:sentinel.conf,名字绝不能错;编辑sentinel.conf
#sentinel monitor 被监控主机名(自定义) ip 端口号 票数
sentinel monitor redis141 192.168.204.141 6479 1
# 讲着计划写入sentinel.conf文件中即可
-
- 启动服务的顺序 主redis ——从redis ——Sentinel1/2/3
-
- 启动命令是:redis- sentinel sentinel.conf
- 主机shutdown,从机进行激烈的投票
- 查看最后权利的分配
- 如果之前挂掉的主机重启的话:
-
- 自己成为了master和新主机平起平坐
-
- 过了几秒后,Sentinel会进行身份 转换,变为从机
- 这种方式的缺点:
-
- 由于所有的写操作都是在master上进行的
-
- 然后同步到slave上,因此两台机器之间的信号会有延迟
-
- 当系统很繁忙的时候,延迟问题会加重
-
- slave机器数量增加,问题也会加重