开发者社区> 技术小美> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

Redis详解(二)

简介:
+关注继续查看

一、redis认证
二、redis事务
三、Connection&server相关命令
四、Redis的发布与订阅//充当mq的功能
五、Redis持久化
六、redis复制
七、master-slave实现
八、sentinal哨兵
九、redis限制
十、redis性能测试
        
一、redis认证
redis认证:
    vim /etc/redis.conf 
        requirepass redispass //密码
    [root@node1 ~]# systemctl restart redis
    
    [root@node1 ~]# redis-cli -h 192.168.4.106
    192.168.4.106:6379> select 0
    (error) NOAUTH Authentication required.
    192.168.4.106:6379> auth redispass
    OK
    192.168.4.106:6379> select 0
    OK    
    
清空数据库
    flushdb:清空当前库
    flushall:清空所有库
    
二、redis事务
1.MULTI用来组装一个事务;
2.EXEC用来执行一个事务;
3.DISCARD用来取消一个事务;
4.WATCH用来监视一些key,一旦这些key在事务执行之前被改变,则取消事务的执行。

我们来看一个MULTI和EXEC的例子:
RDBMS的事务:一组相关操作,是原子性的:满足ACID :原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)
redis的事务:可以将多个命令绑定在一起,顺序执行。通过multi,exec,watch等命令实现事务功能;
    在事务执行过程中,redis不会中断当前事务去执行其他client的指令。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set ip 192.168.0.1
QUEUED
127.0.0.1:6379> set port 800 //放到队列中
QUEUED
127.0.0.1:6379> exec //一起执行
1) OK
2) OK
    
watch:在事务执行过程中,施加乐观锁 //不支持回滚
    在exec之前,监视 指定的数据key是否在 multi和exec之间发生修改操作,有变动则不予执行事务
    事务中关联的 键 的监视操作。    
    //乐观锁,只是看他是否被修该,一旦被修改了,就不予执行。在事务过程中仍然可以被修改
    
redis不支持回滚操作,这是和mysql事务最大的区别
    事务有10个操作,第5个命令错误。redis事务会忽略第5个错误,执行到最后。
    redis目标:简单、高效
    
    redis的原子性:事务队列中的任务,要么全部执行,要么全都不执行
    redis的一致性:在检查入队时的一致性,例如输入为错误命令 //语法级别
    redis的隔离性:单线程,在执行事务中,不会执行其他操作,但是可以接受用户请求到queue中
    redis的持久性:依赖于server是否启用持久化功能 
        rdb或者aof //快照和追加到文件    
        
示例:乐观锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
终端1:            
    127.0.0.1:6379> watch ip 
    OK
    127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> set ip 10.0.0.1
    QUEUED
    127.0.0.1:6379> get ip
    QUEUED
终端2:
    127.0.0.1:6379> set ip 172.16.100.1
    OK
    127.0.0.1:6379> get ip
    "172.16.100.1"
终端1:        
    127.0.0.1:6379> exec
    (nil)  //事务执行失败
     
redis的一致性************        
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set jsidfjd
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
redis的原子性************
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set ip 10.0.0.1
QUEUED
127.0.0.1:6379> set aa
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> exec    //因为有语法错误,因此都没有执行
(error) EXECABORT Transaction discarded because of previous errors.

三、Connection&server相关命令
help @connections

1
2
3
4
5
    auth:
    ping: 验证服务器是否在线
    echo “hello redis"
    quit:
    select:选择指定的DB

help @server 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
    bgsave:异步存储数据到disk
    client setname: 为连接设置名字 //只能为自己修改名字
    client getname :获取当前客户端的链接名
    client kill ip:port //kill client的一个连接
    client list :查看链接
    config get  //redis的多数配置都可以在运行时修改
    config set //配置file中的参数 ,可以在内存中修改
    config rewrite //在内存中修改的操作,写入到配置文件
     
    info //服务器的所有统计数据
    info Memory //指定只看内存信息
    info Cluster //获取指定section的内容
    config resetstat //重置info的所有数据
     
    dbsize:    限制所有的键的数量
     
    bgsave: //
    save:
    lastsave:获取最近一次成功保存到disk的 timestamp
     
    monitor:实时监控接受到的请求
    shutdown [nosave/save ]:同步所有数据到disk后,关闭
    slaveof :配置主从
    slowlog:管理慢查询日志
     
    sync:复制功能的内建命令 //同步master
    time:获取当前server时间

    
