Redis使用场景概况

Redis的使用场景系列文章目录



前言

本系列文章基本参考付磊、张益军的《Redis开发与运维》。同时参考了网上其他的一些资料。

说到Redis的使用场景,大家想到一般都应该是缓存吧。确实,Redis执行命令的速度非常快,用作磁盘和内存之间的缓存非常合适。然而Redis的设计者最初其实是想要实现一个高性能的队列功能,然后可能连他也没有想到,Redis最后会在如此多的场景下都收到强烈追捧。

想要理解Redis在不同场景下的使用,我们必须要先了解Redis本身的特性,已经Redis可以做什么,不能做什么。本篇文章就大概总结一下这两个问题。


一、Redis的特性

1. 速度快

前面说过,Redis执行命令的速度非常快,官方给出的数据是读速度能到达11W/秒,写也能达到8.1W/秒。不考虑机器性能差异的情况下,Redis能达到如此快速的原因也有以下几点:

  1. 数据全部存放在内存中 毫无疑问这是Redis速度快最主要的原因。数据存放在内存中,那么所有操作都是基于内存的操作,速度自然快。
  2. C语言实现 我们知道C语言是离操作系统更近的语言,使用C语言自然能在一定程度上提高执行速度。当然,代码本身质量高也是一个因素。
  3. 单进程单线程架构 CPU的速度是远远大于内存速度的,内存速度又远远大于磁盘速度。一般情况下我们会认为多进程多线程的速度会更快,比如Nginx的多进程单线程,memcached的单进程多线程等。但是Redis基于I/O多路复用技术采用单进程单线程模式,进一步避免了竞争造成的开销,加快了执行速度。

2. 数据存储基于键值对

Redis是键值对数据库,同时,Redis的值并不局限于字符串,还可以是具体的数据结构,这就方便了不同的应用场景开发,大大提高了开发效率。Redis有5中基本数据结构:字符串、哈希、列表、集合、有序集合。本系列文章也主要基于这5种数据结构的应用。

3. 功能丰富

    过期功能,可以用于实现缓存 发布订阅功能,可以用于实现消息系统 Lua脚本功能,可以用于自定义功能 Pipeline功能,批量传输命令,减少网络开销

4. 数据库简单稳定

简单主要表现在源码少、单线程模式、不依赖系统类库三个方面。稳定就不说了,基本没有出现过因Redis自身问题宕机的情况。

5. 客户端语言多

无需多言,几乎所有主流编程语言都有Redis客户端。除了Redis本身的流行,从技术角度而言还有两个原因:

  1. 基于TCP协议实现通信
  2. 指定RESP(Redis Serialization Protocol,Redis序列化协议)实现交互

6. 提供数据持久化功能

  1. RDB:手动或定期触发、将当前进程全量数据以快照形式保存至硬盘
  2. AOF:以独立日志方式实时记录每次写命令,需定期重写AOF文件实现文件压缩

7. 主从复制

提供复制功能,实现数据副本。

8. 高可用和分布式

Sentinel哨兵保证Redis节点的故障发现和自动转移。Redis Cluster则跟一般集群一样实现真正分布式,提供高可用、读写和容量的扩展。

二、使用场景

1.Redis可以做什么

Redis的可以做的事情很多,下面列出常用的几种使用场景:

  1. 缓存:依赖键值过期时间设置以及最大内存和内存溢出后的淘汰策略等
  2. 排行榜:依赖列表和有序集合等数据结构
  3. 计数器:依赖计数功能
  4. 消息队列:依赖发布订阅功能和阻塞队列功能,可以满足一般消息队列功能需求。
  5. 不适合关系型数据库但访问频繁的数据:比如下拉列表,共同好友等。

2.Redis不可以做什么

从技术本身的角度来说,只要能够实现我们需要的功能,那么就没有什么是不可以做的。但是技术应用则一定会有自己的应用场景和边界。Redis本身自然也有很多不适合它解决的问题,比如:

  1. 海量数据。Redis数据存放在内存中,本身成本就相对较高,海量数据存储必然无限提高经济成本。
  2. 冷数据。数据操作频次很低甚至几近于无,完全没有必要存储在Redis中。

简单来说,就是从经济成本考虑,衡量效率与成本,投入产出比是我们技术选型时必须要考虑的问题。当然,投入不仅仅是经济成本,还有人力成本,如果有些问题Redis虽然也能解决,经济成本也不高,但是实现复杂,也不应该作为首选方案。

总结

Redis本身功能丰富,是否适合我们的应用场景需要多方面衡量,当然前提是我们对Redis和场景本身都足够了解。就Redis而言,最好能够了解Redis的原理,并阅读源码,这样我们在开发和运维时,就能提前规避很多问题,甚至做出定制化开发。

经验分享 程序员 微信小程序 职场和发展