redis适合存储什么数据,如何评估数据适不适合放入Redis中？

当项目中引入了 Redis 做分布式缓存，那么就会面临这样的问题：

• 哪些数据应该放到缓存中？依据是什么？
• 缓存数据是采用主动刷新还是过期自动失效？
• 如果采用过期自动失效，那么失效时间如何制定？

正好这两周我们项目做了相关的评估，把过程记录下来和大家分享分享；当然过程中用到了很多“笨办法”，如果你有更好的办法，也希望能分享给我。

01. 项目背景

我们的项目是一个纯服务平台，也就是只提供接口服务，并没有操作页面的，项目的接口日调用量大约在 200 万次，高峰期也就 1000 万出头，因为大部分接口是面向内部系统的，所以大部分请求集中在工作日的 9 点到 21 点，高峰期的时候系统的 QPS 在 300-400 之间。

因为我们项目数据存储使用的是 MongoDB，理论上支撑这个量级的 QPS 应该是绰绰有余，但是我有这么几点观察和考虑：

MongoDB 中虽然是整合好的数据，但是很多场景也不是单条查询，夸张的时候一个接口可能会返回上百条数据，回参报文就有两万多行（不要问我能不能分页返回......明确告诉你不能）；

• MongoDB 中虽然是整合好的数据，但是很多场景也不是单条查询，夸张的时候一个接口可能会返回上百条数据，回参报文就有两万多行（不要问我能不能分页返回......明确告诉你不能）；
• 目前项目 99.95% 的接口响应时间都在几十到几百毫秒，基本可以满足业务的需要，但是还是有 0.05% 的请求会超过 1s 响应，偶尔甚至会达到 5s、10s；
• 观察这些响应时间长的请求，大部分时间消耗在查询 MongoDB 上，但是当我将请求报文取出，再次手动调用接口的时候，依然是毫秒级返回；MongoDB 的配置一般，时刻都有数据更新，而且我观察过，响应时间长的这些接口，那个时间点请求量特别大；
• MongoDB 查询偶尔会慢的原因我我还在确认，我现在能想到的原因比如：大量写操作影响读操作、锁表、内存小于索引大小等等，暂时就认为是当时那一刻 MongoDB 有压力；我观察过，响应时间长的这些接口，那个时间点请求量特别大，这一点就不在这里具体分析了。

虽然一万次的请求只有四五次响应时间异常，但是随着项目接入的请求越来越大，保不齐以后量变产生质变，所以还是尽量将危机扼杀在摇篮里，所以果断上了 Redis 做分布式缓存。

02. 接口梳理

下一步就是对生产环境现有接口进行统计和梳理，确定哪些接口是可以放到缓存中的，所以首先要对每一个接口的调用量有大概的统计，因为没有接入日志平台，所以我采用了最笨的办法，一个一个接口的数嘛。

• 把工作日某一天全天的日志拉下来，我们四台应用服务器，每天的日志大概 1 个G，还好还好；
• 通过 EditPlus 这个工具的【在文件中查找】的功能，查询每个接口当天的调用量，已上线 30 个接口，有几分钟就统计出来了，反正是一次性的工作，索性就手动统计了；
• 一天也调不了几次的接口，就直接忽略掉了，我基本上只把日调用量上万的接口都留下来，进行下一步的分析。

03. 字典表、配置类的数据

这一类的数据是最适合放在缓存中的，因为更新频率特别低，甚至有时候 insert 了之后就再也不做 update ，如果这类数据的调用量比较大，是一定要放到 Redis 中的；

至于缓存策略，可以在更新的时候双写数据库和 Redis，也可以采用自动失效的方式，当然这个失效时间可以放得比较长一些；针对我们项目，我采用的是半夜 12 点统一失效的策略，第一因为我们系统这类数据，是夜间通过 ETL 抽取过来的，每天同步一次，第二就是我们不怕缓存雪崩，没有那么大的访问量，夜间更没有什么访问量了。

04. 明显是热点数据的数据

有一类数据，很明显就是热点数据；

我们就有一个接口，虽然是业务数据，不过数据总量只有几千条，但是每天的调用量大约在 40 万，而且更新频率不是很高，这类数据放入 Redis 中也就再适合不过了；至于缓存策略么，因为数据也是从其他系统同步过来的，根据数据同步的时间，我们最终采用一个小时的失效时间。

05. 其余数据的评估

其实前两种数据很容易就能评估出来，关键是这类数据的评估：

• 我们有一个接口日调用量 20-30 万，量不大，但是查询和处理逻辑比较复杂；
• 基础数据量太大，无法把所有数据都放入 Redis 中；
• 无法把基础数据直接放入 Redis 中，因为有多重查询维度（条件）；
• 无法确定每条数据的调用频率是怎么样的，最悲观的结果，每条数据当天只调用一次，这样就没有缓存的必要了。

但是咱也不能一拍脑袋就说：“调用量挺大的，直接放到 Redis 中吧”，或者“不好评估，算了吧，别放缓存了”，做任何一个决定还是需要有依据的，于是我是这样做的：

Step 1. 把该接口当天的所有日志都找出来

几十个日志文件肯定不能一个一个翻，要么就自己写个程序把需要的数据扒出来，但是考虑到这个工作可能只做一次，我还是尽量节省一些时间吧。

依然使用 EditPlus 这个工具的【在文件中查找】的功能，在查询结果框中【复制所有内容】，花了两分钟，就把 24 万条日志找出来了。

Step 2. 把数据导入到数据库中进行下一步分析

