目前有一个工作人员调用perform_async，它随机排队作业。它有效的10次中有9次......但它偶尔也没有排队工作。作业ID已创建，但我们从未看到它被排队并且它不会运行。当我们注意到这种情况发生时，我们只需在heroku控制台中重新运行该作业，它就会运行。当作业实际运行时，它工作正常。问题是它并不总是运行。
一些统计数据：rails 4.1.11，ruby 2.2.3，sidekiq 4.0.2，redis 2.8.21 美洲狮和heroku
来自sidekiq可靠性维基，它指出有三个与可靠性相关的问题：将作业发送到redis，从redis中获取作业以及安排。
我们无法确定为什么这份工作没有在redis中排队。难倒并且希望有人可以就如何提出建议：
监控工作是否入队的最佳方法？使用sidekiq api是最好的方法吗？
为什么工作可能无法成为redis的一部分原因（范围是什么）？
确保未来可靠性的最佳方法是什么？
如果工作没有进入redis，为什么sidekiq不会认识到这一点并给我们提供某种错误/反馈。
如果它有帮助，请参阅我们的RedisToGo配置：
# = General
port 10655
databases 1
loglevel notice
logfile /mnt/redis.306247.log
# = Security
requirepass xxxxxxxxxxxxxxxxxxxxxxxxxxxx
# = Limits
maxmemory 52428800
maxmemory-policy volatile-lru
maxmemory-samples 3
maxclients 128
timeout 150
dir /home/redis/10655
appendonly yes
appendfilename appendonly.aof
appendfsync everysec
no-appendfsync-on-rewrite no
hash-max-ziplist-entries 64
hash-max-ziplist-value 512
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
activerehashing yes
# = LUA Scripting
lua-time-limit 5000
# = Client Limits
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
提前致谢。