CAPの原則
CAPの原理は、CAP定理とも呼ばれ、分散システムにおける一貫性、可用性、分割許容度を指します。 CAPの原理は、これら3つの要素が同時に2点しか達成できないと述べています。3つすべてを同時に取るのは不可能です。
CAPの原則の本質はAP、CP、またはACのいずれかですが、CAPという概念はありません。 分散システムにデータのコピーが存在しない場合、システムは強整合性条件を満たす必要があります。なぜなら、一意なデータしか存在しないため、データ不整合は存在しません。この時点でCとPの2つの要素が存在する一方で、ネットワーク分割条件やダウンタイムが発生すると、必然的に一部のデータにアクセスできなくなり、可用性条件を満たせなくなります。すなわち、この場合CPシステムは得られますが、CAPは同時に満たされることはできません。
復習：
DotNetCore.CAP
CAPは分散システム(SOA、マイクロサービス)におけるイベントバスおよび実装です。最終的な一貫性(Distributed Transactions)は、軽量で高性能、使いやすいオープンソースのC#ライブラリです。
GitHubアドレス:ハイパーリンクのログインが見えます。
Dotnet CAPはEvent Busのすべての機能を備えており、CAPはEventBusでの公開や購読をより効率化した方法を提供します。
MediatRは、単一のハンドラーに公開するためのSendメソッドと、複数のハンドラーに公開するためのPublish方式を提供する、非常に便利なプロセス中のメッセージサブスクリプションおよびパブリッシングフレームワークです。 現在、.NET Framework4.5、 NET Stardand1.3、. NET Stardand 2.0やその他のバージョンは、プラットフォーム上で使用可能です。
ASP.NET CoreはMediatR仲介モデルを使用しています
https://www.itsvse.com/thread-9272-1-1.html
アーキテクチャプレビュー
CAPはKafka、RabbitMQ、AzureServiceBus、AmazonSQSなどのメッセージキューをサポートし、データベースストレージとしてSql Server、MySql、PostgreSQL、MongoDBの拡張も提供しています。
この記事では、RabbitMQとSQL Serverをメッセージキューおよびストレージとして使用しています。
RabbitMQをインストールする
具体的なインストールチュートリアルについては、以下をご覧ください:
アカウントの追加も省略されていますので、以下を参照してください:
私自身がテストアカウントを追加し、仮想ホスト数を制限しました。以下のように示しています。
そうでなければ、誤差は次のようになります。
ACCESS_REFUSED - 認証機構PLAINによるログインが拒否されました。 詳細はブローカーログファイルをご覧ください。
指定されたエンドポイントはいずれも到達できませんでした
.NET CoreはCAPを統合しています
まず、送信者であり受信者でもある新しい ASP.NET コアプロジェクトを作成します。 Nugetコマンドを使って、このようにパッケージをインストールしてください:
起動時に、サービスメソッドConfigureServicesを次のように設定します:
ダッシュボードは以下の通り、ウェブサイト/capアドレスでご覧いただけます。
データ持続性:キャップは自動作成「公開済み」と「受信済み」は、2つのローカルデータベーステーブルです
テーブルを作成してください。 [公開](
[id] [bigint] 無効ではありません。
[バージョン] [ンヴァルチャル](20) 無効ではない、
[名前] [ンヴァルチャル](200) 無効ではない、
[内容] [ンヴァルチャル](マックス) NULL、
[やり直し] [int] 無効ではありません。
[追加] [日付2](7) 無効ではない、
[有効期限切れ] [日付2](7) 無効、
[ステータスネーム] [ンヴァルチャル](50) 無効ではない、
制約[PK_cap。 公開済み] 主キークラスタリング
(
[同上] ASC
) (PAD_INDEX = オフ、STATISTICS_NORECOMPUTE = オフ、IGNORE_DUP_KEY = オフ、ALLOW_ROW_LOCKS = オン、ALLOW_PAGE_LOCKS = オン)が[プライマリ]
)[主要] TEXTIMAGE_ON [主要]
行け テーブルを作成してください。 [受領済み](
[id] [bigint] 無効ではありません。
[バージョン] [ンヴァルチャル](20) 無効ではない、
[名前] [ンヴァルチャル](200) 無効ではない、
[グループ] [ンヴァルチャル](200) 無効、
[内容] [ンヴァルチャル](マックス) NULL、
[やり直し] [int] 無効ではありません。
[追加] [日付2](7) 無効ではない、
[有効期限切れ] [日付2](7) 無効、
[ステータスネーム] [ンヴァルチャル](50) 無効ではない、
制約[PK_cap。 受信] 主鍵クラスタリング
(
[同上] ASC
) (PAD_INDEX = オフ、STATISTICS_NORECOMPUTE = オフ、IGNORE_DUP_KEY = オフ、ALLOW_ROW_LOCKS = オン、ALLOW_PAGE_LOCKS = オン)が[プライマリ]
)[主要] TEXTIMAGE_ON [主要]
行け
HomeControllerのコントローラー方式は以下の通りです:
ユーザーが正常に登録すると、異なるトピックの3つのメッセージが送信され、その後加入者がそれらを消費します。
CAPが起動すると、同じ消費者グループの複数の消費者が同じトピックメッセージを消費した場合、デフォルトの消費者グループが作成されます。処刑される消費者は一人だけです。 逆にもし消費者が異なる消費者グループに属している場合、すべての消費者は実行されます。
新しい.NET Coreコンソールプロジェクトを作成したり、サブスクライバー(消費者)として作成したり、パッケージを参照したりすると、ダッシュボードは無視できます。
コントローラー内にある場合は、[CapSubscribe(""])を直接追加して、関連するメッセージを購読してください。
もしあなたのメソッドがコントローラーにない場合、加入したクラスはICapSubscribeを継承し、[CapSubscribe(""]]タグを追加する必要があります。
コードは以下の通りです:
サブスクリプションクライアントを開き、メッセージ送信 http://localhost:28116/Home/UserRegister にアクセスしてみてください。効果は以下の通りです:
コンソールとコントローラー受信機の両方がトリガーされており、以下の図に示されています。
受信メッセージメソッドで手動で例外をスローしてみてください。コードは以下の通りです:
CAPは自動的にその方法を再試行します。失敗後の再試行回数はデフォルトで50回、再試行間隔はデフォルトで60秒です、下図に示されているように:
フレームワークはメッセージが一度だけ実行されることを100%確信することはできませんしたがって、いくつかの重要なシナリオでは、メッセージ側はメソッド実装の過程におけるビジネスの重複除去に注意を払います。
最後にソースコードを添付します:
観光客の皆さん、この投稿の隠された内容を見たい方は、どうぞ 答える
| 
2021年3月17日 18:12:50 に投稿
|
|
|
|
2021年3月18日 18:11:20に投稿
|
