redis的应用场景简述

一个产品的使用场景肯定是需要根据产品的特性,先列举一下Redis的特点:

  • 读写性能优异
  • 持久化
  • 数据类型丰富
  • 单线程
  • 数据自动过期
  • 发布订阅
  • 分布式

这里通过几个场景,不同维度说下Redis的应用。

高性能适合当做缓存

缓存是Redis最常见的应用场景,之所有这么使用,主要是因为Redis读写性能优异。而且逐渐有取代memcached,成为首选服务端缓存的组件。而且,Redis内部是支持事务的,在使用时候能有效保证数据的一致性。 作为缓存使用时,一般有两种方式保存数据:

1、读取前,先去读Redis,如果没有数据,读取数据库,将数据拉入Redis

2、插入数据时,同时写入Redis

方案一:实施起来简单,但是有两个需要注意的地方:

1、避免缓存击穿。(数据库没有就需要命中的数据,导致Redis一直没有数据,而一直命中数据库。)

2、数据的实时性相对会差一点。

方案二:数据实时性强,但是开发时不便于统一处理。

当然,两种方式根据实际情况来适用。如:方案一适用于对于数据实时性要求不是特别高的场景。方案二适用于字典表、数据量不大的数据存储。

丰富的数据格式性能更高,应用场景丰富

Redis相比其他缓存,有一个非常大的优势,就是支持多种数据类型。

数据类型说明string字符串,最简单的k-v存储hashhash格式,value为field和value,适合ID-Detail这样的场景。list简单的list,顺序列表,支持首位或者末尾插入数据set无序list,查找速度快,适合交集、并集、差集处理sorted set有序的set

其实,通过上面的数据类型的特性,基本就能想到合适的应用场景了。

  • string——适合最简单的k-v存储,类似于memcached的存储结构,短信验证码,配置信息等,就用这种类型来存储
  • hash——一般key为ID或者唯一标示,value对应的就是详情了。如商品详情,个人信息详情,新闻详情等
  • list——因为list是有序的,比较适合存储一些有序且数据相对固定的数据。如省市区表、字典表等。因为list是有序的,适合根据写入的时间来排序,如:最新的***,消息队列等
  • set——可以简单的理解为ID-List的模式,如微博中一个人有哪些好友,set最牛的地方在于,可以对两个set提供交集、并集、差集操作。例如:查找两个人共同的好友等
  • Sorted Set——是set的增强版本,增加了一个score参数,自动会根据score的值进行排序。比较适合类似于top 10等不根据插入的时间来排序的数据

如上所述,虽然Redis不像关系数据库那么复杂的数据结构,但是,也能适合很多场景,比一般的缓存数据结构要多。了解每种数据结构适合的业务场景,不仅有利于提升开发效率,也能有效利用Redis的性能。

单线程可以作为分布式锁

谈到Redis和Memcached 的区别,大家更多的是谈到数据结构和持久化这两个特性,其实还有一个比较大的区别就是:

  • Redis 是单线程,多路复用方式提高处理效率
  • Memcached 是多线程的,通过CPU线程切换来提高处理效率

所以Redis单线程的这个特性,其实也是很重要的应用场景,最常用的就是分布式锁。

应对高并发的系统,都是用多服务器部署,每个技术框架针对数据锁都有很好的处理方式,如 .net 的lock,java 的synchronized,都能通过锁住某个对象来应对线程导致的数据污染问题。但是毕竟,只能控制本服务器的线程,分布式部署以后数据污染问题,就比较难处理了。Redis的单线程这个特性,就非常符合这个需求,伪代码如下:

/产生锁

while lock!=1

//过期时间是为了避免死锁

now = int(time.time())

lock_timeout = now + LOCK_TIMEOUT + 1

lock = redis_client.setnx(lock_key, lock_timeout)

//真正要处理的业务

doing()

//释放锁

now = int(time.time())

