Consistency and Replication - 東野研究室nakata/mobile-cp/chap-06j...4 レプリカ配置分散データストアの設計課題...

1

一貫性とレプリケーション

教科書6章後半

2

一貫性とレプリケーション

データのレプリケーション (複製:Replication)と一貫性(Consistency)に関する以下の議論を紹介

レプリケーションの必要性

データ中心一貫性モデル（Data-centric Consistency Models）クライアント中心一貫性モデル（Client-centric Consistency Models）配信プロトコル（Distribution Protocols）一貫性プロトコル（Consistency Protocols）

3

配信プロトコル

データの更新をレプリカに伝播（配布）する一般的な手法(配信プロトコル:distribution protocol)を紹介

採用する一貫性モデルに依存しない手法

特定の一貫性モデルに依存するプロトコル(一貫性プロトコル:consistency protocol)は後述

4

レプリカ配置

分散データストアの設計課題どこに、いつ、誰によってデータストアのコピーが配置されるかの決定

コピー（レプリカ）の種類永久レプリカ(permanent replica)サーバ起動レプリカ(server-initiated replica)クライアント起動レプリカ(client-initiated replica)

5

永久レプリカ

永久レプリカ

分散データストアに最初から（静的に）配置されているレプリカ

レプリカの数は少ない

例）webサイトのミラーリング

あるwebサイトのコンテンツを幾つかのサーバ(ミラーサイト)に複製

クライアントは幾つかのミラーサイトから１つを選択

共有なしアーキテクチャ（shared-nothing architecture）で構成された分散データベース

複数のサーバ（クラスタ）上に分散されたデータベースで、各プロセッサがディスクやメモリを共有しないもの

6

サーバ起動レプリカ


データストア（のオーナー）によって動的に生成されるデータストアのコピー

性能向上が目的

例）webサーバに一時的にある地域から大量のアクセスが殺到

一時的にサーバのレプリカをその地域に配置(プッシュキャッシュ:push cache)

7


課題：いつ、どこにレプリカを生成/削除するか？

webホスティングサービスにおけるアプローチ

更新頻度は読まれる頻度より小さいと仮定

個々のファイルのレプリカをそれぞれ異なるサーバに分散配置

そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）

8


アルゴリズム1. 各サーバは各ファイルのアクセス回数とアクセス元を記録

ただし、クライアントC1,C2に近いサーバが共にPであったならば、サーバQはC1,C2からのアクセスをPからのアクセスとしてカウント

cntQ(P,F): QのファイルFへのPからのアクセス回数

cntQ(P,F)

=9+6=15

C2:Fに6回アクセス


P: C1,C2に最も近いサーバ

9


2. cntQ(P,F)がレプリケーション閾値rep(P,F)を超えるとサーバPにレプリカを作成

cntQ(P,F)

=9+6=15>rep(P,F)




rep(P,F)=10

サーバPにファイルFのレプリカを作成

10


3. サーバQでのファイルFへの総アクセス回数ΣS(cntQ(S,F))がdel(Q,F)を下回り、かつファイルFが最後のレプリカでないならば、そのレプリカFを削除

ΣS(cntQ(S,F))= cntQ(Q,F)

=3<del(Q,F)

C3:Fに3回アクセスP: C1,C2に最も近いサーバ

del(Q,F)=5

サーバQからファイルFを削除

C3

C3: Qに最も近い(唯一の)クライアント

ファイルFのコピー

サーバPにはファイルFのレプリカが存在

11


cntQ(P,F)がQでのFの総アクセス回数の半分を超えると、ファイルFをQからPへ移動

ただしcntQ(Q,F) >rep(Q,F)ならば複製 ΣS(cntQ(S,F))= cntQ(P,F)+cntQ(Q,F)

=15+7=22

cntQ(P,F)> (1/2)*ΣS(cntQ(S,F))

cntQ(Q,F)<=rep(Q,F)




ファイルFをQからPへ移動

C3

Q:C3に最も近いサーバ


rep(Q,F)=10

cntQ(P,F)=15

cntQ(Q,F)=7

12


cntQ(P,F)がQでのFの総アクセス回数の半分を超えると、ファイルFをQからPへ移動

ただしcntQ(Q,F) >rep(Q,F)ならば複製 ΣS(cntQ(S,F))= cntQ(P,F)+cntQ(Q,F)

=15+11=26

