求索阁

Redis应用的场景算是我接触过的组件中应用范围最广的，我的一位学C的朋友告诉我说，Redis的学习就是数据结构的学习，Redis的设计充满了艺术的美感。

Redis的应用场景是围绕着它的本质来展开的，分布式内存NoSql数据库，下面看下几种应用场景：

1 会话缓存，类似网购中注册登录用户和匿名登陆用户的购物车内容

2 缓存登录用户的token信息

3 通知机制，基于Redis的订阅发布功能。

由于RabbitMQ、Kafka等专业的MQ对消息队列支持的更全面，所以一般大家忽略了Redis的此能力。

4 持久层二级缓存，SpringBoot已经有了很好的支持，通过简单的注解，将数据的增删改查用Redis缓存起来。

5 排行榜，利用Redis的ZSet很容易获取排行榜Top10的图书、交易量等等

ZRANG key 0 10 WITHSCORES

  并发量较大时通常先用双链将内容收下来，因为链表的新增是最快的，然后另一线程慢慢处理双链的内容。

例如大并发的交易量统计，单笔的交易数据从链的右侧添加，另一线程从链的左侧批量消费，消费的结果存储到ZSet中，这就变成了一个实时更新的交易量排行榜。

6 视频里的弹幕

这玩意确实很烦人，哗啦啦的影响大家对视频的观看，但是为了互动也就忍了。

假如我想每5秒或没满10条记录弹一次，就用到了List里的BLPOP。消息右侧插入，每5秒左侧读出并删除，没内容时阻塞，消息来得快就再右侧慢慢排队等着。

7 秒杀

目前解决秒杀这类的高并发访问问题有3大原则：

A 读写内存不读写磁盘

  SSD速率比普通磁盘读写快3个数量级，内存比SSD再快1个数量级。

B 异步处理不同步处理

同步处理运算越复杂，CPU、内存占用率越高，高并发压下来内存溢出、CPU卡死、申请不到线程等问题接踵而至。所以受理用户请求后压入MQ直接返回结果，后台多线程慢慢去消费。

C 分布式服务

AB搞不定的时候只能不惜血本堆服务器了，屌丝组团PK高富帅。

如果你问ABC都用了还不行咋整？ 我个人觉得那就不整了，技术上已经到极限了，只能从业务上做调整了。例如双十一，以前都是纯秒杀，现在又多了个预付款，虽然对商家来说更好的备货、资金回笼、物流预约等，对于平台来讲是分流，将11号晚0点的请求提前平滑的分流掉了。包括双十一期间每小时的整点秒杀，本质也是一样的。

看完后发现Redis全满足！ 也就不难发现Redis如何做秒杀了。

A读写内存：AOF记得关掉吧，每执行一个命令记录一次磁盘神仙也救不了，若问秒杀的瞬间宕机了怎么办？那只能回复所有秒杀客户“秒杀失败，宝贝已被抢走”，反正没人知道。

B异步处理：只记录客户端标识不处理任何逻辑。也就是说我的Redis双链里收到客户请求只在一端RPUSH userId，越简洁越好，等插入双链到达上线之后拒收客户端请求，再从双链另一端LPOP结果。

C分布式：没啥好说的，多给RedisCluster准备几个节点吧。

8 分布式锁

基于Redis的4个命令

SETNX key value,当且仅当key不存在时设置值后返回1，若已存在直接返回0

Expire keytimeout,为key设置一个超时时间，单位是秒，超过时间后自动删除

Delete key，手动删除

Ttl key，查询key还有多久会自动删除，如果key不存在返回-2，key存在但是没有被expire过返回-1，否则返回expire剩余的时间。

加锁逻辑：

解锁逻辑：

作者：牛麦康纳