企业官网建设流程全解析

1. 项目概述：为什么HBase高可用集群不是“装完就完事”的工程

HBase高可用集群部署，这个词在企业大数据平台建设中出现频率极高，但真正能说清楚“高可用”到底指什么、哪些组件必须冗余、哪些配置一错就导致RegionServer反复闪退的工程师，其实不多。我带过几个团队做HBase落地，发现一个典型误区：很多人把“启动了3个ZooKeeper节点+5台RegionServer”就当成高可用，结果上线两周，一次ZK会话超时没调好，整个集群写入阻塞47分钟，业务方直接打来电话问“是不是数据丢了”。这不是危言耸听——HBase的高可用，本质是故障场景下的服务连续性保障能力，它不体现在仪表盘上绿色的“RUNNING”，而藏在ZooKeeper会话超时参数与HDFS块副本策略的耦合关系里，藏在HMaster主备切换时WAL日志回放的原子性边界中，更藏在运维人员凌晨三点收到告警后，能否在5分钟内判断出是ZK连接抖动还是HDFS NameNode脑裂。

这个标题里的“企业项目实战”四个字很关键。它意味着我们不讲单机伪分布式环境下的Hello World，不演示用hbase shell插入一条测试数据就截图收工；我们要面对的是真实生产环境：每天写入20TB原始日志、峰值QPS 8万、要求99.99%写入成功率、Region故障自动迁移时间≤12秒、且不允许任何人工介入干预。这些指标倒逼我们必须对每一个配置项追根溯源——比如为什么hbase.zookeeper.property.tickTime不能设为2000ms？因为ZK官方明确建议该值应≤客户端sessionTimeout的1/3，而HBase默认zookeeper.session.timeout是40秒，40000÷3≈13333，取整后设为13000才留有余量；设成2000，等于把心跳节拍调得太密，网络瞬时抖动就会触发大量无效重连，反而降低稳定性。再比如hbase.regionserver.handler.count，很多教程直接写“设为100”，但从没解释：这个值不是越大越好，它对应的是RegionServer JVM堆内线程数，每条handler线程默认占用约1MB栈空间，100条就是100MB，若堆内存只配了4GB，线程栈就吃掉1/4，GC压力陡增，反而拖慢RPC响应。这些细节，才是企业级部署和实验室Demo的根本分水岭。

关键词“HBase高可用集群”背后，实际串联起四大技术域：ZooKeeper协调服务的健壮性设计、HDFS底层存储的容错能力、HBase自身Master/RegionServer进程的故障转移机制，以及运维层面的监控告警闭环。本篇聚焦第四环节——即标题所指的“部署（四）”，它是前三者落地的最终承载体。前几期我们已铺垫了ZK集群独立部署规范、HDFS HA架构验证、HBase核心配置模板，本期进入最易踩坑也最考验系统观的实操阶段：多节点协同启动顺序、服务依赖校验脚本编写、首次全链路健康检查清单、以及最关键的——模拟RegionServer宕机后的自动恢复实测记录。全文所有步骤均来自某金融风控平台的真实上线过程，配置参数经压测验证，可直接抄作业，但请务必理解每一行命令背后的“为什么”。

2. 整体架构设计与方案选型逻辑

2.1 为什么坚持ZooKeeper完全独立部署，而非HBase内置ZK？

这是企业级部署的第一道分水岭。HBase安装包自带ZooKeeper，新手常图省事直接启用hbase-env.sh中的export HBASE_MANAGES_ZK=true，看似一键启动，实则埋下重大隐患。原因有三：

第一，资源争抢不可控。HBase RegionServer本身是内存密集型进程，JVM堆常配至16GB以上，而ZooKeeper对GC极其敏感，官方强烈建议ZK进程独占物理机或容器，避免与HBase共享JVM或宿主机内存。我们曾在线上环境复现过：当RegionServer因大Scan触发Full GC时，ZK进程因宿主机内存压力被迫swap，ZK会话超时中断，导致所有RegionServer被强制下线，集群雪崩。

