中间件场景题实战：消息不丢、TongWeb部署与Nginx审计排查

这阵子在整理中间件场景题，发现一个规律：现在面试官不太爱问“Kafka是什么”“Nginx有什么用”这种背诵型问题，而是直接扔一个场景——“线上消费变慢了，你怎么排查？”“TongWeb 8能部署静态资源吗？”“Nginx审计记录到底开没开？”如果你只背概念，大概率会卡在第二句话。这篇《中间件场景题归纳（二）》，就是把这些高频场景拆开揉碎，按我自己的排查习惯重新整理一遍。内容偏实战，适合准备中间件岗位面试的同学，也适合平时做中间件运维和迁移部署的同行参考，照着做至少能帮你少踩几个坑。

1. 消息中间件“消息不丢”场景：面试连环追问背后的配置逻辑

1.1 一个看上去很简单，其实藏了三个环节的硬问题

“你怎么保证消息不丢失？”这是消息中间件场景题里最常出现的一道题。很多人第一反应是“开启confirm模式”，或者“把acks设置成all”，然后面试官追问一句“那Broker端不丢应该怎么处理？”就卡住了。问题在于，消息从生产到消费要经过三个环节：Producer发送到Broker、Broker持久化、Consumer拉取并提交位点。任何一个环节掉链子，都可能丢消息。

我总结过一套可以背但更要理解的回答顺序：

• Producer端：设置acks=all，要求所有ISR副本都写入成功才算发送成功；开启重试机制并调大retries；同时打开幂等性，避免重试造成重复消息。
• Broker端：主题副本数建议设置成replication.factor>=3，并配置min.insync.replicas=2，也就是至少有两个同步副本在，才允许对外提供服务。配合unclean.leader.election.enable=false，防止“非同步副本”被拉上Leader位置造成消息丢失。
• Consumer端：关闭自动提交，改为业务处理成功后手动提交offset。如果处理消息和提交位点不是原子的，还要设计好重入逻辑，至少做到处理接口幂等。

这种分类回答的好处是，面试官能明确看到你的知识有边界感，并不是把网上的配置抄一遍。真正做生产系统的时候，我们也会按这个三段式去核对配置。

1.2 事务消息到底在解决什么问题

如果面试继续往深走，会问“Kafka事务和RocketMQ事务消息有什么区别”。这个问题容易翻车，因为Kafka的事务更侧重于“分区级别原子写入”，而RocketMQ的事务消息解决的是“本地数据库操作与消息发送的一致性”。我给一个实际做过的订单场景：用户在系统里下单，先写订单库，再发一条“订单已创建”的消息给积分服务。如果先发消息再写库，消息发出去了事务回滚，下游就多了一条脏数据；如果先写库再发消息，消息发送失败又不知道要不要补偿。

RocketMQ的事务消息方案是把“本地事务”和“消息发送”绑在一起：先发送一条半消息，服务端收到后不立即可见；本地事务执行成功后再提交消息，让消费者能看到；如果本地事务执行时间过长，Broker会反向回查本地事务表确认状态。这套机制里，真正落地的关键是“事务状态表”和“回查接口”，消息中间件只是一个协调者。

Kafka在0.11之后也提供了事务API，但它更多用来解决“读取-处理-写入”这种流处理场景中的原子性，比如从A主题读数据、处理后写入B主题和本地状态，期间如果挂掉不会出现一部分写了、一部分没写的情况。两者解决的问题并不完全一样，能讲清楚这个区别，已经是比较高的分数了。

1.3 别把“不丢”当成绝对指标

我在生产环境见过一个典型误区：不管什么业务，统一要求消息不能丢，于是把所有配置都调到最严格状态，结果集群吞吐量下来了，成本也高了。这是典型的不理解“可靠性是有代价的”。

