Redis 雾里看花
P1
Redis不就是一个kv缓存，有什么可说？
- Redis里面提供了丰富的数据类型和功能，可以满足各种常见的技术场景。
1.尤其对于中小型公司，没有阿里那么丰富的中间件和基础设施，就会借助Redis曲线满足很多需求。
- 对于一些一次性的活动类需求，既有相关功能需求，但又不想设计太复杂的架构，就可以借助Redis来低成本实现。
P2
Redis 是「Remote Dictionary Service」的首字母缩写，互联网技术领域使用最为广泛的存储中间件。
- 丰富的功能
- 超高的性能
- 完善的文档
- 简洁易懂的源码
- 丰富的客户端库支持
P3
MERZ: 源于意大利广告女郎「Alessia Merz」
P4
五种基本数据结构（快速回顾）
String、Hash、List、Set、SortedSet
String
最简单的数据结构，一个key只能对应一个value
value不定义是String，可以数字，常用方式是存储序列化对象的字符串。
- 单值 set/get
- 多值 mset/mget
- 设置&过期 setex
- 计数 incr/incrby
- 获取子串 getrange
- 覆盖子串 setrange
- 追加子串 append
- 没有提供插入和删除子串的方法
P5
list
- 添加 lpush/rpush
- 删除 lpop/rpop
- 获取元素总量 llen
- 获取指定下标元素 lindex
- 获取指定范围元素 lrange
- 保留指定范围元素 ltrim
list是底层用双向链表实现的，查找操作时间复杂度是o(n),慎用
P6
hash
- 单值 hset/hget
- 多值 hmset/hmget
- 获取元素数量 hlen
- 获取全部元素 hgetall
hash 和 string 都能存储对象信息，怎么选择？
实现层面：hash可以针对每个属性独立存取，而不需像string需要序列化/反序列化对象，如果每次只访问少量属性，效率会更高，也能减少网络传输流量，但存储空间要大于string。
应用层面：使用整个对象用string存储会更便捷，不用逐个值get/set，但更新时全量覆盖要注意安全（有效值清空）
内部实现结构上同 Java 的 HashMap 类似，同样的数组 + 链表二维结构
P7
set
- 添加元素 sadd
- 删除元素 spop
- 获取元素数量 scard
- 获取所有元素 smembers
- 查询某个值是否存在 sismember
set的实现也类似java中的HashSet,本质就是一个value固定为NULL的hash集合
P8
zset
有序的唯一集合，给每个value赋予一个score,代表这个value的排序权重。功能上类似java的TreeSet。
- 添加/删除元素 zadd/zrem
- 排序查询 zrange/zrevrange
- 获取元素数量 zcard
- 获取指定vlaue的score zscore
- 获取指定value的排名 zrank
- 获取指定score范围的value zrangebyscore
zset 是通过跳跃列表来实现的。
p9
expire : 设置过期时间，所有数据结构都支持
坑： 设置了过期时间后，调用set修改值，过期时间会消失。
list/set/hash/zset 这四种数据结构是容器型数据结构，它们共享下面两条通用规则：
- create if not exists
如果容器不存在，那就创建一个，再进行操作。
比如 rpush 操作刚开始是没有列表的，Redis 就会自动创建一个，然后再 rpush 进去新元素。
2.drop if no elements
如果容器里元素没有了，那么立即删除元素，释放内存。这意味着 lpop 操作到最后一个元素，列表就消失了。
p10 分布式锁
可能redis是除了缓存数据外，最常见的用途
> setnx lock:user true
OK
... do something ...
> del lock:user
(integer) 1
如果业务逻辑执行过程出现异常，可能会导致 del 指令没有被调用，这样就会陷入死锁，锁永远得不到释放。
p11
改进版
> setnx lock:user true
OK
> expire lock:user 5
... do something ...
> del lock: user
(integer) 1
还有问题，setnx 和 expire 操作不是原子的，如果两个操作之间客户端挂掉了，也会造成死锁。
为了解决这个疑难，当时Redis 开源社区涌现了一堆分布式锁的 library，专门用来解决这个问题。但实现方法极为复杂，还得引入额外的library。
为了治理这个乱象，Redis 2.8 版本中作者加入了 set 指令的扩展参数，使得 setnx 和 expire 指令可以原子执行。
升级版：
> set lock:user true ex 5 nx
OK
... do something...
> del lock:user
p12
超时问题
如果在加锁和释放锁之间的逻辑执行的太长，以至于超出了锁的超时限制，就会出现问题。因为这时候第一个线程持有的锁过期了，临界区的逻辑还没有执行完，这个时候第二个线程就提前重新持有了这把锁，导致临界区代码不能得到严格的串行执行。
极端情况下，可能引起锁持续失效。
终极版：
1、 Redis 分布式锁不要用于较长时间的任务
2、锁的key增加随机数确保当前线程占有的锁不会被其它线程释放
key = "lock:user:" + random.nextint()
if redis.set(key, tag, nx=True, ex=5):
dosomething()
redis.del(key)
p13
sentinel集群环境下的分布式锁
Redlock 算法：cluster集群 去中心。加锁时，它向所有节点发送指令，过半节点返回成功则认为加锁成功。解锁时向全部节点发送del指令。
p14 锁冲突处理
常见的处理策略：
直接抛出异常，通知调用方（用户）稍后重试；
本质上是对当前请求的放弃，由用户决定是否重新发起新的请求。自旋，sleep 一会再重试；
注意：加锁时间过长会导致大量线程阻塞，如果出现死锁甚至造成雪崩，所以建议加上重试加锁的次数限制。将请求转移至延时队列，过一会再试；
p15 消息队列
Redis 的消息队列不是专业的消息队列，它没有非常多的高级特性,例如应答、重试机制，也不保证消息的高可靠性。
阻塞队列： blpop/brpop
注意：队列阻塞时间超过链接闲置时间（不是阻塞等待时间），服务器一般会主动断开链接，这个时候blpop/brpop会抛出异常来。注意捕获异常，进行相应处理（忽略/重试）。
p16 延时队列
通过 Redis 的 zset(有序列表) 来实现。我们将消息序列化成一个字符串作为 zset 的value，这个消息的到期处理时间作为score，然后用多个线程轮询 zset 获取到期的任务进行处理
def delay(msg):
value = json.dumps(msg)
retry_ts = time.time() + 5 # 5 秒后重试
redis.zadd("delay-queue", retry_ts, value)
def loop():
while True:
# 最多取 1 条
values = redis.zrangebyscore("delay-queue", 0, time.time(), start=0, num=1)
if not values:
time.sleep(1) # 延时队列空的，休息 1s
continue
value = values[0] # 拿第一条，也只有一条
success = redis.zrem("delay-queue", value) # 从消息队列中移除该消息
if success: # 因为有多进程并发的可能，最终只会有一个进程可以抢到消息
msg = json.loads(value)
handle_msg(msg)
优点: 实现简单
缺点：轮询效率低； 不保证可靠性；
p17 位图
byte数组，存取bool型数据。
场景：
1.用户一年的签到记录，签了是 1，没签是 0，要记录 365 天。如果使用普通的 key/value，每个用户要记录 365 个kv。位图每个用户只需365位。
2.若id连续，可以通过位图排重，例如计算用户月活。
127.0.0.1:6379> setbit s 1 1
(integer) 0
127.0.0.1:6379> setbit s 2 1
(integer) 0
127.0.0.1:6379> setbit s 4 1
(integer) 0
127.0.0.1:6379> getbit s 1 # 获取某个具体位置的值
(integer) 1
127.0.0.1:6379> get s # 零存整取
"h"
127.0.0.1:6379> set w hello # 整存
OK
127.0.0.1:6379> bitcount w # 统计出现1位的数
(integer) 21
127.0.0.1:6379> bitpos w 1 # 第一个 1 的位数
(integer) 4
p18 Bloom Filter
Redis4.0 后可作为插件使用。
Bloom Filter可理解为一个不是绝对精确的set，存在一定的误判率。
当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。
实现原理
bitmap + 若干个hash function
错误率 ： bitmap size、 hash function 个数
计算公式：
hash函数个数 = 0.7 * ( 位数组长度 / 预期放入元素个数)
错误率 = 0.6185 ^ (位数组长度 / 预期放入元素个数)
