解读

国内面试官问这道题，并不是想听你背文档，而是验证两条底线：

1. 你是否真的动手搭过 3.x 集群，而不是只会在单节点“next-next-finish”；
2. 你是否理解 CouchDB 的“q-n-r”数据模型，这是后续调优、排障、容量评估的根基。
   “set-up” 是集群模式下的第一个写操作，一旦参数填错，后期扩容、再平衡都会踩坑，所以面试官会追问“为什么这三个值不能随意改”。回答时要先给出参数名，再立刻解释其物理意义，体现“能干活”。

知识点

• q（分片数）：决定数据库在集群内被切成多少份，一旦写入数据后不可在线降低，只能新建库后重导。
• n（副本因子）：每份分片在集群里存几份，必须 ≤ 实际节点数，否则集群状态 stuck 在“等待分配”。
• r / w（读写仲裁）：虽然 3.3 默认把 r=w=2，但“set-up”阶段必须显式给出，国内金融、政务项目常要求 w=majority，面试时主动提一句是加分项。
• bind_address 与 port：不是“set-up” body 里的字段，但国内云环境常有“内网地址≠公网地址”的坑，面试官会顺势问“你当时怎么确认节点间能通”，提前准备可展示排障思路。

答案

POST /_cluster_setup 的 JSON 体里必须出现的三个核心字段是：
"action": "enable_cluster"
"bind_address": "0.0.0.0"（或本机内网 IP）
"port": 5984

若继续完成“finish_cluster”阶段，则还要带上：
"username": "admin"
"password": "****"**

但题目问的是“set-up” API 的最原始三次握手，所以只答上面三组即可；如面试官点头，可补充：“后续建库时，q、n、r、w 会作为默认模板写进 .ini，国内生产我通常把 q 设 8、n 设 3，留足横向扩容空间。”

拓展思考

1. 如果集群节点后续从 3 台扩到 5 台，q 值不能改，只能让 CouchDB 重新平衡已有 8 个分片，面试官会追问“重平衡期间读写延迟飙高你怎么兜底”，可答“先调大 cluster.quiet_period，再在业务低峰触发，或临时把 r/w 降到 1”。
2. 国内政务私有云常给低配虚拟机，磁盘 IO 只有 100 MB/s，此时若盲目把 q 设 16，会导致compaction 时间窗口被拉长，面试可主动说“我会用 iostat 先跑基线，再把 q 压到 4，宁可后期加节点”。
3. 如果面试官是移动厂商背景，会追问“离线端同步到中心集群，q 大会不会导致同步冲突变多”，答案是“不会，冲突发生在文档级，与分片数无关”，但你可以顺势把话题引到_conflicts 数组的处理策略，展示你对移动同步场景的完整闭环认知。