举例来说，一个内部日志采集链路，丢失几百条日志最多就是报表少几个点，不影响核心交易。对这条链路，我会把acks设置成1，副本数保持2，确保不阻塞常规写入即可。而订单支付状态变更这种消息，才需要acks=all、min.insync.replicas=2，甚至加上事务消息。所谓“不丢”，是在业务容忍度、成本和性能之间取一个平衡点。面试场景里主动说出这层意思，比背一堆参数值效果要好很多。

2. 国产中间件部署的隐性坑：宝兰德、金蝶、东方通TongWeb迁移实录

2.1 迁移前的兼容性检查清单

近两年很多项目从Oracle WebLogic、IBM WebSphere迁移到国产中间件，宝兰德BES、金蝶Apusic、东方通TongWeb是出场率最高的三款。很多团队拿到部署任务后第一反应是“把war包直接丢进去”，然后被各种莫名其妙的报错拖住好几天。我在一次从WebLogic迁移到TongWeb 8的项目里，光迁移评估就花了两个工作日，但后面部署非常顺。

迁移前一定要做四件事：第一，确认JDK版本。国产中间件对JDK版本通常要求比较严格，比如TongWeb 8.0常用JDK 1.8或11，高版本JDK可能不兼容部分类库。第二，梳理Servlet/JSP规范版本，确认应用里有没有使用WebLogic私有API或WebSphere特有的类。第三，检查第三方依赖包，尤其是javax.*还是jakarta.*的切换，这决定war包能不能直接用。第四，核对JNDI数据源配置，很多老项目把数据源配置在WebLogic控制台里，换到国产中间件后必须重新建立连接池。

2.2 类加载器冲突是最大的拦路虎

迁移过程中我踩到最多的坑是类加载冲突。现象很典型：应用启动不报错，一访问某个接口就NoSuchMethodError或ClassNotFoundException，排查半天发现是war包自带的Spring库版本和容器lib目录下的版本不一致。Tomcat的类加载原则是“父加载器优先”，容器自带的类会先被加载，于是应用的类就永远用不上。

国产中间件都保留了类似的类加载机制，但配置方式不一致。有的需要在conf目录里改classloader模式，有的需要把应用设为parent-last，让应用自己的lib目录优先加载。我的建议是，war包尽量不携带容器已有的API类，如果确实带，就要确认容器的委托模式。你可以先在测试环境用-verbose:class启动应用，看关键类到底是从哪个jar包加载的，避免靠猜。

另外，部署war包时静态资源404，在国产中间件上也特别常见。这个不一定是中间件的问题，很可能是war包内部结构不对，web.xml里的servlet-mapping把默认Servlet覆盖掉了。我们会在下一节专门说TongWeb 8部署静态资源这件事，这里先提一个排查顺序：先浏览器直接访问一个静态文件路径，如果404，再用curl访问应用上下文根路径，如果应用能访问而静态文件不行，基本就是默认Servlet映射问题。

2.3 宝兰德、金蝶、东方通各自容易忽视的基础配置

三款中间件虽然都遵循Java EE规范，但管理控制台和配置项有很大差异。我用一个表格整理一下自己在部署中的常用配置点：

这张表不是说你必须背下来，而是提醒你，部署前先把“控制台入口、配置文件位置、授权文件机制”三个问题搞清楚。国产中间件的报错信息有时候不太友好，比如许可证过期可能只打印一行“License Error”甚至不打印，导致你以为是端口被占用或代码问题。遇到这类情况，先看一眼授权文件日期，能节省大量定位时间。

3. TongWeb 8部署静态资源：一道送分题怎么被答成送命题

3.1 先别急着回答“能”或“不能”

“东方通TongWeb 8可以部署静态资源吗？”这个问题在客户现场出现的频率远比我预想的高。单看这个问题，答案确实简单：TongWeb是Java应用服务器，静态资源当然能部署。但为什么那么多人会问？因为实际场景里，对方真正想问的往往不是“能不能”，而是“怎么部署最合适、能不能直接放一个目录进去、要不要打包成war”。

我一般会先反问三个问题：静态资源是纯静态页面还是和Java接口共用端口？文件规模有多大，后续会不会做CDN或Nginx缓存？有没有域名和HTTPS证书规划？这些问题不搞清楚，直接回答“能”，后面大概率会被性能问题打回来。

