11.1.6 读写流程与请求处理链路

在ZooKeeper中，读写请求通过分层处理链路完成，从客户端进入到服务端处理与响应，形成可观测的路径。理解该链路有助于定位性能瓶颈、诊断一致性问题与优化参数配置。

原理草图：读写请求处理链路（简化）

请求类型与路由原则
- 读请求：可由任意Follower或Leader处理，默认走本地内存快照，延迟低。
- 写请求：必须由Leader串行处理并广播，确保全局顺序一致。
- 会话类请求（创建/关闭/心跳）：由当前连接的服务器处理，必要时转发或协调。

核心处理器职责（命令解释与对照）
- PrepRequestProcessor：会话/ACL/合法性校验。
- ProposalRequestProcessor：写请求生成提案并写事务日志（WAL）。
- CommitProcessor：等待多数派确认后提交应用。
- FinalRequestProcessor：返回响应与触发Watcher事件。

示例：观察读写流程（客户端 -> 集群）
1) 使用 zkCli 进行写入与读取

# 进入 zkCli（替换为你的地址）
/opt/zookeeper/bin/zkCli.sh -server 127.0.0.1:2181

# 创建节点（写请求 -> Leader）
create /ops "v1"

# 读取节点（读请求 -> 本地Follower或Leader）
get /ops

# 更新节点（写请求 -> Leader）
set /ops "v2"

# 删除节点（写请求 -> Leader）
delete /ops

2) 预期输出（示例）

Created /ops
[zk: 127.0.0.1:2181(CONNECTED) 1] get /ops
v1
cZxid = 0x100000002
mZxid = 0x100000002
...

示例：开启请求链路观测（配置与启动）

通过四字命令与日志确认请求处理情况（相当于“安装/启用观测能力”）

# 1) 修改配置文件 /opt/zookeeper/conf/zoo.cfg
cat >> /opt/zookeeper/conf/zoo.cfg << 'EOF'
# 允许四字命令（4lw）用于诊断
4lw.commands.whitelist=stat,ruok,conf,mntr,cons
# 事务日志与快照目录（确保单独磁盘）
dataDir=/data/zk/data
dataLogDir=/data/zk/log
EOF

# 2) 重启服务
/opt/zookeeper/bin/zkServer.sh restart

# 3) 验证服务健康（ruok 应返回 imok）
echo ruok | nc 127.0.0.1 2181

# 4) 查看连接与请求统计
echo stat | nc 127.0.0.1 2181
echo mntr | nc 127.0.0.1 2181

示例：从日志确认写请求链路

# 日志路径示例（按实际路径调整）
tail -f /opt/zookeeper/logs/zookeeper.out | egrep -i "commit|proposal|zxid"

预期可见写请求的 proposal/commit 关键字与递增的 zxid。

性能与一致性关注点
- 写链路受限于多数派确认与磁盘IO，延迟与吞吐主要受日志刷盘影响。
- 读链路为本地读取，延迟低但存在读陈旧风险，需要根据业务配置读一致性策略。
- Watcher在提交后触发，保证事件与数据变更顺序一致。

排错与诊断清单

# 1) 读到旧数据：确认是否连接到Follower
echo stat | nc 127.0.0.1 2181 | egrep "Mode|Connections"

# 2) 写入慢：查看 fsync 与事务延迟
echo mntr | nc 127.0.0.1 2181 | egrep "fsync|latency|outstanding"

# 3) Leader压力过大：查看连接数与请求队列
echo stat | nc 127.0.0.1 2181 | egrep "Outstanding|Connections"

# 4) 节点不一致：检查是否发生revalidating
grep -i "revalidating" /opt/zookeeper/logs/zookeeper.out

排错解释：
- Mode/Connections：确认请求入口节点与连接数量。
- fsync/latency/outstanding：判断磁盘与请求队列是否成为瓶颈。
- revalidating：可能表明会话切换或短暂不一致。

练习
1) 在3节点集群中分别连接Follower与Leader，执行 get 与 set，观察 stat 输出的 Mode 差异。
2) 人为增加磁盘负载（如dd写盘），测试 mntr 的 fsync 与 latency 指标变化，并记录写入耗时。
3) 注册一个Watcher（get /ops true），执行 set /ops v3，验证事件顺序与提交一致性。