Redis との対話を開始するには、最初に接続する必要があります。Spring Integration は、別の Spring プロジェクトである Spring Data Redis [GitHub] (英語) が提供するサポートを使用します。Spring Data Redis [GitHub] (英語) は、典型的な Spring 構成体 ConnectionFactory および Template を提供します。これらの抽象化により、いくつかの Redis クライアント Java API との統合が簡素化されます。現在、Spring Data Redis は Jedis [GitHub] (英語) および Lettuce (英語) をサポートしています。

で記述されていたように導入、Redis はその PUBLISH、SUBSCRIBE、UNSUBSCRIBE コマンドによってメッセージング、パブリッシュサブスクライブのサポートを提供します。JMS および AMQP と同様に、Spring Integration は、Redis を介してメッセージを送受信するためのメッセージチャネルとアダプターを提供します。

エンタープライズ統合パターン（EIP）ブックに従って、メッセージストア (英語) を使用するとメッセージを保持できます。これは、信頼性が懸念される場合にメッセージ（アグリゲーター、リシーケンサーなど）をバッファリングする機能を備えたコンポーネントを扱うときに役立ちます。Spring Integration では、MessageStore 戦略はクレームチェック (英語) パターンの基盤も提供します。これは EIP でも説明されています。

Spring Integration の Redis モジュールは RedisMessageStore を提供します。次の例は、アグリゲーターでそれを使用する方法を示しています。

上記の例は Bean 構成であり、コンストラクター引数として RedisConnectionFactory を想定しています。

デフォルトでは、RedisMessageStore は Java 直列化を使用してメッセージを直列化します。ただし、別の直列化手法（JSON など）を使用する場合は、RedisMessageStore の valueSerializer プロパティを設定して独自のシリアライザーを提供できます。

バージョン 4.3.10 以降、フレームワークは、Message インスタンスおよび MessageHeaders インスタンス（それぞれ MessageJacksonDeserializer および MessageHeadersJacksonSerializer）の Jackson シリアライザーおよびデシリアライザーの実装を提供します。ObjectMapper の SimpleModule オプションで構成する必要があります。さらに、ObjectMapper で enableDefaultTyping を設定して、直列化された各複合オブジェクトの型情報を追加する必要があります（ソースが信頼できる場合）。その後、その型情報は逆直列化中に使用されます。フレームワークは、JacksonJsonUtils.messagingAwareMapper() と呼ばれるユーティリティメソッドを提供します。これには、前述のすべてのプロパティとシリアライザがすでに提供されています。このユーティリティメソッドには trustedPackages 引数が付属しており、デシリアライゼーションの Java パッケージを制限して、セキュリティの脆弱性を回避します。デフォルトの信頼できるパッケージ: java.util、java.lang、org.springframework.messaging.support、org.springframework.integration.support、org.springframework.integration.message、org.springframework.integration.store。RedisMessageStore で JSON 直列化を管理するには、次の例のような方法で構成する必要があります。

バージョン 4.3.12 から、RedisMessageStore は prefix オプションをサポートし、同じ Redis サーバー上のストアのインスタンスを区別できるようにします。

Spring Integration 3.0 は、新しい Redis ベースの MetadataStore (Javadoc) （メタデータストアを参照）実装を導入しました。RedisMetadataStore を使用して、アプリケーションの再起動後も MetadataStore の状態を維持できます。この新しい MetadataStore 実装は、次のようなアダプターで使用できます。

これらのアダプターに新しい RedisMetadataStore を使用するよう指示するには、metadataStore という名前の Spring Bean を宣言します。フィード受信チャネルアダプターとフィード受信チャネルアダプターの両方が、宣言された RedisMetadataStore を自動的に取得して使用します。次の例は、そのような Bean を宣言する方法を示しています。

RedisMetadataStore は RedisProperties (Javadoc) によってサポートされています。それとの相互作用は BoundHashOperations (Javadoc) を使用します。これは、Properties ストア全体に対して key を必要とします。MetadataStore の場合、この key はリージョンのロールを果たします。これは、いくつかのアプリケーションが同じ Redis サーバーを使用する分散環境で役立ちます。デフォルトでは、この key の値は MetaData です。

バージョン 4.0 以降、このストアは ConcurrentMetadataStore を実装し、キーの値を保存または変更できるインスタンスが 1 つだけである複数のアプリケーションインスタンス間で確実に共有できるようにします。