四、Redis的发布与订阅//充当mq的功能
发布与订阅:发布者在订阅者订阅之前的发布数据默认是收取不到的
redis的发布与订阅功能:(publish/subscribe)
    生产者把信息发布在指定频道上,订阅者从指定的频道去订阅自己关注的信息即可
        
    SUBSCRIBE:订阅一个或多个 队列/频道 
    unsubscribe 退订此前订阅的频道
    psubscribe "new.i[to]" //订阅2个频道
        psubscribe "new.*" //也可以
    
示例:发布与订阅

1
2
3
4
5
6
7
8
9
10
11
12
13
终端1:
    127.0.0.1:6379> SUBSCRIBE news  //可以同时订阅多个channel
    Reading messages... (press Ctrl-C to quit)
    1) "subscribe"
    2) "news"
    3) (integer) 1
终端2:
    127.0.0.1:6379> PUBLISH news hello
    (integer) 1
终端1:
    1) "message"
    2) "news"  //频道名
    3) "hello"     //内容

    
五、Redis持久化    
redis如何实现持久化
    redis默认工作在内存中
持久化
    SAVE:将数据同步保存到磁盘;
    BGSAVE:将数据异步保存到磁盘;
    LASTSAVE:返回上次成功将数据保存到磁盘的 UNIX 时戳;
    SHUNDOWN:将数据同步保存到磁盘,然后关闭服务。
    
持久化:RDB和AOF
RDB:snapshot,二进制格式,默认机制
    按事先定制的策略,周期性的将数据保存到disk中;数据文件默认为dump.rdb
    客户端也可使用save或bgsave密令启动快照保存机制。
        save:异步方式实现,在主线程中保存快照:在save过程中,其他所有client请求都是block的
            完整写入内存数据到disk,而不是增量的同步
        bgsave:异步background save,不会阻塞client请求,使用一个新的进程
AOF:append only file,把每个 写命令 追加到文件尾部。
    假如incr命令,执行100次,默认需要记录100次
    附加日志类型的持久化存储:问题:文件会变的越来越大,
    但是redis能够合并aof的持久化文件,bgrewriteaof 命令来实现。
    例如 set count=100,直接修改aof文件,用来节约空间
127.0.0.1:6379> dir //获取备份目录
    
==============================================================================    
    记录每一次写操作至指定的文件尾部实现持久化,当redis重启时,可重新执行文件中的命令在内存中重建数据库
        BGREWRITEAOF:aof文件重写,
    不会读取正在使用的AOF文件,而通过将内存中的数据以命令的方式保存到临时文件中,完成后替换原有的AOF文件来实现。
            
Redis在实现RDB模式时的实现方式:
    redis调用fork创建一个子进程,父进程继续处理client的请求,子进程负责将内存中的内容快照 到disk 中。
    linux有COW(copy on write)机制,子进程和父进程会共享相同的物理页面,
    当父进程要写请求时,os会为父进程创建一个副本,因此子进程所实现的保存,一定是时间点一致的数据。内核的特性。
        当子进程快照写入完成后,os会用副本覆盖源文件。然后子进程退出
    不足:一定会有一部分数据丢失,rdb保存的时间点之后的时间点会丢失
    
    RDB:
        SAVE 900 1 
        SAVE 300 10
        SAVE 60 10000 //周期性的工作机制。
        SAVE "" //关闭RDB功能
        
        stop-writes-on-bgsave-error yes //在持久化时
        rdbcompression yes //压缩rdb文件
        rdbchecksum yes//对rdb的镜像文件进行校验
        dbfilename dump.rdb 
        dir /var/lib/redis 
        
            //redis-cli> config get dir //可以获取配置
