フレームワーク: 分散理論 CAP、BASE

[[403371]]

この記事はWeChatの公開アカウント「Sneak Forward」から転載したもので、著者はcscwです。この記事を転載する場合は、Qianxingqianxing の公開アカウントにご連絡ください。

序文

事業が拡大するにつれて、どんどん機能が追加されていきます。すべての機能を同じサービス下に置くと、コードが混在し、メンテナンスが困難になります。小さなバグが原因でサービス全体が利用できなくなることもよくあります。そこで、業務機能に応じて複数の異なるサービスに分割します（マイクロサービス化）。複数のサービスから構成されるシステムは、「分散システム」という別名を持っています。システム内でサービスステータスをどのように管理するのでしょうか?関連する理論は何ですか?

分散型とクラスター型
データベーストランザクション
分散トランザクション
分散データの一貫性
CAP理論
ベース理論

分散型とクラスター型

分散とは、ネットワークを介して接続され、情報を交換することで連携する複数のサービスまたはコンポーネントによって形成されるシステムを指します。

クラスターは、同じサービスコンポーネントの複数のインスタンスの集合です。

これら 2 つの概念は完全に矛盾するものではなく、分散システムはクラスターになることもできます。 Zookeeper クラスターも分散システムであり、そのサービスは相互に通信して連携します。

クラスターは分散システムではありません。たとえば、複数の負荷分散された HTTP サーバーは相互に通信しません。負荷分散されていない場合は、分散システムとは言えません。

データベーストランザクション

トランザクションはデータ操作に基づいており、通常はトランザクションデータがデータベースに保存されるようにする必要があります。したがって、トランザクションを導入するときは、データベーストランザクションの ACID 特性を導入する必要があります。
原子性: トランザクション全体のすべての操作は完了するか、まったく完了しないかのいずれかであり、途中のリンクで操作が停止することは不可能です。
一貫性: トランザクションの開始前と終了前、および終了後にデータベースデータの一貫性制約に違反しません。
分離: 分離により、複数のトランザクションが同時に実行されるときに、相互実行によって発生するデータの不整合を防ぐことができます。
耐久性: トランザクションが完了すると、データへの変更は永続的になり、システムに障害が発生しても失われません。

分散トランザクション

分散システムは一般に複数の独立したサブシステムで構成され、ネットワーク通信を通じて相互に連携してさまざまな機能を実行します。このコラボレーションプロセスでは、各システムのデータの一貫性を確保する必要があります。このシステム間トランザクションを分散トランザクションと呼びます。

上記のシナリオには複数のケースがあります。在庫サービスと注文サービスの両方が成功します。あるいは、在庫サービスと注文サービスは部分的に成功しているが、従来の単一マシントランザクション理論はもはや適用されない。

分散トランザクションの難しさ

原子性: トランザクション操作は異なるノードにまたがります。複数のノードのうちの 1 つでの操作が失敗した場合、複数のノードでの操作が何も実行されないか、すべて実行されるようにする必要があります。

一貫性: ネットワーク伝送障害またはノード障害が発生すると、ノード間のデータ複製チャネルが中断され、トランザクション操作中にデータの一貫性を確保する必要があります。

分離: 分散トランザクション制御では、非同期送信が発生し、「部分的に送信された」トランザクションが表示される場合があります。

分散データの一貫性

ACID は分散トランザクションには適していません。分散トランザクションの難しさには、最終的にデータの不整合につながる問題が伴います。したがって、分散システムでは、システムの一貫性を確保することに重点が置かれます。

CAP理論

上で述べた分散トランザクションの難しさには、最終的にデータの不整合につながる問題が伴います。以下では、分散システムの一貫性の問題を理論的に分析し、これらの理論に基づいて分散ソリューションを紹介します（可用性と一貫性の対立：CAP理論）
一貫性: すべてのノードが最新かつ同一のデータコピーにアクセスする
可用性: 障害のないノードは、妥当な時間内に妥当な応答を返します (エラーやタイムアウトではありません)
パーティション耐性: 分散システムがパーティション化された場合でも、外部にサービスを提供し続けることができます。

ネットワークパーティションが発生した場合、サービスの提供を継続するには、強力な一貫性と可用性のどちらかを選択するしかありません。つまり、ネットワーク分割後は P が前提条件となり、P が決定された後にのみ C と A を選択できます。つまり、パーティション耐性を実現する必要があります。

なぜ同時に CA を保証できないのでしょうか?

システムが「パーティション分割」されている場合、システム内のノードが書き込み操作を実行しています。一貫性 C を確保するには、他のノードの読み取りおよび書き込み操作を禁止する必要がありますが、これは A と競合します。 A を保証するために他のノードの読み取りおよび書き込み操作が正常である場合、データの一貫性は保証できず、C と矛盾します。

CAP実践事例

ZooKeeper は CP を保証します。 ZooKeeper への読み取り要求はいつでも一貫した結果を得ることができますが、ZooKeeper は各要求の可用性を保証するものではありません。たとえば、リーダー選出プロセス中や、マシンの半分以上が使用できない場合は、サービスを利用できません。

EurekaはAPを保証します。 Eureka は A (可用性) を優先するように設計されています。 Eureka にはリーダーノードはありません。すべてのノードは同じであり、平等です。したがって、Eureka は、選出プロセス中にサービスが利用できなくなったり、マシンの半分以上が利用できなくなったりする ZooKeeper のような状態になりません。 Eureka は、ほとんどのノードに障害が発生した場合でも、1 つのノードが利用可能である限り、サービスの通常の提供に影響が及ばないことを保証します。ただし、このノード上のデータは最新ではない可能性があります。

ベース理論

BASE は、Basically Available (基本的に利用可能)、Soft-state (ソフトステート)、Eventually Consistent (最終的に一貫性がある) の略です。 BASE 理論は、CAP における一貫性 (C) と可用性 (A) のトレードオフの結果です。

結果的一貫性は、弱い一貫性の特殊なケースです。システムは、一定期間内にデータの一貫性状態が達成されることを保証します。

基本的な使いやすさ

基本的な可用性とは、分散システムで予期しない障害が発生した場合に、ある程度の可用性が失われることが許容されることを意味します。では、可用性をいくらか失うことを許可するということはどういう意味でしょうか?

応答時間の損失: 通常、ユーザー要求を処理して結果を返すのに0.5秒かかりますが、システム障害により、ユーザー要求の処理時間は3秒になります。

システム機能の損失: 通常の状況では、ユーザーはすべてのシステム機能を使用できますが、システムトラフィックの急増により、システムの一部のコア以外の機能が使用できなくなります。

ソフトステート

ソフト状態とは、システム内のデータが中間状態（CAP 理論におけるデータの不整合）を持つことが許可され、この中間状態の存在がシステム全体の可用性に影響を与えないと考えられる状態、つまり、異なるノード上のデータコピー間でデータを同期するプロセスで遅延が発生することがシステムで許可されている状態を意味します。