春データRedisの統合、同様の機能のために専用のメッセージを提供し、春のフレームワークのJMS統合で命名します。
Redisのメッセージは、大きく分けて2つの機能領域に分けることができます。
-
公開やニュースを生産
-
購読やメッセージを消費します
一般的にパブリッシュ/サブスクライブ・モデルと呼ばれます。RedisTemplateクラスは、メッセージを生成するために使用されます。Java EEのメッセージ駆動型Beanの形態と同様の非同期受信のため、スプリングデータメッセージは、メッセージ駆動型POJO(MDP)を作成するために、専用のリスナーの容器を提供し、同期して受信するための手段RedisConnection约定
。
org.springframework.data.redis.connectionとorg.springframework.data.redis.listener 2つのRedisのパッケージは、メッセージのコア機能を提供します。
(メッセージを送信するために)1つのリリース
メッセージを投稿するには、他の低レベルのように同じ動作を使用することができますRedisConnection
かハイレベルRedisTemplate
。2つのエンティティを提供するpublish
、この方法は、パラメータと対象チャネルとしてメッセージを受け入れます。RedisConnection
必要な元のデータ(バイト配列)が、RedisTemplate
次の例に示すように、着信メッセージとして任意のオブジェクトを許容します。
// send message through connection RedisConnection con = ...
byte[] msg = ...
byte[] channel = ...
con.publish(msg, channel); // send message through RedisTemplate
RedisTemplate template = ...
template.convertAndSend("hello!", "world");
フィード2(受信メッセージ)
受信側では、1つまたは複数のチャネルに直接パターンマッチングを命名することで購読することができます。(彼らはパターンに一致している限り)サブスクリプションの時点で作成されていない、それは、複数のサブスクリプションを作成するためにコマンドを使用することができるだけでなく、あなたはまた、チャネルを監視することができますので、後者の方法は非常に便利です。
低レベルの使用においてRedisConnection时
は、マッピングRedisのコマンドのための方法を提供subscribe
し、pSubscribe
方法、それぞれのサブスクリプション・モードまたはチャネル。チャネル又は複数のモードをパラメータとして用いてもよいことに留意されたいです。サブスクリプションまたはクエリを変更するには、接続を待機しているRedisConnection
提供getSubscription
し、isSubscribed
方法。
春データRedisのがブロックされているサブスクリプションでコマンド。言い換えれば、接続上で購読呼び出すと、現在のスレッドがメッセージの開始を待ってブロックされてしまいます。唯一の同じ別のスレッドでは、通話を接続しunsubscribe
たりpUnsubscribe
するときのスレッド退会をリリースしていません。この問題の解決策は、「を参照してください。 メッセージ・リスナー・コンテナ (このドキュメントのを)」。したがって、あなたがメッセージを受信するために待機し始めた、とだけ記事に実行新しいサブスクリプションの接続、既存のサブスクリプションや配信停止コマンドを変更することができ、接続のサブスクリプションを開始した後。
あなたがメッセージをサブスクライブしたい場合は、必要性は、コールバックのMessageListenerを実装します。メッセージが受信されると、コードは、コールバックとのonMessageで実行されます。インタフェースのみ実際のメッセージにアクセスすることができ、それはまた、チャネルを介してアクセスすることができ、受信されたパターンは、サブスクリプション・チャネル(もしあれば)のためのマッチング。これは、コンテンツによってさまざまなメッセージを区別することはできませんと呼ばれるパーティーは、あなたはまた、その他の詳細を確認することができますことができます。
2.1メッセージ・リスナーコンテナ メッセージ・リスナー・コンテナ
障害物の性質により、(接続)下には、各リスナーの接続とスレッド管理を提供する必要があるため、魅力のない購読します。この問題を軽減するために、春データが提供してRedisMessageListenerContainer来处理
、すべての重い仕事を。あなたがEJBおよびJMSに精通している場合は、それがPOJOでSpringフレームワークとメッセージ駆動型サポート(MDP)に近いように設計されたので、あなたは、おなじみの概念を見つける必要があります。
メッセージリスナ容器としてRedisMessageListenerContainerは、メッセージを受信するように適合され、Redisのチャネル駆動のMessageListenerインスタンスが注入されます。すべてこのコンテナ内のスレッドは、現在進行中のリスナーに受け、分散メッセージを担当し、メッセージ・リスナー・コンテナはMDPとメッセージングプロバイダ間の仲介で、メッセージを受信するために登録する責任があり、資源獲得や、異常な変換をリリース。これは、注目フレームに委託(おそらく複雑な)ビジネスロジックとモデルRedisのインフラに関連した書き、メッセージを受信する(とに反応する)ことができ、アプリケーション開発者としてあなたを可能にします。
また、アプリケーションが占めるスペースを最小限にするために、RedisMessageListenerContainer
リスナーの複数のサブスクリプションを共有していない場合でも、また共有するリスナーの複数の接続スレッドを可能にします。そのため、どんなに多くのリスナーやチャネル・トラッキング・アプリケーション、運用コストは、そのライフサイクル全体で同じ残っていません。あなたがアプリケーション内でリスナーを追加または削除できるように、また、コンテナは、再起動することなく、実行されて、実行を変更するときに設定することができます。また、遅延血管サブスクリプション方式を使用して、RedisConnection
必要なときにのみ使用。すべてのリスナーがキャンセルされた場合は、サブスクリプションは、自動的にクリーンアップを実行し、スレッドを解放します。
非同期メッセージ、コンテナの必要性を支援するためにjava.util.concurrent.Executor
(または春の TaskExecutor
メッセージをディスパッチします)。負荷の数、リスナーやランタイム環境によると、あなたはより良いあなたのニーズを満たすために、プログラムの実装を変更したり、調整する必要があります。具体的には、ホスティング環境(例えば、アプリケーションサーバ)で、強く、適切な選択することをお勧めしますTaskExecutor
、その実行時に使用する方法を。
2.2 MessageListenerAdapter
MessageListenerAdapter
最後のカテゴリは、春の非同期メッセージをサポートするコンポーネントです。要するに、それはほとんどのことができます任意の MDP(いくつかの制約がありますが)として公開されたクラス。次のインターフェイスの定義を考えてみましょう:
public interface MessageDelegate {
void handleMessage(String message);
void handleMessage(Map message); void handleMessage(byte[] message);
void handleMessage(Serializable message);
// pass the channel/pattern as well
void handleMessage(Serializable message, String channel);
}
ただし、インターフェイスが伸びていないことに注意してくださいMessageListener
インターフェイスを、まだ使用することができますMessageListenerAdapter
MDPとして使用するクラスを。また、様々なメッセージ処理メソッドが強いのタイプに基づいてどのように注意してコンテンツの異なるMessage
、彼らはタイプを受信して処理することができます。また、送信モードチャンネル又はメッセージは、メソッドのような第2のパラメータ・タイプに渡すことができますString
。
public class DefaultMessageDelegate implements MessageDelegate {
// implementation elided for clarity...
}
上記のことに注意してくださいMessageDelegate
インタフェース(上部DefaultMessageDelegate
クラス)が単にない Redisの依存性。私たちは、次の構成システムはMDPのためのPOJOを変換し、使用します。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:redis="http://www.springframework.org/schema/redis"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/redis http://www.springframework.org/schema/redis/spring-redis.xsd">
<!-- the default ConnectionFactory -->
<redis:listener-container>
<!-- the method attribute can be skipped as the default method name is "handleMessage" -->
<redis:listener ref="listener" method="handleMessage" topic="chatroom" />
</redis:listener-container>
<bean id="listener" class="redisexample.DefaultMessageDelegate"/>
...
<beans>
注:トピックはリスナーチャネルとすることができる(例えば、topic="chatroom"
)やモード(例えばtopic="*room"
)
前述の例では、Redisの名前空間宣言メッセージリスナPOJOの容器を使用し、自動的にリスナーとして登録します。次のように完全なBeanが定義されています。
<bean id="messageListener" class="org.springframework.data.redis.listener.adapter.MessageListenerAdapter">
<constructor-arg>
<bean class="redisexample.DefaultMessageDelegate"/>
</constructor-arg>
</bean>
<bean id="redisContainer" class="org.springframework.data.redis.listener.RedisMessageListenerContainer">
<property name="connectionFactory" ref="connectionFactory"/>
<property name="messageListeners">
<map>
<entry key-ref="messageListener">
<bean class="org.springframework.data.redis.listener.ChannelTopic">
<constructor-arg value="chatroom">
</bean>
</entry>
</map>
</property>
</bean>
メッセージが受信されるたびに、アダプタが自動的かつ透過的に実行するRedisSerializer
フォーマット間の変換を所望のオブジェクト・タイプを下げる(すでに構成します)。コールの捕捉及び処理の方法により容器に起因する任意の異常が(デフォルトでは、例外をログに記録しました)。