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的原理，并阅读源码，这样我们在开发和运维时，就能提前规避很多问题，甚至做出定制化开发。