Redis深さ冒険記(四)をMQとする
4045 ワード
PubSub & Stream PubSub 単純キュー モード購読 Stream id キュー命令 xadd maxlen xdel xrange count xlen 消費指令 グループなし xread count block xgroup create xreadgroup xinfo 高可用性 PubSub
単純キュー
Pubが成功した後にSubを行うとメッセージが得られない場合があります.遅延が必要です.メッセージがない場合、Subは直接空に戻り、ブロックされません.ブロックする方法もあります.まずSubを起動しなければなりません.そうしないと、起動前のPubからの情報が受け取れません.また、SubがRedisを掛けても補充されないRedisが再起動すると、すべてのメッセージが失われます.結局、RedisはすべてのSubがなくなったと考えています.
モード購読
これはRabbitMQのTopicExchangeと似ていて、*でマッチングしています
Stream
StreamはPubSubの2点に対して、1つは再起動でデータが失われないことであり、もう1つはConsumer Group(xgroup createで明示的に作成され、作成時にどのメッセージから消費するかを指定する必要がある)がある.
消費者の内部には状態変数pendingがあります.idsは、現在クライアントによって読み取るがackのメッセージが記録されている.クライアントにackがなければ、この変数のメッセージIDはますます多くなり、あるメッセージがackされると減少し始める.このpending_ids変数はRedisの公式にPEL、すなわちPending Entries Listと呼ばれ、これはコアのデータ構造であり、クライアントが少なくとも1回メッセージを消費することを確保し、ネットワーク伝送の途中で処理されずに失われないようにするために使用される.
id
メッセージIDの形式はtimestampInMillis-sequence
idはxaddで手動で指定することもできるが、前のidより大きくなければならない.そうしないと、エラーが発生する.これは、手動を使用すると、これ以上自動化できないことを意味する.公式の説明によると、これは一般的にDBのidと一致するように、いくつかの小さなシーンに使用されます.
キューめいれい
xadd
ストリームにメッセージを追加します.構文は以下の通りです.*はidが自動的に生成されることを示します.
maxlen
このパラメータでメッセージキューの長さを制御できます.例は次のとおりです.
上の命令が実行された後、長さは3を超えない
xdel
公式サイトによると、メッセージにフラグビットを設定し、メッセージの全長に影響を与えない.本当の削除はmacro-node全体で発生し、すべてのentryが公式サイトにマークされて与えられたこの命令の用途です.
This may be useful, for instance, in order to comply with certain privacy policies.
xrange
ここではclosed intervalを使用し、削除メッセージは含まれません(これは明らかではありません)、次の構文を使用してすべてを返します.
また、パラメータに自動補完機能がある場合は、以下のように説明します.
XRANGE will auto-complete the start interval with -0 and end interval with -18446744073709551615, in order to return all the entries that were generated between a given millisecond and the end of the other specified millisecond.
count
xlen
ここには、キューが存在しない場合は0を返すピットがあります.そのため、typeまたはexistsをさらに使用して空のキューが存在するかどうかを明確にする必要があります.また、私のテストによると、xdel後に長さが減少します.
消費命令
グループなし
xread
このコマンドはStreamをリストとして扱い、指定された場所から完全な構文を読み出します.
XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key …] id [id …]
count
どれだけの情報を消費する必要があるかを指摘する
block
ブロック数ミリ秒、0は常にブロックされていることを示します
xgroup
完全な構文は次のとおりです.
XGROUP [CREATE key groupname id-or- ] [ S E T I D k e y g r o u p n a m e i d − o r − ] [SETID key groupname id-or- ][SETIDkeygroupnameid−or−] [DESTROY key groupname] [DELCONSUMER key groupname consumername]
create
普通は0-0で最初から消費することを表して、**$**は終わりを表します
xreadgroup
xreadと似ていますが、グループ内のメッセージがあるだけです.
xinfo
xinfo groupskeyを使用してgroupメッセージを表示するか、xinfo consumers key consumerを使用して消費者情報を読み取ることができます.consumerは前のコマンドから来ています.
高可用性
ただし、Redisの命令レプリケーションが非同期であることを考慮すると、failoverが発生した場合、Redisはデータの極小部分を失う可能性があります.この点、Redisの他のデータ構造も同様です.
単純キュー
Pubが成功した後にSubを行うとメッセージが得られない場合があります.遅延が必要です.メッセージがない場合、Subは直接空に戻り、ブロックされません.ブロックする方法もあります.まずSubを起動しなければなりません.そうしないと、起動前のPubからの情報が受け取れません.また、SubがRedisを掛けても補充されないRedisが再起動すると、すべてのメッセージが失われます.結局、RedisはすべてのSubがなくなったと考えています.
モード購読
これはRabbitMQのTopicExchangeと似ていて、*でマッチングしています
Stream
StreamはPubSubの2点に対して、1つは再起動でデータが失われないことであり、もう1つはConsumer Group(xgroup createで明示的に作成され、作成時にどのメッセージから消費するかを指定する必要がある)がある.
消費者の内部には状態変数pendingがあります.idsは、現在クライアントによって読み取るがackのメッセージが記録されている.クライアントにackがなければ、この変数のメッセージIDはますます多くなり、あるメッセージがackされると減少し始める.このpending_ids変数はRedisの公式にPEL、すなわちPending Entries Listと呼ばれ、これはコアのデータ構造であり、クライアントが少なくとも1回メッセージを消費することを確保し、ネットワーク伝送の途中で処理されずに失われないようにするために使用される.
id
メッセージIDの形式はtimestampInMillis-sequence
idはxaddで手動で指定することもできるが、前のidより大きくなければならない.そうしないと、エラーが発生する.これは、手動を使用すると、これ以上自動化できないことを意味する.公式の説明によると、これは一般的にDBのidと一致するように、いくつかの小さなシーンに使用されます.
キューめいれい
xadd
ストリームにメッセージを追加します.構文は以下の通りです.*はidが自動的に生成されることを示します.
XADD mystream * field1 value1 field2 value2 field3 value3
maxlen
このパラメータでメッセージキューの長さを制御できます.例は次のとおりです.
xadd codehole maxlen 3 * name xiaorui age 1
上の命令が実行された後、長さは3を超えない
xdel
公式サイトによると、メッセージにフラグビットを設定し、メッセージの全長に影響を与えない.本当の削除はmacro-node全体で発生し、すべてのentryが公式サイトにマークされて与えられたこの命令の用途です.
This may be useful, for instance, in order to comply with certain privacy policies.
xrange
ここではclosed intervalを使用し、削除メッセージは含まれません(これは明らかではありません)、次の構文を使用してすべてを返します.
XRANGE somestream - +
また、パラメータに自動補完機能がある場合は、以下のように説明します.
XRANGE will auto-complete the start interval with -0 and end interval with -18446744073709551615, in order to return all the entries that were generated between a given millisecond and the end of the other specified millisecond.
count
count , :
XRANGE somestream 1526985054069-0 + COUNT 1
1) 1) 1526985054069-0
2) 1) "duration"
2) "72"
3) "event-id"
4) "9"
5) "user-id"
6) "839248"
xlen
ここには、キューが存在しない場合は0を返すピットがあります.そのため、typeまたはexistsをさらに使用して空のキューが存在するかどうかを明確にする必要があります.また、私のテストによると、xdel後に長さが減少します.
消費命令
グループなし
xread
このコマンドはStreamをリストとして扱い、指定された場所から完全な構文を読み出します.
XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key …] id [id …]
count
どれだけの情報を消費する必要があるかを指摘する
block
ブロック数ミリ秒、0は常にブロックされていることを示します
xgroup
完全な構文は次のとおりです.
XGROUP [CREATE key groupname id-or- ] [ S E T I D k e y g r o u p n a m e i d − o r − ] [SETID key groupname id-or- ][SETIDkeygroupnameid−or−] [DESTROY key groupname] [DELCONSUMER key groupname consumername]
create
普通は0-0で最初から消費することを表して、**$**は終わりを表します
xreadgroup
xreadと似ていますが、グループ内のメッセージがあるだけです.
xinfo
xinfo groupskeyを使用してgroupメッセージを表示するか、xinfo consumers key consumerを使用して消費者情報を読み取ることができます.consumerは前のコマンドから来ています.
高可用性
ただし、Redisの命令レプリケーションが非同期であることを考慮すると、failoverが発生した場合、Redisはデータの極小部分を失う可能性があります.この点、Redisの他のデータ構造も同様です.