redis在实现AOF模式时的实现方式
    每一个命令发出后,直接追加到append到文件中 
    重建过程:redis父进程调用fork,启动一个子进程,子进程根据内存中现有的文件的数据,在临时文件中,写入一个数据库重建的命令。
        父进程继续处理client请求,client新的请求除了把命令写入到文件中,还要把新的命令缓存起来,放到缓存队列中,后续执行。
    当子进程把快照内容写入到新的AOF文件后,通知父进程,父进程会用新的AOF替换老的AOF文件,并把这个操作启动之后,新收到的请求命令,追加到新的AOF文件中
    默认每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中)
    
    1.redis主进程fork一个子进程
    2.子进程根据redis内存中的数据创建数据库重建命令序列于临时文件中
    3.父进程继续接受客户端请求,并且会把这些请求中的写操作继续追加到原来的AOF文件;额外地,这些新的写请求还会被放置于一个缓冲队列中
    4.子进程重写完成后通知父进程,父进程把缓冲中的命令写到临时文件中
    5.父进程用临时文件替换老的aof文件
AOF方式的另一个好处,我们通过一个“场景再现”来说明。某同学在操作redis时,不小心执行了FLUSHALL,导致redis内存中的数据全部被清空了,这是很悲剧的事情。不过这也不是世界末日,只要redis配置了AOF持久化方式,且AOF文件还没有被重写(rewrite),我们就可以用最快的速度暂停redis并编辑AOF文件,将最后一行的FLUSHALL命令删除,然后重启redis,就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇,这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了,那就无法通过这种方法来恢复数据了。    
但AOF方式也同样存在缺陷,比如在同样数据规模的情况下,AOF文件要比RDB文件的体积大。而且,AOF方式的恢复速度也要慢于RDB方式。
如果在追加日志时,恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整,也没有关系,redis提供了redis-check-aof工具,可以用来进行日志修复。    
    appendonly no //默认是关闭的
    appendfilename "appendonly.aof" //追加到哪个文件
    
    # appendfsync always //每次收到写请求,就执行操作
    appendfsync everysec //每s一次
    # appendfsync no //append的功能自行不会触发写操作,所有写操作都是提交给OS,由OS自行决定如何写。
            //由内核决定如何进行写操作
    no-appendfsync-on-rewrite no //yes:表示,对重写操作,对新写入的操作,不做fsync,而是暂存到队列中
    
    auto-aof-rewrite-percentage 100 //本次重新的aof文件是上次重新文件的2倍时,执行重写。
        (当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之100时就是2倍时触发Rewrite)
    auto-aof-rewrite-min-size 64mb //刚开始的时候,1个1s后,4个大于1的2倍,会发起重写操作,显然不合理,要设置最小aof文件大小
    aof-load-truncated yes        //
    
可以同时启动RDB和AOF,

注意:持久本身不能取代备份,还应该指定备份策略,对redis数据库及逆行定期备份
假如同时启用AOF和RDB    
    两个同时满足,需要重写
        bgsave和rewrite不会同时执行,redis只会让一个执行,为了避免过大的磁盘IO,逐个执行

RDB,简而言之,就是在不同的时间点,将redis存储的数据生成快照并存储到磁盘等介质上;
AOF,则是换了一个角度来实现持久化,那就是将redis执行过的所有写指令记录下来,在下次redis重新启动时,只要把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了。
其实RDB和AOF两种方式也可以同时使用,在这种情况下,如果redis重启的话,则会优先采用AOF方式来进行数据恢复,这是因为AOF方式的数据恢复完整度更高。
如果你没有数据持久化的需求,也完全可以关闭RDB和AOF方式,这样的话,redis将变成一个纯内存数据库,就像memcache一样。

六、redis复制
特点:    
    一个master可以有多个slave,一个slave也可以有自己的slave
    支持链式复制功能:
    master以非阻塞方式同步数据至slave//master会继续接受一个或多个slave的同步请求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