Redis ストア受信チャネルアダプターは、Redis コレクションからデータを読み取り、Message ペイロードとして送信するポーリングコンシューマーです。次の例は、Redis ストア受信チャネルアダプターを構成する方法を示しています。

上記の例は、store-inbound-channel-adapter 要素を使用して Redis ストア受信チャネルアダプターを構成し、次のようなさまざまな属性の値を提供する方法を示しています。

key のリテラル値があるため、前述の例は比較的単純で静的です。ある条件に基づいて、実行時にキーの値を変更する必要がある場合があります。そのためには、代わりに key-expression を使用します。指定された式は、有効な SpEL 式であればどれでもかまいません。

また、Redis コレクションから読み取られ、正常に処理されたデータに対して後処理を実行することもできます。例: 処理後に値を移動または削除することができます。そのためには、Spring Integration 2.2 で追加されたトランザクション同期機能を使用します。次の例では、key-expression とトランザクション同期を使用しています。

transactional 要素を使用して、ポーラーをトランザクション対応として宣言できます。この要素は、実際のトランザクションマネージャーを参照できます（たとえば、フローの他の部分が JDBC を呼び出す場合）。「実際の」トランザクションがない場合は、Spring の PlatformTransactionManager の実装である o.s.i.transaction.PseudoTransactionManager を使用でき、実際のトランザクションがない場合に Redis アダプターのトランザクション同期機能を使用できます。

ポーラーがトランザクション対応になると、o.s.i.transaction.TransactionSynchronizationFactory のインスタンスを transactional 要素に設定できます。TransactionSynchronizationFactory は、TransactionSynchronization のインスタンスを作成します。便宜上、デフォルトの SpEL ベースの TransactionSynchronizationFactory を公開しました。これにより、SpEL 式を構成し、その実行をトランザクションと調整（同期）できます。評価結果（存在する場合）が送信されるチャネル（イベントの種類ごとに 1 つ）とともに、コミット前、コミット後、ロールバック後の式がサポートされています。子要素ごとに、expression および channel 属性を指定できます。channel 属性のみが存在する場合、受信したメッセージは特定の同期シナリオの一部としてそこに送信されます。expression 属性のみが存在し、式の結果が NULL 以外の値である場合、ペイロードとしての結果を含むメッセージが生成され、デフォルトチャネル（NullChannel）に送信され、ログ（DEBUG レベル）に表示されます。評価結果を特定のチャネルに移動する場合は、channel 属性を追加します。式の結果が null または void の場合、メッセージは生成されません。

トランザクション同期の詳細については、トランザクションの同期を参照してください。

RedisStore 送信チャネルアダプターを使用すると、次の例に示すように、メッセージペイロードを Redis コレクションに書き込むことができます。

上記の構成では、store-inbound-channel-adapter 要素を使用して Redis ストア送信チャネルアダプターを保存します。次のようなさまざまな属性の値を提供します。

key およびその他の属性のリテラル値があるため、前の例は比較的単純で静的です。場合によっては、条件に基づいて実行時に値を動的に変更する必要があります。これを行うには、同等の -expression （key-expression、map-key-expression など）を使用します。ここで、提供される式は任意の有効な SpEL 式にすることができます。

Spring Integration 4.0 は Redis コマンドゲートウェイを導入し、汎用の RedisConnection#execute メソッドを使用して標準の Redis コマンドを実行できるようにしました。次のリストは、Redis 送信ゲートウェイで使用可能な属性を示しています。

<int-redis:outbound-gateway> を共通コンポーネントとして使用して、任意の Redis 操作を実行できます。次の例は、Redis アトミック番号から増分値を取得する方法を示しています。

Message ペイロードの名前は redisCounter である必要があり、これは org.springframework.data.redis.support.atomic.RedisAtomicInteger Bean 定義によって提供される場合があります。

RedisConnection#execute メソッドには、戻り値の型として汎用 Object があります。実際の結果はコマンドの種類によって異なります。例: MGET は List<byte[]> を返します。コマンド、それらの引数、結果型の詳細については、Redis 仕様 (英語) を参照してください。

Spring Integration は、リクエストおよび応答シナリオを実行するために Redis キュー送信ゲートウェイを導入しました。提供された queue に会話 UUID をプッシュし、その UUID をキーとして値を Redis リストにプッシュし、UUID' plus '.reply のキーを使用して Redis リストからの応答を待ちます。対話ごとに異なる UUID が使用されます。次のリストは、Redis 送信ゲートウェイで使用可能な属性を示しています。

