Lignum: 分散メッセージキュー

Nov 24 2022

すべての WFH ファズと孤立した状況の間で、私は Consul を使用して分散ロックを調査することに着手しました。単純なテストプログラムはすぐに、Lignum と呼ばれる分散メッセージキューを構築する道になりました。これは、Lignum メッセージキューの紹介記事です。

すべての WFH ファズと孤立した状況の間で、私は Consul を使用して分散ロックを調査することに着手しました。単純なテストプログラムはすぐにLignumと呼ばれる分散メッセージキューを構築するための道となりました。

リグナムの概要

これは、Lignum メッセージキューの紹介記事です。

分散システムとは

そこには多くの定義があり、単純な Google 検索では複数の回答が得られます。分散システムを、共通の目標に向かって機能する自律的または個別のプログラムまたはシステムの集合と定義できます。

つまり、共通の目的を果たすために、さまざまな通信手段によってネットワーク化された複数のシステム。ある人が Web ページを要求し、ある人が Web ページを提供するシステムである可能性があります。エンドユーザーにとって、これらのシステムは 1 つのように見えるかもしれませんが、相互に通信してタスクを実行するそのようなシステムが何百も存在する可能性があります。

メッセージキューとは

他のサービスが FIFO 順でメッセージを読み書きするためのキューデータ構造を提供するシステム。
Queue を使用すると、プロデューサーサービスはメッセージを書き込み、コンシューマーは非同期で消費できます。生産者と消費者はお互いを意識する必要はありません。

メッセージ待ち行列

メッセージキューの 2 つの基本的な特徴は次のとおりです。

トピック
メッセージは名前付きバッファに送信され、これらはトピックと呼ばれます。トピックからメッセージを生成および消費します。
メッセージ
これは、他のユーザーが使用できるようにトピックに書き込む実際のメッセージです。

分散メッセージキューとは

複数のノードでホストされるメッセージキューを構築すると、他のサービスの単一のエンティティとして機能するために集合的に連携します。

提供するユーザーメッセージをホストする複数のキューがあります。

信頼性と高可用性
耐障害性
パフォーマンス
複数のノードで読み取り負荷を共有する

Lignumは、 Consul session lockを使用した分散ロックを学習するためのテストプログラムとして開始されました。当時、私が Kafka に取り組んでいたときに、メッセージキューにピボットし始めました。
これはGoで書かれています。テスト駆動開発を念頭に置いて始めたのですが、すぐにめちゃくちゃになってしまいました。

リグナム建築

Lignum は本格的なメッセージキューではなく、進行中の作業です。あなたはできる

トピックにメッセージを送信
トピックからメッセージを消費する
メッセージはすべてのノードに複製されます。つまり、任意のノードを使用してトピックからメッセージを読み取ることができます
メッセージをディスクに永続化する

Lignum は、特別なセットアップを必要とせずにクラスターモードで動作できます。
クラスタ管理は、Consul のセッションロックによって容易になります。
各ノードは Consul に接続してリーダーを取得します。リーダーが見つからない場合、ノードの 1 つがリーダーとして選出されます。
他のすべてのノードは、自分自身をフォロワーとしてリーダーに登録します
リーダーに送信されたメッセージは、フォロワーノードにレプリケートされます
2 つのレプリケーションモードがあります
。WAL レプリケーション
b. ライブレプリケーション
リーダーが倒れた場合、フォロワーのいずれかがリーダーとして選出されます

現在、lignum は複製戦略の 2 つのモードを実装しています。

WAL レプリケーション
ライブ複製。

WAL レプリケーション

メッセージが config( message.initial-szie-per-topic) で定義されたバッファサイズを超えると、トピックごとにログファイルが作成されます。Lignum は.qwalトピックごとに WAL ファイル( )を作成します。メッセージ数がバッファサイズに達すると、このファイルはファイルとしてディスクにフラッシュされlogます。Lignum は、これらのログファイルの作成を頻繁に監視し、フォロワーに送信します。すべてのフォロワーはリーダーと定期的に同期され、最終的/遅延整合性が提供されます。

ライブレプリケーション

これはストリーミングレプリケーションです。フォロワーが既にリーダーに登録されている場合、後でトピックが作成された場合、メッセージの同期について心配する必要はありません。リーダーで受信したメッセージをそのままフォロワーに転送するだけです。この戦略では、メッセージは登録されたフォロワーにすぐに送信されます。このようにして、リグナムは強力な一貫性を提供できます。

リグナムの実行方法

前提条件
— Consul README
で指定されている Dockerfile を使用できます
リポジトリをクローンする

https://github.com/NishanthSpShetty/lignum.git

update 、構成の詳細については、このドキュメントconfig.ymlを参照できます。
走るmake run

メッセージを送る

curl --request POST \
  --url http://localhost:8080/api/message \
  --header 'Content-Type: application/json' \
  --data '{
   "topic": "test",
   "message":"this is a test message"
   }'

curl --request GET \
  --url http://localhost:8080/api/message \
  --header 'Content-Type: application/json' \
  --data '{
   "topic": "test",
   "from": 0,
   "to": 3
   }'

それが提供する配送保証は何ですか？
メッセージは永続化され、消費者はいつでも任意のオフセットを読み取ることができるため、配信の保証は消費者にあります。Lignum はメッセージの順序を保証します。

Lignum: 分散メッセージ キュー

Lignum: 分散メッセージキュー