redis笔记
基础的数据结构：string、list、hash、set、zset
容器型数据结构（list、hash、set、zset）通用规则
String
内部编码3种：int、raw、embstr
- int: 保存在字符串对象结构的ptr属性里（将void*转换成 long），并将字符串对象的编码设置为int
- embstr编码是专门用于保存短字符串的一种优化编码方式。
mbstr会通过一次内存分配函数来分配一块连续的内存空间来保存redisObject和SDS；
优点：
embstr相对于raw，创建字符串对象所需的内存分配次数从两次变为一次；
释放 embstr编码的字符串对象同样只需要调用一次内存释放函数；
embstr编码的字符串对象的所有数据都保存在一块连续的内存里面可以更好的利用 CPU 缓存提升性能。
缺点：
embstr编码的字符串对象实际上是只读的
对embstr编码的字符串对象执行任何修改命令（例如append）时，程序会先将对象的编码从embstr转换成raw，然后再执行修改命令。
应用场景
缓存对象
常规计数(计算访问次数 点赞 转发 库存数量的场景)
分布式锁 SETNX
SET lock_key unique_value NX PX 10000 // unique_value是客户端生成的唯一标识
解锁(判断锁的 unique_value 是否为加锁客户端 – 是则将 lock_key 键删除):
解锁是有两个操作，这时就需要 Lua 脚本来保证解锁的原子性, Redis 在执行 Lua 脚本时，可以以原子性的方式执行
// 释放锁时，先比较 unique_value 是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
共享Session信息
分布式系统单独存储 Session 流程图:
借助 Redis 对这些 Session 信息进行统一的存储和管理:
list 简单的字符串列表 按插入顺序排序 可以从头部或尾部向 List 列表添加元素
底层数据结构是由双向链表或压缩列表实现…
redis3.2后List 数据类型底层数据结构就只由 quicklist 实现
应用场景
消息队列
需求: 消息保序 处理重复消息 保证消息的可靠性
基于List的消息队列实现
- 消息保序
生产者使用 LPUSH key value[value…] 将消息插入到队列的头部，如果 key 不存在则会创建一个空的队列再插入消息。
消费者使用 RPOP key 依次读取队列的消息，先进先出。
问题: 消费者不停调用RPOP命令, 消耗CPU.
解决:Redis提供BRPOP命令阻塞式读取, 客户端在没有读到队列数据时，自动阻塞，直到有新的数据写入队列，再开始读取新数据。 - 处理重复的消息
方案: 自行为每个消息生成一个全局唯一ID. 用LPUSH命令将消息插入队列时,在消息中包含全局唯一ID.
eg. 把一条全局 ID 为 111000102、库存量为 99 的消息插入消息队列
> LPUSH mq "111000102:stock:99"
- 保证消息可靠性
**问题:**如果消费者程序在处理消息的过程出现了故障或宕机，就会导致消息没有处理完成，那么，消费者程序再次启动后，就没法再次从 List 中读取消息了。
解决:BRPOPLPUSH
问题: List 不支持多个消费者消费同一条消息
List实现消息队列优点:
Hash
Key-value 集合, 适合用于存储对象
数据结构: 哈希表, 如果哈希类型元素个数小于 512 个, 所有值小于 64,会使用压缩列表作为底层数据结构.
应用场景
缓存对象
一般对象用 String + Json 存储，对象中某些频繁变化的属性可以考虑抽出来用 Hash 类型存储。
# 存储一个哈希表uid:1的键值
> HMSET uid:1 name Tom age 15
2
# 存储一个哈希表uid:2的键值
> HMSET uid:2 name Jerry age 13
2
# 获取哈希表用户id为1中所有的键值
> HGETALL uid:1
1) "name"
2) "Tom"
3) "age"
4) "15"
购物车
Set
哈希表或整数集合实现
在主从集群中，为了避免主库因为 Set 做聚合计算（交集、差集、并集）时导致主库被阻塞，我们可以选择一个从库完成聚合统计，或者把数据返回给客户端，由客户端来完成聚合统计.
点赞
Set 类型可以保证一个用户只能点一个赞，这里举例子一个场景，key 是文章id，value 是用户id。
共同关注
抽奖活动
- 如果允许重复中奖，可以使用 SRANDMEMBER 命令。
- 如果不允许重复中奖，可以使用 SPOP 命令。
Zset
压缩列表或跳表
排行榜
电话姓名排序
待补充:
BitMap
HyperLogLog
GEO
Stream
使用场景
消息队列，相比于基于 List 类型实现的消息队列，有这两个特有的特性：自动生成全局唯一消息ID，支持以消费组形式消费数据。
Redis 是否适合做消息队列?
- 如果你的业务场景足够简单，对于数据丢失不敏感，而且消息积压概率比较小的情况下，把 Redis 当作队列是完全可以的。
- 如果你的业务有海量消息，消息积压的概率比较大，并且不能接受数据丢失，那么还是用专业的消息队列中间件吧。
原文地址:https://blog.csdn.net/yfdddong/article/details/134626015
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_2355.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
