redis强一致_为什么你的redis总是开小差？

导读

提起分布式缓存，想必大多数同学脑海中都会浮出redis这个名字来……但是，对于它，你真的玩转了吗？为什么你的redis会慢，会卡顿，会崩溃？猛犸技术团队带你一探究竟。

为什么redis会开小差？

本文主要简要介绍redis使用过程中可能遇到的一些意外情况，只讲原因，并不过多分析细节，对于细节问题，读者可自行查询相关资料。

1.连接数过多

• 限制了redis最大连接数(maxclients)，高并发场景下，达到该值，那么新的请求无法获取连接执行读写操作
• 没有限制，那么连接数在达到5000以上时(2g4c)，可能影响到性能，在更高请求或更低配置机器情况下，数据会更低

针对这种情况，建议开启限制最大连接数，同时预估客户端数量，控制好连接参数；同时需要确认请求操作后所使用的连接是否被释放的问题。

2.bigkey

如果一个key的value过大，则被称为大key。主要包括：

• 单个简单的key存储的value很大
• hash， set，zset，list 中存储过多的元素(以万为单位)

若单key过大，读写频繁，那么数据读写中的序列化、网络传输等本身就是瓶颈点。

3.慢命令操作

• 危险命令：keys。执行全量扫描，在数据量大的场景下，将引起整个redis阻塞
• O(N)命令：hgetall、lrange、smembers、zrange、sinter、hkeys、hvals等，慎用。如需要使用，提前预估数据，一般认为应该控制在元素量控制在5K以内，如果的确过大，则需要根据实际机器配置评估验证。
• monitor命令：主要用于debug使用，生产环境长时间开启对性能有较大影响

4.内存策略不合理

在redis.conf中有一行配置，关于内存淘汰策略的说明

当redis占用达到指定的maxmemory值时，会触发redis部分key的移除以释放内存。

• 如果选择不当的策略，可能会造成部分key被除后读不到引发意外。
• 如果选择策略noeviction，不会释放内存，但是对于写操作会提示错误。
• 如果读写并发高，可能出现频繁的内存释放，导致系统卡顿。

遇到报错或者获取key内容丢失，未必是redis故障，因为也这是一种自我保护机制。

5.外部数据双写一致性

在分布式的环境下，数据库和缓存双写，存在一致性问题，如果要求强一致性，那么redis会受到db的影响造成瓶颈。此时一般建议走最终一致，通过异步(如消息队列)方式来实现。

需要站在架构设计的角度来对待redis的使用。

6.保护机制未开启

redis有一种保护机制，默认情况下是开启的。但有些时候为了图方便，没有开启该机制，同时将redis暴露于公网，此时容易受到外部攻击，导致redis甚至操作系统不可用。

在生产环境还是要有提高安全的意识。

未雨绸缪，减少风险

新上线的需求，可提前预估key数量、value占比、是否需要集合、是否需要ttl？以避免引起内存不足或内存泄漏风险。

如何快速定位慢的原因？

常用工具，redis内部命令如info、slowget慢查询，内存分析排查可参考redis-rdb-tool等。当然，完善的监控系统能让我们更快，更准地解决，这里建议telegraf+influxdb+grafana组合实现图形化监控预警。

结论

1.对于使用不当引起的风险操作，需要对症下药。

2.对于海量数据、高并发这种的确因为正常需求引起的资源不足问题的场景，就需要考虑扩容的方式来解决。

3.做好准备工作、善用工具、建立监控预警机制，将使你对redis的维护工作事半功倍