slaveof <masterip> <masterport>
masterauth <master-password>  //主redis设置了验证密码的话(使用requirepass来设置)
slave-read-only yes
repl-ping-slave-period 10  //slave默认每10s向master发送ping
repl-timeout 60  //设置ping超时时间,确保这个时限比repl-ping-slave-period的值要大,否则每次主redis都会认为从redis超时。
repl-disable-tcp-nodelay no  //主从同步时是否禁用TCP_NODELAY。开启:主redis会使用更少的TCP包和更少的带宽来向从redis传输数据。但是这可能会增加一些同步的延迟,大概会达到40毫秒左右。如果你关闭了TCP_NODELAY,那么数据同步的延迟时间会降低,但是会消耗更多的带宽
repl-backlog-size 1mb //同步队列长度。队列长度(backlog)是主redis中的一个缓冲区,在与从redis断开连接期间,主redis会用这个缓冲区来缓存应该发给从redis的数据。这样的话,当从redis重新连接上之后,就不必重新全量同步数据,只需要同步这部分增量数据即可。
repl-backlog-ttl 3600 //如果主redis等了一段时间之后,还是无法连接到从redis,那么缓冲队列中的数据将被清理掉。我们可以设置主redis要等待的时间长度。如果设置为0,则表示永远不清理。默认是1个小时。
slave-priority 100 //redis优先级,在主redis持续工作不正常的情况,优先级高的从redis将会升级为主redis。而编号越小,优先级越高。比如一个主redis有三个从redis,优先级编号分别为10、100、25,那么编号为10的从redis将会被首先选中升级为主redis。当优先级被设置为0时,这个从redis将永远也不会被选中。默认的优先级为100。
min-slaves-to-write 3 //redis提供了可以让master停止写入的方式,如果配置了min-slaves-to-write,健康的slave的个数小于N,mater就禁止写入。master最少得有多少个健康的slave存活才能执行写命令。这个配置虽然不能保证N个slave都一定能接收到master的写操作,但是能避免没有足够健康的slave的时候,master不能写入来避免数据丢失。设置为0是关闭该功能。
min-slaves-max-lag 10 //#延迟小于min-slaves-max-lag秒的slave才认为是健康的slave。
slave-serve-stale-data yes    //联系不到master之后,仍然使用过期数据
repl-diskless-sync no //当硬盘太慢的时候,启用该值 
repl-diskless-sync-delay 5 //延迟操作时间

    
当从redis失去了与主redis的连接,或者主从同步正在进行中时,redis该如何处理外部发来的访问请求呢?这里,从redis可以有两种选择:
    第一种选择:如果slave-serve-stale-data设置为yes(默认),则从redis仍会继续响应客户端的读写请求。
    第二种选择:如果slave-serve-stale-data设置为no,则从redis会对客户端的请求返回“SYNC with master in progress”,当然也有例外,当客户端发来INFO请求和SLAVEOF请求,从redis还是会进行处理。
    你可以控制一个从redis是否可以接受写请求。将数据直接写入从redis,一般只适用于那些生命周期非常短的数据,因为在主从同步时,这些临时数据就会被清理掉。自从redis2.6版本之后,默认从redis为只读。
只读的从redis并不适合直接暴露给不可信的客户端。为了尽量降低风险,可以使用rename-command指令来将一些可能有破坏力的命令重命名,避免外部直接调用。比如:
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
    
主从情况下的timeout:
1.以从redis的角度来看,当有大规模IO传输时。
2.以从redis的角度来看,当数据传输或PING时,主redis超时
3.以主redis的角度来看,在回复从redis的PING时,从redis超时    

七、master-slave实现
MONITOR:实时转储收到的请求; //master和slave之间进行的ping-pong也可以看到
    192.168.4.106 server
    192.168.4.109 slave
server: 
    bind 0.0.0.0 
    service redis resart //没有认证密码
slave:    
    bind 0.0.0.0 
    service redis resart     
    

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[root@node2 ~]# redis-cli -h 192.168.4.109
192.168.4.109:6379> SLAVEOF 192.168.4.106 6379
OK Already connected to specified master
192.168.4.109:6379> get ip
"172.16.100.1"
192.168.4.109:6379> config get slaveof
1) "slaveof"
2) "192.168.4.106 6379"    
192.168.4.109:6379> key * //查看所有的key
     
192.168.4.109:6379> config set masterauth "redispass" //slave通过auth进行认证
    注意:可以在同一个主机上启动多个redis,使用不同的端口接口
    如果主redis设置了验证密码的话(使用requirepass来设置),则在从redis的配置中要使用masterauth来设置校验密码,否则的话,主redis会拒绝从redis的访问请求。
     
192.168.4.106:6379> info Replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.4.109,port=6379,state=online,offset=575,lag=1
master_repl_offset:589
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:588
//默认slaveof 之后,slave将变成只读

        
八、sentinal哨兵
主从架构问题:主故障,从不会执行写操作
redis引入了sentinel哨兵机制。监控整个主从架构。
    [监控主机] //sentinel会在主node挂的时候,选取一个从作为主node
        
[master]    
-----------------------
[s1]    [s2]    [s3]
    
