如何自动扩缩？
解读
国内面试官问“CouchDB 如何自动扩缩”，并不是想听“装个 Kubernetes 就完事”这种泛泛回答，而是考察候选人是否真正理解 CouchDB 的无中心多主架构、复制与分片边界、国内云厂商生态限制以及离线优先场景下的扩缩代价。回答必须围绕“CouchDB 本身不提供原生 Auto-Scaling 控制器”这一事实，给出可落地的国产云+自建混合方案，并权衡数据一致性、复制带宽、分区重平衡三大风险。
知识点
- 水平扩展单元：CouchDB 3.x 的“q值”(分片数)在集群创建时固化，后续只能通过离线重分片或自建外部路由层扩容，无法像 MongoDB 那样在线自动 rebalance。
- 复制与写入模型：多主复制带来高可用，但也导致写入冲突与版本向量膨胀；自动扩容时必须同步评估_revs_limit与压缩窗口，否则磁盘会先于吞吐爆炸。
- 国内云现状：阿里云、腾讯云、华为云均未托管 CouchDB，只提供 ECS 或裸金属；自动扩缩需基于自研 Operator或ACK/TKEx/ASM 上的 Helm 包，并对接云监控 CMS与AS 伸缩组。
- 离线优先场景：移动端 PouchDB 通过_sync协议直连 CouchDB；若后端节点因自动缩容而下线，必须保证至少一个节点持有完整副本，否则本地 PouchDB 会出现 404 同步中断，这是国内 IoT、政务平板项目踩坑高发点。
- 扩缩信号选型：CPU 不足信，写队列长度、/(_active_tasks) 中 indexer 堆积数、文件句柄增长率才是更真实信号；需用Telegraf + 阿里云 CMS 自定义指标暴露给伸缩组。
答案
CouchDB 官方并不带自动扩缩控制器，在国内落地需“三件套”：
- 容器化基座：用阿里云 ACK 或腾讯 TKE 把 CouchDB 打成 StatefulSet，每个 Pod 挂云盘 ESSD PL1，利用多可用区反亲和保证容灾；镜像里预置couchdb-prometheus-exporter暴露 9984 端口指标。
- 自定义指标伸缩：通过Kubernetes Custom Metrics API把“http_request_post_seconds_sum>阈值”或“couchdb_database_doc_count增长率”注册为 HPA 信号；HPA 只负责扩容副本数，不负责重分片，因此初始 q 值必须按未来最大规模一次性设置(例如 32 或 64)。
- 离线优先兜底：在缩容逻辑里加PreStop Hook，调用**/_replicate把本节点数据强制推送到至少两个存活节点**；同时把集群最小副本数硬编码为“≥2 且覆盖全部分片”，防止 PouchDB 终端同步失败。
完成以上三步后，再配合阿里云弹性伸缩组的预测式伸缩与定时策略(例如白天 9-18 点保持 5 节点，夜间降到 3 节点)，即可实现**“ quasi-auto-scaling”——扩容秒级，缩容分钟级，且数据零丢失、同步不中断**。
拓展思考
如果面试官继续追问“q 值初始设大了浪费，设小了后期要重分片，怎么办？”，可回答：
- 采用**“逻辑库+按年分库”模式，把热数据按时间前缀拆成多个数据库，每个库 q=8；历史库只留 2 副本，不再扩容，从而把重分片需求转化为“新建库+replicate 迁移”**，规避在线 rebalance 难题。
- 对强一致性业务，可引入中间层 Kafka + CouchDB 单写节点，把多主降级为主写主读，牺牲离线写能力换取线性扩容；此时自动扩缩只扩只读副本，通过SLB 权重秒级上下线，写节点固定不变，大幅降低冲突与重分片复杂度。