第二，版本兼容性风险。HBase内置ZK版本固定（如HBase 2.4.9内置ZK 3.4.14），而企业安全策略可能要求升级ZK至3.6.x以修复CVE-2020-14492等漏洞。若强行替换内置ZK jar包，HBase源码中大量使用ZK 3.4.x私有API（如ZKUtil.deleteNodeRecursively），升级后直接ClassNotFound。

第三，运维隔离性缺失。ZK作为分布式协调中枢，其日志、监控、备份策略应与业务组件解耦。独立部署后，ZK集群可单独配置Prometheus exporter、设置独立告警阈值（如zk_avg_latency > 50ms）、执行滚动升级，而无需停机HBase。

因此，本方案采用3节点ZK集群完全独立部署：3台专用虚拟机（8C16G），ZK版本3.6.4，数据目录挂载SSD，tickTime=2000ms，initLimit=10，syncLimit=5，maxClientCnxns=60。所有HBase节点通过hbase.zookeeper.quorum指向这3个IP，hbase-env.sh中强制export HBASE_MANAGES_ZK=false。这种解耦设计，让ZK成为真正的“基础设施层”，而非HBase的附属品。

2.2 HDFS HA模式为何必须启用QJM，而非NFS或SharedDirs？

HBase严重依赖HDFS存储WAL（Write-Ahead Log）和HFile。若HDFS NameNode单点故障，HBase将无法写入新数据，RegionServer持续报Failed to get block locations错误。因此HDFS高可用是HBase高可用的前提。当前主流方案有三：NFS共享目录、QJM（Quorum Journal Manager）、以及基于BookKeeper的分布式日志（较少见）。我们弃用NFS，原因明确：

NFS存在单点瓶颈与一致性风险。所有DataNode需挂载同一NFS服务器，该服务器磁盘I/O成为写入瓶颈；更致命的是NFS文件锁机制在断网重连时易出现“假死锁”，导致JournalNode无法获取编辑日志锁，NameNode切换失败。某电商项目曾因此导致HDFS集群卡在Standby状态长达38分钟。

QJM则通过奇数个JournalNode（推荐3或5个）组成法定人数（quorum）集群，EditLog以Paxos协议同步。即使1个JournalNode宕机，剩余2个仍可达成多数派写入，NameNode切换可在30秒内完成。我们采用3节点QJM：每台JournalNode部署在独立物理机（4C8G），dfs.journalnode.edits.dir挂载RAID10阵列，dfs.namenode.shared.edits.dir配置为qjournal://jn1:8485;jn2:8485;jn3:8485/hbase。此架构下，HDFS HA切换平均耗时12.3秒（压测数据），完全满足HBase对底层存储的SLA要求。

2.3 HBase Master高可用：主备模式 vs. 多Master模式？

HBase 2.x起支持多Master部署（hbase.master.maxclockskew等参数控制），但企业生产环境仍首选双Master主备模式，理由如下：

首先，多Master虽理论上提升可用性，但实际引入复杂度。HBase Master职责包括Region分配、负载均衡、失效RegionServer处理等，多个Master需通过ZK竞争leader，若网络分区发生，可能出现“脑裂”：两个Master同时认为自己是leader，向RegionServer下发冲突指令，导致Region状态混乱。我们曾用3 Master集群做混沌测试，当模拟ZK网络延迟>5s时，100%概率触发Region分裂异常。

其次，主备模式成熟稳定。HBase原生支持Master Failover：备用Master监听ZK/hbase/master节点，一旦主Master进程退出，ZK自动删除该临时节点，备用Master立即创建新节点并接管服务。切换过程无需人工干预，平均耗时8.6秒（实测）。关键配置仅两项：hbase.master.maxclockskew=30000（容忍时钟偏差30秒，避免因NTP不同步误判Master死亡），hbase.master.wait.on.regionservers.maxstart设为足够大（如600000），确保所有RegionServer注册完成后再启动服务。

