一个 RegionServer 掉线,大多数人的第一反应是登上那台机器翻日志。十几个 RegionServer 在几十秒内接连掉线,这个动作基本就没有意义了——能在同一分钟里干掉十几台机器的,不会是某一台机器的 JVM,而是它们共同依赖的某个东西。我把这类故障叫共因故障:ZooKeeper、DataNode、网络、时钟,以及那批机器共同的硬件批次。单机原因的排查思路(看堆、看盘、看线程栈)在批量掉线的场景里往往会把人带偏,因为你盯的那台机器可能只是倒霉,而不是有病。这篇就把我自己处理过的几次 HBase RegionServer 批量掉线拆开讲:日志时间线怎么拼、ZooKeeper 那个最会骗人的90 秒是怎么回事、GC 停顿和 WAL 阻塞各自在日志里长什么样、网络和时钟这类看起来一切正常的原因怎么验证,最后给一份可以直接照着做的处置清单。适合手里有 HBase 集群、需要半夜被叫起来看监控的运维和开发同学,基础概念我会顺手解释,新手也能跟下来。1. 先判断是共因故障还是独立故障1.1 时间聚集性是最便宜也最有效的判据HBase 的 RegionServer 掉线,在 Master 眼里只有一个事实:它注册在 ZooKeeper 上的临时节点消失了,或者它主动上报了致命错误。这个事实本身不携带任何原因信息,原因藏在掉线发生前后的那几十秒里。所以第一步永远不是看为什么掉,而是看什么时候掉、谁先掉。把 Master 日志里所有掉线事件的服务器名和时间戳抽出来排个序,看两个指标:第一是总时长跨度,如果从第一台到最后一台不超过两分钟,几乎可以断定是共因;第二是顺序和位置,如果掉的全是同一个机架、同一个交换机下、或者同一批采购的机器,那方向就更明确了。我遇到过最典型的一次,14 台 RegionServer 在 47 秒内全部掉线,分布在 5 个机架,但它们的 ZooKeeper 客户端日志里的negotiated timeout全是 40000 毫秒——答案就摆在眼前,不是机器的问题,是会话超时被 GC 停顿吃掉了。反过来,如果掉线时间散布在几个小时里,每次一两台,那就不是批量掉线,而是慢性的单机问题:磁盘坏道、内存缓慢泄漏、Region 分布不均导致的个别热点。这两种情况的排查路径完全不同,先把它们分开,能省掉大量无效劳动。1.2 四条并行的线索,少一条都可能判断错我习惯在拿到告警后的头五分钟内同时抓四样东西,不追求看完,先存下来,因为很多现场信息(线程栈、连接状态、GC 状态)过一会儿就没了:Master 日志:掉线事件的官方记录,以及后续的 Region 重新分配动作,能看出 Master 自己有没有卡住。RS 日志:退出前最后 200 行,这是信息密度最高的地方。ZK 日志:ZooKeeper 服务端的Expiring session和延迟指标,决定了是客户端的问题还是服务端的问题。系统层:dmesg -T、journalctl -k、iostat、ss -s,用来排除 OOM Killer、磁盘、网络。这四份材料的时间必须能对齐。如果各机器的时钟本身就差了几十秒,后面所有推理都是空中楼阁,所以顺手确认一下 NTP 状态,这个习惯救过我两次。2. 三份日志的时间线怎么拼起来2.1 Master 日志:它只知道人没了,但会告诉你谁先没的Master 侧最需要盯的几类日志如下表,关键字在不同版本里略有差异,但语义是稳定的:日志片段(含义)说明排查价值reported a fatal error and will be processedRS 主动上报致命错误,通常是它自己决定不干了说明进程还活着时自己选择了退出,不是被网络隔离Processing expiration of serverMaster 发现 ZK 上该 RS 的临时节点消失说明是会话层面失效,进程状态未知Server Crash Processing/ServerCrashProcedure开始处理崩溃,重建 WAL、重分配 Region这是后果不是原因,但能看出 Master 有没有被压垮transitioned to DEAD状态机的终态配合时间戳做排序一个非常有用的细节:如果同一次故障里,第一批日志是reported a fatal error,后面才是Processing expiration,那说明 RegionServer 是主动退出的。主动退出意味着它自己检测到了某个不可恢复的错误(WAL 写失败、ZK 会话过期、Region 处于不一致状态),进程会走System.exit。这种情况下机器本身大概率是健康的,问题在它依赖的东西上。这在定性上已经把方向从机器坏了推到依赖坏了。2.2 RegionServer 日志:只看 Aborting 之前的那两百行RS 日志里Aborting之后的内容价值很低,那是收尸过程。真正的原因在它前面。我一般的做法是先定位到 Aborting 的行号,然后往前翻,重点找这几类:grep -n -E Aborting|ABORTING|ShutdownHandler|Received EXIT|fatal regionserver.log # 拿到行号 N 之后 sed -n $((N-200)),${N}p regionserver.log在这两百行里,常见的关键信息有:zookeeper.ClientCnxn打印的Client session timed out, have not heard from server in XXXXms——这句话直接给出会话失联的时长,是判断 GC 停顿还是网络断开的黄金证据;hlog或WAL相关的 IOException;Slow sync、Sync duration这类性能告警;以及NotServingRegionException的密集出现。have not heard from server in XXXXms里的这个数字非常关键。如果它接近会话超时值,说明是心跳彻底断了;如果它比超时值大很多,比如超时 40 秒但报的是 43 秒,说明 RegionServer 在这 43 秒里没能执行任何代码,典型的长时间停顿。2.3 ZooKeeper 侧:区分客户端卡住和服务端卡住ZooKeeper 服务端日志里,Expiring session 0x...表示它按规则清理了一个超时会话。如果一次故障里 ZK 只 Expire 了这一批 RS,而其他客户端(比如 HMaster、其他 RS)安然无恙,那基本可以锁定是这些 RS 自身的问题;如果连 HMaster、Hive 客户端、其他一切连 ZK 的进程都在同一时间段报会话问题,那就是 ZK 集群本身出事了。ZK 服务端有一个非常好用的四字命令,能直接看到延迟水位:echo mntr | nc zk-host-1 2181 | grep -E max_latency|avg_latency|outstanding|num_alive echo cons | nc zk-host-1 2181 | wc -lmax_latency是历史最大值,意义不大;要看的是故障时间点前后的avg_latency是否突然抬升,以及outstanding是否堆积。ZK 的请求处理是单线程的(提交到事务日志的路径尤其如此),一旦它自己的磁盘 fsync 变慢,所有客户端的 ping 都会排在后面,表现出来就是所有客户端同时会话超时。这类故障我在把 ZK 的事务日志和数据放在一块高负载盘上的环境里见过不止一次。3. ZooKeeper 会话超时:最会骗人的那个90 秒3.1 你在配置文件里写的 90 秒,大概率没有生效这是我在批量掉线排查里见过最多的认知偏差。很多人在hbase-site.xml里看到zookeeper.session.timeout是 90000,就默认自己有四十五秒甚至九十秒的容错窗口,于是把 GC 调优的目标定在停顿不超过 60 秒就行。这个前提是错的。ZooKeeper 服务端有一个maxSessionTimeout参数,默认值是20 * tickTime。如果集群沿用 ZK 默认的tickTime2000,那么maxSessionTimeout就是 40000 毫秒。客户端发起连接时请求的是 90000,服务端会把它截断到 40000再返回。真实生效的值只有一个地方能看到:客户端日志里那句negotiated timeout。请求值(hbase 配置)ZK tickTimeZK maxSessionTimeout实际生效容错窗口9000020004000040000严重缩水90000600012000090000符合预期4000020004000040000刚好卡在边界,不建议1800006000120000120000仍然被截断提示:动手调参之前,先去任意一台 RegionServer 的日志里 grep 一次negotiated timeout,确认到底是多少。这一步比看任何配置文件都可靠,配置可以有多份、有覆盖、有历史残留,日志不会骗人。上表的计算逻辑很简单:maxSessionTimeout 20 × tickTime,客户端请求值取小。HBase 的hbase.zookeeper.property.tickTime只影响客户端自己算的默认值,真正的上限由服务端的 zoo.cfg 决定。所以想真正拿到 90 秒窗口,得先把 ZK 服务端的tickTime或maxSessionTimeout调上去,并且需要滚动重启 ZK——这是一个有成本的操作,不能拍脑袋做。3.2 掉线其实是自杀,不是被踢出来理解这条路径对定性非常有帮助。RegionServer 起来后会往 ZooKeeper 的/hbase/rs/下写一个临时节点,同时注册一个 Watcher。当这个会话被判定过期,ZooKeeper 客户端会回调,RegionServer 内部走到Abortable.abort(),再交给ShutdownHandler执行退出。也就是说,绝大多数掉线是 RegionServer 自己执行的退出,而不是 Master 把它踢掉。这个结论带来两个非常实用的推论。第一,进程退出前一定会留下日志,而且退出码是明确的,hbase-rs-*.out或者 systemd/journal 里能看到退出时间和退出码,把它和 ZK 的 Expire 时间对齐,如果 RS 退出时间晚于 ZK Expire 时间几毫秒到几十毫秒,因果链就闭合了。第二,既然是自杀,那么把它救活这件事就有了参数级的抓手——HBase 提供hbase.regionserver.restart.on.zk.expire这个开关,开启后会话过期时 RegionServer 会尝试重启自己而不是退出。这是个权衡:重启能让节点自己回来,少一次 Region 大搬迁,但代价是这个 RS 上的 Region 会短暂不可用,而且如果根因是持续性的大停顿,重启只是把问题变成周期性抖动。我的建议是把它当止血手段,不当解决方案。4. 模式一:GC 停顿把心跳按在地上4.1 用两个工具锁死停顿窗口判断 GC 是不是元凶,不需要猜,两个工具就够了。第一个是jstat,故障后如果进程还在(或者你提前挂了采集),它可以一秒一次地看 GC 趋势:jstat -gcutil pid 1000 60重点看FGCT(Full GC 总耗时)和GCT的增量,以及FGC的次数。如果在掉线时间窗口内FGC从 0 变成 1 且FGCT增加了 40 秒以上,基本可以定案。第二个是 JVM 参数-XX:PrintGCApplicationStoppedTime,它会打印每一次真正的 stop-the-world 时长,包括那些不发生在 GC 里的停顿(比如偏向锁撤销、代码反优化)。这个参数的价值在于它是唯一能直接告诉你JVM 停了多少秒的证据,而 GC 日志里的时长往往只统计了 GC 自己那一段。我见过一个案例,GC 日志显示最长停顿 3 秒,但应用停顿日志里有连续 47 秒的 STW——原因是巨量的System.gc()加上堆外内存回收,GC 日志被切成了很多小段。STW 停顿时长相对 40 秒会话超时结果 10 秒安全心跳正常续期10 ~ 30 秒危险一次网络抖动叠加就掉线30 ~ 45 秒极危险单次停顿即可掉线 45 秒必然掉线且往往成批出现4.2 为什么 Region 多的机器特别容易长停顿根因往往不是堆太小,而是Region 数量乘以每个 Region 的 MemStore 上限这个乘积远远超过堆容量,导致写缓存永远处于高压状态,flush 和 compaction 排队,一旦遇到写入高峰就雪崩。举个例子算一下:单机 180 个 Region,hbase.hregion.memstore.flush.size128MB,hbase.regionserver.global.memstore.size0.4,堆 32GB。全局 MemStore 上限是 12.8GB,单个 Region 的 flush 阈值是 128MB,理论上能同时容纳 100 个 Region 各写满一半。看似够,但 compaction 也会占内存,读缓存(BlockCache)默认占 0.4,加起来就顶到 80% 以上,剩下的空间要装 RPC 队列、各种索引结构,Full GC 就在这时候发生。我的经验是先把单机 Region 数压下来,再谈堆。把 Region 数从 180 降到 80,带来的收益比把堆从 32G 加到 48G 大得多,而且风险更低。堆从 32G 加到 48G 会让单次 Full GC 的时长增加接近 50%,这在批量掉线的语境下是负优化。4.3 一个反直觉的结论:堆越大,批量掉线越狠这条是我踩过坑才信的。32GB 以内的堆,大多数收集器还能用压缩指针,对象布局紧凑,GC 效率高;超过这个规模,CMS 时代的单次 Full GC 动辄以分钟计。同样的写入压力下,16GB 堆的机器可能只停顿 8 秒,48GB 堆的机器停顿 50 秒——后者掉线,前者不掉。所以正确的方向是:堆控制在合理区间(我个人偏好 16~24GB),用 G1 加上合理的MaxGCPauseMillis,把 Region 数控住,必要时把一台物理机拆成两个 RegionServer 实例(用不同的端口和目录),分散单实例的 Region 数和堆压力。这个方案听起来麻烦,但它把单点故障域缩小了一半,在批量掉线的场景里收益非常直接。5. 模式二:HDFS 写不进去,RS 一样会自杀5.1 WAL 阻塞时线程栈长什么样RegionServer 的每一次写操作都要落 WAL,而 WAL 是写在 HDFS 上的。当 HDFS 侧的写入变慢或者失败,RegionServer 的 handler 线程会全部堆在同步等待上,RPC 队列迅速堆满,客户端开始超时,然后 RegionServer 因为无法在合理时间内完成关键操作而选择退出。现场抓jstack是最直接的:jstack -l pid /tmp/rs-stack-$(date %s).txt grep -c waitForAckedSeqno /tmp/rs-stack-*.txt grep -c DataStreamer /tmp/rs-stack-*.txt grep -A3 IPC Server handler /tmp/rs-stack-*.txt | head -60如果几十个 handler 线程都停在DFSOutputStream的waitForAckedSeqno或者hflush/hsync上,而DataStreamer线程在等待 pipeline 的 ack,那基本可以确定是 HDFS 写入路径被堵住了。此时继续在 RegionServer 上调参数是浪费时间,应该直接去看 DataNode。5.2 DataNode 侧的三类天花板HDFS 写入卡住的常见原因就那么几个,我按遇到频率排:DataNode 侧现象典型报错后果xceiver 线程数打满xceiverCount ... exceeds the limit of concurrent xcievers新连接直接被拒,写入失败单块盘慢或坏Slow BlockReceiver write packet to mirror/Slow flushOrSyncpipeline 整体变慢,写入延迟抬升DataNode 全部退出或假死All datanodes are bad/Could not obtain blockWAL 直接写失败,RS 立刻退出dfs.datanode.max.transfer.threads这个参数在新版本里默认已经是 4096,但很多老集群还留着 4096 以下的旧值和旧机器的限制。RegionServer 是 HDFS 的重度写入方,每个 WAL 文件都会占用 pipeline 上的连接,写入高峰时打满 xceiver 的情况并不罕见。这个坑的特点是平时完全正常,一到大促或批量导入就爆,所以如果你们的批量掉线总是和业务高峰同时出现,优先怀疑它。5.3 磁盘:不要只看使用率df -h看不出任何问题的时候,iostat -x 1往往能说出真相:iostat -x 1 10 # 关注 %util、await、aqu-sz(或 avgqu-sz)、w/s对 WAL 和数据目录所在的盘,await持续超过 20 毫秒就要警惕,超过 50 毫秒基本可以认为盘跟不上。还有一个在云环境里特别隐蔽的情况:云盘的突发 IOPS 额度被耗尽。前几十分钟跑得飞快,额度用完后延迟陡增,表现为每天固定时段批量掉线。这个现象用iostat能看出来,但需要你提前有历史基线,否则单次采样看不出异常。我个人的硬性要求是:WAL 目录和 DataNode 数据目录不要放在同一块物理盘上。HBase 写 WAL 是顺序小写入加频繁 fsync,DataNode 是大块顺序写,两者抢同一块盘的 IO 队列,延迟会非线性放大。6. 模式三:网络与时钟,最容易被看起来正常骗过去6.1 一次交换机抖动能同时打断 ZK 和 HDFS共因故障里最难查的是网络,因为它不留日志。判断方法主要靠拓扑相关性:把掉线的机器按机架、按接入交换机分组,如果某一组的命中率明显高于其他组,那就不是软件问题。抓证据的手段有限但够用:# 重传与连接统计 netstat -s | grep -E retransmit|reset|segments retransmited ss -s # 网卡错误计数 ip -s link show # 带宽与丢包趋势 sar -n DEV 1 10netstat -s里的重传计数如果在一个时间窗口内快速增长,说明链路有丢包。ip -s link里的errors、dropped字段如果非零且在涨,网卡或链路层有问题。还有一类很少见但很坑的情况:MTU 不一致。当 RegionServer 和 ZooKeeper 之间的路径上存在 MTU 较小的链路,大包被丢弃且 ICMP 被过滤,表现为小包能通、大包不通,ZK 的 ping 可能正常但数据同步失败,最终会话超时。用ping -M do -s 1472逐级探测可以确认。6.2 NTP 漂移引发的假掉线时钟问题导致的故障看起来完全不像时钟问题,这是它最容易误导人的地方。ZK 的会话机制本身对时钟漂移不敏感(它用的是相对时间),但下面这几件事会受影响:Kerberos 票据的有效期判断(偏差超过 5 分钟直接认证失败)、HFile 的时间戳排序、以及你所有日志时间线的可对齐性。最后一点在排查时是致命的。如果两台机器的时钟差了 30 秒,你看到的RS 在 ZK Expire 之后 30 秒才退出这个结论就是假的,推理链会完全走偏。所以每次做时间线分析之前,先看一眼:chronyc tracking # 或 ntpq -p # 关注 System time offset 与 Last offset我给自己定的阈值是:集群内容器/虚拟机时钟偏移超过 200 毫秒就要处理,超过 1 秒视为故障。虚拟化环境下时钟漂移比物理机严重得多,chrony的配置要针对虚拟化做调整(比如放宽maxpoll、启用makestep)。6.3 一类非常隐蔽的假掉线:DNS 或主机名解析RegionServer 注册到 ZooKeeper 的节点名是hostname,port,startcode。如果 Master 侧解析不了这个主机名,或者解析到了错误的 IP,Master 会认为该 RS 已死并在日志里报掉线,但你去那台机器上一看,进程活得好好的,Region 也还在服务。这种情况在容器化环境、或者运维改过 DNS 记录之后特别容易出现。识别方法很简单:看到Processing expiration之后,立刻去那台机器上ps一下。如果进程还在,那这次掉线就是假的,问题在名称解析或者网络可达性上,不用去查 GC。这个动作只要十秒,但能省掉几个小时的错误方向。7. 还有一种掉线:进程根本没来得及说再见7.1 OOM Killer 干掉的进程不会留下遗言如果 RegionServer 的日志在某一刻突然中断,没有任何 Aborting 字样,后面的日志是空的,那要立刻怀疑是被操作系统杀掉了。Linux 的 OOM Killer 在内存紧张时会挑 RSS 最大的进程下手,一个 32GB 堆的 JVM 是最理想的目标。dmesg -T | grep -i -E killed process|out of memory journalctl -k --since 2024-01-01 02:00 --until 2024-01-01 03:00 | grep -i oom看到Out of memory: Killed process 12345 (java)就定案了。注意dmesg -T的时间戳用的是本地时区,和你日志里的时间可以直接对齐;有些系统的dmesg默认不带时间,要用-T或者journalctl -k。OOM Killer 的触发经常不是堆造成的,而是堆外内存 页缓存 容器 limit的组合。JVM 的堆外内存包括 Direct Buffer、JNI、线程栈、元空间,一个 32GB 堆的进程实际 RSS 可能到 40GB 以上。如果容器 limit 设成 36GB,被 OOM 是必然的。这个坑在把 HBase 搬进容器时几乎人人踩一遍。7.2 句柄和线程数:两个廉价但致命的限制too many open files和unable to create new native thread这两类错误,单看都是单机问题,但在批量场景下会同时爆发,因为它们的触发条件往往是同一个业务高峰。RegionServer 的线程数可以粗略估算:hbase.regionserver.handler.count(默认 30,高并发场景常调到 100 以上) 各个后台线程池 每个 HDFS pipeline 的 DataStreamer GC 线程。一个 handler 数 200 的 RegionServer,线程总数破千很常见,而ulimit -u或者容器里的pids limit可能是 1024。这个限制平时不显眼,写入高峰一来就撞墙。ulimit -n # 建议不低于 65535 ulimit -u cat /proc/pid/limits ls /proc/pid/fd | wc -lls /proc/pid/fd | wc -l这个数字要定期看趋势。如果它在几天内从几千缓慢涨到几万,那是句柄泄漏,和批量掉线是两件事,但会在同一个时间点一起发作。8. 止血与根治:一份按时间尺度划分的处置清单8.1 十分钟内能做的三件事故障正在进行时,目标不是找到根因,而是让集群别继续恶化。我一般按这个顺序:降低写入压力。停掉批量导入任务、暂停离线计算、必要时用 HBase 的 Quota 功能对特定用户或表做写入限流(2.x 版本支持得比较好)。这一步最有效,因为它同时缓解了 GC、WAL、磁盘、ZK 四个方向。确认 Master 是否还活着。如果 Master 也被拖垮了,那 Region 的重新分配会停滞,集群会进入所有 Region 都不可用的状态,这时候要优先保 Master,把负载降下来让它喘气。不要急着重启 RegionServer。批量掉线时重启 RS 会让它立刻承接大量 Region 的 open 请求,叠加 WAL split,反而更容易再挂一次。等负载降下来、Master 完成 Region 分配之后再考虑。这三步的共同逻辑是:批量掉线的现场,减载比修复更值钱。8.2 一周内该做的参数与容量修正故障过去之后,按根因做针对性调整。下面这张表是我自己集群的基线,具体数值要根据规模调:参数调整方向理由zookeeper.session.timeout与 ZK 服务端maxSessionTimeout对齐消除截断,让配置真正生效ZK 服务端tickTime/maxSessionTimeout适度上调并滚动重启给 GC 留出容错窗口hbase.regionserver.restart.on.zk.expire视情况开启会话过期后自愈,减少 Region 搬迁hbase.regionserver.handler.count按并发量与线程上限反推避免线程数撞上系统限制hbase.hregion.memstore.mslab.enabled开启减少内存碎片,显著降低 Full GC 概率hbase.hregion.memstore.flush.size结合 Region 数上调减少小 flush,降低 compaction 压力hbase.hstore.blockingStoreFiles适度上调避免写入被 StoreFile 数量卡死JVM 收集器G1 合理MaxGCPauseMillis把长停顿拆成短停顿dfs.datanode.max.transfer.threads确认不低于 4096避免 WAL 写入被拒单机 Region 数压到可接受范围降低 MemStore 总量与 GC 压力这张表里最容易被忽略的是最后一行。前面所有参数都是调,只有 Region 数是设计。一个 180 Region 的 RegionServer,你把所有参数都调对,它也只是从经常掉变成偶尔掉;压到 80,才是从根上解决问题。8.3 长期:把批量掉线变成几个可观测的数字经历过一次之后,就该把当时靠人肉翻日志才能拿到的信息变成监控指标。我自己会在 RegionServer 上固定采集这几项:negotiated timeout的实际值,在启动时打印到监控里,任何一次配置变更都能立刻看到。ZK 服务端的avg_latency和outstanding,这是 ZK 自身健康的先行指标。JVM 的 STW 停顿 P99,注意是停顿而不是 GC 耗时,这两个经常不是一个数。WAL sync 的 P99 延迟,这是 HDFS 写入路径是否健康的直接体现。RegionServer RPC 队列长度,它比 CPU 使用率更能反映真实压力。进程 FD 数量和线程数量,趋势比绝对值重要。还有一个特别值得做的动作:主动演练。找非高峰时间,故意 kill 掉一个 ZooKeeper 节点、故意把一块盘的 IO 打满、故意让一台机器的时钟漂移,然后观察集群的反应和你监控上的表现。演练一次的成本远低于真实故障,而且它会暴露出一堆平时看不见的假设——比如你可能以为 Master 会自动切主,实际上因为 ZK 地址配置不全,它卡住了。8.4 我自己的三个检查习惯最后说几个纯经验的东西,都是踩坑踩出来的。第一,先看时间再看内容。任何一次批量掉线,我会先在纸上画出时间轴,把 Master、RS、ZK 三份日志里的事件按秒标上去,谁在前谁在后一目了然。很多争论(是 GC 导致的还是 ZK 导致的)在这张纸面前会立刻消失。第二,不要相信配置里写了就是生效了。zookeeper.session.timeout会被截断,ulimit会被 systemd 覆盖,-Xmx会被容器 limit 卡住,hbase-site.xml会有多份。凡是关键参数,一定要从运行时的证据里确认一遍:日志、/proc、JMX,哪个都行,就是别信配置文件。第三,批量掉线的复盘一定要落到下次怎么更快定位上,而不是下次注意。前者产出的是监控项、检查脚本、演练计划,后者什么都不会留下。我自己维护了一个排查清单脚本,一键收集上面提到的四类材料并打上时间戳,平时觉得它没用,真出事的时候,它能把前二十分钟的手忙脚乱压缩成两分钟。
