网站整合营销建设,上海建设银行招聘网站,协同办公平台系统oa,wordpress放置htmlredis笔记
基础的数据结构#xff1a;string、list、hash、set、zset
容器型数据结构#xff08;list、hash、set、zset#xff09;通用规则
如果容器不存在#xff0c;就创建一个#xff0c;再进行操作如果容器里没有数据了#xff0c;就立即删除#xff0c;回收内存…redis笔记
基础的数据结构string、list、hash、set、zset
容器型数据结构list、hash、set、zset通用规则
如果容器不存在就创建一个再进行操作如果容器里没有数据了就立即删除回收内存
String
如图 String 是reids 中最常见的数据类型
内部编码3种int、raw、embstr
int: 保存在字符串对象结构的ptr属性里将void*转换成 long并将字符串对象的编码设置为int embstr编码是专门用于保存短字符串的一种优化编码方式。 mbstr会通过一次内存分配函数来分配一块连续的内存空间来保存redisObject和SDS 优点 embstr相对于raw创建字符串对象所需的内存分配次数从两次变为一次 释放 embstr编码的字符串对象同样只需要调用一次内存释放函数 embstr编码的字符串对象的所有数据都保存在一块连续的内存里面可以更好的利用 CPU 缓存提升性能。 缺点 embstr编码的字符串对象实际上是只读的 对embstr编码的字符串对象执行任何修改命令例如append时程序会先将对象的编码从embstr转换成raw然后再执行修改命令。
应用场景
缓存对象
直接缓存整个对象的JSON将key分离为user:ID:属性, MSET存储。MGET 获取各属性值
常规计数(计算访问次数 点赞 转发 库存数量的场景)
Redis 处理命令是单线程所以执行命令的过程是原子的。
分布式锁 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] thenreturn redis.call(del,KEYS[1])
elsereturn 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实现消息队列优点:
redis存储,不受限于JVM内存上限Redis具有持久化机制,数据安全性有保障
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 的差集、并集和交集的计算复杂度较高在数据量较大的情况下如果直接执行这些计算会导致 Redis 实例阻塞。
在主从集群中为了避免主库因为 Set 做聚合计算交集、差集、并集时导致主库被阻塞我们可以选择一个从库完成聚合统计或者把数据返回给客户端由客户端来完成聚合统计.点赞
Set 类型可以保证一个用户只能点一个赞这里举例子一个场景key 是文章idvalue 是用户id。
共同关注
抽奖活动
如果允许重复中奖可以使用 SRANDMEMBER 命令。如果不允许重复中奖可以使用 SPOP 命令。
Zset
压缩列表或跳表
排行榜
电话\姓名排序
待补充:
BitMap
HyperLogLog
GEO
Stream
使用场景
消息队列相比于基于 List 类型实现的消息队列有这两个特有的特性自动生成全局唯一消息ID支持以消费组形式消费数据。
Redis 是否适合做消息队列?
如果你的业务场景足够简单对于数据丢失不敏感而且消息积压概率比较小的情况下把 Redis 当作队列是完全可以的。如果你的业务有海量消息消息积压的概率比较大并且不能接受数据丢失那么还是用专业的消息队列中间件吧。