前端代理会向sentinal发起查询请求,获取新的master node
万一sentinal故障:或者sentinal联系不到master,因此sentinal可以做集群,例如3个sentinal节点,避免误判
    
sentinal只监控主的,从master获取从的配置信息,一旦主故障,则选一个从为主
sentinal:
    用于管理多个redis服务器实现HA
        监控
        通知
        自动故障转移
    
        流言协议[sentinal之间接受master是否下线的消息],投票协议[决定是否执行故障迁移,以及选取哪一个为主master]
    
redis-server --sentinal 在启动的时候,指定sentinal可以自己成为sentinal 服务器
    redis-sentinal /path/to/file.conf  //专用命令,配置文件
    
sentinal启动:
    1.sentinal初始化自身服务器,运行redis-server中专用于sentinal功能的代码
    2.初始化sentinal状态,根据给定的配置文件,初始化监控的master服务器列表
    3.创建连向master的连接
    
专用配置文件:
/etc/redis-sentinal.conf 专用配置文件
port 26379     
(1)sentinel monitor mymaster 127.0.0.1 6379 2 //监控的主节点
    mymaster是自己取名,master-name,可以不是主机名,随意
    2:quorum 法定票数,至少2票,才可以启动集群
    //该条目可以出现多个
(2)sentinel down-after-milliseconds mymaster 30000
    master多少时间联系不到后为 down 离线
(3)sentinel parallel-syncs mymaster 1
    刚设定为新master时,允许同时多少个slave发起同步请求
(4)sentinel failover-timeout mymaster 18000
    故障转移的超时时间。在3min内不能把该slave提升为master,则故障转移失败
(5)logfile /var/log/redis/sentinel.log    
    
setinal只需要知道master节点,从node,sentinal会从主node获取的
主观下线:一个sentinal发现master找不到了,认为其down了
客观下线: 所有sentinal都认为该master down,
    sentinal会每隔1s 探测 ping(pong)
    
常用命令:
    sentinal masters
    sentinal slaves master_name
    sentinal get-master-addr-by-namne master_name
    sentinal reset //清除所有状态
    sentinal failover master_name //强制故障转移
实现:
    启动三个redis
    1主,2从,1个sentinal,让主的下线然后查看效果 //取消认证功能
[root@node1 lib]# mkdir /etc/redis
[root@node1 lib]# cp /etc/redis.conf /etc/redis
[root@node1 lib]# cd /etc/redis
[root@node1 redis]# cp redis.conf redis.conf.2
[root@node1 redis]# cp redis.conf redis.conf.3
[root@node1 redis]# mkdir -pv /redis/{db1,db2,db3}
[root@node1 redis]# chown -R redis.redis /redis/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
(1)默认
    vim redis.conf 
bind 0.0.0.0
port 6379
logfile /var/log/redis/redis.log
pidfile /var/run/redis/redis.pid
daemonize yes //能够在后台运行
protected-mode no
(2)vim redis.conf.2
port 6380
bind 0.0.0.0
pidfile /var/run/redis/redis2.pid
logfile /var/log/redis/redis2.log    
dir /redis/db2
daemonize yes
protected-mode no
     
(3)    vim redis.conf.3
port 6381
bind 0.0.0.0
pidfile /var/run/redis/redis3.pid
logfile /var/log/redis/redis3.log    
dir /redis/db3
daemonize yes
protected-mode no
     
[root@node1 redis]# redis-server /etc/redis/redis.conf
[root@node1 redis]# redis-server /etc/redis/redis.conf.2
[root@node1 redis]# redis-server /etc/redis/redis.conf.3    
[root@node1 redis]# ss -tunl |grep -E "6379|6380|6381"
tcp    LISTEN     0      128       *:6379                  *:*                  
tcp    LISTEN     0      128       *:6380                  *:*                  
tcp    LISTEN     0      128       *:6381                  *:*       
     
6379为主,其他都是从

    
三个终端:
1.6379
[root@node2 ~]# redis-cli -h 192.168.4.106 -p 6379
192.168.4.106:6379> config set requirepass masterpass
192.168.4.106:6379> config set masterauth mastermaster
//在mater上set 添加新值,slave会立即看到

