第二章 搭建法庭：安装部署与集群组建

第二章 · 搭建法庭：安装部署与集群组建

章节摘要：本章走完从零到可用集群的完整路径：先在本机跑起单机版认识基本构件，再把三台服务器组成真正的多数派集群，最后把 zoo.cfg 里每个参数掰开揉碎——为什么 tickTime 决定了一串超时的连锁反应，为什么机器数要选奇数。

一条主线

第一章我们把法庭的图纸画清楚了，本章来砌砖。主线任务只有一个：让三台机器对"谁是主节点"达成一致，并稳定地对外提供服务。这件事看起来只是装软件，实际每一步都在为第四章的机制埋伏笔——你配置的 tickTime 决定了心跳的节奏，你填写的 server 列表决定了选举时候选人名单，你选择的机器数目决定了法庭能容忍几位法官同时缺席。

部署是全册最"动手"的一章，也最容易产生虚假的安全感：单机版跑通了不等于集群会配，集群起来了不等于参数配对了。很多线上事故的根子，就埋在这一章某个没细看的默认值里。建议全程跟着命令敲，别只读。

沿途站点

第一站，2.1 节 单机模式安装。从环境准备（JDK、目录规划）到下载解压、写最小配置、启动验证，十分钟的流程，但四字命令与日志查看的习惯从这里养成。单机版的意义不在生产，而在给后面所有实验提供一个可以随手重启的沙盘。

第二站，2.2 节 集群模式部署。真正的重头戏：myid 文件与 server 列表如何互相咬合，三台机器如何互相发现、投票、选出 Leader，以及部署拓扑上那些不显眼却致命的细节——机器要跨机架、时钟要同步、防火墙要放行哪些端口。

第三站，2.3 节 zoo.cfg 逐项精读。把配置文件当合同读：每个参数对应什么机制、默认值在什么场景会出事、调大调小的连锁反应是什么。这一节是运维调参的速查表，也是第六章排障的对照手册。

三站递进的逻辑：单机版认识构件，集群版理解协作，参数精读掌握边界。 读完你应该能独立完成一次三节点部署，并解释每个配置项为什么这么填。

拐点与结论

本章的认知转折在第二站末尾：当你亲手停掉 Leader、看到剩下两台在几秒内选出新 Leader 时，"高可用"不再是文档里的名词，而是你刚刚亲眼目睹的一次换庭。另一个转折在第三站：你会发现 ZooKeeper 的参数大多彼此挂钩（tickTime 牵着 initLimit 和 syncLimit，会话超时又由客户端与 tickTime 共同决定），孤立地调某一个参数几乎没有意义——这是一套需要整体理解的节奏系统，不是一堆独立的旋钮。

读完本章你应该能：完成单机与三节点集群部署并逐台验证角色；写出规范的 myid 与 server 列表配置；说清 tickTime、initLimit、syncLimit、dataDir、clientPort 各自管辖的范围；根据机房条件判断两台机器为什么不比一台强多少。

下一章的接力

法庭开张了，接下来轮到你出场——第三章讲客户端：三种客户端怎么选、原生 API 的会话与异步事件模型长什么样、Curator 如何把繁琐的细节封装成趁手的工具。本章搭好的集群，就是那一章所有代码的试验场。

本章结构速览

部署工作的依赖链一图收拢，先有节拍器，再有多数派，最后才有参数体系：

部署这一章有一个容易被低估的收益：它是你第一次以运维身份而非开发身份接触 ZooKeeper。开发视角关心 API 与语义，运维视角关心进程、端口、磁盘与时间——两种视角在同一份配置文件上交汇。本章刻意让每个配置项都同时给出"它管什么机制"与"它出什么事故"两面，往后的章节里，这两面会反复互相印证：机制课讲不清的用事故讲，事故查不明的回机制里找。

另一个建议是保留你的实验记录。无论是单机版的第一次启动日志，还是三节点集群的第一次换届日志，都归档到一个笔记目录里——第六章排障时，这些"健康样本"是你判断异常的唯一参照系。没见过健康长什么样的人，看见异常也认不出来。