redis分享

Redis 雾里看花

P1

Redis不就是一个kv缓存，有什么可说？

Redis里面提供了丰富的数据类型和功能，可以满足各种常见的技术场景。
1.尤其对于中小型公司，没有阿里那么丰富的中间件和基础设施，就会借助Redis曲线满足很多需求。

对于一些一次性的活动类需求，既有相关功能需求，但又不想设计太复杂的架构，就可以借助Redis来低成本实现。

P2

Redis 是「Remote Dictionary Service」的首字母缩写，互联网技术领域使用最为广泛的存储中间件。

丰富的功能
超高的性能
完善的文档
简洁易懂的源码
丰富的客户端库支持

P3

image.png

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，但更新时全量覆盖要注意安全（有效值清空）

https://stackoverflow.com/questions/16375188/redis-strings-vs-redis-hashes-to-represent-json-efficiency

内部实现结构上同 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集群环境下的分布式锁

image.png

Redlock 算法：cluster集群去中心。加锁时，它向所有节点发送指令，过半节点返回成功则认为加锁成功。解锁时向全部节点发送del指令。

p14 锁冲突处理

常见的处理策略：

直接抛出异常，通知调用方（用户）稍后重试；
本质上是对当前请求的放弃，由用户决定是否重新发起新的请求。
自旋，sleep 一会再重试；
注意：加锁时间过长会导致大量线程阻塞，如果出现死锁甚至造成雪崩，所以建议加上重试加锁的次数限制。
将请求转移至延时队列，过一会再试；

p15 消息队列

Redis 的消息队列不是专业的消息队列，它没有非常多的高级特性,例如应答、重试机制，也不保证消息的高可靠性。

image.png

阻塞队列： 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，存在一定的误判率。
当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。

实现原理

image.png

bitmap + 若干个hash function

错误率： bitmap size、 hash function 个数

计算公式：

hash函数个数 = 0.7 * ( 位数组长度 / 预期放入元素个数)  
错误率 = 0.6185 ^ (位数组长度 / 预期放入元素个数)

https://krisives.github.io/bloom-calculator/

redis分享

P1

P2

P3

P4

P5

P6

P7

P8

p9

p10 分布式锁

p11

p12

p13

p14 锁冲突处理

p15 消息队列

p16 延时队列

p17 位图

p18 Bloom Filter

你可能感兴趣的:(redis分享)