分散データベース管理のデータの一貫性は、その最も重要なコア技術の一つですが、また、最も基本的なACID特性の「一貫性」（一貫性）データベースを満たすために分散データベースの保護を確実にするために。分散技術開発では、データの一貫性のソリューションとテクノロジーは、著者が実際に分散データベースのデータの一貫性と実際の実装の原則を導入するケーススタディとして、分散データベース開発本論文では、絶えず進化したものです。
1.データの一貫性
1.1データの一貫性とは何ですか
従来のリレーショナルデータベースのDBAの使用のほとんどは、「データの一貫性」を参照してくださいするとき***反応は、テーブル総務シーン間でデータの一貫性であったかもしれません。しかし、この記事では、「データの一貫性は、」どのように保証データの一貫性「のシーンに複数のコピーに保存されているのデータを指します。
データの整合性を確保するためにどのようにリレーショナルデータベース1.2
動作環境のために、従来のリレーショナル・データベース - ハードウェア要件は、例えば、高されている、Oracleはユーザーがミニコンピュータ+共有ストレージ環境データベースとして実行することをお勧めします、DB2 DPFはまた、ビルド、ハイエンド・ストレージ・サーバー+データベースに良く使用することをお勧めします動作環境。だから、データストレージ、セキュリティのための技術的要件に、従来のリレーショナルデータベースは、データのセキュリティを保護するためのハードウェア技術への依存度です。
データのセキュリティを保護ハードウェアやデータへのリレーショナル・データベースに基づいているため、データ、一貫性があると考えられ、デフォルトではデータを格納するために、ユーザリレーショナルデータベースを保護するために複数のセキュリティで同時に保存されることはありません。
データの整合性を保護するためにどのように1.3分散ストレージ
SequoiaDBとHDFS：ディスカッション・ペーパー分散ストレージの間、主にそのようなデータベースを分散大きなデータ製品及び分散ファイルシステム、を指します。
ユーザーが分散ファイルシステムの一貫性の原則を理解して行うとき、彼らは違いが何であるかのデータストレージとリレーショナルデータベースのデータの一貫性に格納されたデータ、および分散ストレージを必要とする理由は、まず理解する必要があります。
ビッグデータ技術の誕生は、新しい画期的なシステム・パフォーマンスを聞かせてください、そしてパフォーマンスとストレージにおける線形成長を取得するためにサポートするハードウェアの水平スケーラブルな方法です。これらは、従来のリレーショナルデータベースが提供できない、過去です。また、ビッグデータテクノロジーは、実行環境が必須要件のために良い十分でなければならない捨てられたが、垂直方向の拡大が提供頼る過去に比べバルク安いX86サーバクラスタ+より多くのコンピューティングハードウェアを取得するためにローカルディスクの方法を通じてビルド規模にユーザーを可能に機能とより多くのストレージスペース。
ビッグデータ技術の核となるアイデアは、複数のより小さなタスクに、大きなタスクを分散し、次いでそれによって全体のコンピューティング・システムまたは記憶容量の効率を改善する、完了するために同時操作により分配されます。データセキュリティ - 分散環境では、減少によるハードウェア要件に、必ずしも大規模なデータ製品は、他の重要な機能を提供が必要です。
データセキュリティを解決する方法上のビッグデータ製品は、簡単な言葉で、比較的近い、それはデータのセキュリティを保護するために、複数のマシンに保存されている非同期または同期の方法を介してデータを作ることです。
アドレスデータ技術的困難の後、セキュリティ、および新しい技術的な問題の導入に分散ストレージは、データの一貫性の複数のコピーを保護する方法です。ラフトはSequoiaDBが複数のコピーでデータの整合性を確保するためのアルゴリズムを使用することで、現在です。
2.Raftアルゴリズム
2.1Raftアルゴリズムの背景
分散環境では、わかりやすさ（コンセンサスアルゴリズムは***のPaxosアルゴリズムにする必要がありますが、2人が理解することはジョン・アスターハウト、ディエゴ・Ongaro、そう2013年に、それはあまりにも曖昧にされているため、そして達成することは極めて困難）コンセンサスアルゴリズムいかだの目標を設計しました。いかだ***アルゴリズムが理解しやすく、実装が簡単なことを特徴としています。
2.2Raftアルゴリズムの概要
そしてたPaxos異なる、ラフト強調は簡単限り、ラフトたPaxosであり、n / 2 + 1のノードは、通常のサービスを提供することができます。
問題はうまく問題はさらにいくつかのマイナーな問題に対処するために複雑になっているとき、いかだも分割統治のアイデアを使用することが知られている破ることができます。選挙（リーダー選挙）、ログのレプリケーション（ログ・レプリケーション）、安全性（安全性）：筏アルゴリズムサブは三つの問題を解決するに焦点を当てました。
ラフトアルゴリズムはノードリーダーの機能を強化するために、フォロワノードデータのみリーダーから得ることができ、フォロワが達成されるノードは、リーダーのような単純なようになり、通信を維持する責任があり、そしてデータは、リーダーを受け入れるように押し込むことができます。
2.3Raftアルゴリズム原則
2.3.1ノードロール
ラフトアルゴリズムは、ノードのステータスは、ロールの三種類、即ちリーダー（***）、フォロワー（フォロワー）と候補（候補）に分割されています。
リーダー、クライアントからの要求を処理する責任、責任のフォロワーは、ログに同期して、ハートビートフォロワーとの間の接触を確実にするために、
フォロワー、クラスターがちょうど始まったとき、すべてのノードがフォロワー状態です、その作業は主に、ログの同期要求、応答候補者の要求のリーダーへの応答、およびトランザクションフォロワーリーダーに要求を転送するための要求です。
候補者、選挙の投票を担当するリーダーは、状態にリーダー、候補状態からリーダーノードを選出しました。
2.3.2規約
分散環境では、「時刻同期は、」持続的な技術的な問題となっています。ラフトは、この問題を解決するために、項に一度は、データ整合性の異なる時間期間に対応する（「論理時間」として理解することができます）。
利用規約には、以下の原則を持っています
- 各用語は、ほとんどのリーダーであり
- 特定の用語は、選挙の敗北のために存在してもよい、状況は何のリーダーではありません
- 各ノードは、独自のローカルcurrentTermを維持します
- 各用語は、継続的に増えています
- 他の数の時間よりもフォロワーフォロワー用語用語数ならば、番号が他の番号フォロワー期間と一致するようにフォロワー用語用語数を更新します。
2.3.3選挙
タイマーによってトリガーいかだ選挙、各ノードのトリガ時間は同じではありません。
タイマー火災が選挙期間数の増加やフォロワーによって、ノードの状態が候補になって、他のノードにRequestVote RPC（投票へのリモートプロシージャコールプロトコルリクエスト）を開始要求し、そのときのすべてのノードは、状態フォロワーの開始時にあります発生する可能性が選挙の3種類があります。
発信元ノードは、候補ノードリーダー状態から状態へ、RequestVote投票ノードN / 2 + 1（大部分）を受信し、リーダーの正常な状態を維持するために、他のノードにハートビートを送信します。
如果收到投票请求后，该节点发现发起投票的节点Term大于自己，则该节点状态从Candidate转为Follower，否则保持Candidate状态，并且拒绝该投票请求
选举期间发生了超时，则Term编号递增，重新发起选举.
2.3.4 日志复制
日志复制主要的作用就是用来保证节点的数据一致性与高可用性。
当Leader被选举出来后，所有的事务操作都必须要经过Leader处理。这些事务操作成功后，将会被按顺序写入到LOG中，每个LOG都包含一个index编号。
Leader在LOG发生变化后，通过HeartBeat将新的LOG同步到Follower上，Follower在接收到LOG后，再向Leader发送ACK信息，当Leader接到大多数(2/n+1)Follower的ACK信息后，将该LOG设置为已提交，并且Leader将LOG追加到本地磁盘中。
同时Leader将在下一个HeartBeat中，通知所有的Follower将该LOG存储在各自的本地磁盘中。
2.3.5 安全性
安全性是用于确保每个节点都是按照相同的日志序列进行执行的安全机制。
如果当某个Follower在同步Leader的日志时失败，但是未来该Follower又可能被选举为Leader时，就有可能导致前一个Leader已经commit的日志发生覆盖，这样就导致了节点执行不同序列的日志。
Raft的安全性就是用于保证选举出来的Leader一定包含先前已经commit LOG 的机制，主要遵循的原则如下：
每个Term 只能选举一个Leader;
Leader的日志完整性，则当Candidate重新选举Leader时，新的Leader必须要包含先前已经commit的LOG;
Candidate在选举新的Leader时，使用Term来保证LOG的完整。
3.分布式数据库数据一致性技术实现
以国产原厂的分布式数据库SequoiaDB为例，SequoiaDB在多副本的部署中，采用Raft算法保证数据在多副本环境中保持一致。
SequoiaDB集群中，总共包含3中角色节点，分别是协调节点、编目节点和数据节点。由于协调节点本身不存任何数据，所以只有编目节点和数据节点存在事务操作，换言之，编目分区组和数据分区组的副本同步采用Raft算法保证数据一致性。