2.6380
[root@node2 ~]# redis-cli -h 192.168.4.106 -p 6380
192.168.4.106:6380> slaveof 192.168.4.106 6379
192.168.4.106:6380> config set masterauth masterpas //和master的requirepass一致
192.168.4.106:6380> keys *
1) "port"
2) "ip"
3) "mm"
4) "kk"
5) "nn"

3.6381
[root@node2 ~]# redis-cli -h 192.168.4.106 -p 6381
192.168.4.106:6381> slaveof 192.168.4.106 6379
192.168.4.106:6381> config set masterauth masterpass
192.168.4.106:6381> info Replication    
192.168.4.106:6380> keys *    
        
启动sentinal配置,只启动一个sentinal
192.168.4.109:
[root@node2 ~]# cp /etc/redis-sentinel.conf /etc/redis/
[root@node2 ~]# cd /etc/redis/
[root@node2 redis]# vim redis-sentinel.conf
1.port :当前Sentinel服务运行的端口
2.dir : Sentinel服务运行时使用的临时文件夹
3.sentinel monitor master001 192.168.110.101 6379 2:Sentinel去监视一个名为master001的主redis实例,这个主实例的IP地址为本机地址192.168.110.101,端口号为6379,而将这个主实例判断为失效至少需要2个 Sentinel进程的同意,只要同意Sentinel的数量不达标,自动failover就不会执行
4.sentinel down-after-milliseconds master001 30000:指定了Sentinel认为Redis实例已经失效所需的毫秒数。当实例超过该时间没有返回PING,或者直接返回错误,那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移:只有在足够数量的Sentinel都将一个实例标记为主观下线之后,实例才会被标记为客观下线,这时自动故障迁移才会执行
5.sentinel parallel-syncs master001 1:指定了在执行故障转移时,最多可以有多少个从Redis实例在同步新的主实例,在从Redis实例较多的情况下这个数字越小,同步的时间越长,完成故障转移所需的时间就越长
6.sentinel failover-timeout master001 180000:如果在该时间(ms)内未能完成failover操作,则认为该failover失败
7.sentinel notification-script <master-name> <script-path>:指定sentinel检测到该监控的redis实例指向的实例异常时,调用的报警脚本。该配置项可选,但是很常用     

[root@node2 redis]# egrep -v "^#|^$" redis-sentinel.conf 
sentinel monitor mymaster 192.168.4.106 6380 1 //有1个哨兵认为其故障,就确定故障
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 18000
sentinel auth-pass mymaster redispass
logfile "/var/log/redis/sentinel.log"
protected-mode no
daemonize yes     
sentinel auth-pass mymaster redispass //密码,没有密码,因此没有使用
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 192.168.2.103 6380
sentinel known-slave mymaster 192.168.2.103 6381  //生成的
    
[root@node2 redis]# redis-sentinel /etc/redis/redis-sentinel.conf    
[root@node2 ~]# redis-cli -h 192.168.4.109 -p 26379    
sentinel masters //查看master所在的node
sentinel slaves mymaster //查看从s

kill 主node进程 6379
info //查看新的master 变为 6380
sentinel master //可以看到
在 6381上
    info replication //查看master
重新启动master //6379

26379:info 端口仍然为6380
    sentinel slaves mymaster //原主依然为从

九、redis限制
maxclients 10000 //如果达到了此限制,redis会拒绝新请求,并发出“max number of clients reached”回应。
maxmemory <bytes> //一旦到达内存使用上限,redis将会试图移除内部数据,移除规则可以通过maxmemory-policy来指定。
    如果你的redis是主redis(说明你的redis有从redis),那么在设置内存使用上限时,需要在系统中留出一些内存空间给同步队列缓存,只有在你设置的是“不移除”的情况下,才不用考虑这个因素。
对于内存移除规则来说,redis提供了多达6种的移除规则。他们是:
1.volatile-lru:使用LRU算法移除过期集合中的key
2.allkeys-lru:使用LRU算法移除key
3.volatile-random:在过期集合中移除随机的key
4.allkeys-random:移除随机的key
5.volatile-ttl:移除那些TTL值最小的key,即那些最近才过期的key。
6.noeviction:不进行移除。针对写操作,只是返回错误信息。
无论使用上述哪一种移除规则,如果没有合适的key可以移除的话,redis都会针对写请求返回错误信息。