if now < lock_timeout:

redis_client.delete(lock_key)

以上是一个只说明流程的伪代码,其实整体的逻辑是很简单的,只要考虑到死锁时的情况,就比较好处理了。Redis作为分布式锁,因为其性能的优势,不会成为瓶颈,一般会产生瓶颈的是真正的业务处理内容,还是尽量缩小锁的范围来确保系统性能。

自动过期能有效提升开发效率

Redis针对数据都可以设置过期时间,这个特点也是大家应用比较多的,过期的数据清理无需使用方去关注,所以开发效率也比较高,当然,性能也比较高。最常见的就是:短信验证码、具有时间性的商品展示等。无需像数据库还要去查时间进行对比。因为使用比较简单,就不赘述了。

分布式和持久化有效应对海量数据和高并发

Redis初期的版本官方只是支持单机或者简单的主从,大多应用则都是自己去开发集群的中间件,但是随着应用越来越广泛,用户关于分布式的呼声越来越高,所以Redis 3.0版本时候官方加入了分布式的支持,主要是两个方面:

  • Redis服务器主从热备,确保系统稳定性
  • Redis分片应对海量数据和高并发

而且Redis虽然是一个内存缓存,数据存在内存,但是Redis支持多种方式将数据持久化,写入硬盘,所有,Redis数据的稳定性也是非常有保障的,结合Redis的集群方案,有的系统已经将Redis当做一种NoSql数据存储来适用。

示例:秒杀和Redis的结合

秒杀是现在互联网系统中常见的营销模式,作为开发者,其实最不愿意这样的活动,因为非技术人员无法理解到其中的技术难度,导致在资源协调上总是有些偏差。秒杀其实经常会出现的问题包括:

  • 并发太高导致程序阻塞
  • 库存无法有效控制,出现超卖的情况

其实解决这些问题基本就两个方案:

  • 数据尽量缓存,阻断用户和数据库的直接交互
  • 通过锁来控制避免超卖现象

现在说明一下,如果现在做一个秒杀,那么,Redis应该如何结合进行使用?

  • 提前预热数据,放入Redis
  • 商品列表放入Redis List
  • 商品的详情数据 Redis hash保存,设置过期时间
  • 商品的库存数据Redis sorted set保存
  • 用户的地址信息Redis set保存
  • 订单产生扣库存通过Redis制造分布式锁,库存同步扣除
  • 订单产生后发货的数据,产生Redis list,通过消息队列处理
  • 秒杀结束后,再把Redis数据和数据库进行同步

以上是一个简略的秒杀系统和Redis结合的方案,当然实际可能还会引入http缓存,或者将消息对接用MQ代替等方案,也会出现业务遗漏的情况。

每个技术都有属于自己的应用场景,只有对技术的特点有一定清晰的认识,才能更好的利用技术,发挥其最大的优势。

原文地址:https://www.cnblogs.com/danzhihua/p/11100305.html

时间: 2024-10-28 09:13:20

redis的应用场景简述的相关文章

Redis 数据结构使用场景

Redis 数据结构使用场景 redis共有5种数据结构,每种的使用场景都是什么? 一.redis 数据结构使用场景 原来看过 redisbook 这本书,对 redis 的基本功能都已经熟悉了,从上周开始看 redis 的源码.目前目标是吃透 redis 的数据结构.我们都知道,在 redis 中一共有5种数据结构,那每种数据结构的使用场景都是什么呢? String——字符串 Hash——字典 List——列表 Set——集合 Sorted Set——有序集合 下面我们就来简单说明一下它们各自

redis的适应场景

redis应用场景: 1.对数据高并发读写 2.对海量数据的高效存储和访问 3.对数据的高可扩展性和高可用性 做分布式扩展很简单,因为没有固定的表结构 redis介绍: redis是一个key-value存储系统, key的数据类型包含:Strings,hashes,lists,set(集合),zset(有序集合) 为了保证效率,数据都是缓存在内存中,它可以周期性的保存在磁盘上. redis的适用场景: 1.应用程序直接读写redis服务器集群. 2.应用程序读写redis,redis和mysq

