Redis Stream-メッセージキューとしての一般的なアプリケーションシーン
Redis Stream
Redisの最新の大バージョン5.0はすでにRC 1で、その中で最も重要なFeatureは
Redis Streamで、Redis Streamの基本的な使用紹介と設計理念について私の前の文章(Redis Streamの概要)を見ることができます.Redis Streamは本質的に、Redisカーネル上で実装されるメッセージ配信サブスクリプション機能コンポーネントである.従来のPUB/SUB、BLOCKED LISTに比べて、簡単なシーンでメッセージキューとして使用することもできるが、Redis Streamはかなり改善されるに違いない.Redis Streamは、より効率的なメモリ使用およびメッセージ読み取り、さらにはKafkaに類似したConsumer Group機能をサポートするために、メッセージの永続化およびプライマリ・レプリケーション機能、新しいRadixTreeデータ構造を提供する.今日は、Redis Streamを実際のビジネスシーンでどのように使用するかに重点を置いています.Redis Stream実戦——IRCシステム
皆さんはIRCについてよく知っていると思います(調和のとれたxxチャットルームを覚えていますか:-))、多くの有名なオープンソースプロジェクト(Redisを含む)は自分のIRCチャンネルを持っていて、開発者と使用者がリアルタイムで思想の火花の衝突を行うのに便利で、私たちが今日紹介した主役--Redis Streamは、自身がIRCの中の1人のユーザーのideaに起源しています.IRCのモデルは以下の通りです.
あるIRCチャネルにおけるユーザは、他のすべてのユーザに自由にメッセージを送信してもよいし、他のすべてのユーザが送信したメッセージを受信してもよい.Redisに基づいてIRCシステムを構築するには、Redisの
PUB/SUB機能を使用することを思わず考えてしまいます.PUB/SUBに基づいて、すべてのユーザ(client)が同じIRCチャネル(channel 1)を購読するだけで、すべてのユーザからのメッセージを受信できることがわかる.メッセージを送信する場合は、パブリッシュコマンド(subscribe)コマンドを使用するだけでよい.ビジネス全体のロジックは非常に明確で簡単で、これもRedisの強さと流行の重要な原因です.提供される機能とデータ構造は、開発者の開発効率をできるだけ向上させることができます.しかし、
publishに基づいて構築されたIRCでは、PUB/SUBのメッセージモデルがPUB/SUBであるという問題がある.つまり、Redis自体は履歴メッセージを保存していない.IRCのあるユーザのネットワーク接続に異常が発生した場合、IRCに再加入した後、彼はチェーンを切った間のチャットの記録が見えず、新しく加入したユーザも最近の履歴が見えず、現在の議論の問題を迅速に理解するのに非常に不便である.また、Redisが再起動された場合、すべてのユーザーがチャンネルを再購読する必要があります.では、Redis Streamに基づいてIRCを構築するとしたら?
# Redis stream， ,
# stream( )
ip:7000> xadd channel1 * create-channel null
1528702126345-0# ， xadd ， ， ， 。
# ， 。
ip:7000> xadd channel1 * msg1-tony "Hello everyone."
1528702503377-0
ip:7000> xadd channel1 * msg2-tony "I am a big Redis fan." msg3-tony "Hope we can learn from each other.:-)"
1528702573546-0# ， '$' ID ，
# ， ID
# ，xread
ip:7000> xread BLOCK 100 STREAMS channel1 $
1) 1) "channel1"
2) 1) 1) 1528703048021-0
2) 1) "msg1-tony"
2) "Hello everyone."
ip:7000> xread BLOCK 100 STREAMS channel1 1528703048021-0
1) 1) "channel1"
2) 1) 1) 1528703061087-0
2) 1) "msg2-tony"
2) "I am a big Redis fan."
3) "msg3-tony"
4) "Hope we can learn from each other.:-)"
ip:7000> xread BLOCK 100 STREAMS channel1 1528703061087-0
(nil)Fire and ForgotとRedis Streamとでは、PUB/SUBが履歴送信メッセージを取得できることが重要な違いであるため、ユーザが接続を切断してIRCに再加入すると、# 1528703061087-0 ID
ip:7000> xrange channel1 1528703061087-0 +
1) 1) 1528706457462-0
2) 1) "msg1-andy"
2) "Nice to meet you guys."
2) 1) 1528706497200-0
2) 1) "msg4-tony"
2) "When will Redis 5.0 GA comes out?"
3) 1) 1528706601973-0
2) 1) "msg1-antirez"
2) "I think it will arrive in the second half of 2018."Redis Stream実戦——IoTデータ収集
Redisは強力で豊富なデータ構造のサポートに加えて、プラットフォームをまたいで、組み込み型のストレージシステムとしてARMベースのプラットフォームを走っています.例えば、著者は以前から、Redisが「ベリーパイ」に成功したと主張していました.
考えてみてください.IoT時代には、いつでもどこでもインターネットに接続できるスマートデバイスが無数にあります.あなたの家の冷蔵庫はリアルタイムで報告されます.冷蔵庫の中にはどんな食べ物がありますか.数量はいくらですか.新鮮度はどうですか.エアコンは今の温度はいくらですか.空気の質はどうですか.あなたの車はエンジンの各データ、変速箱の各データ、車内の空気の各データを絶えず報告します.このような多くのIoTデバイスは巨大なデータの洪水を形成し、採集が完了した後、クラウド上で分析を行い、巨大なユーザー価値を生み出す.
これらのデータは内容がそれぞれ異なるが,共通の特徴があり,いずれもタイミングデータである.ここを見ると、Redis Streamは設計当初から時系列データをサポートするために生まれた(第1部のRedis Streamの紹介を参照)、RedisはまたARMプラットフォームに成功し、将来のIoTには1兆級のデバイスがARMプラットフォームに基づいていることに気づくかもしれません.だから、私たちは思わず、現在様々なインターネットサービスの中でCacheとKVストレージとして広く応用されているほか、Redisの次の大きな異彩を放つ分野がユビキタスネットワークにあるかもしれないと推測することができます.
上の図は、典型的なモノのインターネット設備の情報収集、分析、展示のアーキテクチャです.Redisは埋め込み型のストレージシステムとして各IoTデバイス上を走り、各デバイスは
Redis Streamを使用して生成されたタイミングデータを一時的に保存し、その後、非同期的にクラウドにプッシュする.クラウド上に導入された各ビジネスプログラムは、プッシュされた元のデータを読み取り、一定のルールに基づいて分析し、信頼性の高いデータストレージシステムに結果を書き込む.ユーザは結果を読み取り,APPやwebページに表示し,システム全体に閉ループを形成する.著者:夏周tony
原文を読む
本文は雲栖コミュニティのオリジナル内容で、許可を得ずに転載してはならない.