GitHub 的 Redis 和 Resque 失败行为？答案

【问题标题】：GitHub's Redis and Resque failure behavior?GitHub 的 Redis 和 Resque 失败行为？
【发布时间】：2012-05-22 08:00:02
【问题描述】：

谁知道 GitHub 在使用 Resque 时如何处理 Redis 服务器的潜在故障或暂时不可用？

还有其他人似乎已经将半复杂的解决方案放在一起，作为使用 zookeeper 的 redis-cluster 的保留（请参阅https://github.com/ryanlecompte/redis_failover 和 Solutions for resque failover redis）。其他人似乎有“糟糕的故障转移”，即在第一眼看到连接问题时就将从属切换到主控，而没有 redis 客户端之间的协调（但这在临时不可用的情况下似乎有问题）。

问题：Defunkt 是否讨论过 GitHub 如何处理 Redis 故障？是否有不涉及 Zookeeper 的故障转移最佳实践？

关于 resque 的原始帖子指出，选择 Redis 的部分原因是 redis 的主从功能，但该帖子没有描述 GitHub 如何利用这一点，因为所有工作人员都需要对 Redis 的读+写访问权限（见https://github.com/blog/542-introducing-resque)。

【问题讨论】：

标签： github redis resque

【解决方案1】：

基本 Resque 库不处理故障。如果一个盒子在弹出消息后立即死亡，则该消息将永远消失。您必须编写自己的代码来处理故障，这非常棘手。

https://github.com/resque/resque/issues/93

【讨论】：

最接近我见过的答案！感谢您指出。归根结底，自从使用 Resque 的原始帖子以来我所写的所有内容都运行起来，因此 redis 的失败并不重要。例如。我将跟踪使用单独的数据库条目后会发生的特定任务，以便可以检查并重新运行丢失的作业，还构建了我的应用程序，这样如果错过了一个作业调度，所有计划的作业都无关紧要。如果 resque but c'est la vie 更清楚地记录了这一点，那将会有所帮助。