最后，运维成本差异显著。双Master只需维护2台机器，监控项清晰（MasterActive指标）；而3 Master需监控ZK leader选举状态、各Master间心跳延迟、RegionServer注册一致性，告警规则复杂度翻倍。对于99%的企业场景，双Master已提供充足冗余，过度设计反而增加故障面。

2.4 RegionServer部署密度：为何拒绝“越多越好”的惯性思维？

新手常认为RegionServer节点越多，集群吞吐越高。但真实生产环境需遵循“适度冗余”原则。我们为某风控平台设计的5节点集群，配置如下：

注意：node1/node2同时运行Master和RegionServer，这是为节省资源做的权衡，但必须确保Master JVM堆（-Xmx4g）与RegionServer堆（-Xmx32g）严格分离，通过hbase-env.sh中HBASE_MASTER_OPTS和HBASE_REGIONSERVER_OPTS分别配置。node3/node4配置更高，因其承担80%写入流量；node5作为轻量级节点，专用于运行Coprocessor（协处理器）和离线MR任务，避免干扰核心写入路径。

这种非对称设计源于真实负载特征：风控日志写入具有明显波峰（早9点、晚8点），但读取请求（实时查询）相对平稳。将计算密集型任务（如协处理器过滤）剥离到专用节点，可避免GC抖动影响写入延迟。实测表明，相比5台同构节点（均为16C64G），该方案在峰值写入时P99延迟降低37%，Region分裂成功率从92%提升至99.8%。

3. 核心配置解析与实操要点

3.1 ZooKeeper连接参数：超时设置的黄金三角法则

HBase与ZooKeeper的连接稳定性，取决于三个参数的协同配置，我们称之为“黄金三角”：

• zookeeper.session.timeout（ZK会话超时）
• hbase.zookeeper.property.tickTime（ZK心跳周期）
• hbase.zookeeper.recovery.retry（ZK连接恢复重试次数）

很多教程只告诉你“设大一点”，却未说明内在逻辑。真相是：这三个值必须满足数学约束，否则集群会在网络抖动时陷入“假死”循环。

先看ZK官方约束：sessionTimeout必须介于2*tickTime与20*tickTime之间。若tickTime=2000ms，则sessionTimeout合法范围是4000~40000ms。HBase默认值为40000ms（40秒），这已是上限，不能再大，否则ZK服务端会拒绝连接。

再看HBase侧逻辑：当RegionServer检测到ZK会话过期，会触发ZooKeeperWatcher的connectionLoss事件，此时它不会立即退出，而是尝试重连。重连行为由hbase.zookeeper.recovery.retry（默认3次）和hbase.zookeeper.recovery.retry.interval（默认1000ms）控制。但关键点在于：每次重连尝试，都会消耗1个sessionTimeout周期。若sessionTimeout设为40秒，重试3次，最长等待时间达120秒！这期间RegionServer处于“半死”状态，既不服务也不下线，客户端持续超时。

因此，我们的实操方案是：

• hbase.zookeeper.property.tickTime=2000（ZK服务端配置，所有ZK节点统一）
• zookeeper.session.timeout=12000（12秒，满足2×2000≤12000≤20×2000）
• hbase.zookeeper.recovery.retry=5
• hbase.zookeeper.recovery.retry.interval=2000

计算重连总耗时：5次×2秒间隔=10秒，小于12秒会话超时，确保RegionServer在12秒内完成重连或彻底退出。实测中，当模拟ZK网络丢包率15%时，该配置下RegionServer平均恢复时间为8.3秒，无一例进入长时间等待。

提示：修改ZK参数后，必须重启所有ZK节点，且需按顺序：先停follower，再停leader，最后停observer（如有）；启动时相反。任意节点ZK配置不一致，会导致集群脑裂。

3.2 HDFS底层优化：Block Size与Replication Factor的业务适配

HBase数据最终落盘为HDFS上的HFile，其性能直接受HDFS块大小（dfs.blocksize）和副本数（dfs.replication）影响。通用教程常建议dfs.blocksize=128MB，dfs.replication=3，但这对HBase并非最优。

