如何处理Redis客户端的read（）超时？

Question

假设我的客户端向redis服务器发送'INCR'命令，但响应数据包丢失，所以我的客户端的read（）将超时，但客户端无法确定服务器是否执行了INCR操作。

接下来要做什么？重新发送INCR或继续下一个命令？如果客户端重新发送INCR，但是如果redis之前在服务器端执行了INCR，该密钥将增加两次，这不是我们想要的。

Answer 1

这不是Redis特有的问题：它也适用于任何其他数据存储（包括事务性存储）。这个问题没有解决办法：你只能希望尽量减少这个问题。

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

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

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

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