共计 3062 个字符，预计需要花费 8 分钟才能阅读完成。
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)、掘金，转载请注明出处。