分析HBase写入模式：客户端写入先到MemStore，满128MB（默认hbase.hregion.memstore.flush.size）后刷写为HFile。若HDFS块大小为128MB，则一个HFile恰好占1个HDFS块，看似完美。但问题在于：HFile是顺序写入，而HDFS块是分布式存储单元。当RegionServer刷写HFile时，需将128MB数据分散写入3个DataNode。若块大小过小（如64MB），则128MB HFile需跨2个块，涉及更多DataNode协调，写入放大；若过大（如256MB），则单个HFile可能无法填满一个块，造成磁盘空间浪费，且小文件（<128MB）读取时需跨块寻址，延迟升高。

我们通过压测确定：对风控日志这类中等大小（平均记录2KB）、高吞吐场景，dfs.blocksize=256MB最佳。原因：HBase 2.x默认hbase.hregion.memstore.flush.size=128MB，但实际生产中我们调大至256MB（需同步调整hbase.hregion.memstore.flush.size），使单次刷写生成的HFile接近256MB，与HDFS块对齐，减少跨块IO。同时，dfs.replication设为2而非3——这需要勇气，但有充分依据：HBase自身具备WAL预写日志机制，即使1个DataNode宕机，WAL可保证数据不丢失；而replication=2可降低33%网络带宽消耗和磁盘写入压力，实测集群整体写入吞吐提升22%。当然，此方案要求HDFS DataNode至少3台（满足2副本的容错），且必须开启dfs.namenode.replication.min=1，防止副本不足时写入阻塞。

注意：修改HDFS参数需滚动重启DataNode，且必须先在hdfs-site.xml中配置，再执行hdfs dfsadmin -setBalancerBandwidth 10485760（10MB/s）以加速副本均衡。

3.3 RegionServer关键参数：内存与Handler的精细调控

RegionServer是HBase的“心脏”，其JVM配置决定集群生死。常见错误是直接套用网上模板，如-Xms8g -Xmx8g，却忽略业务特征。风控平台日志写入具有突发性，需应对短时流量洪峰，因此我们采用动态内存分配策略：

• -Xms32g -Xmx32g：固定堆大小，避免GC时堆伸缩开销
• -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m：元空间固定，防OOM
• -XX:+UseG1GC -XX:MaxGCPauseMillis=200：G1垃圾收集器，目标停顿200ms
• -XX:G1HeapRegionSize=4M：Region大小设为4MB（HBase 2.x推荐），匹配HFile块大小

更关键的是hbase.regionserver.global.memstore.size（全局MemStore占比）和hbase.regionserver.heapmemory.fraction（堆内存分配比例）。默认hbase.regionserver.global.memstore.size=0.4（40%堆内存），但风控场景写入密集，需提高至0.45；而hbase.regionserver.heapmemory.fraction默认0.4，我们调至0.35，为BlockCache（读缓存）留出更多空间（hfile.block.cache.size=0.3），因实时查询频次高。计算：32GB堆×0.45=14.4GB MemStore，32GB×0.3=9.6GB BlockCache，剩余9GB为其他开销，分配合理。

Handler数量（hbase.regionserver.handler.count）同样需精算。公式为：handler_count ≈ (预期峰值QPS × 平均处理延迟秒数) × 1.5。风控平台峰值QPS 8万，平均写入延迟15ms（0.015秒），则理论值=80000×0.015×1.5=1800。但受限于CPU核心数，我们设为128（32核×4线程/核），并通过hbase.ipc.server.callqueue.handler.factor=0.5将CallQueue分为2个队列，防止单一热点Region占满所有handler。实测中，该配置下CPU利用率稳定在65%~75%，无handler饥饿现象。

3.4 安全加固：Kerberos认证的最小化接入方案

