大约1个月前，我开始在Heroku上托管Redis/芹菜/Python(Dash)应用程序。在这段时间里，它工作得很完美，但是在我最近的更新中，我的数据存储凭证改变了，不知何故引入了一个新的错误。
每次我重新启动我的dyno时都会发生，因为我收到下面的错误大约5分钟。
错误是:kombu.exceptions.OperationalError: Error 8 connecting to ec2-44-208-193-34.compute-1.amazonaws.com:19130. EOF occurred in violation of protocol (_ssl.c:1129).
不知何故，大约5分钟后，错误自行解决，错误消失。
我的代码看起来像celery_app = Celery(
__name__,
broker = "rediss://:*@ec2-44-208-193-34.compute-1.amazonaws.com:19130/0",
backend = "rediss://:*@ec2-44-208-193-34.compute-1.amazonaws.com:19130/1",
broker_use_ssl = {
'ssl_cert_reqs': ssl.CERT_NONE
},
redis_backend_use_ssl = {
'ssl_cert_reqs': ssl.CERT_NONE
}
)
有没有人知道是什么原因造成的以及如何预防?
检查你的Heroku插件运行的是哪个Redis版本，有v6版本的变化，耗尽最大连接池不会导致"达到最大客户端数";这是一种TLS错误。
当部署发生时，现有的dynos正在使用一些基线和连接流量计数，而替换的dynos试图获取新的连接，但被Redis拒绝。
它在一段时间后自行修复的原因是Redis的超时设置，默认情况下通常是300秒。300秒后所有旧的动态连接将被清理，然后所有超过最大客户端的TLS连接问题将消失。
你可以降低超时时间来减少错误发生的持续时间，但更好的解决办法是通过Redis计划增加最大连接，或者减少芹菜正在使用的连接(这是一个复杂的话题)，希望这和这有帮助。
令人沮丧的是，如果你看Redis统计，Heroku根本不会报告你超过了限制。它没有显示您突然试图增加一倍或更多客户端连接的迹象。这是一种误导，因为它从未真正开放，但很快就被直接拒绝了，所以没有解释。更糟糕的是，当它是一个资源耗尽问题时，错误被很好地掩盖为SSL问题。