ビッグデータの飼育係（上）

1分散の概要

• 我々は、すべてのサービスが、インターネットの発展に伴い、サーバーのプロセスに展開し、徐々に分散アーキテクチャへと進化しているしている、複数のサービスが異なるマシンに異なるプロセスで展開され、早期の単量体構造を取得するために使用しました。

 

 

 

2飼育係の概要

• 飼育係は、オープンソースは、分散アプリケーションは、データリリースのサブスクリプション、負荷分散、ネーミングサービス、クラスタ分散ロック管理、分散キューの機能を実装することができ、分散データの一貫性のあるソリューションを提供するために、コーディネートサービスを配布しています。
• 飼育係は、分散データの一貫性ソリューションへのアクセスを提供し、分散データの一貫性は何ですか？

 

 

•  上に示したように、ユーザのユーザDB1 900を修正するためのバランスがあり、DB2データベース、データベース・データがDB2にDB1を更新していないユーザーへの読み取り要求場合、データベースは、クラスタ全体のデータの矛盾が発生します。

 

• 強い整合性と結果整合性へのデータの一貫性、データの矛盾た場合、ユーザーは読み取りと書き込みのデータは常に一貫していることを確認するために、外部データ・サービスを提供していないことを強い整合手段。強力なデータの一貫性値は、DB2からの同期データの前にアンロック、読み取り操作を提供しないからケースDB1に、ロック機構を介して解決される必要があります。限り、同期が完了すると、将来的にサービスを提供するためだけに。最終的一貫性には、リアルタイムの要件はありません、データが最終同期させることができることが必要です。

 

3つのCAPの原則

• 分散システムにおけるCAPは、主に一貫性（整合性）、アベイラビリティ（可用性）およびフォールトトレランスパーティション（パーティション公差）を指します。
  • 一貫性：一貫性が強い整合性を指します。
  • 可用性：システムが提供するサービスは、ユーザーの操作は、指定された応答時間内に応答要求は、システムが利用できないことを時間を超える要求し、常に利用可能です。
  • パーティションが依然として全体のネットワーク障害がない限り、提供される外部サービスの一貫性と可用性を確保するために必要とされる場合、任意のネットワーク障害の面における分散システム：フォールトトレランスをゾーニング。
• 分散システムでは、同時に2つまで満たすために、一貫性、可用性、パーティションのフォールトトレランスを満たすことができない、分散型インターネットアプリケーションのために、そのP、そうCP、いずれかのAPのいずれかを確認する必要があります。

 

4コヒーレンシ・プロトコル

4.1概要

• 複数の分散ノード間場合トランザクションのニーズは、トランザクションのACID特性を保証するために、我々は、スケジューリングがコヒーレンシ・プロトコルの様々な由来するこの考えに基づいて、各ノードを分散調整するコーディネーターを選出する必要があります。

4.2 2PC（二阶段提交）

• 顾名思义，二阶段提交叫事务的提交过程分为两个阶段：

• 阶段一：提交事务请求。
• ①协调者向所有的参与者节点发送事务内容，询问是否可以执行事务操作，并等待其他参与者节点的反馈。
• ②各个参与者节点执行事务操作。
• ③各个参与者节点反馈给协调者，事务是否可以执行。

 

• 阶段二：事务提交
• 根据一阶段各个参与者节点反馈的ack，如果所有参与者节点反馈ack，则执行事务提交，否则中断事务。
• 事务提交：
• ①协调者向各个参与者节点发送commit请求。
• ②参与者节点接受到commit请求后，执行事务的提交操作。
• ③各个参与者节点完成事务提交后，向协调者返送提交commit成功确认消息。
• ④协调者接受各个参与者节点的ack后，完成事务commit。
• 中断事务：
• ①发送回滚提交。
• ②各个参与者节点回滚事务。
• ③反馈给协调者事务回滚结果。
• ④协调者接受各个参与者节点ack后回滚事务。

 

• 二阶段提交存在的问题：
• ①同步阻塞：二阶段提交过程中，所有参与事务操作的节点都处于同步阻塞状态，无法进行其他的操作。
• ②单点问题：一旦协调者出现单点故障，无法保证事务的一致性操作。
• ③脑裂导致数据不一致：如果分布式节点出现网络分区，某些参与者未收到commit提交命令，则出现部分参与者完成数据提交。未收到commit命令的参与者则无法进行事务提交，整个分布式系统则出现了数据不一致的现象。

4.3 3PC（三阶段提交）

• 3PC是2PC的改进版，实质是将2PC中提交事务请求拆分为两部，形成了CanCommit、PreCommit、doCommit三个阶段的事务一致性协议。

 

 

• 阶段一：CanCommit
• ①事务询问。
• ②各个参与者节点向协调者反馈事务询问的响应。

 

• 阶段二：PreCommit
• 根据阶段一的反馈结果分为两种情况：
• 1）执行事务预提交。
• ① 发送预提交请求：协调者向所有参与者节点发送PreCommit请求，进入Prepared阶段。
• ②事务预提交：各个参与者节点接受到PreCommit请求，执行事务操作。
• ③各个参与者节点向协调者反馈事务执行：　　
• 2）中断事务。任意一个参与者节点反馈给协调者响应No的时候，或者在等待超时后，协调者还没有收到参与者的反馈，就中断事务。
• ①协调者向各个参与者节点发送abort请求。
• ②参与者节点接受到abort请求后，或者等待超时时间后，中断事务。

 

• 阶段三：doCommit
• 1）执行提交
• ①发送提交请求。协调者向所有参与者节点发送doCommit请求。
• ②事务提交。各个参与者节点接受到doCommit请求后，执行事务提交操作。
• ③反馈事务提交结束。各个参与者节点完成事务提交以后，向协调者发送ack。
• ④事务完成。协调者接受各个参与者反馈的ack后，完成事务。
• 2）中断事务
• ①参与者接受到abort请求后，执行事务回滚。
• ②参与者完成事务回滚以后，向协调者发送ack。
• ③协调者接受回滚ack以后，回滚事务。

 

• 3PC相对于2PC而言，解决了协调者挂点后参与者无限阻塞和单点问题，但是仍然无法解决网络分区问题。