ここでの基本的な問題は、「CAP定理」として知られています。これは、分散システムが持つことができる3つのプロパティを定義します。
- 一貫性:システムからデータを読み取ると、常に最新のデータが返されます。
- 可用性:すべての応答は成功または失敗します(状況が回復するまで待機し続けるだけではありません)
- パーティションの許容範囲:システムは、サーバーが相互に通信できない場合でも動作できます(サーバーがダウンしている場合は、この特殊なケースの1つです)。
CAP定理は、これらのうち2つしか持つことができないと述べています。システムに一貫性があり、パーティションに耐性がある場合、可用性条件が失われます。応答を受け取る前に、パーティションが修復されるのを待つ必要がある場合があります。一貫性と可用性がある場合は、パーティションがあるか、十分な数のサーバーがダウンしているときにダウンタイムが発生します。可用性とパーティションの許容範囲がある場合は、古いデータを読み取るか、書き込みの競合に対処する必要があります。
これは読み取りと書き込みに別々に適用されることに注意してください。読み取りにはAvailableおよびPartition-Tolerantシステムを使用できますが、書き込みにはConsistentandAvailableシステムを使用できます。これは基本的にマスタースレーブシステムです。パーティションでは、書き込みは失敗する可能性がありますが(パーティションの反対側にある場合)、読み取りは機能します(ただし、古いデータが返される場合があります)。
したがって、読み取りに対して使用可能でパーティション耐性が必要な場合、簡単なオプションの1つは、書き込みを実行できる唯一のホストとして1つのホストを指定し、そこから同期することです(たとえば、cronスクリプトなどのrsyncを使用してCでプロジェクトでは、いくつかの単純なネットワークコードを定期的に使用してファイルをコピーし、変更した直後に追加のコピーを実行します)。
ただし、書き込みにパーティショントレランスが必要な場合は、より複雑になります。2つのサーバーが相互に通信できず、両方とも書き込みを実行し、後でどのデータが優先されるかを把握する必要がある場合があります。これは基本的に、同期するときに2つのバージョンを比較し、どちらが優先されるかを判断する必要があることを意味します。これは、「最高のタイムスタンプを獲得する」のように単純にすることも、Dynamoのようにベクタークロックを使用して、より複雑なポリシーを実装することもできます。これは、アプリケーションによって異なります。