Azure Message Queue メッセージの有効期限は最大 7 日間です。うーんなんで?メッセージの存続時間を無限にして、処理に取り掛かるまでキューで待機させたいと考えています。この奇妙な 7 日間の制限がなければ、Azure キューは私にとって完璧なソリューションです。キューをバックアップする 100 TB のストレージ アカウント全体を持っていますが、それを使用できないのはなぜですか?
誰かがこの問題の回避策または解決策を考えていることを願っています。何か案は?
Azure Message Queue メッセージの有効期限は最大 7 日間です。うーんなんで?メッセージの存続時間を無限にして、処理に取り掛かるまでキューで待機させたいと考えています。この奇妙な 7 日間の制限がなければ、Azure キューは私にとって完璧なソリューションです。キューをバックアップする 100 TB のストレージ アカウント全体を持っていますが、それを使用できないのはなぜですか?
誰かがこの問題の回避策または解決策を考えていることを願っています。何か案は?
Brian が指摘しているように、Service Bus Queues は無制限の TTL を提供します。
複数の SB キューにまたがってシャーディングすることで、5GB の制限を超えることができます。しかし、私たちが発見したことは、その制限に達した人々は、一般に、より便利で費用対効果の高い方法を見つけてアプローチすることで、彼らが持っている大きなデータ項目が何であれストレージ (つまり BLOB) に入り、それらに関連付けられたジョブのみがキューに入るということです.
これにより、ブロック単位のアップロード (ブロック BLOB を使用) を実行するストレージの機能を活用し、SB キューを介してその BLOB の存在を伝えることができます。ジョブを処理したら、データを削除できます。
Queue が 5 GB の上限を超える一般的な使用例は多くなく、そのようなパターンは全体的により適切な選択ではありません。
あなたが言及している7日間の制限は、可視性の遅延(つまり、メッセージが見えなくなる時間)だと思います
Time-to-Live (メッセージがキューに残る期間を指定します) については、私が認識している文書化された制限はありません (そうでない場合は、リンクを教えてください)。
次のページにコメントを寄せていますhttp://msdn.microsoft.com/en-us/library/windowsazure/hh563575.aspx
お役に立てれば