企业生产环境必须启用Kerberos认证，但全量接入会极大增加复杂度。我们的策略是：仅对HBase服务端启用Kerberos，客户端保持简单认证。即HBase Master/RegionServer进程以Kerberos principal启动，但应用通过hbase.client.scanner.caching等参数访问时，无需Kerberos票据。

具体操作：

• 在KDC中创建hbase/_HOST@REALM和hbase-master/_HOST@REALMprincipal
• 生成keytab文件，分发至各节点
• hbase-site.xml中配置：

<property> <name>hbase.security.authentication</name> <value>kerberos</value> </property> <property> <name>hbase.rpc.protection</name> <value>privacy</value> <!-- 启用数据加密 --> </property> <property> <name>hbase.master.kerberos.principal</name> <value>hbase-master/_HOST@REALM</value> </property> <property> <name>hbase.master.keytab.file</name> <value>/etc/security/keytab/hbase.service.keytab</value> </property>

• 所有RegionServer同理配置hbase.regionserver.kerberos.principal和hbase.regionserver.keytab.file

此方案优势：服务端获得强身份认证和通信加密，客户端无需改造现有代码（如Spark/Hive连接HBase仍用普通方式），运维只需管理服务端keytab轮换。我们设定keytab有效期为30天，通过Ansible脚本每月自动续期，避免证书过期导致集群瘫痪。

4. 实操过程与核心环节实现

4.1 部署前检查清单：12项必验项

在执行任何安装命令前，必须完成以下检查，缺一不可。这是避免后续数小时排查的基石：

1. 时间同步：所有节点NTP服务必须启用，ntpq -p显示offset < 50ms。我们使用chrony替代ntpd，因chrony在虚拟化环境中时钟漂移更小。
2. 主机名解析：/etc/hosts中必须包含所有节点完整FQDN（如node1.cluster.local），且hostname -f返回值与hosts中一致。DNS解析禁用，仅用hosts文件。
3. SSH免密登录：主节点需能无密码SSH到所有节点（包括自身），ssh node1 date应秒回。这是Ansible部署的前提。
4. Java版本：java -version必须为OpenJDK 11.0.15+，JAVA_HOME环境变量正确导出。HBase 2.4.x不支持JDK 17。
5. ulimit设置：ulimit -n≥65535，ulimit -u≥65535。在/etc/security/limits.conf中添加hbase soft nofile 65535等。
6. SELinux状态：getenforce必须为Permissive或Disabled。Enforcing模式下HBase进程常因权限被拒。
7. 防火墙端口：开放ZK（2181,2888,3888）、HDFS（8020,50070,50010）、HBase（16000,16010,16020,16030）等端口。使用firewall-cmd --permanent --add-port=2181/tcp批量添加。
8. 磁盘挂载选项：SSD数据盘必须用noatime,nodiratime,data=ordered挂载，mount | grep ssd验证。
9. HDFS格式化状态：hdfs namenode -format仅执行一次，且必须在core-site.xml和hdfs-site.xml配置完成后。
10. ZK集群健康：echo stat | nc zk1 2181返回Zookeeper version:且Mode: follower或Mode: leader，无Connection refused。
11. HDFS HA状态：hdfs haadmin -getServiceState nn1返回active，hdfs haadmin -getServiceState nn2返回standby。
12. HBase配置校验：用hbase org.apache.hadoop.hbase.util.HBaseConfTool检查hbase-site.xml语法，无WARNING。

注意：第12项常被忽略。该工具会扫描所有配置项，提示如hbase.zookeeper.quorum is not set等致命错误，比启动时报错更早发现问题。

4.2 分步启动脚本：从ZK到HBase的精确时序

HBase集群启动有严格依赖顺序，错一步即全盘失败。我们编写了start-hbase-cluster.sh脚本，核心逻辑如下：