Spring Integration 4.1 は、リクエストと応答のシナリオを実行するために Redis キューの受信ゲートウェイを導入しました。提供された queue から会話 UUID をポップし、その UUID をキーとする値を Redis リストからポップし、UUID と .reply のキーを使用して Redis リストへの応答をプッシュします。次のリストは、Redis キューの受信ゲートウェイで使用可能な属性を示しています。

Spring Integration 5.4 は、メッセージペイロードを Redis ストリームに書き込むためのリアクティブ Redis ストリーム送信チャネルアダプターを導入しました。送信チャネルアダプターは、ReactiveStreamOperations.add(…​) を使用して Record をストリームに追加します。次の例は、Redis ストリーム送信チャネルアダプターの Java 構成とサービスクラスを使用する方法を示しています。

Spring Integration 5.4 は、Redis ストリームからメッセージを読み取るためのリアクティブストリーム受信チャネルアダプターを導入しました。受信・チャネルアダプターは、自動確認応答フラグに基づいて StreamReceiver.receive(…​) または StreamReceiver.receiveAutoAck() を使用して、Redis ストリームからレコードを読み取ります。次の例は、Redis ストリーム受信チャネルアダプターの Java 構成を使用する方法を示しています。

autoAck が false に設定されている場合、Redis ストリームの Record は Redis ドライバーによって自動的に確認応答されません。代わりに、IntegrationMessageHeaderAccessor.ACKNOWLEDGMENT_CALLBACK ヘッダーがメッセージに追加され、SimpleAcknowledgment インスタンスを値として生成します。このようなレコードに基づいてメッセージのビジネスロジックが実行されるたびに、acknowledge() コールバックを呼び出すことはターゲット統合フローの責任です。デシリアライズ中に例外が発生し、errorChannel が構成されている場合でも、同様のロジックが必要です。ターゲットエラーハンドラーは、そのような失敗したメッセージを確認するか、削除するかを決定する必要があります。IntegrationMessageHeaderAccessor.ACKNOWLEDGMENT_CALLBACK に加えて、ReactiveRedisStreamMessageProducer はこれらのヘッダーをメッセージに入力して、RedisHeaders.STREAM_KEY、RedisHeaders.STREAM_MESSAGE_ID、RedisHeaders.CONSUMER_GROUP、RedisHeaders.CONSUMER を生成します。

バージョン 5.5 以降、ReactiveRedisStreamMessageProducer で StreamReceiver.StreamReceiverOptionsBuilder オプションを明示的に構成できます。これには、逆直列化エラーが発生したときに Redis ストリームコンシューマーがポーリングを続行する必要がある場合に必要な、新しく導入された onErrorResume 関数が含まれます。デフォルトの関数は、上記のように、失敗したメッセージの確認応答を含むメッセージをエラーチャネル（提供されている場合）に送信します。これらの StreamReceiver.StreamReceiverOptionsBuilder はすべて、外部から提供された StreamReceiver.StreamReceiverOptions と相互に排他的です。

Spring Integration 4.0 は RedisLockRegistry を導入しました。特定のコンポーネント（アグリゲーターやリシーケンサーなど）は、LockRegistry インスタンスから取得したロックを使用して、一度に 1 つのスレッドのみがグループを操作するようにします。DefaultLockRegistry は、単一のコンポーネント内でこの機能を実行します。これで、これらのコンポーネントで外部ロックレジストリを構成できます。共有 MessageGroupStore で使用する場合、RedisLockRegistry を使用して複数のアプリケーションインスタンスにこの機能を提供でき、一度に 1 つのインスタンスのみがグループを操作できます。

ローカルスレッドによってロックが解除されると、通常、別のローカルスレッドがすぐにロックを取得できます。別のレジストリインスタンスを使用するスレッドによってロックが解放された場合、ロックを取得するのに最大 100 ミリ秒かかることがあります。

「ハング」ロック（サーバーの障害時）を回避するために、このレジストリのロックはデフォルトの 60 秒後に期限切れになりますが、レジストリでこの値を構成できます。ロックは通常、はるかに短い時間保持されます。

バージョン 5.0 から、RedisLockRegistry は ExpirableLockRegistry を実装します。ExpirableLockRegistry は、age より前に最後に取得され、現在ロックされていないロックを削除します。

バージョン 5.5.6 の文字列である RedisLockRegistry は、RedisLockRegistry.setCacheCapacity() を介して RedisLockRegistry.locks の redisLocks のキャッシュを自動的にクリーンアップすることをサポートしています。詳細については、JavaDocs を参照してください。