cntQ(P,F)> (1/2)*ΣS(cntQ(S,F))

cntQ(Q,F)>rep(Q,F)

ファイルFをPに複製（Qにも残す）

C3

rep(Q,F)=10

cntQ(P,F)=15

cntQ(Q,F)=11




Q:C3に最も近いサーバ


13

クライアント起動レプリカ

クライアント起動レプリカ（クライアントキャッシュ）クライアントが生成する複製（キャッシュ）

リクエストしたデータを一時的にローカルストレージに蓄積

キャッシュの管理：クライアントの責任一般に、一貫性の保証にデータストア（サーバ）は関与しない

目的：データへのアクセス時間向上

キャッシュ：一般に有効期限あり元ファイルと一貫性が無くなったデータを捨てるため

ディスクの空きを増やすため

14

更新伝播

データの更新操作

クライアントで起動され、データストアのある一つの複製（サーバ）に転送他の全ての複製に伝播（一貫性を保証）

更新伝播(update propagation)に関するさまざまな設計課題を紹介

15

状態 vs 操作

実際に何を伝播させるか？更新があったことの通知のみを伝播

無効化プロトコル（invalidation protocol）更新があったことのみを通知し、今のレプリカの内容を無効化(invalidate)伝播されるデータ量が小さいネットワーク帯域が小さいときに有効

読み取りに比べて更新が頻繁な場合に有効

データの内容を伝播更新されたデータ内容を他のサーバに転送

更新に比べて読み取りが頻繁な場合に有効

更新操作を伝播アクティブレプリケーション（active replication）

更新されたデータではなく、更新操作内容を転送 --- 各サーバは同じ更新操作を実行してデータを更新

ネットワーク帯域は小さくてもよい

一般に各サーバに高い計算パワーが要求される

16

プル vs プッシュプロトコル

更新をプル(pull)するかプッシュ(push)するか？

プッシュベースアプローチ（サーバベースプロトコル）更新を行ったサーバが、他のレプリカ（サーバ）に伝播させる

更新される側は問い合わせを行う必要が無い

主に永久レプリカとサーバ起動レプリカの間で用いられる

サーバからクライアントキャッシュに更新をプッシュすることもあり得る

複製間で高い一貫性が要求される場合に有効

プルベースアプローチ（クライアントベースプロトコル）サーバ又はクライアントが、他のサーバに更新の送信を要求

主にクライアントキャッシュの更新で用いられる

更新に比べて読み取りの頻度が小さい場合に効果的

キャッシュが共有されていない（一つのクライアントで占有している）場合など

17

プル vs プッシュプロトコル

プッシュベースとプルベースプロトコルの比較簡単のため、複数クライアント、単一サーバシステムで考える

プッシュベースの場合、全てのクライアントキャッシュの状態をサーバで管理する必要（スケーラビリティ問題）

プルベースの場合、更新の有無をサーバに問い合わせ（ポーリング）、その後、更新を取得する必要クライアントの応答時間はプッシュベー

スの方が良い

両者の混合アプローチ（リースに基づく更新伝播）

18

プル vs プッシュプロトコル:リースに基づく混合アプローチ

リースに基づく更新伝播[Gray and Cheriton 1989]

プッシュとプルの混合アプローチ

リース(lease): 特定時間以内は更新をプッシュし続けるというサーバによる約束

サーバは更新を管理すべきクライアント数を一定数に制限可能スケーラビリティ問題を解決

リースが失効するとクライアントは更新をプルするか、リースを再取得する必要

19

プル vs プッシュプロトコル:リースに基づく混合アプローチ

リースの失効時間の動的適応[Duvvuri et.al. 2000]

異なるリース基準に基づいてリース失効時間を動的に適応

３つのリース基準エイジベースリース(age-based leases)

仮定：長期間変更されないデータの生存期間は長い

そのようなデータには長いリース期間を与える

更新頻度ベースリース(renewal-frequency based leases)頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライアントに長いリース期間を与える

状態空間オーバヘッドベースリース(state-space overhead based leases)

サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くする同時に管理すべきクライアント数が減少サーバの持つべき状態空間を小さく出来るサーバ負荷軽減

20

ユニキャスト vs マルチキャスト

プッシュ/プルプロトコルに関連した設計課題

ユニキャストとマルチキャストのどちらを用いるか？

N個のサーバを更新する場合

ユニキャストならばN個のメッセージが必要