3.2 方案一：打成war包放进TongWeb

如果静态资源量不大，就是公司内部系统的一些HTML、CSS、JS、图片，最简单的方式是打成war包部署。war包内部结构如下：

code复制static-site.war
├── index.html
├── css/
│   └── style.css
├── js/
│   └── app.js
├── images/
│   └── logo.png
└── WEB-INF/
    └── web.xml

这里有个很容易漏的细节：WEB-INF/web.xml可以没有很多配置，但最好显式声明welcome-file，例如index.html。否则通过http://ip:9060/static-site/访问时，可能返回目录列表或者404。如果只有纯静态资源，根本不需要写Servlet，只需要保证war包最外层是这些静态目录。

部署过程跟在TongWeb控制台里部署普通应用一样：登录控制台，选择“部署应用”，上传war包，指定应用上下文路径，比如/static。启动后访问http://ip:9060/static/就能看到页面。这种方式的优点是和应用共用TongWeb实例，管理简单，不需要额外装Nginx；缺点是静态请求也要经过Java容器的线程池，并发高时占资源。

3.3 方案二：利用TongWeb默认静态资源映射

TongWeb本身可以配置静态文件目录，在conf/server.xml的Host节点下增加Context配置，把磁盘上的某个物理目录映射成访问路径。类似这样：

xml复制<Host name="localhost" appBase="webapps"
      unpackWARs="true" autoDeploy="false">
    <Context path="" docBase="/data/static-file" reloadable="false"/>
</Host>

把静态资源放到/data/static-file目录下，访问时通过应用根路径直接对应到文件。这样不用打war包，上传文件后立刻生效，适合只做简单文件服务。但要注意两点：第一，生产目录建议不要放在TongWeb安装目录内，避免升级中间件时被误删；第二，如果配置了应用上下文，path最好不要设为/，和正常应用冲突会非常难排查。

这种方式的性能上限仍然受限于Java容器本身。如果静态资源日访问量在百万级别，我建议还是把静态资源放到Nginx上，让TongWeb专注处理动态接口。TongWeb前面挂Nginx做动静分离，是客户现场最常见的方案，也最不容易出问题。

3.4 方案对比和选择建议

这道题的答案本身不值钱，值钱的是你能在现场快速评估出对方真实需求，然后给出对应的方案。面试里问这个，其实也是想看你会不会“先拆解问题再给答案”。

4. Nginx审计记录“查不到”场景：日志开关的完整排查链路

4.1 审计记录开没开，别只翻access_log

“怎么查看Nginx中间件的审计记录是否开启？”这个问题在合规审计场景里特别常见。很多运维同学拿到需求后，第一反应是去/var/log/nginx/目录下找access.log，发现文件不存在，就回答“没开”。这个判断经常是错的。

Nginx的正常访问日志配置项叫access_log，但access_log的路径可以自定义，甚至日志内容也可以不写到文件而直接发到远程日志服务器。所以“没找到文件”只能说明默认路径下没有日志，不能说明审计功能没开。正确做法是看生效配置里到底写了什么。

4.2 用nginx -T看永久生效配置

Nginx最常用的排查命令是nginx -T，它会输出当前完整的生效配置，包括主配置文件和include进来的所有子配置。执行：

bash复制nginx -T | grep access_log

如果输出里有access_log /data/logs/nginx/access-main.log main;，说明审计日志已经配置到了指定路径。如果输出为空，再看是否存在access_log off;，如果明确写了off，那就是主动关闭的。

这里有个容易被忽略的情况：log_format配置。Nginx里access_log可以指定日志格式名称，比如：

nginx复制log_format audit '$remote_addr - $remote_user [$time_local] "$request" '
                 '$status $body_bytes_sent "$http_referer" '
                 '"$http_user_agent" "$http_x_forwarded_for" $request_time';

access_log /var/log/nginx/audit.log audit;

