1.事务操作 watch key1 key2//监视key1,key2是否变化 unwtach [key1 key2//取消监视 multi//开启事务 command command ... discard/exec//取消或者提交

注意:如果命令格式有误,exec会报错 如果命令格式不错,只是逻辑错,exec不执行正确的命令---需要程序员去负责

2.消息的发布与订阅

	 subscribe<------频道----------publish

subscribe news --订阅新闻频道 publish news 内容--发布新闻内容

适宜做在线聊天,消息推送

SUBSCRIBE channel [channel ...]

订阅给定的一个或多个频道的信息。

UNSUBSCRIBE [channel [channel ...]] 指示客户端退订给定的频道。

如果没有频道被指定，也即是，一个无参数的 UNSUBSCRIBE 调用被执行， 那么客户端使用 SUBSCRIBE 命令订阅的所有频道都会被退订

PUNSUBSCRIBE [pattern [pattern ...]]

指示客户端退订所有给定模式。 psubscreibe [pattern [pattern ...]] //可以指定模式 比如 psubscribe new*等

redis的持久化有两种方式：1.快照 2.aof

持久化的方式 持久化: 即把数据存储于断电后不会丢失的设备中,通常是硬盘.

常见的持久化方式: 主从:通过从服务器保存和持久化,如mongoDB的replication sets配置 日志:操作生成相关日志,并通过日志来恢复数据 couchDB对于数据内容,不修改,只追加,则文件本身就是日志,不会丢失数据.

redis----RDB快照持久化 rdb的工作原理:

每隔N分钟或N次写操作后, 从内存dump数据形成rdb文件, 压缩 放在备份目录 redis---参数配置 save 900 1 #刷新快照到硬盘中，必须满足两者要求才会触发，即900秒之后至少1个关键字发生变化。 save 300 10 #必须是300秒之后至少10个关键字发生变化。 save 60 10000 #必须是60秒之后至少10000个关键字发生变化。

stop-writes-on-bgsave-error yes #后台存储错误停止写。（主要保持数据的一致性，数据不一致将会导致很严重的后果，这个参数主要用于后台备份进程出错时,主进程停不停止写入?）

rdbcompression yes #使用LZF压缩rdb文件。(可以减小rdb文件的大小) rdbchecksum yes #存储和加载rdb文件时校验。（加校验保持数据的完整性，当redis重启导入rdb文件时会做校验）

dbfilename dump.rdb #设置rdb文件名。

dir ./ #设置工作目录，rdb文件会写入该目录。 rdb的最大缺点是容易丢失数据，如： 在2个保存点之间,断电, 将会丢失1-N分钟的数据 但优点也很明显 出于对持久化的更精细要求,redis增添了aof方式 append only file

1:每个命令重写一次aof? 2:某key操作100次,产生100行记录,aof文件会很大,怎么解决?

aof日志持久化 appendonly no #是否仅要日志，是否打开 aof日志功能 appendfsync no # 系统缓冲,统一写,速度快，写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快, appendfsync always # 系统不缓冲,直接写,慢,丢失数据少，每1个命令,都立即同步到aof. 安全,速度慢 appendfsync everysec #折衷,每秒写1次

no-appendfsync-on-rewrite no #重写aof时同步最新数据，正在导出rdb快照的过程中,要不要停止同步aof auto-AOF-rewrite-percentage 100 当前aof文件是上次重写是大N%时重写，aof文件大小比起上次重写时的大小,增长率100%时,重写 auto-AOF-rewrite-min-size 64mb aof重写至少要达到的大小，aof文件,至少超过64M时,重写

在dump rdb过程中,aof如果停止同步,会不会丢失? 答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

注: aof重写是指什么? 答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里. 以解决 aof日志过大的问题.

问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据? 答: aof

问: 2种是否可以同时用? 答: 可以,而且推荐这么做

问: 恢复时rdb和aof哪个恢复的快 答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行 redis 服务器端命令 redis 127.0.0.1:6380> time ,显示服务器时间 , 时间戳(秒), 微秒数

  1. "1375270361"
  2. "504511"

redis 127.0.0.1:6380> dbsize // 当前数据库的key的数量 (integer) 2 redis 127.0.0.1:6380> select 2 OK redis 127.0.0.1:6380[2]> dbsize (integer) 0 redis 127.0.0.1:6380[2]>

BGREWRITEAOF 后台进程重写AOF BGSAVE 后台保存rdb快照 SAVE 保存rdb快照 LASTSAVE 上次保存时间

Slaveof master-Host port , 把当前实例设为master的slave