#!/bin/bash # Step 1: 启动ZooKeeper集群（所有节点） for node in zk1 zk2 zk3; do ssh $node "cd /opt/zookeeper/bin && ./zkServer.sh start" done sleep 10 # 等待ZK选举完成 # Step 2: 启动HDFS（先NN1，再NN2，最后DN） ssh nn1 "hdfs --daemon start namenode" ssh nn2 "hdfs --daemon start namenode" sleep 30 for dn in dn1 dn2 dn3 dn4 dn5; do ssh $dn "hdfs --daemon start datanode" done sleep 60 # 等待DataNode注册 # Step 3: 启动YARN（如需MR） ssh rm "yarn --daemon start resourcemanager" for nm in nm1 nm2; do ssh $nm "yarn --daemon start nodemanager" done # Step 4: 启动HBase（先Master，再RegionServer） ssh master "hbase-daemon.sh start master" sleep 15 ssh backup-master "hbase-daemon.sh start master" sleep 10 for rs in rs1 rs2 rs3 rs4 rs5; do ssh $rs "hbase-daemon.sh start regionserver" done

关键点在于sleep时长：ZK选举通常需5~8秒，但为保险设10秒；HDFS DataNode注册需30~60秒，因需向NameNode汇报块信息；HBase Master启动后需15秒完成ZK注册和Region分配初始化。若跳过sleep，RegionServer可能因找不到Master而反复重试，日志刷屏Connection refused。

启动后，必须立即执行健康检查：

• echo "status 'simple'" | hbase shell -n：返回1 active master, 1 backup masters, 5 live servers即成功
• hbase hbck -details：检查HBase元数据一致性，无INCONSISTENCY警告
• hdfs fsck /hbase -files -blocks -locations：验证HBase数据目录HDFS块完整性

4.3 首次全链路健康检查：5个核心指标验证

启动成功不等于可用。我们定义5个硬性指标，全部达标才算部署完成：

1. Region分配均匀性：hbase shell -n -e "list_regions 'hbase:meta'" | wc -l应≈总Region数×0.95。若某RegionServer分配Region数偏离均值±30%，需手动balance_switch true并balancer。
2. WAL写入延迟：hbase shell -n -e "status 'detailed'"中WAL字段avg_time< 10ms。超时说明HDFS写入慢，检查DataNode磁盘IO。
3. ZK连接稳定性：echo "stat" | nc zk1 2181 | grep "Connections"，连接数应稳定在5（3个ZK节点+2个Master），无剧烈波动。
4. BlockCache命中率：hbase shell -n -e "status 'detailed'"中blockCacheHitRatio> 85%。低于此值说明hfile.block.cache.size过小或热点Region未预热。
5. GC健康度：jstat -gc $(pgrep -f "HMaster") 1000 3，G1YGCT（Young GC时间）< 200ms，G1FGCT（Full GC时间）= 0。若Full GC频繁，需调优G1参数。

某次部署中，第4项指标仅72%，排查发现是hbase.regionserver.global.memstore.size设得过大（0.5），挤占BlockCache空间。调回0.45后，命中率升至89%。

4.4 故障注入实测：RegionServer宕机自动恢复全流程

高可用必须经受住故障考验。我们在node3上执行kill -9 $(pgrep -f "HRegionServer")，模拟RegionServer进程崩溃，全程记录：

• T=0s：node3进程退出，ZK/hbase/rs/node3节点消失
• T=3s：Master检测到节点失联，开始ServerShutdownHandler
• T=8s：Master将node3上所有Region标记为OFFLINE，并分配给node4/node5
• T=12s：node4/node5开始Recovery流程，从WAL中重放未提交事务
• T=18s：所有Region在新节点上线，hbase shell -n -e "status 'simple'"显示4 live servers
• T=22s：客户端写入恢复正常，无超时

整个过程22秒，符合≤30秒SLA。关键观察点：WAL重放期间，新RegionServer的hbase.regionserver.wal.max.age.ms（默认600000ms）必须足够长，确保旧WAL未被清理。我们将其设为1800000（30分钟），并配置hbase.wal.provider=filesystem（非default），因filesystem WAL在故障恢复时更稳定。

实操心得：故障测试必须在业务低峰期进行，且提前通知所有依赖方。我们约定每月第一个周五凌晨2点执行，测试脚本自动发送钉钉告警：“RegionServer故障注入开始，预计影响20秒”。