如果access_log指定的格式名在配置里找不到，Nginx会启动失败，所以通常不会出现这种情况。但如果你修改了日志格式，忘记重载配置，新格式不会生效。所以查看审计记录是否开启，不能只看文件，还要核对配置和实际写入的字段。

4.3 验证日志是不是真的在写

很多时候配置文件里确实写了access_log，但日志半天不更新。可能的原因有几类，我按出现频率排一下：

• Nginx没有reload。修改配置后需要执行nginx -s reload，否则旧配置还在跑。
• 日志目录不存在或Nginx工作进程没有写权限。可以执行nginx -T确认路径，再用ls -ld看目录权限。
• 日志缓冲区没刷。Nginx有buffer=参数，日志先写入内存再批量落盘，正常情况下不会导致丢数据，但如果你用tail -f观察，会感觉日志不是实时出来的。

验证审计日志是否真正开启，最直接的办法是主动制造一条访问请求，然后去日志里看有没有对应记录：

bash复制curl http://127.0.0.1/health-check
tail -n 10 /var/log/nginx/audit.log

如果curl请求有返回，但日志文件里看不到记录，优先检查是否有非200请求被错误处理，以及是不是用了条件日志，比如if ($request_uri !~ ...)。某些审计场景需要记录所有请求，那就不要设置过滤条件。

4.4 审计记录留痕的最小配置

合规审计一般对日志内容有明确要求：时间、来源IP、访问的URL、状态码、响应时间。我给一个能直接抄的配置段：

nginx复制log_format audit_json escape=json
'{"time":"$time_local",'
 '"remote_addr":"$remote_addr",'
 '"method":"$request_method",'
 '"uri":"$request_uri",'
 '"status":$status,'
 '"body_bytes":$body_bytes_sent,'
 '"request_time":$request_time,'
 '"xff":"$http_x_forwarded_for"}';

access_log /data/nginx/audit.log audit_json;

用JSON格式的好处是后续可以直接对接日志采集系统，比如Logstash或Loki，解析字段不需要写正则。配置好后执行nginx -t检查语法，再nginx -s reload。最后用curl验证一条日志，格式正确再交给审计同事。

5. 中间件优化面试的“三板斧”之外：连接池、线程池、JVM参数该怎么串起来

5.1 面试官想听的不是“调大参数”

“中间件性能上不去，应该怎么优化？”这道题的经典错误答案，是把连接池调大、线程池调大、JVM堆调大。这些说法本身没错，但如果只是三个孤立的参数，面试官会觉得你没有实际调优经验。真正的优化套路，应该是“观察指标—定位瓶颈—修改配置—压测验证”的闭环。

我一般回答这类问题时会先表达一个观点：优化前必须有一个可量化的目标。比如“单机吞吐量从1000 QPS提升到3000 QPS”，或者“接口P99延迟从800ms降到200ms”。没有目标就调参数，是碰运气。有了目标之后，所有动作都能被验证。

5.2 工具组合拳：top、jstack、jstat、Arthas

中间件表面上一大堆，真正调优时常用的工具并没有多少。Linux系统层面，top和vmstat看CPU、负载、上下文切换；Java中间件层面，jstack看线程卡在哪个方法，jstat -gcutil看GC频率和堆占用；线上排查接口慢，我会用Arthas的trace命令，直接看一次调用里时间花在哪一层。

举个例子：某次Tomcat线程池被打满，大量请求排队。我先用top -Hp看到CPU不高，说明不是计算密集；然后用jstack抓线程堆栈，发现大量线程阻塞在DataSource.getConnection()；最后检查数据库连接池监控，发现连接一直被占用不归还，核心代码里少了一个finally关闭连接的逻辑。这个问题靠“调大Tomcat线程池”也能暂时缓解，但根因不修，连接池迟早还会爆。

5.3 可以抄作业的中间件优化SOP

我自己的习惯是固定四步：