LRU算法和最小TTL算法都并非是精确的算法,而是估算值。所以你可以设置样本的大小。假如redis默认会检查三个key并选择其中LRU的那个,那么你可以改变这个key样本的数量。
maxmemory-samples 3

1
2
3
4
5
6
7
8
9
info memory: //实际占用内存
    used_memory:13490096 //数据占用了多少内存(字节)
    used_memory_human:12.87M //数据占用了多少内存(带单位的,可读性好)
    used_memory_rss:13490096  //redis占用了多少内存,常驻内存集
    used_memory_peak:15301192 //占用内存的峰值(字节)
    used_memory_peak_human:14.59M //占用内存的峰值(带单位的,可读性好)
    used_memory_lua:31744  //lua引擎所占用的内存大小(字节)
    mem_fragmentation_ratio:1.00  //内存碎片率
    mem_allocator:libc //redis内存分配器版本,在编译时指定的。有libc、jemalloc、tcmalloc这3种。

十、redis性能测试
redis-benchmark [option] [option value]
$ redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000
100个并发连接,100000个请求,检测host为localhost 端口为6379的redis服务器性能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
-h      指定服务器主机名        127.0.0.1
-p      指定服务器端口  6379
-s      指定服务器 socket
-c      指定并发连接数  50
-n      指定请求数      10000
-d      以字节的形式指定 SET/GET 值的数据大小   2
-k      1=keep alive 0=reconnect        1
-r      SET/GET/INCR 使用随机 key, SADD 使用随机值
-P      通过管道传输 <numreq> 请求      1
-q      强制退出 redis。仅显示 query/sec 
--csv   以 CSV 格式输出
-l      生成循环,永久执行测试
-t      仅运行以逗号分隔的测试命令列表。
-I      Idle 模式。仅打开 N 个 idle 连接并等待。

参考:
https://piaosanlang.gitbooks.io/redis/content/happy/section2.html
https://www.cnblogs.com/wyy123/p/6078593.html
https://yq.aliyun.com/articles/226052    
http://www.cnblogs.com/hjfeng1988/p/6144352.html
http://chong-zh.iteye.com/blog/2175166












本文转自MT_IT51CTO博客,原文链接:http://blog.51cto.com/hmtk520/2056357,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Redis - RedisShardedPoolUtil & RedisShardedPool
Redis - RedisShardedPoolUtil & RedisShardedPool
0 0
redis之(一)redis的简单介绍
[一]:概念 --->Redis是一个开源的,高性能的,基于键值对的缓存与存储系统 --->Redis数据库中的多有数据都存储在内存中,由于内存的读写速度远快于硬盘,一秒读写超过10万键值 --->Redis提供对数据持久化的支持,可以将内存中的数据异步写入硬盘。
578 0
Redis(四)初识Redis
Redis是一个非关系型远程内存数据库,由于操作都在内存中,所以Redis的速度非常快,性能十分强劲。 它可以存储键和5种不同类型的值之间的映射。可以帮助用户解决各式各样的问题,直接将数据自然的映射到这5种数据结构。 通过复制、持久化和客户端分片功能,可以将Redis拓展成为一个包含数百GB的数据库,除非非常高的并发量。
0 0
【Redis】Redis 初探
一 简介   Redis 是一款完全开源免费的高性能的key-value数据库,可以作为缓存,kv结构存储和队列,目前在互联网行业比较广泛使用。   Redis作为Key-value型数据库,它提供了Key-Value 映射关系。
761 0
Redis详解(一)冰叔带你了解Redis
Redis详解(一)冰叔带你了解Redis
0 0
redis 总结
redis是什么: Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can co...
612 0
Redis总结(一)
Redis 的全称是:Remote Dictionary.Server,本质上是一个 Key-Value 类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据 flush 到硬盘上进行保存。因为是纯内存操作,Redis 的性能非常出色,每秒可以处理超过 10 万次读写操作,是已知性能最快的Redis 的出色之处不仅仅是性能,Redis 最大的魅力是支持保存多种数据结构,此外单个 value 的最大限。
0 0
redis 的各种介绍
http://www.jb51.net/list/list_242_1.htm未来星开发团队--狒狒 QQ:9715234
452 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
Redis4.0解密
立即下载
Getting Rezdy to Use Redis wit
立即下载
阿里云Redis-读写分离
立即下载