Redisパブリッシュ/サブスクライブ：Redisは、大きなストレス下でもメッセージを配信することが保証されていますか？
サブスクライブしているクライアントとメッセージを公開しているサーバーの両方が接続を保持している場合、Redisは、クライアントやサーバーに大きなストレスがかかっている状況でも、最終的には公開されたメッセージを常にサブスクライブしているクライアントに配信することが保証されていますか？または、物事が「熱くなる」ときにRedisがメッセージをときどきドロップする可能性を計画する必要がありますか？
Redisは、パブリッシュ/サブスクライブトラフィックの配信を保証するものではありません。このメカニズムは、ソケットとイベントループのみに基づいており、キューは含まれていません（メモリ内であっても）。パブリケーションの発生中にサブスクライバーがリッスンしていない場合、このサブスクライバーのイベントは失われます。
Redisの上にいくつかの保証された配信メカニズムを実装することは可能ですが、パブリッシュアンドサブスクライブAPIでは実装できません。 Redisのリストデータ型は、キューとして、およびより高度なキューイングシステムの基盤として使用できますが、マルチキャスト機能を提供しません（したがって、パブリッシュアンドサブスクライブは提供されません）。
AFAIK、Redisでパブリッシュアンドサブスクライブと保証付き配信を同時に簡単に実装する明確な方法はありません。
Redisは、Pub/Subメカニズムを使用した配信の保証を提供していません。さらに、サブスクライバーがチャネルでアクティブにリッスンしていない場合、発行されたはずのメッセージを受信しません。
以前、RedisリストをBLPOPと組み合わせて使用して、信頼性の高いマルチキャストpub/sub配信を実装する方法を説明する詳細な記事を書きました。
http://blog.radiant3.ca/2013/01/03/reliable-delivery-message-queues-with-redis/
記録のために、ここに高レベルの戦略があります：
- 各コンシューマーが起動してメッセージを消費する準備ができると、キューに登録されているすべてのコンシューマーを表すセットに自分自身を追加して登録します。
- プロデューサーがキューにメッセージを公開すると、次のようになります。
- メッセージの内容をRedisキーに保存します
- キューに登録されているコンシューマーのセットを反復処理し、登録されている各コンシューマーのリストにメッセージIDをプッシュします。
- 各コンシューマーは、コンシューマー固有のリストで新しいエントリを継続的に探し、エントリが入ると、エントリを削除し（
BLPOP操作を使用）、メッセージを処理して次のメッセージに進みます。
また、Javaこれらの原則の実装をオープンソースで利用できるようにしました： https://github.com/davidmarquis/redisq
これらの原則は、単一のRedisインスタンスとコンシューマーアプリケーションの2つのインスタンスからの1秒あたり約1,000のメッセージを処理するために使用されており、各インスタンスは5つのスレッドでメッセージを消費します。