redis的数据结构及使用场景「redis常用场景」
今天给大家普及一下redis的数据结构及使用场景「redis常用场景」相关知识，最近很多在问redis的数据结构及使用场景「redis常用场景」，希望能帮助到您。
redis五种数据结构如下：1.String 字符串类型是redis中最基本的数据类型，一个key对应一个value。
String类型是二进制安全的，意思是 redis 的 string 可以包含任何数据。如数字，字符串，jpg图片或者序列化的对象。
2.Hash （哈希）是一个Mapmap，指值本身又是一种键值对结构，如 value={{field1,value1},......fieldN,valueN}}
3.链表 (List)List 说白了就是链表（redis 使用双端链表实现的 List），是有序的，value可以重复，可以通过下标取出对应的value值，左右两边都能进行插入和删除数据。
4.Set 集合集合类型也是用来保存多个字符串的元素，但和列表不同的是集合中 1. 不允许有重复的元素，2.集合中的元素是无序的，不能通过索引下标获取元素，3.支持集合间的操作，可以取多个集合取交集、并集、差集。
5.zset 有序集合有序集合和集合有着必然的联系，保留了集合不能有重复成员的特性，区别是，有序集合中的元素是可以排序的，它给每个元素设置一个分数，作为排序的依据。
应用场景String应用场景1. 单值缓存Set Key Value
Get Key
2. 对象缓存1.Set user:1 value (json格式数据)
2.MSet user:1:name guajia use:1:balance 1888
MGet user1:name user:1:balance
3. 分布式锁：3.1 分布式运用场景一【下单减库存】
如图标红的部分，如果是单体架构 我们一般是这样来实现减库存操作的 但是在高并发的互联网公司这样做，就会造成“超卖”的现象。所以就需要redis来实现分布式锁
如上图标记SETNX命令 它只会存入一个不存在的键值对，如果不会改变原来的key所存入的值，返回结果为0
SETNX product:10001 true //返回1代表获取锁成功 返回0代表获取锁失败---》 执行业务操作
如果setnx 命令返回0 直接扔给前端后端服务正忙 请稍后重试】 DEL product:10001 //执行完业务用它来释放锁
SET product:10001 true ex 10 nx //防止程序意外终止而导致死锁
3.2 分布式运用场景二
INCR 命令 每次执行 所存储的key的值 数量加1 (如果用数据库的话 需要考虑并发和加锁) 【注：redis是个单线程应用程序 这样不会导致高并发的脏读,主从的redis 在后面会使用分布式锁，一般单体的redis并发量在9-10万左右 】
3.3 分布式运用场景三 【 Web集群的session 共享 】
原理是把原有的tomcat存储用户信息转为redis 把用户的信息 序列化后 存入redis。
3.4 分布式运用场景四【 分布式系统全局序列号 】
INCRBY orderId 1000 // redis 批量生成序列号提升性能
如项目使用 分库分表 ，就可以使用这个 ，目的是让主键ID 在都是唯一的 ，这个在实际场景非常重要。
使用INCRBY orderId 1000 （这个命令是一次生成1000个订单id 供下次生成订单使用）
Hash应用场景大家仔细看 Hset key field value 比string多出来了一个field
Hash应用场景一 【电商购物车】如图先示刚加入购物车的商品使用 hset cart:1001 10088 1,啥意思 cart代表的购物车 当然这个key 你可以随意定 但是意义要让所有人清楚，:1001 这里代表的是用户id，后面的10088 代表的是商品id。
第二步 点击 购物车的增加商品按钮 可以使用hincrby 命令 对已有值进行增量操作
有人可能会问，如果减少加购数量？骚年 你太年轻了 可以把增量的值调为-1 那每次就是减1
获取购物车商品总数 hlen cart:1001 [这边把商品id去掉就行了 前提是你所有的加购设置key 和field的格式是一样的 不然查出来的数量肯定不对] //它返回的是key下的所有field数量
涉及删除商品，使用删除的命令 hdel cart:1001 10088
获取加购商品的总数量 使用hgetall cart:1001 //它返回的key下的所有键值，可以把所有的值加起来就是加购商品总数量
hash的优点 缺点hash的会分配槽位，集群中 会导致数据过于集中，没办法做分片。
List应用场景仔细看命令前缀 有L 和R 分别代表左和右。
常用的数据结构
栈: LPUSHLPOP = > 放进去的数据放在左边 导致最后放进去的元素处于栈顶 最先的元素是处于栈底 使用LPOP 取值【或称移除值】是先从最左侧【栈顶】取值的 符合 先进后出的规则 【FILO】
队列： 与上面相反 取值时是使用RPOP 是 移除值是从最右侧开始的 所有最后进入的会被取出 符合 队列的先进先出的规则【FIFO】
**BLOCKIng MQ(阻塞队列) **: = LPUSH＋BRPOP [这个就是一个消息队列 ，消息队列中有个发送者 和 接受者 ]
BRPOP 就是从key列表尾弹出一个元素，如果列表中没有元素，就会一直处于阻塞等待多少秒，后面又会循环地执行 直到取到元素为止
运用的场景一 【微博和公众号的消息流】如微博你关注了1000个大V 每个大V 一天放两条数据 ，有1亿用户 。那么数据量有多大。可能有几百M的数据。 如果使用数据库 查询效率那就不是很高了
比如 你关注了小明和小红。
小明发了一条消息： 使用 LPUSH msg:小明Id 消息Id 小红发了一条消息： 使用 LPUSH msg:小红Id 消息Id
查看最新的微博消息： 使用LRANGE msg:小红Id 0 4 这个就是从左侧取下标是0到4的消息 意味着是取小红发的最新的5条消息的消息ID 进而从缓存里面取出对应的消息内容
SET应用场景常见命令运用的场景一 【微信抽奖】1.参与抽奖： SADD key 用户id ： 参与了用户的id2.查看参与抽奖的又会: SMEMBERS key
抽取n名中奖者方式一：DMEMBER key [count]
方式二： SPOP key [count]
方式一和方式二的运用常见是 方式一 只有中奖单一 没有多次抽奖和设置奖品等级。因为方式一 每次执行不会把抽取的数据删掉，后面执行还可能会抽取到原来的用户
[ SRANDMEMBER key [count] 返回集合中一个或多个随机数]
ps: like:{消息ID} 就是 key {用户ID} 是 member
运用的场景三【微信微博关注模型】SDIFF set1 set2 set3 是以 set1为基准 秋 与set2和set3的并集 的差集[得到a是set2和set3的并集中所没有的】
关注模型：
1.你关注的人
set guanzhu:我的id {张三、李四、王五、小明、程咬金}
2.小明关注的人
set guanzhu:小明的id {张三、赵六、尼古拉斯}
3.程咬金关注的人
set guanzhu:程咬金的id {小明、李四}
4.我和小明的共同关注：
SINTER guanzhu:我的id guanzhu:小明的id
得到就是 张三
5.我关注的人也在关注他 【我关注的某人 否也请关注小明】
SISMEMBER guanzhu:程咬金的id 小明的ID
SISMEMBER guanzhu:张三的id 小明的ID
SISMEMBER //判断 member 元素是否是集合 key 的成员
6.我可能认识的人
SDIFF guanzhu:小明的id 我的ID
