Redis的应用场景 曾经终败给现在 2022-06-05 03:53 255阅读 0赞 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准备几个节点吧,Redis集群原理和搭建详见《[三张图秒懂Redis集群设计原理][Redis]》《[Redis在Centos7下的集群安装][Redis_Centos7]》 8 分布式锁 基于Redis的4个命令 SETNX key value,当且仅当key不存在时设置值后返回1,若已存在直接返回0 Expire keytimeout,为key设置一个超时时间,单位是秒,超过时间后自动删除 Delete key,手动删除 Ttl key,查询key还有多久会自动删除,如果key不存在返回\-2,key存在但是没有被expire过返回\-1,否则返回expire剩余的时间。 加锁逻辑: ![Center][] 解锁逻辑: ![Center 1][] [Redis]: http://blog.csdn.net/yejingtao703/article/details/78484151 [Redis_Centos7]: http://blog.csdn.net/yejingtao703/article/details/78520618 [Center]: /images/20220605/ed83c32ca8534c7cbb43ed065743601c.png [Center 1]: /images/20220605/f9efe13d938944cca02a53201b74728f.png
还没有评论,来说两句吧...