如何评估数据适不适合放入Redis中？

如何评估数据适不适合放入Redis中？这个好像都不怎么用评估，在互联网公司待了好几年，行不行放进去试试就行，工作这几年时间，还没有见过不能放入Redis的数据场景。下面就以个人的经历，简单分享一些特殊的数据场景和使用过程中的问题，娱乐为主，甄别借鉴。

在负责前台业务时，配置数据是一种很典型的数据场景，如 APP 首页所加载的轮播图、ICON跳转信息等，这些数据属于典型的低频变更、高频访问型数据，面向所有用户请求响应，产品运营在配置后台变更。我负责的业务本身访问量也不高，PV 110w，UV 80，峰值QPS 200+，处理方案是被动配置信息缓存，缓存时间为 5 min，产品运营配置的数据最悲观的情况下 5 min生效，产品侧接受，研发侧实现简单。但在维护过程中，发现 redis 的 key 生成规则中有当前时间因子，导致该配置信息缓存永远都取不到，这种低级错误读者感觉别出心裁，也很不容易定位。幸好我们的业务并发并不高，要不然数据库压力就够呛了。

在维护页面型业务时，发现该业务的整个页面进行了缓存，定时调度每分钟拉群上游数据，结合本地 vm 模板进行渲染，然后将选择结果放入 redis，当有用户请求时，直接返回该渲染完成的页面html，起到快速响应的目的。这种快速响应用户请求优化的方式，第一次见到，很有借鉴意义，页面的响应优化方面可以考虑的层面又多了一些方式。

还有一种高性能的业务场景，业务 QPS 10w+，这种请求并发，关系型数据库往往无能为力，曾经历过以 redis 为中心，搭建整个应用体系，用户型数据永久存储，为保证数据的准备性，异步消息队列消费入库，数据库中数据主要用作维护和数据备份。所有的请求都由 redis 反馈结果，redis中无数据，就表明该用户数据不存在，这种架构可以轻松支撑起 10w+ 的QPS。但也不是没有问题的，运营的久了，往往会出现数据库和缓存的数据不一致的情况，这种时候就考虑结合数据库中数据，对缓存中数据进行清洗和补偿。

以上，仅是职业生涯遇到的一些特殊场景，处理方案或许不那么完美，但也足够支撑业务。在开发中，着力追求技术方案完美值得肯定，但也尽量避免过度设计。在当下这个迭代速度超快的业务和技术场景中，能够支撑业务发展就是一种好的架构设计。

作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。

判断数据是否放入Redis的方法，我说下自己的理解。

Redis的特点是内存存储，所以它主要适合的是独立、速度快、适合频繁访问/修改、常作为快速缓存替代SQL。

什么样的数据适合放入Redis中呢？这里没必要扯什么数据类型、什么业务等等虚的概念。从它的特点中能看出，所有不适合把数据放入SQL数据库、同时又不方便本地缓冲的场景数据，都适合放入Redis中。

因此，如果目标数据既需要高速缓存，又需要独立存在于程序之外：比如防止服务重启（包括且不限于升级、错误、重启）等造成数据丢失，或者多个服务共享此数据，这时就可以放入Redis中。因为Redis的稳定性是可期的，同时网络接口又允许多个服务器同时访问。

因此所有要求使用Redis的场景，都有重要的特征，即高速和独立存储。基于这个需求，创造出来的业务概念即哪些所谓的 热点业务数据、高速数据镜像、共享缓存等等，也就好理解了。

下图就是实际业务中的一种场景，即为了帮SQL抗流量。重复的查询和快速的更新由Redis抗下，而SQL只做持久化。

希望能帮到有类似问题的朋友。朋友们，望不吝赐赞啊！

1：字典，配置类型的数据，因为更新频率很低，如果这类型数据调用量比较大的话，适合放到redis

2:热点数据，就是每天调用量很大的数据，而且更新频率不是很大，适合放到redis

3:虽然有些业务数据，每日调用量比较大，但是查询和处理逻辑复杂，这类数据不适合放到redis

4：基础数据量比较大，有多个维度的查询，不适合放到redis

5:对调用数据不确定使用频率怎样的，不适合放到redis

评估数据是否适合放入Redis中需要考虑以下几个方面：

1. 数据类型：Redis支持多种数据类型，包括字符串、哈希、列表、集合和有序集合。首先需要确定数据的类型，确保它与Redis支持的数据类型相匹配。
2. 数据量和内存：Redis将数据存储在内存中，因此需要评估数据的大小和数量，以确保Redis具有足够的内存来存储所有数据。如果数据量很大，超过了可用的内存容量，则不适合使用Redis。
3. 数据访问模式：Redis适用于高速读写操作，对于频繁的读取和写入操作，Redis可以提供低延迟的响应。如果数据需要经常更新或者需要快速查询，那么将其存储在Redis中是合适的。
4. 数据持久化需求：Redis支持持久化功能，可以将数据保存到磁盘上以便重启后恢复。如果需要数据持久化，并要求高可靠性，Redis可以满足这一需求。
5. 数据一致性要求：Redis是内存数据库，如果对数据的一致性有高要求，则需要使用Redis提供的事务和持久化机制来保证数据的一致性。
6. 并发访问：如果多个客户端同时对数据进行访问，需要考虑并发访问的效率和性能。Redis提供了高效的并发访问机制，可以满足并发读写的需求。
7. 数据安全性：Redis提供密码认证来保护数据安全，可以设置密码来限制对数据的访问。如果数据的安全性是关键考虑因素之一，Redis可以满足这一要求。

综上所述，评估数据是否适合放入Redis中需要综合考虑数据类型、数据量、数据访问模式、数据持久化需求、数据一致性要求、并发访问和数据安全性等因素。根据具体需求和场景，决定是否选择使用Redis作为数据存储解决方案。

以下是一些常见的例子。

1. 用户会话数据：对于需要快速读写和高并发访问的用户会话数据，如用户登录状态、购物车信息等，可以将这些数据存储在Redis中。因为这些数据需要频繁更新和查询，并且对延迟要求较高。
2. 缓存数据：Redis被广泛用作缓存解决方案，可以将经常被访问的数据缓存到Redis中。例如，数据库查询结果、计算结果、API调用结果等，可以存储在Redis中，以提高读取速度和减轻后端负载。
3. 计数器和排行榜：对于需要实时计数和排名的场景，如文章阅读量、点赞数、关键词搜索热度等，可以使用Redis的计数器和有序集合数据结构来实现。这样可以方便地进行增减操作和获取排名数据。
4. 任务队列：如果有任务需要通过异步方式处理，可以使用Redis的列表数据结构作为任务队列。生产者将任务推入队列，而消费者则从队列中获取任务进行处理。Redis提供了队列相关的命令，支持简单可靠的任务队列功能。
5. 实时消息发布和订阅：Redis支持发布-订阅模式，可以用于实时消息传递和广播。如果有需求需要对实时事件进行发布和订阅，Redis可以作为可靠的消息中间件来使用。

到此，以上就是小编对于mongodb 分页查询 性能的问题就介绍到这了，希望这1点解答对大家有用。