1、CPU 相关：复杂度的命令、数据的持久化都需要消耗cpu资源。机器单独使用redis，cpu占比80%即可。如服务机器：一定注意其他服务的瞬时cpu消耗，或者长时间占用过多cpu情况。
2、内存相关：（1）内存使用量：推荐使用30G-50G为宜，再大时落盘、或重启恢复时会出现卡顿、慢的情况。（2）bigkey内存的申请和释放、数据过期、数据淘汰等，大key的操作会严重影响性能，定期刷一刷库，看看有没有大批量异常数据出现，即使清理。（3）避免大key把内存占满了，写不进来数据。
3、磁盘相关：数据持久化、AOF 刷盘策略，也会受到磁盘的影响。配置：appendfsync no，把Redis 每次写操作只写内存，什么时候把内存中的数据刷到磁盘，交给操作系统决定，此方案对 Redis 的性能影响最小，但当 Redis 宕机时，会丢失一部分数据，为了数据的安全性，一般我们也不采取这种配置。
4、网络相关：网卡尽量用万兆了的，避免短连接、实例流量过载、网络流量过载等。大key操作时，根据qps计算网卡使用量，避免网卡成瓶颈。
5、其他：可以绑定cpu、设置内存大页、关闭swap等，都能提高一部分性能，具体接触实际业务时调参设置。
如果你在使用 Redis 时，也遇到过以下这些「诡异」的场景，那很大概率是踩到「坑」了：
明明一个 key 设置了过期时间，怎么变成不过期了？
使用 O(1) 复杂度的 SETBIT 命令，Redis 竟然被 OOM 了？
执行 RANDOMKEY 随机拿出一个 key，竟然也会阻塞 Redis？
同样的命令，为什么主库查不到数据，从库却可以查到？
从库内存为什么比主库用得还多？
写入到 Redis 的数据，为什么莫名其妙丢了？
Redis雪崩问题：如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。
1、缓存雪崩：大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机。
2、缓存击穿：如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取。
3、缓存穿透：当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库。
RedisMod这个东西，它是一系列Redis的增强模块。有了RedisMod的支持，Redis的功能将变得非常强大。目前RedisMod中包含了如下增强模块：
RediSearch：一个功能齐全的搜索引擎；
RedisJSON：对JSON类型的原生支持；
RedisTimeSeries：时序数据库支持；
RedisGraph：图数据库支持；
RedisBloom：概率性数据的原生支持；
RedisGears：可编程的数据处理；
RedisAI：机器学习的实时模型管理和部署。
秒杀系统难点：访问的用户突然爆增，系统不堪重负，死机，系统无法访问；超卖，原本只卖100件商品，但现在卖了200件商品；作弊导致一个用户购买了多件商品等问题。
秒杀主要的应用场景包括：预约抢购、限时购、春运12306抢购火车票、某西医院专家号等都属手秒杀范畴。
解决方案：异步、解耦、削峰。