エントランス
統一ZKクラスタ開始回復で書籍接続ブログの記事の後にデータを完了した後に、論理的な開始ZkServerに来て、仕事の次の焦点は、異なるプロセッサプロセッサの異なる役割に対応する開始することです
図を参照してくださいZooKeeperServer継承グラフ、三つの異なる役割が異なっていZooKeeperServer論理実装を
3つの開始、すべてが来るときZooKeeperServer.javaにはstartUp()、この方法下記のソース、しかし異なる役割のためには、setupRequestProcessors();異なる書き換えたので、このブログの焦点も、彼らが書き換えされている方法を見て
public synchronized void startup() {
if (sessionTracker == null) {
// todo 创建session计时器
createSessionTracker();
}
// todo 开启计时器
startSessionTracker();
// todo 设置请求处理器， zookeeper中存在不同的请求处理器, 就在下面
setupRequestProcessors();
//todo 是一个为应用程序、设备、系统等植入管理功能的框架。
//todo JMX可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活的开发无缝集成的系统、网络和服务管理应用
registerJMX();
// todo 修改状态 --> running
setState(State.RUNNING);
// todo 唤醒所有线程, 因为前面有一个线程等待处理器 睡了一秒
notifyAll();
}リーダーリライトsetupRequestProcessors
以下のソースとして：それは見ることができるプロセッサの初期化の数
- PrepRequestProcessor（checkAcl建設TNX）
- ProposalRequestProcessor（開始の提案）
- CommitProcessor（提出された提案）
- ToBeAppliedRequestProcessor
FinalRequestProcessor（クライアントへの応答、更新メモリ）
SyncRequestProcessor（単一のオープン、彼はスレッドである）役割：永続TXN
RequestProcessor finalProcessor = new FinalRequestProcessor(this);
RequestProcessor toBeAppliedProcessor = new Leader.ToBeAppliedRequestProcessor(
finalProcessor, getLeader().toBeApplied);
commitProcessor = new CommitProcessor(toBeAppliedProcessor,
Long.toString(getServerId()), false,
getZooKeeperServerListener());
commitProcessor.start();
ProposalRequestProcessor proposalProcessor = new ProposalRequestProcessor(this,
commitProcessor);
proposalProcessor.initialize();
firstProcessor = new PrepRequestProcessor(this, proposalProcessor);
((PrepRequestProcessor)firstProcessor).start();フォロワーリライトsetupRequestProcessors
- FollowerRequestProcessor
- CommitProcessor
- SendAckRequestProcessor
決勝のRequestProcessor
SyncRequestProcessor（単一のオープン、彼はスレッドである）役割：永続TXN
RequestProcessor finalProcessor = new FinalRequestProcessor(this);
commitProcessor = new CommitProcessor(finalProcessor,
Long.toString(getServerId()), true,
getZooKeeperServerListener());
commitProcessor.start();
firstProcessor = new FollowerRequestProcessor(this, commitProcessor);
((FollowerRequestProcessor) firstProcessor).start();
syncProcessor = new SyncRequestProcessor(this,
new SendAckRequestProcessor((Learner) getFollower()));
syncProcessor.start();オブザーバー書き換えsetupRequestProcessors
- ObserverRequestProcessor
- CommitProcessor
- 決勝のRequestProcessor
追加するかどうかを判断する構成とすることにより
SyncRequestProcessorその事務を永続化します
RequestProcessor finalProcessor = new FinalRequestProcessor(this);
commitProcessor = new CommitProcessor(finalProcessor,
Long.toString(getServerId()), true,
getZooKeeperServerListener());
commitProcessor.start();
firstProcessor = new ObserverRequestProcessor(this, commitProcessor);
((ObserverRequestProcessor) firstProcessor).start();
// todo 通过这个判断控制需不需要Observer 对事务进行持久化
if (syncRequestProcessorEnabled) {
syncProcessor = new SyncRequestProcessor(this, null);
syncProcessor.start();
}実験1：リーダーが書き込み要求を受け取ります
リーダーは、要求を受信した場合、クラスタ内の各プロセッサの動作のフローチャートを要求直接与えられます。
図では、リーダーが要求を受信した後、そのプロセッサを介して、確かに順次要求し、PrepRequestProcessor - > ProposalRequestProcessor
ProposalRequestProcessorプロセッサでは、同じ要求がCommitProcessorに直接提出されますが、また、ライブブロックされます
アトミックブロードキャスト要求が続くリーダー、フォロワーはこの要求のすべてを教えてくれています
彼らはすぐにSyncRequestProcessor完全な永続することをアトミック放送した後、
一方、要求を受信した後フォロワーは、よりこのLearnerHandlerでチェック機構の半分以上は、存在するフォロワーは、それをACKを送ってはなりませんでした、完成が持続した後LearnerHandlerのリーダーにACK応答を送信し、永続化するための独自のSyncRequestProcessを使用します。それは半分以上に達するまで）（通知トリガする、トリガを確認し、待機（）内だけcommitProcessorリーダー、保留中の送信機能は、すべての学習者がリーダーをコミットコミット放送される目覚めされ、データの一貫性に到達しました
実験2：フォロワーまたは書き込み要求がオブザーバーを受信します
直接指定された又はフォロワオブザーバーが要求を受信した場合、クラスタ内の各プロセッサの動作のフローチャートを要請
我々は、要求オブザーバーを受けた後、上記のグラフから見ることができるか、フォロワーはまずローカルに提出されるcommitProcessorプロセッサが、すぐにトランザクションをコミットしませんが、オンとした後、最初のプロセッサ・リーダーに要求を転送し、そしてだろう同じプロセスフローの上面図