redis-事务，持久化，主从复制，sentimal相关

13719654321

　　1.事务操作
　　watch key1 key2//监视key1,key2是否变化
　　unwtach [key1 key2//取消监视
　　multi//开启事务
　　command
　　command
　　...
　　discard/exec//取消或者提交
　　注意:如果命令格式有误,exec会报错
　　如果命令格式不错,只是逻辑错,exec不执行正确的命令---需要程序员去负责
　　2.消息的发布与订阅
　　

     subscribe 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，“主观”失效)
　　##
　　##默认为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