redis的应用场景 为什么用redis

一、不是万能的菲关系系数据库redis

在面试的时候,常被问比较下Redis与Memcache的优缺点,个人觉得这二者并不适合一起比较,redis:是非关系型数据库不仅可以做缓存还能干其它事情,Memcache:是仅用做缓存。常常让我们对这二者进行比较,主要也是由于Redis最广泛的应用场景就是Cache。

1.2 redis 都能干嘛

  1. 缓存,毫无疑问这是Redis当今最为人熟知的使用场景。再提升服务器性能方面非常有效;
  2. 排行榜,在使用传统的关系型数据库(mysql oracle 等)来做这个事儿,非常的麻烦,而利用Redis的SortSet(有序集合)数据结构能够简单的搞定;
  3. 计算器/限速器,利用Redis中原子性的自增操作,我们可以统计类似用户点赞数、用户访问数等,这类操作如果用MySQL,频繁的读写会带来相当大的压力;限速器比较典型的使用场景是限制某个用户访问某个API的频率,常用的有抢购时,防止用户疯狂点击带来不必要的压力;
  4. 好友关系,利用集合的一些命令,比如求交集、并集、差集等。可以方便搞定一些共同好友、共同爱好之类的功能;
  5. 简单消息队列,除了Redis自身的发布/订阅模式,我们也可以利用List来实现一个队列机制,比如:到货通知、邮件发送之类的需求,不需要高可靠,但是会带来非常大的DB压力,完全可以用List来完成异步解耦;
  6. Session共享,以PHP为例,默认Session是保存在服务器的文件中,如果是集群服务,同一个用户过来可能落在不同机器上,这就会导致用户频繁登陆;采用Redis保存Session后,无论用户落在那台机器上都能够获取到对应的Session信息。
  7. 一些频繁被访问的数据,经常被访问的数据如果放在关系型数据库,每次查询的开销都会很大,而放在redis中,因为redis 是放在内存中的可以很高效的访问

1.3 最好别用redis 来做

用Redis去保存用户的基本信息,虽然它能够支持持久化,但是它的持久化方案并不能保证数据绝对的落地,并且还可能带来Redis性能下降,因为持久化太过频繁会增大Redis服务的压力。

总结就是数据量太大、数据访问频率非常低的业务都不适合使用Redis,数据太大会增加成本,访问频率太低,保存在内存中纯属浪费资源。

使用redis的理由

上面所说的一些场景, 缓存可以用Memcache,Session共享能用MySql来实现,消息队列可以用RabbitMQ等,

理由:
完全基于内存所以速度很快,使用C语言实现,网络层使用epoll解决高并发问题,单线程模型避免了不必要的上下文切换及竞争条件; 注意:单线程仅仅是说在网络请求这一模块上用一个请求处理客户端的请求,在持久化时它就会重开一个线程/进程去进行处理

丰富的数据类型,Redis有8种数据类型,常用的有 String、Hash、List、Set、 SortSet 这5种,都是基于键值的方式组织数据。每一种数据类型提供了非常丰富的操作命令,可以满足绝大部分需求

Redis的代码开源在GitHub,代码非常简单优雅,愿意花时间就能去看懂;它的编译安装也很简单,不存在其他系统依赖;各种客户端的语言支持也是非常完善。另外它还支持事务、持久化、主从复制让高可用、分布式成为可能。

原文地址:https://www.cnblogs.com/shiqi17/p/9581752.html

时间: 2024-10-27 19:01:19

redis的应用场景 为什么用redis的相关文章

Redis 数据结构使用场景

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

NoSQL初探之人人都爱Redis:(3)使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时呢,也使响应延迟加剧.这也说明

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的应用场景分析

【转】NoSQL初探之人人都爱Redis:(3)使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时呢,也使响应延迟加剧.这也说明

Redis的应用场景

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

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的应用场景简述

一个产品的使用场景肯定是需要根据产品的特性,先列举一下Redis的特点: 读写性能优异 持久化 数据类型丰富 单线程 数据自动过期 发布订阅 分布式 这里通过几个场景,不同维度说下Redis的应用. 高性能适合当做缓存 缓存是Redis最常见的应用场景,之所有这么使用,主要是因为Redis读写性能优异.而且逐渐有取代memcached,成为首选服务端缓存的组件.而且,Redis内部是支持事务的,在使用时候能有效保证数据的一致性. 作为缓存使用时,一般有两种方式保存数据: 1.读取前,先去读Red

在微博微信场景下学习Redis数据结构

Redis安装 下载地址:http://redis.io/download 安装步骤: 1.yum install gcc 2.wget http://download.redis.io/releases/redis‐5.0.3.tar.gz tar xzf redis‐5.0.3.tar.gz cd redis‐5.0.3 3.make 4.src/redis‐server redis.conf(注意要使用后台启动,所以修改redis.conf里的daemonize改为y es) 5.ps ‐