マルチキャストならば1個でよい

多くの場合マルチキャストを用いる方が良い

特にプッシュベースアプローチの場合に有効

プルベースアプローチの場合、更新要求を出す相手は多くの場合、単一のクライアント又はサーバ

この場合はユニキャストの方がよい

21

エピデミックプロトコル

エピデミックプロトコル（epidemic protocols）イベンチュアル一貫性を保証するアルゴリズムの一種

目的：出来るだけ少ないメッセージで更新を伝播

更新の競合は解決しない（別の解決策を使用）

説明のため、更新はある1つのサーバで起こり、それが他のサーバに伝播されると仮定

write-write競合は起こらない

22

エピデミックプロトコル:更新伝播モデル

エピデミックプロトコルのモデル

エピデミクス（epidemics：伝染病に関する学問）に由来更新をサーバからサーバへ伝染させる

サーバの状態：infective: 伝播させるべき更新データを持っている

susceptible: まだ更新されていない

removed: 既に更新されて、これ以上更新を伝播させたくない

23


一般的な伝播モデル: アンチエントロピー（anti-entropy）モデル

サーバPは、他のサーバQをランダムに選び、Qと更新情報を交換

交換のアプローチは以下の3通り

１．Pは自分の更新情報をQにプッシュするのみ

２．PはQの更新情報を自分にプルするのみ

３．PとQはお互いの更新情報を交換(プッシュ-プルアプローチ)

P

QPとQは更新情報を交換

PはランダムにサーバQを選択

infective

susceptible

removed

24


速い伝播のためには、プッシュのみのアプローチは良くない

infectiveなサーバからしか更新情報は伝播されない

infectiveなサーバが多いと、それらがプッシュする相手としてsusceptibleなサーバを選ぶ確率は小さいsusceptibleなサーバが長い期間更新されない状態が続く可能性が高い

P

Q

TR

Pはランダムに選択したサーバに更新をプッシュ

Q,R,Sはいずれも更新の必要なし

infective

susceptible

removed S

更新が必要なTが選択される確率は小

25


プルのみのアプローチは、infectiveサーバが多い場合に有効

susceptibleサーバがinfectiveなサーバを選ぶ確率が高い

更新を受け取ったサーバはさらにinfectiveになる

P

Q

T

R

Pはランダムに選択したサーバから更新をプル

infective

susceptible

removed S

Tはランダムに選択したサーバから更新をプル

infectiveなサー

バを選ぶ確率大

26


1つのinfectiveサーバからも伝播は可能 --- 最初から複数のサーバをinfectiveにすると更に伝播は速くなる

最初に幾つかのサーバに更新をプッシュしておくことで達成可能

P

Pは最初にいくつかのサーバに更新をプッシュ

infective

susceptible

removed

27


1つのinfectiveサーバからも伝播は可能 --- 最初から複数のサーバをinfectiveにすると更に伝播は速くなる

最初に幾つかのサーバに更新をプッシュしておくことで達成可能

P

複数のinfectiveサーバから更新が伝播

伝播の高速化

infective

susceptible

removed

28


うわさ拡散(rumor spreading) (又は、ゴシッピング(gossiping))

前述のアプローチの変種

サーバPでデータｘが更新他の任意のサーバQを選んで更新情報をプッシュ

ただし、Qは既に他のサーバによって更新されていても良い

