Redis基础

关闭

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采用*无中心结构*，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。没有中心节点

集群中至少应该有*奇数个节点*

72页面试题