5. 常见问题与排查技巧实录

5.1 RegionServer频繁退出：ZK会话超时的连锁反应

现象：RegionServer日志持续打印org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired，进程每5~10分钟重启一次。

排查思路：

1. 先确认ZK服务端是否健康：echo stat | nc zk1 2181，若返回Connection refused，则是ZK集群故障。
2. 若ZK正常，检查网络：ping zk1、telnet zk1 2181，确认端口可达。
3. 检查RegionServer主机负载：top -b -n1 | head -20，若CPU或内存100%，ZK心跳线程无法及时发送，导致会话过期。
4. 最终定位：hbase-site.xml中zookeeper.session.timeout与ZK服务端tickTime不匹配。

解决方案：

• ZK服务端zoo.cfg中tickTime=2000，则zookeeper.session.timeout必须≤40000且≥4000
• RegionServer JVM需增加GC日志：-Xloggc:/var/log/hbase/gc.log -XX:+PrintGCDetails
• 若GC频繁，按3.3节调优JVM参数

避坑技巧：在hbase-env.sh中添加校验逻辑：

if [ "$HBASE_MANAGES_ZK" = "false" ]; then ZK_TIMEOUT=$(grep "zookeeper.session.timeout" $HBASE_CONF_DIR/hbase-site.xml | sed -r 's/.*<value>([0-9]+)<\/value>.*/\1/') if [ "$ZK_TIMEOUT" -gt 40000 ] || [ "$ZK_TIMEOUT" -lt 4000 ]; then echo "ERROR: zookeeper.session.timeout $ZK_TIMEOUT out of range [4000,40000]" exit 1 fi fi

启动前自动校验，防患未然。

5.2 Master无法切换：ZK节点状态不一致

现象：主Master宕机后，备用Master日志显示Waiting for master to be assigned，始终无法成为active。

根本原因：ZK集群节点状态不一致。echo stat | nc zk1 2181返回Mode: follower，但nc zk2 2181返回Connection refused，说明zk2进程已死但ZK服务端未感知。

排查步骤：

1. 登录所有ZK节点，ps aux | grep QuorumPeerMain确认进程存活
2. 检查ZK日志/opt/zookeeper/logs/zookeeper-*.out，搜索WARN或ERROR
3. 执行echo ruok | nc zk1 2181，正常返回imok；若超时，说明ZK进程假死

解决方法：

• 重启故障ZK节点：./zkServer.sh restart
• 强制ZK重新选举：在所有ZK节点执行./zkServer.sh stop，再按顺序./zkServer.sh start
• 重启HBase Master：hbase-daemon.sh stop master→hbase-daemon.sh start master

独家技巧：为防ZK单点故障，我们在ZK集群外部署zookeeper-exporter，通过Prometheus监控zk_server_state指标（1=leader, 0=follower），当leader连续30秒为0时自动告警。

5.3 HBase写入卡顿：HDFS DataNode磁盘写满

现象：hbase shell中put命令超时，hdfs dfs -df -h显示某DataNode磁盘使用率100%。

深层原因：HDFS默认dfs.datanode.du.reserved为0，即磁盘满时DataNode停止服务，但HBase仍向其分配Region，导致写入失败。

解决方案：

• 立即清理DataNode磁盘：hdfs dfs -du -h / | sort -hr | head -20找大文件
• 设置保留空间：hdfs-site.xml中dfs.datanode.du.reserved=10737418240（10GB）
• 重启DataNode：hdfs --daemon stop datanode→hdfs --daemon start datanode

预防措施：部署hdfs-disk-monitor脚本，每5分钟检查df -h /data，使用率>85%时自动触发hdfs dfsadmin -report并邮件告警。

5.4 客户端连接拒绝：HBase端口未监听

现象：应用报错java.net.ConnectException: Connection refused，netstat -tuln | grep 16000无输出。

排查链路：

• `ps aux |