Sidekiq獨特工作的奇怪行爲

Question

好吧。我使用Sidekiq來轉換背景中的視頻文件。我使用sidekiq-unique-jobs gem來避免作業與相同的有效內容對象重複。

我跑我的sidekiq過程中不使用任何選項只是在默認隊列中的25

的問題是併發性：正在處理的很長一段時間（視頻文件非常大）後，每一項工作去排隊積壓，但已處理作業的大小也在增加。

工作就像既沒有完成也沒有獨特。我卡住了。在此先感謝

UPD：

我跑彪馬作爲Web服務器。

Answer 1

嘗試運行它沒有sidekiq-unique-jobs寶石。無論如何，它只能保護你免受30分鐘的欺騙。該Gem在Redis中將其哈希鍵設置爲30分鐘後自動失效（可配置）。 sidekiq本身將其作業設置爲在24小時後在Redis中自動過期。

我明顯看不到您的應用，但我敢打賭，您不想經常處理相同的文件。我會在應用層，而不是控制這一點，並跟蹤我自己hashkey做類似的東西有什麼獨特的作業寶石做：

hash = Digest::MD5.hexdigest(Sidekiq.dump_json(md5_arguments)) 

這也有可能是sidekiq-unique-jobs中間件也越來越在sidekiq的辦法知道如果工作正常完成或沒有。我敢打賭，在同樣的配置下，沒有很多人用長時間運行的作業來測試它。

如果您在沒有附加中間件的情況下繼續看到此行爲，請嘗試使用resque。我從來沒有見過這樣的行爲，失敗的作業在管理GUI中有一個有用的重試選項。

sidekiq的主要優點是它是多線程的。即使如此，大型視頻進程的併發性可能會推動一點。根據我的經驗，分叉更穩定便攜，對應用程序線程安全性（YMMV）的擔心更小。

無論您做什麼，請確保您知道這些系統在Redis中將其數據放入的自動過期TTL設置。工作的規模和性質意味着工作可以輕鬆地進行24小時的備份。這些自動刪除發生在數據庫層。應用程序層沒有回調來警告是否已自動刪除作業。例如，在sidekiq的代碼中，他們引入了自動過期行爲以「避免任何可能的泄漏」。 （reference）如果你真的需要這些工作來執行，這並不是很令人鼓舞。