Redis的n种妙用，分布式锁，分布式唯一id，消息队列，java入门视频教程

每次获取userId的时候，对userId加1再获取，可以改进为如下形式

直接获取一段userId的最大值，缓存到本地慢慢累加，快到了userId的最大值时，再去获取一段，一个用户服务宕机了，也顶多一小段userId没有用到

set userId 0

incr usrId //返回1

incrby userId 1000 //返回10001

消息队列（list）

在list里面一边进，一边出即可

# 实现方式一

一直往list左边放

lpush key value

key这个list有元素时，直接弹出，没有元素被阻塞，直到等待超时或发现可弹出元素为止，上面例子超时时间为10s

brpop key value 10

实现方式二

rpush key value

blpop key value 10

新浪/Twitter用户消息列表（list）

假如说小编li关注了2个微博a和b，a发了一条微博（编号为100）就执行如下命令

lpush msg::li 100

b发了一条微博（编号为200）就执行如下命令：

lpush msg::li 200

假如想拿最近的10条消息就可以执行如下命令（最新的消息一定在list的最左边）：

# 下标从0开始，[start,stop]是闭区间，都包含

lrange msg::li 0 9

抽奖活动（set）

# 参加抽奖活动

sadd key {userId}

获取所有抽奖用户，大轮盘转起来

smembers key

抽取count名中奖者，并从抽奖活动中移除

spop key count

抽取count名中奖者，不从抽奖活动中移除

srandmember key count

实现点赞，签到，like等功能(set)

# 1001用户给8001帖子点赞

sadd like::8001 1001

取消点赞

srem like::8001 1001

检查用户是否点过赞

sismember like::8001 1001

获取点赞的用户列表

smembers like::8001

获取点赞用户数

scard like::8001

实现关注模型，可能认识的人（set）

seven关注的人

sevenSub -> {qing, mic, james}

青山关注的人

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】

开源完整内容戳这里

qingSub->{seven,jack,mic,james}

Mic关注的人

MicSub->{seven,james,qing,jack,tom}

# 返回sevenSub和qingSub的交集，即seven和青山的共同关注

sinter sevenSub qingSub -> {mic,james}

我关注的人也关注他,下面例子中我是seven

qing在micSub中返回1，否则返回0

sismember micSub qing

sismember jamesSub qing

我可能认识的人,下面例子中我是seven

求qingSub和sevenSub的差集，并存在sevenMayKnow集合中

sdiffstore sevenMayKnow qingSub sevenSub -> {seven,jack}

电商商品筛选（set）

每个商品入库的时候即会建立他的静态标签列表如，品牌，尺寸，处理器，内存

# 将拯救者y700P-001和ThinkPad-T480这两个元素放到集合brand::lenovo

sadd brand::lenovo 拯救者y700P-001 ThinkPad-T480

sadd screenSize::15.6 拯救者y700P-001 机械革命Z2AIR

sadd processor::i7 拯救者y700P-001 机械革命X8TIPlus

获取品牌为联想，屏幕尺寸为15.6，并且处理器为i7的电脑品牌(sinter为获取集合的交集)

sinter brand::lenovo screenSize::15.6 processor::i7 -> 拯救者y700P-001

排行版（zset）

redis的zset天生是用来做排行榜的、好友列表, 去重, 历史记录等业务需求

# user1的用户分数为 10

zadd ranking 10 user1

zadd ranking 20 user2

取分数最高的3个用户

zrevrange ranking 0 2 withscores

过期策略

========

定期删除

redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定期遍历这个字典来删除到期的 key。

定期删除策略

Redis 默认会每秒进行十次过期扫描（100ms一次），过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。

从过期字典中随机 20 个 key；

删除这 20 个 key 中已经过期的 key；

如果过期的 key 比率超过 1/4，那就重复步骤 1；

惰性删除

除了定期遍历之外，它还会使用惰性策略来删除过期的 key，所谓惰性策略就是在客户端访问这个 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除，不会给你返回任何东西。

定期删除是集中处理，惰性删除是零散处理。

为什么要采用定期删除+惰性删除2种策略呢？

=========================

如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了

但是问题是，定期删除可能会导致很多过期key到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。这就是说，在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。

并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下

通过上述两种手段结合起来，保证过期的key一定会被干掉。

所以说用了上述2种策略后，下面这种现象就不难解释了：数据明明都过期了，但是还占有着内存

内存淘汰策略