Flushall 清空所有库所有键 Flushdb 清空当前库所有键 Showdown [save/nosave]

注: 如果不小心运行了flushall, 立即 shutdown nosave ,关闭服务器 然后 手工编辑aof文件, 去掉文件中的 “flushall ”相关行, 然后开启服务器,就可以导入回原来数据.

如果,flushall之后,系统恰好bgrewriteaof了,那么aof就清空了,数据丢失.

Slowlog 显示慢查询 注:多慢才叫慢? 答: 由slowlog-log-slower-than 10000 ,来指定,(单位是微秒)

服务器储存多少条慢查询的记录? 答: 由 slowlog-max-len 128 ,来做限制

Info [Replication/CPU/Memory..] 查看redis服务器的信息

Config get 配置项
Config set 配置项 值 (特殊的选项,不允许用此命令设置,如slave-of, 需要用单独的slaveof命令来设置)

Redis运维时需要注意的参数 1: 内存

Memory

used_memory:859192 数据结构的空间 used_memory_rss:7634944 实占空间 mem_fragmentation_ratio:8.89 前2者的比例,1.N为佳,如果此值过大,说明redis的内存的碎片化严重,可以导出再导入一次. 2: 主从复制

Replication

role:slave master_host:192.168.1.128 master_port:6379 master_link_status:up

3:持久化

Persistence

rdb_changes_since_last_save:0 rdb_last_save_time:1375224063

4: fork耗时 #Status latest_fork_usec:936 上次导出rdb快照,持久化花费微秒 注意: 如果某实例有10G内容,导出需要2分钟, 每分钟写入10000次,导致不断的rdb导出,磁盘始处于高IO状态.

5: 慢日志 config get/set slowlog-log-slower-than CONFIG get/SET slowlog-max-len slowlog get N 获取慢日志

运行时更改master-slave 修改一台slave(设为A)为new master 1)命令该服务不做其他redis服务的slave 命令: slaveof no one 2)修改其readonly为yes

其他的slave再指向new master A 1)命令该服务为new master A的slave 命令格式 slaveof IP port

集群的作用

1: 主从备份 防止主机宕机 2: 读写分离,分担master的任务 3: 任务分离,如从服分别分担备份工作与计算工作

master master-slave1-slave2 |
slave1 slave2 这是两种主从模式 第一种：当master宕机后由slave1接管，然后修改slave2指向slave1 第2种方式的好处: master宕机后, 可以直接切换到slave1

Sentinel不断与master通信,获取master的slave信息. 监听master与slave的状态 如果某slave失效,直接通知master去除该slave.

如果master失效,,是按照slave优先级(可配置), 选取1个slave做 new master ,把其他slave--> new master

疑问: sentinel与master通信,如果某次因为master IO操作频繁,导致超时, 此时,认为master失效,很武断. 解决: sentnel允许多个实例看守1个master, 当N台(N可设置)sentinel都认为master失效,才正式失效.

Sentinel选项配置 port 26379 # 端口 sentinel monitor mymaster 127.0.0.1 6379 2 , 给主机起的名字(不重即可), 当2个sentinel实例都认为master失效时,正式失效

sentinel down-after-milliseconds mymaster 30000 多少毫秒后连接不到master认为断开 sentinel can-failover mymaster yes #是否允许sentinel修改slave->master. 如为no,则只能监控,无权修改./ sentinel parallel-syncs mymaster 1 , 一次性修改几个slave指向新的new master. sentinel client-reconfig-script mymaster /var/redis/reconfig.sh ,# 在重新配置new master,new slave过程,可以触发的脚本

注意：当一个master启动后会自动同步slave,先dump rdb,在缓冲aof,一次同步最好不要多个来避免master io飙升！ 缺陷:每次salave断开后,(无论是主动断开,还是网络故障) 再连接master

都要master全部dump出来rdb,再aof,即同步的过程都要重新执行1遍.

所以要记住---多台slave不要一下都启动起来,否则master可能IO剧增

具体例子： sentinel monitor def_master 127.0.0.1 6379 2

sentinel auth-pass def_master 012_345^678-90

##master被当前sentinel实例认定为“失效”的间隔时间
##如果当前sentinel与master直接的通讯中，在指定时间内没有响应或者响应错误代码，那么
##当前sentinel就认为master失效(SDOWN，“主观”失效)
##<mastername> <millseconds>
##默认为30秒
sentinel down-after-milliseconds def_master 30000

##当前sentinel实例是否允许实施“failover”(故障转移)
##no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover)，
##全局中至少有一个为yes
sentinel can-failover def_master yes
##sentinel notification-script mymaster /var/redis/notify.sh