关闭
bin/redis-cli -h node01 -p 6379 shutdown
bin/redis-cli -h node02 -p 6379 shutdown
bin/redis-cli -h node03 -p 6379 shutdown
pkill redis-server pkill redis-sentinel
连接redis客户端
cd /export/server/redis-3.2.8/ bin/redis-server redis.conf bin/redis-sentinel sentinel.conf ps -ef | grep redis
Bitmaps
设置值
SETBIT key offset value setbit unique:users:2016-04-05 0 1
获取值
GETBIT key offset getbit unique:users:2016-04-05 8
获取Bitmaps指定范围值为1的个数
BITCOUNT key [start end] bitcount unique:users:2016-04-05
Bitmaps间的运算
BITOP operation destkey key [key, …]
计算4-5访问量
bitop and unique:users:and:2016-04-04_05 unique:users:2016-04-04 unique:users:2016-04-05 bitcount unique:users:2016-04-04_05
HyperLogLog
HyperLogLog 提供不精确的去重计数方案,虽然不精确但是也不是非常不精确,标准误差是 0.81%
pfadd AAA a,b,c,d......
pfcount AAA
pfmerge AAA+BBB AAA BBB
JAVA API
持久化
内存易丢失,用RDB快照或者AOF解决
sync
将有关文件系统的存储器常驻信息送入物理介质内,多在重启系统前使用
RDB快照
save [seconds] [changes] save 60 100
60秒发生100次数据变更,则触发快照,生成dump.rdb文件
每次生成新的dump.rdb都会覆盖掉之前的老的快照
性能影响小
快照多,可靠
数据恢复快
缺点
定期快照,不完善
数据集大的时候影响对外服务的性能
AOF持久化
记录操作,每次重启redis,按顺序再执行一遍
AOF默认是关闭的,如要开启,进行如下配置:
第594行appendonly yes
appendfsync配置
AOF rewrite功能,重写AOF文件,只保留能够把数据恢复到最新状态的最小写操作集
auto-aof-rewrite-percentage 100 AOF的rewrite日志大小在该基础上增长了100%后,自动进行AOF rewrite auto-aof-rewrite-min-size 64mb 该变量仅初始化启动Redis有效。
安全稳定不怕停电,易读取,可修改,只要没有rewrite,错误命令都是可以修复的
缺点
AOF通常比RDB文件大,性能消耗高,数据恢复速度慢
Redis高级
*Redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令*
l *Redis事务没有隔离级别的概念*
l *Redis不保证原子性* 没有回滚。事务中任意命令执行失败,其余的命令仍会被执行。
事务三个阶段:
l 第一阶段:开始事务,检测语法错误
l 第二阶段:命令入队
l 第三阶段、执行事务,检测类型 逻辑错误
l MULTI
开启事务,入列
l EXEC
执行事务中的所有操作命令
l DISCARD
取消事务
l WATCH
监视一个或多个key,如果事务在执行前,这个key(或多个key)被其他命令修改,则事务被中断,不会执行事务中的任何命令
l UNWATCH
取消WATCH对所有key的监视
不支持回滚原因
保持这样简易的事务,完全是为了保证高并发下的核心问题---性能
过期策略
l *定时过期*
每个key有定时器,占用cpu
l *惰性过期*
只有访问到过期key时才删除,可能导致大量过期key占用内存
l *定期过期*
定时扫描过期key,最优解
内存淘汰策略
Redis的用于缓存的内存不足时,怎么处理需要新写入且需要申请额外空间的数据,在Redis的配置文件中描述如下:
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory \# is reached. You can select among five behaviors: \#最大内存策略:当到达最大使用内存时,你可以在下面5种行为中选择,Redis如何选择淘汰数据库键 \#当内存不足以容纳新写入数据时 \# volatile-lru -> remove the key with an expire set using an LRU algorithm \# volatile-lru :在设置了过期时间的键空间中,移除最近最少使用的key。这种情况一般是把 redis 既当缓存,又做持久化存储的时候才用。 \# allkeys-lru -> remove any key according to the LRU algorithm \# allkeys-lru : 移除最近最少使用的key (推荐) \# volatile-random -> remove a random key with an expire set \# volatile-random : 在设置了过期时间的键空间中,随机移除一个键,不推荐 \# allkeys-random -> remove a random key, any key \# allkeys-random : 直接在键空间中随机移除一个键,弄啥叻 \# volatile-ttl -> remove the key with the nearest expire time (minor TTL) \# volatile-ttl : 在设置了过期时间的键空间中,有更早过期时间的key优先移除 不推荐 \# noeviction -> don't expire at all, just return an error on write operations \# noeviction : 不做过键处理,只返回一个写操作错误。 不推荐 \# Note: with any of the above policies, Redis will return an error on write \# operations, when there are no suitable keys for eviction. \# 上面所有的策略下,在没有合适的淘汰删除的键时,执行写操作时,Redis 会返回一个错误。下面是写入命令: \# At the date of writing these commands are: set setnx setex append \# incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd \# sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby \# zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby \# getset mset msetnx exec sort \# 过期策略默认是: \# The default is: \# maxmemory-policy noeviction
主从复制架构
数据从主节点复制到从节点
主节点有多个从节点,从节点只有一个主节点
应用场景
读写分离
读多写少时,从节点读,主节点写
从数据库持久化
从数据库持久化
数据自动同步到从数据,崩溃时恢复
Sentinel哨兵架构
查看哨兵
bin/redis-cli -h node01 -p 26379
bin/redis-cli -h node02 -p 26379
bin/redis-cli -h node03 -p 26379
info
info 查看信息 ping 检查状态pong
redis集群
若master宕机可自动将slave转为master,但它也有一个问题,就是不能动态扩充;所以在Redis 3.x提出*cluster集群*模式
分布式架构,有多个节点,每个节点都负责进行数据读写操作,每个节点之间会进行通信。Redis Cluster采用*无中心结构*,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。没有中心节点
集群中至少应该有*奇数个节点*