每一条日志大概是这样的：

XXXX.log"(64190,95):2020-3-17 16:44:10.092 http-nio-8080-exec-5 INFO 包名.类名 : 请求参数:args1={"字段1":"XXX","字段2":"YYY"}

日志里面我只需要三个内容：请求报文中的字段 1 和字段 2，以及调用时间；怎么摘出来？写个程序？当然没问题，但是我懒呀，几分钟能做好的事情为什么话花几十分钟呢？而且这工作是一次性的，于是：

• 全文替换：[ 2020-3-17 ] 替换成 [ /t2020-3-17 ] ，也就是在时间戳前面加一个 tab；
• 全文替换：[ {"字段1":" ] 替换成 [ /t ] ;
• 全文替换：[ ","字段2":" ] 替换成 [ /t ] ;
• 全文替换：[ "} ] 替换成 [ ]，也就是替换成空 ;
• 全选复制，粘贴到 excel 中，excel 自动按照 tab 换列；
• 删除不需要的列，只留字段 1 和字段 2 的内容，以及时间戳；

这几步操作用不了一分钟。

Step 3. 调用频率分析

当把数据进入到数据库中，就根据我们的需要进行分析了；我们主要想知道，相同的入参会不会重复调用？每次调用间隔的时间是多少？一个 SQL 搞定：

当然调用间隔时间的统计，这里统计的不精确，具体我不解释了，你们细品...

总之吧，全天 24 万的调用量，其中 10 万只调用了一次，14 万的数据会在短时间内重复调用，有一些数据甚至会在几分钟之内重复查询几十次，所以这个接口还是比较适合放入到 Redis 中的。

Step 4. 数据怎么存？

再说说我们的数据用什么格式保存到 Redis 中，一图胜千言：

至于缓存更新策略嘛，我们依然使用设置失效时间的方式，根据数据同步的时间和调用统计结果，这个时间设置成 15 分钟比较合适。

可以看到在这个评估过程中，我所有操作都保持了“能偷懒就偷懒”这个好习惯，保持高效，善用工具，节约不必要的时间，全部过程花了两个小时，其中大部分时间是在数据导入，几乎用了一个半小时，还好在这个过程中我还能做其他的工作。

本人redis菜鸟，昨天刚刚接触redis ​ 现在需要将MySQL数据库的数据导入到redis中求大神？

redis是一款内存数据库，数据写入内存，服务器重启数据丢失，一般位于数据库和WEB服务之间，用于保存临时数据。由于其读写效率高，通常我们开发中会将一些读写频繁的数据写入其中，从而减少对数据库的压力。

要将MySQL DB中的数据写入redis，有两种方式：

1、开发一款程序，将DB中的数据写入redis，也非常简单（面向程序员）

2、redis客户端RedisClient（一款优秀的GUI工具）。

这里我介绍第2种。

1、请从github上下载redisclient。直接在搜索栏里输入【redisclient】即可。

2、下载解压，进入release目录。

3、运行rediscliet。根据操作系统版本运行不同的jar包。

java -jar redisclient-

win32.x86_64.2.0.jar

(切换到这个目录，在cmd命令行运行，前提要安装JRE)

4、连接redis。

输入名称、主帐号IP、端口（默认6379）及密码。

5、进入redisclient主界面。

连接成功后，redisclient显示结构是这样的，通常数据是写入db0.

6、往redis里导入数据。

redis是以key-value形式保存的。value数据类型是多样的，可以是字符串、列表（List）、集合、有序集合、哈希表。

选择db0，右键选择导入，可以实现数据的导入，但前提是数据格式要对。

这种方式纯运维工作，如果是程序员，通过程序导入也很简单，50行代码能搞定。

Redis是啥？

想要了解Redis，先从Redis是什么？为何要用Redis？有哪些特性，以及其集群架构来几个方面来了解。

Redis 简介

Redis 是一个开源（BSD 许可）的、内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。

为什么要用 Redis

在高并发场景下，如果需要经常连接结果变动频繁的数据库，会导致数据库读取及存取的速度变慢，数据库压力极大。因此我们需要通过缓存来减少数据库的压力，使得大量的访问进来能够命中缓存，只有少量的需要到数据库层。由于缓存基于内存，可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计，缓存的设计是必不可少的一环。而 Redis 作为比较热门的内存存储系统之一，由于其对数据持久化的支持，种类丰富的数据结构，使其定位更倾向于内存数据库，适用于对读写效率要求都很高、数据处理业务复杂和对安全性要求较高的系统。

Redis 特征

1. 单线程，利用 redis 队列技术将访问变为串行访问，消除了传统数据库串行控制的开销。

Redis 的线程模型：

1. Redis 支持数据的持久化，包括 RDB 的全量持久化，或者 AOF 的增量持久化，从而使得

Redis 挂了，数据是有机会恢复的。也可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。

1. 分布式架构，读写分离。
2. 支持的数据结构丰富。Redis 不仅仅支持简单的 key-value 类型的数据，同时还提供 list、

set、zset、hash 等数据结构的存储。

1. Redis 支持数据的备份，提供成熟的主备同步，故障切换的功能，从而保证了高可用。

Redis Cluster 架构

Redis 搭建方式有很多种，本章主要介绍 Redis Cluster 集群构建方式：

Redis 3.0 之后版本支持 Redis Cluster 集群，Redis Cluster 采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。Redis Cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的 SORT 就可以由从服务器来承担。Redis 的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低 redis 的处理性能。主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。