redis - 如何处理 Redis 客户端中的 read() 超时？

Question

假设我的客户端向redis服务器发送了'INCR'命令，但是响应包丢失了，所以我的客户端的read()会超时，但是客户端无法判断服务器是否执行了INCR操作。

接下来做什么？重新发送 INCR 或继续下一个命令？如果客户端重新发送INCR，但是如果redis之前在服务器端进行了INCR，这个key会增加2倍，这不是我们想要的。

Answer 1

这不是 Redis 特有的问题：它也适用于任何其他数据存储（包括事务性数据存储）。这个问题没有解决方案：您只能希望将问题最小化。

例如，有些人倾向于为他们的超时设置非常激进的值，认为 Redis 应该是一个软实时数据存储。Redis 速度很快，但你还需要考虑网络，以及系统本身。网络相关问题可能会产生高延迟。如果系统开始交换，它将非常严重地影响 Redis 响应时间。

我倾向于认为将超时设置在 2 秒以下在任何 Unix/Linux 系统上都是无稽之谈，如果涉及到网络，我更喜欢 10 秒。人们之所以设置非常低的值，是因为他们希望避免他们的应用程序被阻止：这是一个错误。他们应该将应用程序设计为异步的并设置合理的超时，而不是设置非常低的超时并保持应用程序同步。

超时后，客户端永远不应“继续”执行下一个命令。它应该关闭连接，并尝试打开一个新连接。如果回复（或查询）丢失，则客户端和服务器不太可能重新同步。关闭连接更安全。

您是否应该在重新连接后尝试再次发出 INCR？这真的取决于你。但是，如果刚刚触发了读取超时，则重新连接很可能也会超时。Redis是单线程的，当一个连接慢时，所有连接同时慢。