この場合、Pは（例えば1/kの確率で）更新の伝播を止める(removed状態に移行）

現実世界のゴシップ（噂話）がモデル

もし相手が既に知っている話であったら、噂を広める意欲が無くなる

P

Qinfective

susceptible

removed

29


うわさ拡散(rumor spreading) (又は、ゴシッピング(gossiping))

前述のアプローチの変種

サーバPでデータｘが更新他の任意のサーバQを選んで更新情報をプッシュ

ただし、Qは既に他のサーバによって更新されていても良い

この場合、Pは（例えば1/kの確率で）更新の伝播を止める(removed状態に移行）

現実世界のゴシップ（噂話）がモデル

もし相手が既に知っている話であったら、噂を広める意欲が無くなる

P

Qinfective

susceptible

removed

Pは1/kの確率でremoved状態に

30


ゴシッピングは更新を速く伝播させる方法としては非常に良い

ただし、全てのサーバが更新されたことは保証できない

全サーバのうち、更新されていないサーバの割合をsとすると、以下の関係式が成立

s=e-(k+1)(1-s)

もしk=3ならばsは0.02(=2%)以下

アンチエントロピー手法との併用で、残りのサーバに伝播させることが可能

31


エピデミックプロトコルの大きな利点の一つ

スケーラビリティを持つ

プロセス間同期の総数が他の手法に比べて小さいことが理由

各サーバは他の幾つか少数のサーバと通信すればよい

32

エピデミックプロトコル：データの削除

エピデミックプロトコルの副作用（欠点）

データが削除されたことを伝播させることが困難

データｘを単純に削除すると、他のサーバからｘに関する古い更新情報を受け取ったとき、自分がまだ持っていない新しい更新だと思ってしまう

単純な解決法：データが削除されたことを記録するレコード (死亡証明書：death certificates)を伝播させる

問題点：いつかは本当に削除しないと、死亡証明書がどんどん溜まっていく

33

エピデミックプロトコル：データの削除

より良い解決法：

各死亡証明書にタイムスタンプを付加

もし、ある時間T以内に全サーバに更新が伝播されることが保証されているなら、死亡証明書のタイムスタンプからＴ時間経過後に死亡証明書自体を削除してよい

削除の伝播をより高度に保証するには、少数のサーバ（例えばサーバP）に休眠中死亡証明書（dormant death certificate）を削除せず残しておく

もしサーバPにxに関する古い更新が伝わったならば、Pはxに関する死亡証明書をもう一度伝播させる

34

一貫性プロトコル

特定の一貫性モデルの実装手法を紹介最も重要な一貫性モデル:

read/write等の操作が大域的に順序付けられたモデル

順序一貫性

弱一貫性(同期変数への操作が順序一貫)など

順序一貫性を実現するプロトコルの分類プライマリコピー(primary copy)を持つか否か？

プライマリコピーを持つ全てのwrite操作はプライマリコピーを持つサーバに転送され、そこでwrite操作を実行

write操作は一箇所のみで実行 write操作の順序を大域的に保証

プライマリコピーを持たない任意のサーバでwrite操作を実行可能

35

一貫性プロトコル：プライマリベースプロトコル

プライマリベースプロトコル(primary-based protocol)

任意のデータ要素xに対して、プライマリ (サーバ)を割り当て

プライマリはxに対するwrite操作に関して責任を持つ

分類：プライマリがある特定のサーバに固定遠隔書き込みプロトコル(Remote-Write Protocol)write操作の実行を依頼したプロセスにプライマリを移動して、そこでwrite操作を実行ローカル書き込みプロトコル(Local-Write Protocol)

36

プライマリベースプロトコル：遠隔書き込みプロトコル

最も単純なプライマリベースプロトコルある１つのサーバがread/write操作全てに責任を持つ

データは複製されない従来のクライアントサーバシステム

37


より良いプライマリベースプロトコルwriteはある1つのサーバで責任を持つ

readは近くのローカルコピーから行う

プライマリバックアッププロトコル(primary-backup protocols)[Budhiraja et al. 1993]

38


プライマリバックアッププロトコルの問題点write実行時、実際の更新が終わるまで時間が掛かる（全サーバの更新終了までwrite操作は停止（ブロック））

解決法：ノンブロッキングアプローチ[Budhiraja and Marzullo 1992]

プライマリサーバがローカルコピーを更新したらすぐ確認通知を返すこの時点でwrite操作は終了

その後、他のサーバに更新を反映

write終了時、更新した値が他のサーバにバックアップされたという保証がない別の手法で耐故障性を保証する必要あり

39

プライマリベースプロトコル：ローカル書き込みプロトコル

プライマリベースローカル書き込みプロトコル（primary-based local-write protocols）

2種類に分類

１．各データxに対して唯1つのコピー（原本）のみ(レプリカを持たない)

２．書き込みクライアントの場所にプライマリコピーが移動

40


１．各データxに対して唯1つのコピーのみを持つローカル書き込みプロトコル

プロセスがxにread/writeしたいとき：

xの値を現在持っているサーバからローカルサーバに移動

xに対するread/write操作を実行

41


１．各データxに対して唯1つのコピーのみを持つローカル書き込みプロトコル

一貫性は自明に保証される(複製を同時に１つしか持たないので)問題点：現在データxのコピー（原本）が何処に居るか把握する必要がある

4章で述べたように、ブロードキャスト, 転送ポインタ, ホームベースアプローチ, 階層的アプローチなどの利用が考えられる（データxをモバイルエンティティと捉える）

42


２．書き込みクライアントの場所へのプライマリコピーの移動を許すローカル書き込みプロトコル

write操作実行時のみ、プライマリをローカルコピーに移動

更新結果は全てのローカルコピーに反映(バックアップ)read操作はローカルコピーに対して実行

43


２．書き込みクライアントの場所へのプライマリコピーの移動を許すローカル書き込みプロトコル

利点：複数のwrite操作をローカルで連続して行える

read操作はすべてローカルで行える

さまざまな分散共有メモリに適用されている

44


２．書き込みクライアントの場所へのプライマリコピーが移動を許すローカル書き込みプロトコル

モバイルPCで、非接続モード（disconnected mode）でもデータ操作可能にする実装にも応用可能

モバイルPCは非接続モードになる前に、更新が予想されるデータに関してプライマリサーバになる

非接続モードではwrite操作はローカルに実行その間、他のプロセスはread操作を各々のローカルコピーに対して実行

モバイルPCが再び接続モードになれば、更新内容が全てのローカルコピーに反映一貫性のある状態に

45

レプリカ書き込みプロトコル

レプリカ書き込みプロトコル（replicated-write protocols）

write操作を複数のレプリカに対して実行

分類：アクティブレプリケーション（active replication）

全てのレプリカに対してwrite操作を実行(更新操作の伝播)

コーラムベースプロトコル（quorum-based protocols）幾つかのレプリカに対してのみwrite操作を実行

多数決投票(majority voting)メカニズムによって一貫性を保持

46

レプリカ書き込みプロトコル：アクティブレプリケーション

アクティブレプリケーション

各レプリカをそれぞれ１つのプロセスに対応付け

プロセスは対応付けられたレプリカに対してwrite操作を実行

write操作は他の全てのレプリカに伝播される

R1 R2 R3

P1 P2 P3

read

更新の伝播

write readwrite

write

47


アクティブレプリケーションの問題点：全てのレプリカで同じ順番でwrite操作を実行する必要がある(一貫性保持のため)解決法：

全順序マルチキャストの利用

Lamportのタイムスタンプを用いて実装可能

ただし、スケーラブルではない

中央コーディネータ (シーケンサ(sequencer))の利用

ある1つのコーディネータが各write操作にシーケンス番号を振り、全順序を保証

依然としてスケーラブルでない

シンメトリックマルチキャスト(symmetric multicast)[Rodrigues et.al. 1996]の利用詳細は文献参照のこと

48


アクティブレプリケーションの問題点：分散オブジェクトにおける複製された起動（replicated invocation）の問題

49


複製された起動の解決法：

レプリカのうち、コーディネータが代表してリクエストを送信

結果の返信もコーディネータが代表して行う

50

レプリカ書き込みプロトコル：投票ベースプロトコル

投票（voting）を利用したレプリカ書き込みプロトコル

基本アイディア[Thomas 1979]クライアントは、全サーバのうち過半数のサーバに対してread/write操作のリクエストを送信して許可をもらう

過半数のサーバが合意すればそれは正しいバージョンのデータであることが保証される

51


N個のレプリカサーバの例クライアントがデータの更新操作を行いたいとき、N個のサーバのうち過半数のサーバに対して更新リクエストを出し、許可をもらう

その後、それらのサーバに対して更新操作を行い、更新されたデータに新しいバージョン番号(又はタイムスタンプ)を付与する

更新は最終的には全レプリカに伝播する

x(8) x(8) x(8) x(7) x(6)

データxの値をバージョン８に更新

サーバの総数N=5の場合

52


データを読みたいときも同様に、過半数のサーバに対して読み込みリクエストを出して許可をもらう

それらから読み込んだデータのバージョン番号が同一ならば、そのデータは最も最近のバージョンであることが保証される

x(8) x(8) x(8) x(7) x(6)

データxの値を読み込む

バージョンが一致しないので最新

の値ではない


53


データを読みたいときも同様に、過半数のサーバに対して読み込みリクエストを出して許可をもらう

それらから読み込んだデータのバージョン番号が同一ならば、そのデータは最も最近のバージョンであることが保証される

x(8) x(8) x(8) x(7) x(6)

データxの値を読み込む

バージョンが一致したので最新

の値であることが保証される


54

レプリカ書き込みプロトコル：コーラムベースプロトコル

コーラムベースプロトコル(quorum-based protocol)[Gifford 1979]

投票ベースプロトコルの一般化

N個のレプリカからデータを読み込むときクライアントは読み取りコーラム(read quorum)と呼ばれるサーバの部分集合に対してリクエスト

任意のNR個のサーバ

書き込むとき書き込みコーラム(write quorum)と呼ばれるサーバの部分集合に対してリクエスト

任意のNW個のサーバ

ただし、NR + NW >N　　（read-write競合を避けるため）

NW >N/2　　　　（write-write競合を避けるため）

55

レプリカ書き込みプロトコル：コーラムベースプロトコル

読み取り/書き込みコーラムの選択例

特に(c)はRead-One, Write-All(ROWA)と呼ばれる例

コーラムベースプロトコルの詳細は[Jalote 1994]参照

56

キャッシュコヒーレンスプロトコル

キャッシュコヒーレンスプロトコル（cache-coherence protocol）

キャッシュ(=クライアント起動レプリカ)の内容がサーバ側のデータと一貫性があることを保証するプロトコル

コヒーレンス検出戦略(coherence detection strategy)の違いによる分類（キャッシュの不整合がいつ検出されるか？）

静的な解決策

プログラム実行前にコンパイラが静的に分析

動的な解決策

実行時にキャッシュの不整合を検出

57


コヒーレンス強制戦略（coherence enforcement strategy）の違いによる分類

キャッシュとサーバとの一貫性を保つ手法

単純な解決法：共有データはキャッシュに置かず、サーバだけに置く

一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証

性能はキャッシュを用いる場合より悪い

58



共有データをキャッシュする場合：

データが更新されると、サーバが全てのキャッシュに対して無効化(invalidate)メッセージを送信するアプローチ

データの更新を単純に全てのキャッシュに伝播させるアプローチ

59



キャッシュされたデータを更新する場合：

リードオンリーキャッシュの場合更新はサーバでのみ行われ、その更新内容をいずれキャッシュに反映

多くの場合プルベースアプローチを利用

60



キャッシュされたデータを更新する場合：リードライトキャッシュの場合：

ライトスルーキャッシュ（write-through cache）: キャッシュ内容を更新すると同時に、サーバでも更新操作を実行

クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似

（順序）一貫性保証のため、クライアントに排他的な書き込み権限が与えられる必要

ライトバックキャッシュ（write-back cache）: キャッシュ内容のみを更新し、後でまとめてサーバに伝播

更新の伝播を遅延することにより、サーバに通知する前に複数の書き込みが起こることを許容

61

6章のまとめ

データを複製する理由：分散システムの信頼性向上、および、性能向上のため

複製はデータ不整合の問題を引き起こす一貫性を保つため、更新を全ての複製に伝播させる必要常に一貫性を保証するのは困難

一貫性の要求を弱める必要

さまざまな（データ中心）一貫性モデルの提案厳密一貫性, 順序一貫性 (直線化可能性), 因果一貫性, FIFO一貫性, 弱一貫性, 解放一貫性, エントリ一貫性

クライアント中心一貫性モデル一つのクライアントからデータの不整合を隠す一貫性モデル

モバイルPC対象のアプリケーションで有効

62

6章のまとめ（続き）

更新の伝播に用いられる技術の分類何を伝播させるか？（更新があったことの通知, 更新操作, 更新内容（データ））

何処へ伝播させるか？（配信プロトコルの種類によって異なる）

誰が伝播を引き起こすか？（プッシュ/プルベースアプローチ）

一貫性プロトコル: 特定の一貫性モデル（順序一貫性）の実装プライマリベースプロトコル, レプリカ書き込みプロトコル

63

演習問題

1. 順序一貫性の保証のためにノンブロッキングプライマリバックアッププロトコルを用いたデータストアは、書き込み後読み取り一貫性を常に保証するか？理由も説明せよ。

2. ファイルが10個のサーバに複製されているとしたとき、コーラムベースプロトコルで許される全ての読み取りコーラム, 書き込みコーラムの組み合わせを列挙せよ。

Consistency and Replication - 東野研究室nakata/mobile-cp/chap-06j...4 レプリカ配置 分散データストアの設計課題...

Documents

Consistency and Replication - 東野研究室nakata/mobile-cp/chap-06j...4 レプリカ配置分散データストアの設計課題...