redis的应用场景分析

Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,并且它没有原生的可扩展机制,不具有scale(可扩展)能力,要依赖客户端来实现分布式读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上 redis的应用场景分析

Redis的应用场景

缓存 作为Key-Value形态的内存数据库,Redis 最先会被想到的应用场景便是作为数据缓存.而使用 Redis 缓存数据非常简单,只需要通过string类型将序列化后的对象存起来即可,不过也有一些需要注意的地方: 必须保证不同对象的 key 不会重复,并且使 key 尽量短,一般使用类名(表名)加主键拼接而成. 选择一个优秀的序列化方式也很重要,目的是提高序列化的效率和减少内存占用. 缓存内容与数据库的一致性,这里一般有两种做法: 只在数据库查询后将对象放入缓存,如果对象发生了修改或删除操

Redis的使用场景 by 杨卫华

转载自新浪微博架构师杨卫华的博客 http://timyang.net/tag/redis/,省略了部分内容 按:杨卫华在2010年就已经测试了Redis的性能,并给出了初步的结论:“Redis性能惊人,国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求.” 而我在今天才开始看Redis,已经落后了6年. Redis是什么?这个问题的结果影响了我们怎么用Redis.如果你认为Redis是一个key value store, 那可能会用它来代替MySQL:如果认为它是一个可

016 redis的使用场景

一 .概述 redis并不是在任何情况下都可以使用的,必须在合适的情况下使用. 二 . 缓存 redis最为常用的就是场景就是帮助实现缓存,以前的缓存都可以使用redis来完成. 三 .获取最新的N个数据 可以使用list来完成,很方便的获取前面的数据. 四 . 排行榜的使用 我们可以使用zset来完成,使用权值的方式进行set的排序. 五 .计数器 这个我们使用string类型来完成. 六 . 存储关系 比如查询A和B共同的人群. 我们可以使用set来完成. 七 . 构建系统的队列和栈结构 我

redis的应用场景 为什么用redis

一.不是万能的菲关系系数据库redis 在面试的时候,常被问比较下Redis与Memcache的优缺点,个人觉得这二者并不适合一起比较,redis:是非关系型数据库不仅可以做缓存还能干其它事情,Memcache:是仅用做缓存.常常让我们对这二者进行比较,主要也是由于Redis最广泛的应用场景就是Cache. 1.2 redis 都能干嘛 缓存,毫无疑问这是Redis当今最为人熟知的使用场景.再提升服务器性能方面非常有效: 排行榜,在使用传统的关系型数据库(mysql oracle 等)来做这个事

redis常见应用场景

目录 String应用场景 分布式锁 计数器 分布式全局唯一id(string) list应用场景 消息队列(list) 新浪/Twitter用户消息列表(list) Set应用场景 抽奖活动(set) 实现点赞,签到,like等功能(set) 实现关注模型,可能认识的人(set) 电商商品筛选(set) zset应用场景 String应用场景 分布式锁 setnx key value,当key不存在时,将 key 的值设为 value ,返回1.若给定的 key 已经存在,则setnx不做任何

redis 购物网站应用场景

1.cookies 登录信息记录: cookies记录登录信息有两种方式: 客户端记录登录的信息,过期时间,用户ID等,然后对信息进行签名: 优点:实现简单,分担了服务器的压力: 缺点:签名的过程,容易导致安全漏洞,(忘记签名),服务器分析用户行为不方便: token方式,cookies记录一串随机码,服务器将用户的相关信息关联该随机码: 优点:安全,请求的数据量小: 缺点:增加了服务器的压力. token实现方式可以用借助redis实现,相比关系数据库,redis有更好的读写性能,吞吐量更大.