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 别离代表左和右。
罕用的数据结构
栈: LPUSH +LPOP = > 放进去的数据放在右边 导致最初放进去的元素处于栈顶 最先的元素是处于栈底 应用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 ： 参加了用户的id
2.查看参加抽奖的又会: 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的并集中所没有的】
关注模型：
- 你关注的人
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
获取小明关注的人和我关注人的差集 【就是我关注人我没有关注他】
本文来源于：宋文超super，专属平台有csdn、思否(SegmentFault)、 简书、 开源中国(oschina)、掘金，转载请注明出处。