刚接触 Redis 的伙伴们可能会因为不熟悉而感到困惑。本文简述 Redis 是什么、有哪些作用的问题,是一篇短浅而入门级别的文章。
Redis官网:Redis
打开 Redis 官网可以看到,官方对 Redis 的介绍是这样的:The open source, in-memory data store used by millions of developers as a database, cache, streaming engine, and message broker.
关于 Redis 的定位和作用,由这个官方定义可知:
下面就从以上几个角度来简单说明。
目录
Redis的数据存储是在内存中的。
那么问题来了:既然是将值存储在内存中,那普通的变量也可以做到,为什么还需要 Redis 呢?
因为事实上,Redis的使用场景是分布式系统而非单机程序。只有在分布式系统中它才能真正发挥威力。如果只是单机程序,直接通过变量存储数据的方式是比Redis更优的选择,但在分布式系统中,一个分布式系统势必涉及到多个进程,这多个进程在不同的主机上,由于进程的隔离性,此时要直接访问其它进程内存中的变量是很困难的,Redis正是对这个需求点进行了封装。
进程间通信往往依靠网络。网络这种方式既可以实现同一个主机的多个进程间通信,还能实现跨主机的进程通信。Redis 基于网络,可以把自己内存中的变量给别的进程(甚至别的主机的进程)使用。
总而言之,Redis的使用紧紧围绕三个字:分布式。抛开分布式系统,Redis就没有太大的优势了。
MySQL是大家更为熟知的一种数据库。MySQL确实可以在一个分布式系统中帮助我们存储数据,同时也能提供丰富和强大的功能,但它有一个最大的问题:访问速度比较慢。如今一些互联网产品对于性能的要求是很高的,这样一来,MySQL就显得有些力不从心。
而Redis相较于MySQL的优点就是更快,而且快很多。因为MySQL的数据存储在硬盘上,而Redis的数据在内存中。内存的访问速度比硬盘的访问速度快几个数量级,差距非常大。另一方面,MySQL为了支持像数据约束等一系列机制,往往会在一次查询中涉及多次的IO访问,让本不富裕的性能更加雪上加霜。(由于Redis和MySQL支持的功能和使用的场景都有一定差异,所以很难定量地衡量二者的性能如何,只能从定性的角度知道Redis快很多。)
这样一来,Redis也就有了用作数据库进行数据存储的市场。
但是作为数据库,Redis也有缺点。它和MySQL相比最大的劣势在于存储空间有限。内存虽然访问速度快,但是容量小。因此,如果对于性能的要求并不是那么高,但同时又希望以更低的成本存储更多的数据,MySQL是首选。MySQL也比Redis提供了更丰富的增删改查能力。
Redis更“快”,MySQL更“大”,那么能不能做到又大又快?
这就是Redis的又一个用途:缓存。
要做到“又大又快”,典型的方案是把Redis和MySQL结合起来使用,把Redis作为MySQL的cache。
使用方式是把热点数据用Redis来存储,把全量数据使用MySQL来存储。依照“二八原则”,即20%热点数据往往能满足80%的访问需求。我们把一部分热点数据拿出来放在Redis里,当用户访问这些常用数据时,访问的是Redis,就会更快。同时全量数据仍然存储在MySQL中。
Redis在分布式系统中最主要的作用就是扮演缓存的角色。
这样做的代价是,系统的复杂程度大大提升了。而且如果数据发生修改,还涉及到Redis和MySQL之间的数据同步问题。
究竟如何安排,需要看实际的应用场景,在哪个场景下怎样进行的安排更加合适,没有哪一种方式是“万金油”。
Redis被研发出来的初心其实就是用来作为消息中间件(消息队列),实现分布式系统下的生产者消费者模型。(注意:此处的消息队列与Linux进程间通信的那个消息队列不是一回事。)
2008 年,Redis 的作者 Salvatore Sanfilippo 在开发⼀个叫 LLOOGG 的网站时,需要实现⼀个高性能的队列功能,最开始是使用 MySQL 来实现的,但后来发现无论怎么优化 SQL 语句等都不能使网站的性能提高上去,再加上自己囊中羞涩,于是他决定自己做一个专属于LLOOGG 的数据库,这个就是 Redis 的前身。
但实际中,以redis作为消息队列的反而比较少。业界也有很多知名的消息队列,如 RabbitMQ, Kafka,RocketMQ等。这些消息队列的功能比 Redis 更强大更丰富。虽然Redis也提供了消息队列的功能,甚至在Redis最新的几个版本中也有相关特性在更新,但即使如此,实际中也很少直接用Redis作为消息队列。
如果当前场景中对于消息队列的功能依赖的不是很多,并且又不想引入额外的依赖了,那么Redis可以作为一个选择。