阅读 272

深入了解redis(一)——redis的前世今生

前言

其实本人我也不是很了解redis,通过写文章的过程中,我也学习一下redis。

以下是redis的部分相关资料,大家可以了解一下。

redis的创始者:Salvatore Sanfilippo,

大佬的网名:antirez

大佬的博客:antirez.com

大佬的github地址github.com/antirez

redis官网redis.io/

最后送上大佬的照片一张:

居然还有点帅,真的是不让人活了。

redis的概念

redis是一个开源的数据库,它是c语言编写的,是一个当前业界非常出名,也普遍都在使用的key-value数据库,它支持网络交互性,是基于内存存储数据的,当然也支持持久化的。

一般来说,我们使用redis都是用来做三个用途:

1.数据库
2.缓存
3.消息中间件
4.分布式锁
复制代码

当然,除了这四种以外,也会被用来做其他的作用,比如说比较经典的是使用redis的自增incr命令来使id自增来生成分布式Id。还有其他的作用,大家如果感兴趣,可以自己去了解了解。

接下来,我们来深入了解一下redis在实际的生产过程中具体的作用。

redis作为数据库

redis从广义数据库的定义来说,确实是可以当数据库来使用,但是我们都知道,我们在谈论数据库的时候,我们的标准是mysql,oracle这种关系型数据库,当然,我们存储数据的时候,并不是说一定要是关系型的数据库存储,也可以改换方式来存储,从这种意义上来讲,redis也确实可以当做数据存储的数据库来使用。

但是既然使用redis当作我们的存储数据库,那我们必须要考虑一下,当使用redis来作为我们的数据,那么都会出现那些问题呢?

1.当习惯了使用关系型数据库这种强逻辑性的数据库来进行开发的开发人员来说,使用redis当做存储数据库的时候,
是否能保证redis里面存储的数据库的正确性和低冗余呢?

2.因为redis是内存型的数据库,如果数据量特别大的情况下,这使用的成本是否需要考虑下?而且数据量太大的话,
redis的扩增和转移数据,是否有可靠的方案支撑?

3.当使用redis作为数据库,是否有可靠的事务方案保持数据的一致性呢?

4.当我们的业务需要的数据非常复杂的情况下,redis因为其薄弱的关系性和逻辑性,是否能满足业务对数据的查询呢?

5.由于redis是保存在内存中,一旦出现redis宕机或者断电的情况,如何保证数据不丢失?当然,redis也可以做持久
化,AOF和RDB这两种方案确实可以保证大部分数据的完好无损,但是还是会极少数的数据会丢失,那么我们的业务需求
是否能接受这部分的数据丢失呢?
复制代码

问题提了这么多,那么,redis到底是否能够当作数据库来使用呢?

我觉得是可以的!

如果你能保证你的业务需求上,对数据没有极高的准确性要求,且数据的读取压力很大,而且数据之间的业务逻辑性不强,那么你就可以使用redis当作数据库使用。

其实,在业界,已经有了使用redis当做数据库的公司,这个公司就是新浪微博!而且一些游戏公司,视频公司,也都开始使用redis当做数据库,而这些公司的一部分需求,如果当作一个独立的项目来看,是可以符合我们对redis数据库的要求的。

还有一些方案,就是前端可以使用redis当作前端数据库,不过要前端需要封装一层lua的逻辑,用来封装数据库的业务逻辑。

redis作为缓存

redis当做缓存来使用,是redis在当前业界最常见的做法。

如果在系统中,有一部分数据,它的读的操作远远大于写的操作,那么我们就可以将这部分数据放到redis中,目的是为了减轻我们数据库的压力,而且redis的响应能力远远大于mysql和oracle,会大大的提高用户体验。

而且,如果数据库的压力太大的话,会造成数据库的崩溃宕机,而redis可以分担一部分访问请求,减轻了数据库的压力。

当然,我们也要注意redis可能产生的缓存雪崩等问题,如果真的出现这种情况,将会整个存储系统击溃,那么就会造成巨大的损失。

redis作为消息中间件

redis在创造的时候,从来不是用来当作中间件而存在的,但是在实际开发中,有太多的用户使用redis当作中间件,倒逼着redis的创始人antirez,基于redis的核心代码,另外实现了一个消息队列disque。部署、协议等方面都跟redis非常类似,并且支持集群,延迟消息等等。

那么,为什么这么多人会使用redis来做消息队列呢?

因为redis自带了两种和队列密切相关的机制,PUB/SUB模式和PUSH/POP模式,这两种模式,在大多数消息中间件中大规模的用到了,于是很多开发者基于redis这两种机制,把redis当作了消息中间件来使用。据我的经验来看,如果你的业务的日活是在百万级以下,那么可以使用redis来当消息中间件,但是超过了百万级别的话,那么使用redis就无法满足了,或者说使用redis就会变得很复杂了,如果这个时候转向使用kafka或者其他的MQ,其实也不麻烦,学习成本也不高。

所以,在业务是在百万日活以下的朋友们,可以放心大胆的使用redis当做消息中间件!

redis作为分布式锁

为什么可以使用redis作为分布式锁呢,其主要的原因是redis是单进程单线程的模式,所有的请求到了redis都是变成了队列,由并行模式变为了串行模式,因此,在redis中,各个请求是没有竞争关系的。

了解过分布式锁的朋友应该都知道,分布式锁是有其条件存在的,条件如下

1.互斥性。在任意时刻,只有一个客户端能持有锁。
2.不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
3.具有容错性。只要大部分的Redis节点正常运行,客户端就可以加锁和解锁。
4.解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。
复制代码

而redis就恰好能满足我们的要求,引入Jedis开源组件,redis中有一个方法:

jedis.set(String key, String value, String nxxx, String expx, int time)
复制代码

这个方法,就是redis中用来使用分布式锁的方法,

后记

今天的redis的学习就先到这儿,后续我们将继续深入学习redis。

关注下面的标签,发现更多相似文章
评论