Redis应用场景简介

淩亂°似流年 2022-01-11 06:23 287阅读 0赞

REmote DIctionary Server(Redis)是完全开源免费的，遵守 BSD 协议，是一个高性能的key-value数据库。它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Hash), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。

注：BSD开源协议（original BSD license、FreeBSD license、Original BSD license）是一个给于使用者很大自由的协议，BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。

一个产品的使用场景肯定是需要根据产品的特性，所以下面根据Redis特点延伸对应的应用场景。

Redis的特点有7个，分别是：读写性能优异，数据类型丰富，单线程，数据自动过期，支持发布订阅，分布式，持久化。

## 1. 读写性能优异 ##

高性能适合当做缓存，缓存是Redis最常见的应用场景，之所以这么使用，主要是因为Redis读写性能优异。而且逐渐有取代memcached成为首选服务端缓存组件的趋势，而且，Redis内部是支持事务的，在使用时候能有效保证数据的一致性。

作为缓存使用时，一般有两种方案保存数据：

### 1.1 方案1 ###

读取前，先去读Redis，如果没有数据，读取数据库，将数据拉入Redis。

1.  **使用场景：**适用于对于数据实时性要求不是特别高的场景。
2.  **该方案实施起来简单，但是有两个需要注意的地方**
    
    1.  避免缓存击穿。（数据库没有就需要命中的数据，导致Redis一直没有数据，而一直命中数据库。）使用redis的 setnx方法构建一个互斥锁，只有一个请求线程获得锁去更新数据，其他请求等待，之后去请求最新缓存。
    2.  数据的实时性相对会差一点。

### 1.2 方案2 ###

插入数据时，同时写入Redis。

1.  **使用场景：**适用于字典表、数据量不大的数据存储。

## 2. 数据类型丰富 ##

Redis相比其他缓存，有一个非常大的优势，就是支持多种数据类型。

Redis最为常用的数据类型主要有以下五种：

### 2.1. String ###

String 数据结构是简单的key-value类型，value其实不仅是String，也可以是数字。

**2.1.1.　常用命令**  
get、set、incr、decr、mget等。  
**2.1.2.　使用场景**  
常规key-value缓存应用适合最简单的k-v存储，类似于memcached的存储结构，常规计数（微博数, 粉丝数），短信验证码，配置信息等，就用这种类型来存储。  
**2.1.3.　实现方式**  
String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。

### 2.2. Hash ###

hash格式，hash类型的格式为：键名->字段名，适合ID-Detail这样的场景。

**2.2.1.　常用命令**  
hget,hset,hgetall 等。  
**2.2.2.　使用场景**  
存储部分变更数据，如商品详情，个人信息详情，新闻详情等。  
**2.2.3.　实现方式**  
Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现：

*  当Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap。
 *  当成员数量增大时会自动转成真正的HashMap，此时encoding为ht。

### 2.3.　List ###

简单的list，顺序列表，支持首位或者末尾插入数据

**2.3.1.　常用命令**  
lpush,rpush,lpop,rpop,lrange等。  
**2.3.2.　使用场景及实现方式**  
因为list是有序的，比较适合存储一些有序且数据相对固定的数据。如省市区表、字典表等，适合根据写入的时间来排序，如：最新的\*\*\*，消息队列等。  
**2.3.2.1.　消息队列系统**  
使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。  
比如：将Redis用作日志收集器  
实际上还是一个队列，多个端点将日志信息写入Redis，然后一个worker统一将所有日志写到磁盘。  
**2.3.2.2.　取最新N个数据的操作**  
记录前N个最新登陆的用户Id列表，超出的范围可以从数据库中获得。  
比如sina微博：  
     在Redis中我们的最新微博ID使用了常驻缓存，这是一直更新的。但是我们做了限制不能超过5000个ID，因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候，才需要去访问数据库。  
    我们的系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

### 2.4.　Set ###

无序list，查找速度快，适合交集、并集、差集处理

**2.4.1.　常用命令**  
sadd,spop,smembers,sunion 等。  
**2.4.2.　使用场景**  
可以简单的理解为ID-List的模式，如微博中一个人有哪些好友，set最牛的地方在于，可以对两个set提供交集、并集、差集操作。例如：查找两个人共同的好友等。  
**2.4.3.　实现方式**  
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

### 2.5.　Sorted set ###

有序的set

**2.5.1.　常用命令**  
zadd,zrange,zrem,zcard等  
**2.5.2.　使用场景**  
是set的增强版本，增加了一个score参数，自动会根据score的值进行排序。比较适合类似于top 10等不根据插入的时间来排序的数据。  
比如：一个存储全班同学成绩的Sorted Set，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用Sorted Set来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。  
**2.5.3.　实现方式**  
Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

