Redis学习总结(8)——Redis常见使用场景总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u012562943/article/details/82664826

1、缓存

在目前的互联网网站中,缓存几乎是网站都在用的,合理的使用缓存不但可以提升网站访问速度,还可以大大降低数据库的压力。Redis不仅提供了键过期功能,也提供了灵活的键淘汰策略,而且拥有相比memcached更丰富的数据类型。所以,现在Redis用在缓存的场合非常多。

2、排行榜

很多网站都有排行榜的展示,如天猫的月度销量榜单、商品按时间的上新排行榜等。使用Redis提供的有序集合数据结构能方便的实现各种复杂的排行榜。

3、计数器

计数器就是像电商网站商品的浏览量、视频网站视频的播放数等等。为了保证数据实时效,每次浏览都得给+1,如果使用数据库存储,那么并发量高时如果每次都请求数据库的压力会比较大。可以使用Redis提供的incr命令来实现计数器功能,内存操作,性能非常好,非常适用于这些计数场景。

4、最新列表

Redis列表LIST结构,LPUSH可以在列表头部插入一个内容ID作为关键字,LTRIM用来修建LIST以限制LIST的长度,这样列表永远为N个ID,无需查询最新的列表,直接根据ID去到对应的内容页即可。

5、分布式Session

前面的文章讲过,可以使用Redis做session管理,以实现分布式下的session共享。

6、分布式锁

在很多互联网公司中都使用了分布式技术,分布式技术带来的技术挑战是对同一个资源的并发访问,如全局ID、减库存、秒杀等场景,并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现,但在并发量高的场合中,利用数据库锁来控制资源的并发访问是不太理想的,大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁,如果设置返回1说明获取锁成功,否则获取锁失败,实际应用中要考虑的细节要更多。

7、 社交网络

点赞、踩、关注/被关注、共同好友等是社交网站的基本功能,社交网站的访问量通常来说比较大,而且传统的关系数据库类型不适合存储这种类型的数据,Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。

8、消息系统

消息队列是大型网站必用中间件,如RocketMQ、RabbitMQ、Kafka等流行的消息队列中间件,主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能,能实现一个简单的消息队列系统。另外,这个不能和专业的消息中间件相比。

附:不适合使用Redis场景思考

1,从数据规模角度

从数据规模的角度来看,数据可以分为大规模数据和小规模数据。我们知道Redis是将数据存在内存中,目前来讲,相对于磁盘而言内存还是比较贵的,如果将大规模数据全放在内存里,成本上考虑还是不合适的。而且据我所知,现在运维上内存扩容还是要停机的,磁盘可以在线扩容。

2,从冷热数据的角度

很多业务数据可以分为冷数据和热数据。热数据就是应用需要频繁使用的数据。如果将大量的冷数据放在内存里,那就是对内存的一种浪费。所以应该从业务场景上区分出冷热数据,区别对待。只将热数据放在内存中,加速数据读写,也可降低后端存储的压力。另外在使用上,Redis的运维同样重要。很多使用 Redis 的开发者认为只要会用 API 开发相应的功能就可以,更有甚者认为 Redis 就是 get、set、del,不需要知道 Redis 的原理。很多线上的故障和问题都是由于完全把 Redis 当做黑盒造成的,如果不了解 Redis 的单线程模型,有些开发者会在有上千万个键的 Redis 上执行 keys*操作,如果不了解持久化的相关原理,会在一个写操作量很大的 Redis 上配置自动保存 RDB。而且在很多公司内只有专职的关系型数据库 DBA,并没有 NoSQL 的相关运维人员,也就是说开发者很有可能会自己运维 Redis,对于 Redis 的开发者来说既是好事又是坏事。站在好的方面看,开发人员可以通过运维 Redis 真正了解 Redis 的一些原理,不单纯停留在开发上。站在坏的方面看,Redis 的开发人员不仅要支持开发,还要承担运维的责任,而且由于运维经验不足可能会造成线上故障。但是从实际经验来看,运维足够规模的 Redis 会对用好 Redis 更加有帮助。

没有更多推荐了,返回首页