redis用法技巧

- 一、缓存设计
- - [1. 多个库的使用](#1. 多个库的使用)
  - 2.避免多个应用公用一个redis实例
  - 3.合理评估业务场景，并设置最大内存以及内存淘汰策略(maxmemory和maxmemory-policy)
  - 4.使用带有连接池的数据库，可以有效控制连接，同时提高效率
  - 5.给redis设置一个密码
  - 6.冷热数据区分
  - [7.缓存非特殊情况不做中间态 redis大多数时候都是做缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。](#7.缓存非特殊情况不做中间态 redis大多数时候都是做缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。)
- 二、场景实战问题
- 三、查询使用问题
- - 1、线上Redis禁止使用Keys正则匹配操作
- 四、其他
- - 1、redis同步工具
  - 2、大key查询

一、缓存设计

1. 多个库的使用

如果应用中会涉及到各种不同的redis数据存储，应该分库存储，最好是一种业务使用一个库

比如：课程缓存:库1；订单队列:库2；日志处理:库3

2.避免多个应用公用一个redis实例

避免一个应用出现问题或者错误使用拖累其他应用

3.合理评估业务场景，并设置最大内存以及内存淘汰策略(maxmemory和maxmemory-policy)

目前我们用的阿里云redis，不太存在这个问题

4.使用带有连接池的数据库，可以有效控制连接，同时提高效率

5.给redis设置一个密码

目前我们用的阿里云redis，不太存在这个问题

6.冷热数据区分

虽然 Redis支持持久化，但将所有数据存储在redis中，成本非常昂贵。
建议将热数据 (如 QPS超过 5k) 的数据加载到redis中。
低频数据可存储在Mysql、ElasticSearch中。

7.缓存非特殊情况不做中间态 redis大多数时候都是做缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。

缓存的高可用会影响业务；
产生深耦合会发生无法预料的效果；
会对维护产生负效果。

二、场景实战问题

1、项目redis使用问题

当前的使用方式是，每个接入的应用要配置核心项目的redis配置。这样是不合理的，核心项目的redis应该只能在核心项目中使用，对外应该是提供api接口或者rpc进行访问。

2、慎用laravel自带的cache功能

laravel自带的cache功能最容易导致大key，经常由于简单使用至今将整个对象模型存储到redis，造成大key。

3、注意key的过期时间设置

在报名等高峰期的时候，key值设置过短容易造成缓存穿透，导致大量请求直接打到mysql数据库。

4、小心缓存穿透

经常使用会只给有数据的结果进行缓存，结果导致空数据无法缓存，相同查询直接每次都到达数据库，所以空值也应该被缓存。

5、慎用缓存层层包裹

缓存里面的数据还有一层缓存数据，会导致问题排查麻烦，出问题也不容易处理。

6、慎用将redis做为消息队列

如没有非常特殊的需求，严禁将 Redis 当作消息队列使用。redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。
如需要消息队列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ，nsq,(花园同步有时间前后要求，且量不大才使用的)。

三、查询使用问题

1、线上Redis禁止使用Keys正则匹配操作

redis是单线程处理，在线上Key数量较多时，操作效率极低【时间复杂度为O(N)】，该命令一旦执行会严重阻塞线上其它命令的正常请求，而且在高QPS情况下会直接造成redis服务崩溃！如果有类似需求，请使用scan命令代替。

目录：