## 3.　单线程 ##

*  谈到Redis和Memcached 的区别，大家更多的是谈到数据结构和持久化这两个特性，其实还有一个比较大的区别就是：Redis 是单线程，多路复用方式提高处理效率。所以Redis单线程的这个特性，其实也是很重要的应用场景，最常用的就是分布式锁。
 *  Redis作为分布式锁，因为其性能的优势，不会成为瓶颈，一般会产生瓶颈的是真正的业务处理内容，还是尽量缩小锁的范围来确保系统性能。

## 4.　数据自动过期 ##

*  自动过期能有效提升开发效率。
 *  Redis针对数据都可以设置过期时间，这个特点也是大家应用比较多的，过期的数据清理无需使用方去关注，所以开发效率也比较高，当然，性能也比较高。最常见的就是：短信验证码、具有时间性的商品展示等。无需像数据库还要去查时间进行对比。

## 5.　发布订阅 ##

Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。  
5.1.　**常用命令：**PSUBSCRIBE，PUBSUB，PUBLISH，SUBSCRIBE，PUNSUBSCRIBE，UNSUBSCRIBE等。  
5.2.　**使用场景**

1.  构建实时消息系统，比如普通的即时聊天，群聊等功能。
2.  订阅某个channel的信息
3.  发布信息到某个channel上
4.  简单的应用场景的话, 以门户网站为例, 当编辑更新了某推荐板块的内容后:CMS发布清除缓存的消息到channel (推送者推送消息)，门户网站的缓存系统通过channel收到清除缓存的消息 (订阅者收到消息)，更新了推荐板块的缓存

5.3.　**实现方法**  
Redis提供了发布订阅功能，可以用于消息的传输，Redis的发布订阅机制包括三个部分，发布者，订阅者和Channel。  
发布者和订阅者都是Redis客户端，Channel则为Redis服务器端，发布者将消息发送到某个的频道，订阅了这个频道的订阅者就能接收到这条消息。

> Redis的这种发布订阅机制与基于主题的发布订阅类似，Channel相当于主题。

## 6.　分布式和持久化两个特点 ##

可以有效应对海量数据和高并发。  
Redis 3.0版本时候官方加入了分布式的支持，主要是两个方面：

*  Redis服务器主从热备，确保系统稳定性
 *  Redis分片应对海量数据和高并发

而且Redis虽然是一个内存缓存，数据存在内存，但是Redis支持多种方式将数据持久化，写入硬盘，所以，Redis数据的稳定性也是非常有保障的，结合Redis的集群方案，有的系统已经将Redis当做一种NoSql数据存储来使用。  
**6.1.　持久化**  
如果Redis服务器只作为缓存使用，Redis中存储的数据来自其他地方同步过来的备份，那么就没有必要开启数据持久化的选项。  
Redis提供了将数据定期自动持久化至硬盘的能力，包括RDB和AOF两种方案，两种方案分别有其长处和短板，可以配合起来同时运行，确保数据的稳定性。  
**6.1.1.　RDB**  
定期保存数据快照至一个rbd文件中，并在启动时自动加载rdb文件，恢复之前保存的数据。  
**6.1.1.1.　优点**  
1)    对性能影响最小：Redis在保存RDB快照时会fork出子进程进行，几乎不影响Redis处理客户端请求的效率。  
2)    每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照（例如把每天0点的快照备份至其他存储媒介中），作为非常可靠的灾难恢复手段。  
3)    使用RDB文件进行数据恢复比使用AOF要快很多。  
**6.1.1.2.　缺点**  
1)    由于快照是定期生成的，所以在Redis crash时或多或少会丢失一部分数据。  
2)    如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力。  
**6.1.1.3.　实现方式**  
**6.1.1.3.1.　自动保存**  
修改配置文件，配置Redis进行快照自动保存的时机，例如：  
save 60 100  
让Redis每60秒检查一次数据变更情况，如果发生了100次或以上的数据变更，则进行RDB快照保存。  
注：  
1)    可以配置多条save指令，让Redis执行多级的快照保存策略。  
2)    Redis默认开启RDB快照。  
**6.1.1.3.2.　手动保存**  
通过BGSAVE命令手动触发RDB快照保存。  
**6.1.2.　AOF**  
Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。  
**6.1.2.1.　优点**  
1)    最安全：在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据。  
2)    AOF文件在发生断电等问题时也不会损坏：即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。  
3)    AOF文件易读，可修改：在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。  
**6.1.2.2.　缺点**  
1)    AOF文件通常比RDB文件更大  
2)    性能消耗比RDB高  
3)    数据恢复速度比RDB慢  
**6.1.2.3.　实现方式**  
AOF默认是关闭的，如要开启，进行如下配置：  
appendonly yes  
AOF提供了三种fsync配置，always/everysec/no，通过配置项\[appendfsync\]指定：  
1)    appendfsync no：不进行fsync，将flush文件的时机交给OS决定，速度最快  
2)    appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢  
3)    appendfsync everysec：折中的做法，交由后台线程每秒fsync一次  
随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大，也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。  
AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：  
auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb  
上面两行配置的含义是，Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。  
**6.1.3.　数据持久化引发的延迟**  
Redis的数据持久化工作本身就会带来延迟，需要根据数据的安全级别和性能要求制定合理的持久化策略：  
1)    AOF + fsync always的设置虽然能够绝对确保数据安全，但每个操作都会触发一次fsync，会对Redis的性能有比较明显的影响  
2)    AOF + fsync every second是比较好的折中方案，每秒fsync一次  
3)    AOF + fsync never会提供AOF持久化方案下的最优性能  
4)    使用RDB持久化通常会提供比使用AOF更高的性能，但需要注意RDB的策略配置  
5)    每一次RDB快照和AOF Rewrite都需要Redis主进程进行fork操作。fork操作本身可能会产生较高的耗时，与CPU和Redis占用的内存大小有关。根据具体的情况合理配置RDB快照和AOF Rewrite时机，避免过于频繁的fork带来的延迟。