1. 压测建立基线。用wrk或JMeter对接口做一次固定并发压测，记录QPS、P99延迟、CPU、内存、GC情况。
2. 从外部往内部看。先看网络带宽和TIME_WAIT连接数，再看Nginx或网关层连接数，然后看应用中间件线程池和JVM，最后看数据库连接池和慢SQL。
3. 定位到具体资源瓶颈。连接池满大概率是连接泄漏或后端处理慢；线程池满大概率是某个上游调用超时；GC频繁大概率是对象分配过快或堆设置不合理。
4. 一次只改一个参数。改完重新压测，对比基线数据，确认有效再继续下一个参数。

很多面试题都会问“你们中间件做过哪些优化”，按这个SOP答，能很自然地带出你解决过的一个真实问题。比单纯背“我调了-Xmx”要有说服力得多。

6. 模糊场景题的第一反应：先把问题“翻译”成可执行的排查计划

6.1 越模糊的问题，越要追问式翻译

面试和实际工作都会遇到一种情况：对方抛出一个极其模糊的问题——“系统卡死了，你去看一下”。这句话信息量几乎为零。但很多人接到这种指令后，会直接冲上服务器敲命令，最后敲了一堆命令也不知道在看什么。

我的第一反应永远是把问题翻译成几个具体维度：

• 现象：是页面打不开，还是接口响应慢？是所有用户都受影响，还是部分用户？
• 时间：从什么时候开始？是持续卡死还是间歇性卡顿？和最近一次发版、重启、变更有没有时间重叠？
• 范围：影响的是单个中间件实例，还是整个集群？有没有其他服务同时报错？
• 可恢复性：重启中间件能恢复吗？还是重启后过一段时间又卡死？

这一通追问下来，原本一个“系统卡死”的模糊问题，已经变成了“某台Nginx从10:03开始5xx比例飙升，只有特定接口受影响，重启进程后恢复，20分钟后再现”。这才是排查的真正起点。

6.2 用时间线把现象变成证据链

排查中间件问题时，我习惯先画一条时间线，不是画流程图，而是把自己收集到的零散信息按时间排序。比如：

• 10:00 发布新版本，更新了一个Dubbo接口的调用参数
• 10:03 Nginx开始出现大量502
• 10:05 运维收到告警，Tomcat线程池活跃数超过300
• 10:10 人工重启Tomcat，服务恢复
• 10:30 问题再次出现

这种时间线一旦列出来，根因范围会迅速收敛。在这个例子里，重点怀疑对象就是新版本中Dubbo调用参数变化导致下游超时，线程池被慢请求占满，最终Nginx返回502。如果没有时间线，你可能会先去查Nginx配置、查防火墙规则，浪费大量时间。

6.3 临时恢复与根治分开，不要在慌的时候两头堵

线上出问题时有一个原则我记得特别牢：先恢复业务，再排查根因。很多新手把这两个动作混在一起，一边想着重启服务，一边还在翻代码，结果业务中断时间更长。

正确做法是：如果重启能临时恢复，先把服务恢复起来，同时保留现场信息，比如jstack、top、日志文件再加一个进程快照。如果问题反复出现，就不要再重启了，而是用Arthas或jmap保留一份堆快照，方便后面分析。保留完现场再重启，既不影响业务恢复，也不至于事后没有任何线索。

6.4 我处理这类问题的个人习惯

处理模糊场景题，比技术更考验的是“提问能力”和“记录能力”。我自己现在遇到任何问题，哪怕最后只花了五分钟解决，也会在文档里写清楚三件事：问题的原始描述是什么、我最终定位到了哪个根因、中间有哪些没用的操作被排除掉了。这样下次同样问题再来，我花五分钟翻文档就能解决，而不是再花两小时重新踩一遍坑。

这个习惯也影响了我准备面试的方式：不再背场景题答案，而是把每个场景当成一次真实故障来推演，按照“翻译问题—收集信息—临时恢复—根治—复盘”这个顺序去组织语言。中间件这个领域，原理和框架一直在变，但排查问题的方法论是比较稳定的，掌握好这套思路，换哪个中间件都不慌。