## 7.　使用redis数据库的公司实例 ##

**7.1.　新浪微博**  
大多数的数据还是落地到mysql的，按照那边DB组同学说法，mysql在新浪只用来存储数据，Redis是用来抗量的。  
**7.2.　百度的LBS（基于位置服务——Location Based Service）**  
大量的使用Redis，很多信息都交给Redis来存储，不过同样也是对Redis进行了定制和扩展——增加了数据切分、服务监控、自动扩容等。 按照业务来看，核心业务建议数据还是落地到mysql，redis在异常情况下回丢数据。

## 8.　按照发展阶段来分析redis的使用 ##

**8.1.　产品初期**  
业务需求多变，数据量很小，数据结构朝令夕改，这时候如果用mysql很有可能会在改数据库结构上疲于奔命，如果用Redis，由于没有Scheme约束，数据结构的变更相对容易，比起mysql能轻松不少。  
**8.2.　产品中期**  
业务需求逐渐稳定，可以将核心数据导到mysql中落地，其余数据仍然放在Redis中。  
**8.3.　产品后期**  
业务需求基本稳定，数据应该尽量都落地到mysql，Redis做高速缓存，或者先写到Redis，再异步刷到mysql。

## 9.　总结 ##

*  非核心业务，比如运营推广，数据聚合统计这种允许数据少量丢失的业务可以全用redis，扩展方便，效率高，业务量也不大。特别是运营推广这种时效性很强的业务，在推广结束后数据接没用了，Redis内存压力也不会很大。
 *  redis是目前公认的速度最快的基于内存的键值对数据库，但redis的缺点也非常明显，仅提供最基本的hash set, list, sorted set等基于数据类型，不分表，没有schema，没有索引，没有外键，缺少int/date等基本数据类型，多条件查询需要通过集合内联(sinter,zinterstore)和连接间接实现，操作不便，开发效率低，可维护性不佳；因此一般不将其视为完整的数据库单独使用，很多网站将redis作为高速缓存和session状态存储层，然后再配合关系型数据库做高速缓存，缓存高频次访问的数据，降低数据库io。

## 10. 参考链接 ##

[Redis-使用场景][Redis-]

[Redis高级特性及应用场景][Redis]

[redis学习（八）——redis应用场景][redis_redis]

[Redis发布订阅和应用场景][Redis 1]

[聊聊redis数据持久化][redis]

[Redis 可以用来做数据库吗][Redis 2]

> 最后，谢谢各位读者的耐心阅读，如有语句不通顺或者不准确的地方，大家也可以提提改善的意见！(*^\_\_^*)

[Redis-]: https://blog.csdn.net/sinat_27143551/article/details/80599170
[Redis]: https://www.cnblogs.com/tianciliangen/p/7942560.html
[redis_redis]: https://www.cnblogs.com/xiaoxi/p/7007695.html
[Redis 1]: https://blog.csdn.net/fly910905/article/details/78495971
[redis]: https://baijiahao.baidu.com/s?id=1611955931705092609&wfr=spider&for=pc
[Redis 2]: https://blog.csdn.net/bigtree_3721/article/details/80101754