企业官网建设流程全解析

做消息中间件选型的时候，十个人里有九个会把Kafka放进候选名单，可真到了生产环境，能把它用明白的团队其实不多。太多人把它当成一个“能用的消息队列”，挂了半年，遇到消息堆积、延迟飙升、数据对不上账，回头才发现自己对Kafka的理解还停留在“一个Topic就是一个大管道”的层面。我这些年帮别人救过不少类似现场，最后几乎所有问题都能归到几个底层机制上：分区、副本、偏移量、页缓存。这篇文章是“Kafka原理剖析”的第一篇，不讲怎么装、怎么调参，而是把Kafka最核心的设计思路和运行机制一层层拆开。适合正准备深入学习Kafka的开发者，也适合那种“用了一段时间但总感觉哪里没想透”的运维和架构师。

1. 先看整体设计：Kafka不是一个“传统消息队列”

1.1 从“队列”切换到“提交日志”视角

很多困惑的根源在于用错了模型。RabbitMQ这类传统消息队列，本质是一个“分发中心”：消息进来，路由到不同队列，消费完之后就从队列里删除。Kafka不是这个路子，它本质上是一个分布式提交日志——所有消息追加写到日志尾部，谁想读就从指定位置自己往后读。

我经常打一个比方：传统MQ是快递站，包裹到了要按地址分拣、签收后就不在了；Kafka是一条流水传送带，每个工位（消费者）旁边都有一份完整的货物记录单，记录单不会被抽走，你自己记住“我看到第几件了”就行。所有消费者看到的是同一份历史，只是各自的阅读进度（offset）不同。

这个差异直接决定了你能拿Kafka干什么：因为它不消费即删除，所以可以做离线重放、可以做多个独立业务同时订阅同一份数据流、可以追溯历史。代价是它不像传统MQ那样天然支持“点对点私聊式”的消息队列语义，所有“队列效果”其实都是消费组模型模拟出来的。

1.2 理清Topic、Partition、Offset、Replica的关系

这四个概念基本就是Kafka的“四梁八柱”，搞不清楚后面全部白搭。

• Topic（主题）：逻辑上的消息分类，相当于数据库里的表名。
• Partition（分区）：一个Topic被水平切分成若干个分区。分区才是真正的物理存储单元，每个分区是一个独立的、有序的日志文件。
• Offset（偏移量）：分区内消息的编号。从0开始递增，每条消息在所属分区内有唯一offset。
• Replica（副本）：每个分区会有多个副本，副本之间一主多从，保证某个Broker挂掉时数据不丢。

我见过不少刚接触Kafka的人，把Topic理解成“一个大队列”，把Partition理解成“队列里的多个线程”，其实不够准确。更贴切的说法是：一本大手册被拆成了很多分册（Partition），每个分册里的页码连续（Offset），而每个分册又有若干本复印件存在不同资料室（Replica）。消费者读的时候，大家各拿各的书签，互不干扰；同一本分册同一时刻只允许一个人在读——对应同一个分区只能被消费组里的一个消费者实例消费。

为什么Kafka把并行度放在“分区”而不是“消息”上？因为只有分区这个粒度才能同时保证并行和顺序：分区内天然有序，分区之间天然无关。这是一个贯穿全文的核心思想，后面讲生产端、消费端和顺序性，全都绕不开它。

2. 存储引擎：Kafka为什么写得快、读得也快

2.1 顺序写盘与页缓存：把磁盘压榨到极限

我看很多文章上来就吹Kafka“每秒百万级吞吐”，但不说清楚这百万级从哪来的。Kafka的第一个底层秘密，是它把所有写入都做成了顺序追加（Append-Only）。机械硬盘的顺序写能达到100MB/s甚至更高，而随机写可能只有几百KB/s——差了三个数量级。SSD虽然改善了随机写，但顺序写在延迟稳定性上依然有优势。Kafka让每个分区只往后追加消息，不做随机更新，相当于避开了磁盘最痛的点。

第二个秘密是操作系统页缓存（Page Cache）。Kafka没有在JVM堆里自己搞一套复杂缓存，而是直接把消息写进操作系统的页缓存。好处有两个：一是读写都能命中OS级的缓存，速度非常可观；二是堆内存压力小，避免了大堆带来的GC长暂停。很多人的经验是Broker所在机器物理内存越大越好，但JVM堆并不用给太大，剩下的内存全部留给OS做页缓存，性能反而更好。

第三个秘密是零拷贝。消费端读消息时，传统做法是从磁盘读到内核缓冲区、再拷贝到用户态、再从用户态拷回内核态发给网卡，来回绕。Kafka在支持的情况下会走sendfile（Java里对应FileChannel.transferTo），让内核直接把磁盘数据发到网卡，跳过两次用户态拷贝。实测下来，对于大消息量的拉取，这个优化的收益非常明显。

提示：在设计磁盘布局时，如果有多块磁盘，一定要把log.dirs配置成多目录逗号分隔。Kafka会把不同分区分摊到不同磁盘，把单盘IO扛住。否则你机器再好，也会被一块盘的顺序写能力卡死。

2.2 分段日志与稀疏索引：消息是怎么被快速定位的

继续说读取。一个分区如果不做任何处理，消息全堆在一个文件里，要读offset=500万那一条，只能从头扫到尾，这谁受得了？所以Kafka做了两件事：分段和稀疏索引。

每个分区的日志不是一个大文件，而是被切成一串Segment段。Segment文件命名很规矩，以该段第一条消息的offset作为文件名，比如00000000000000000000.log、00000000000003706880.log。默认情况下，单个Segment写到1GB（log.segment.bytes）就滚动生成新段。这样文件大小可控，清理老数据时直接删除整段文件，操作效率极高。

定位一条消息时流程是这样：先根据目标offset，在内存里对segment文件名列表做二分，找到目标在哪个段；然后打开这个段对应的索引文件（.index），再二分一次找到不大于目标offset的最近索引项；拿到这条索引项记录的物理位置，顺着日志文件往后顺序扫描几条，就定位到了目标消息。

这里有两个细节值得注意。第一，索引文件不是每条消息一条索引，而是稀疏索引，默认大概每写4KB才落一条索引项（log.index.interval.bytes）。所以二分找到的只是一个“最接近的位置”，后续还要在日志段里做少量顺序扫描。稀疏索引节省了大量索引空间，扫描代价又足够小，属于典型的空间换时间的合理折中。第二，索引文件是可变长的——顺序写、只追加，所以也可以用零拷贝或者mmap来读写，性能非常好。

所以Kafka“读得快”并不是说它能像Redis一样O(1)命中，而是它的查找路径设计得非常平滑：文件分段二分 + 稀疏索引二分 + 小范围顺序扫。这个设计思路后来被我用到自研存储上，效果同样不错。

2.3 日志清理：Kafka的“回收站”不只是删数据

Kafka不做消费删除，那数据越积越多怎么办？答案在log.retention系列配置。最常见的是按时长和按大小清理：超过log.retention.hours（默认168小时）或者累计大小超限后，直接删除最老的Segment。删除是异步的，以Segment为最小单位，所以老消息的“过期”粒度是分钟级的，不会精确到单条。

除了删除，Kafka还支持日志压缩（Log Compaction）。这个概念容易被忽略，但非常重要：对于键相同的消息，只保留最新一条。为什么需要它？因为Kafka可以做“状态型”的Topic，比如用户的最新资料、配置变更记录。有了Log Compaction，整个Topic就能当做一个可重放的KV存储来用，消费端从头读一遍就能恢复全量状态。我的习惯是，如果业务需要一个“变更事件流”又要随时能恢复最终态，这个特性比再另外搭一套存储要省事得多。

注意：日志压缩不等于事务，它不处理删除时机和并发问题，只是回收历史键。别把它当成数据库的UPSERT用，它的定位是日志领域的最终态收敛。

3. 副本机制：高可用背后的ISR与HW

3.1 从LEO和HW说起

副本机制是Kafka里最容易含糊的部分，但它直接决定了你会不会丢消息。先给两个定义：

• LEO（Log End Offset，日志末尾偏移量）：每个副本自己当前写到的位置，下一条待写入消息的offset。
• HW（High Watermark，高水位）：整个分区组里，所有“正在同步的副本（ISR）”都至少写到的位置。消费者只能读到HW之前的消息，HW之后的消息视为“尚未确认”。

打个比方，leader是主写手，follower是见习抄写员。LEO就是每个人自己抄到哪一行，HW则是所有人（至少是核心名单里的人）都抄到的那一行。对外公布的稿子只能公开到HW这一行，超过了不行，因为万一leader突然出事，抄得慢的follower顶上来时，稿子是不完整的。

所以HW本质是一道安全边界：它把“已经确认一致的数据”和“只有leader自己知道的数据”隔开了。这个设计保证了消费者读到的消息不会在后续选举中被悄悄换掉。

3.2 谁有资格当Leader：ISR与选举

现在问题来了：follower同步慢一点没关系，但慢到什么程度算“掉队”？Kafka用**ISR（In-Sync Replicas，同步中的副本）**这个集合来圈定名单。副本落后太多，就会被踢出ISR。判定标准是replica.lag.time.max.ms，默认30秒：一个follower超过30秒没有追上leader的最新消息，就算不合格。这里有一个历史坑：旧版本还有replica.lag.max.messages，按落后条数判断，结果短时间大量流量涌入时，follower瞬间落后几千条就被误踢出去了，导致集群频繁补副本、忽上忽下。后来Kafka改成纯时间判定，就是为了抗住这种瞬时抖动。这类“短期表象指标害死人”的坑，在分布式系统里太常见了。

当leader挂了，会在ISR里选出新leader。为什么明明有“更完整”的副本却要从ISR选？因为ISR里的副本数据与leader足够接近，选出来不会出现数据“倒退”。如果允许一个滞后很多的副本当leader，虽然它能立刻服务，但它会丢失大量已写入消息，这个风险通常比短暂不可用更严重。生产环境一定要把unclean.leader.election.enable保持为false，宁肯短时间没有leader，也不要选出一个缺数据的leader造成丢消息。

3.3 一个Partition的读写上限由谁决定

很多人理解Kafka水平扩展时有个误区：集群机器加得多，所有Topic就自动变快。实际上，每个Partition的读写都只走它的Leader副本，follower只是被动同步，不承担读写流量。所以单个Partition的吞吐上限，基本上就是这个Leader所在Broker的单磁盘顺序写能力和网卡带宽。

这意味着：Kafka整体并行度来自分区数，而不是Broker机器数量。想要让某个Topic吞吐翻倍，最直接的手段是给它加Partition，让消息分散到更多Leader上。但分区也不是越多越好，每个Partition都对应一堆文件句柄、内存中的元数据、以及重平衡时的调度开销。我见过有人把Partition设到上千个，结果Broker一重启，重平衡和副本恢复能拖垮整个集群。常规经验是：每台Broker上的全部分区数维持在几百到一两千量级，别贪多。

拿实际数据说话：单个Partition在普通SSD上，1KB左右的消息，顺序写基本能到几十MB/s的量级，换算成条数就是每秒几万到十几万条。如果你的业务峰值需求在几十万条每秒，那就需要把Topic切成足够多的Partition，把它摊到多台机器上，而不是指望单机奇迹。

4. 生产者端：你的消息是怎么被发出去的

4.1 分区分配：顺序性是从这里埋下的伏笔

生产者决定一条消息去哪个Partition，规则不复杂：指定了partition字段就按指定来；没指定但有key，就对key做哈希再对分区数取模；key也没有，就用轮询或者黏性轮询（Sticky）在可用分区之间分配。

这个选择看着不起眼，实际上就是顺序性问题的源头。同一key的消息会被哈希到同一个分区，而分区内天然有序，所以只要保证同一业务实体的key一致，消息的处理顺序就得到了初步保障。比如订单场景，把orderId作为key，那么同一订单的所有状态变更一定会进同一个分区，消费端按顺序处理就不会出现“已支付”跑到“已创建”前面这种事。

反过来，如果业务上不在乎顺序、只图吞吐，就尽量不带key，让Kafka走轮询把消息均匀打散。带了key而key的基数又很小，会出现明显的数据倾斜，某些分区忙死某些分区闲死，这是我压测时反复踩过的坑。

4.2 内存缓冲与批量发送：高吞吐的两大功臣

生产端不是来一条发一条，那太浪费网络了。Kafka客户端在内存里维护了一个RecordAccumulator，消息先进缓冲区，按Partition攒成一个个Batch，攒够了再一起发。

两个核心参数：

• batch.size：默认16KB。一个Batch没装满但等太久也不划算，所以还有——
• linger.ms：默认0。意思是“即使Batch没满，也立刻发送，不额外等”。

这个组合很有意思。如果业务测试发现吞吐上不去、请求太密、每条都只有几十字节，那大概率就是Batch始终没攒起来。你可以把batch.size调大到几MB，linger.ms设成3到10毫秒，给消息一点“结伴同行”的时间。注意，linger.ms越大，单条消息的延迟越高，这是一个吞吐与延迟的权衡，别闭着眼调大。

生产端另一个容易被忽略的缓冲区是buffer.memory，默认32MB。所有分区共用这个缓冲区。如果发送速度超过了Broker消费速度，缓冲区满了，生产者send()会阻塞，最多等max.block.ms（默认60秒），超过就抛异常。很多“消息延迟高”的故障，根子其实就在生产端这里：消息不是慢在网络，是压根塞不进发送队列。

4.3 acks与min.insync.replicas：可靠性到底怎么配

消息可靠性的第一个入口是acks参数。我做了个表，方便对照：

acks=all的意思大家容易误解，以为它会等“所有副本”。其实它等的是“ISR里当前所有副本”。如果ISR已经缩小到只剩leader自己，那acks=all实际只等了一个副本，之前的努力全白费。

所以生产环境标准配方是：acks=all+min.insync.replicas=2（Topic有3个副本时）。含义是：至少保证有2个副本同步成功，写入才算成功。这样即使一台Broker宕机，剩下的副本里还有完整数据，不会丢。它的代价是：当ISR因为故障缩小到不足2个时，生产者的写入会直接失败，而不是“带病写入”。这就叫宁可失败，不可丢失。如果你连失败都接受不了，那还得靠Consumer端的重试和幂等兜底。

4.4 幂等与事务：先搞清楚重复从哪来

很多同学看到“消息重复”，第一反应就是加幂等。但你得先理解重复是怎么产生的。最常见的场景是：消息已经写进Leader并同步给了ISR，但返回给生产者的ACK在网络中丢了，于是生产者触发重试，把同一条消息又发了一遍。Broker层面其实看到了两条物理消息。

Kafka的幂等机制（enable.idempotence=true）就是干这个用的。它在发送的每个Batch里带上Producer ID和递增序号，Broker对相同Producer发来的相同序号做去重。它的语义是：单个Partition内、单个Producer会话内，有序且不重复。这是很多人的误区——幂等不是全局消息只消费一次，只是解决生产者重试导致的写入端重复。

真正要跨分区、跨会话做到“恰好一次”，必须启用事务API（transactional.id+initTransactions），让生产端和消费端配合isolation.level=read_committed。但事务是有代价的：吞吐下降、状态管理变重。我的建议是，绝大多数业务根本不需要事务，先把“消费端幂等设计”做好（比如写库时按业务唯一键去重），比在生产端强行上事务性价比高得多。

5. 消费者端：消费组、偏移量与重平衡

5.1 消费组模型：一个分区为什么只能被一个消费者消费

同一个Topic可以被多组消费者同时订阅，互不干扰，这叫发布订阅模式。如果多个消费者实例属于同一个group.id，那就变成了队列模式：消息在组内分摊。核心规则是：一个Partition在同一时刻只会分配给组内的某一个消费者实例。这就是为什么消费者数量超过分区数时，多出来的消费者只会闲着——不是它懒，是没分到活。

这条规则是顺序性的基石。只有分区间并行、单分区内被单消费者独占，才能保证“某分区消息按顺序被同一个人处理”。如果你想提高某个Topic的消费速度，方向有两个：给Topic加分区，或者增加消费者实例（上限等于分区数）。只加消费者不加分区，毫无意义。

5.2 偏移量提交：先提交还是先处理，这是个选择题

消费进度（Offset）由消费者提交到Kafka的__consumer_offsets主题。提交时机决定你面对哪种交付语义。

• 默认自动提交（enable.auto.commit=true，5秒一次）：在poll()返回后定时提交上次拉取的位置。这最容易出问题——我处理一批消息要10秒，但提交已经在上一个5秒周期发生了，那这10秒里处理的这批消息如果没等提交成功就宕机，下次消费就会从旧的offset开始，把这批消息再拉一遍。重复消费就这么来了。
• 手动提交：commitSync()会同步等待提交完成，适合处理完一批再提交，保证“处理完才记进度”。commitAsync()不阻塞但可能乱序，一般在处理完业务后commitAsync()提交，在关闭消费者前用一次commitSync()兜底。

这里本质上是一个二选一：

• 先处理、后提交：处理成功但提交前挂了，重启后重复消费。这是至少一次（At Least Once），不丢但可能重复。
• 先提交、后处理：提交成功但处理前挂了，重启后跳过这批消息。这是最多一次（At Most Once），不重复但可能丢。

Kafka默认的世界是“至少一次”，因为它不允许丢消息。大多数业务也都接受“重复了靠幂等去兜底”。那些号称“正好一次”的，是在消费端做了事务性读取+幂等存储来实现的，不是Kafka本身白给的。

5.3 重平衡：Kafka最让运维头疼的“暂停时刻”

消费组发生成员变化、订阅Topic变化、分区数变化时，会触发Rebalance（重平衡）。老版本的重平衡是全员暂停：协调者把全组所有分区都收回，选一个Group Leader重新分配，分配完再下发。这段时间组内所有消费者都停止消费，数据流动活活“暂停”数秒。分区越多、消费者越多，这个过程越痛苦。

触发重平衡的主动场景还好说，真正烦人的是被动踢出：消费者处理一批消息太久，超过max.poll.interval.ms（默认5分钟），Kafka认为它“失联”了，强制把它T出组并触发重平衡。我们排障时见过好多次：消费端一条消息处理30秒，积压一点就触发了重平衡，重平衡又导致更多人超时，最后雪崩。

现代Kafka给了两个缓解工具。一是CooperativeStickyAssignor（增量协同分配），重平衡时尽量保留原分配，只调整变动部分，而不是全组重来；二是静态成员（group.instance.id），让消费者重启后还是组内的“同一个人”，不触发重平衡。我的经验是：生产环境把分配策略显式配成cooperative-sticky（或按版本选择兼容策略），并把max.poll.interval.ms和单次拉取量max.poll.records做成“处理时间可控”的组合，重平衡发生的概率能下降一个数量级。

5.4 消息延迟高的排查思路

“消息延迟高”几乎是Kafka群里日经问题，热词里也排在最前面。我给一个从生产端到消费端的排查顺序：

1. 生产端卡没卡：先看生产者的发送队列有没有打满。队列打满会导致send()阻塞，延迟直接从毫秒级跳到秒级。其次看linger.ms是不是设得太大，明明业务要低延迟却为了吞吐把等待窗口拉长，这是自相矛盾。
2. Broker侧慢没慢：看网络线程、IO线程是否跑满；看磁盘IO util是否饱和；看是否存在Page Cache长期未命中导致的磁盘读；看GC日志有没有长时间STW。
3. 消费端抢到货没有：fetch.min.bytes默认是1字节，几乎不造成延迟；真正常见的是max.poll.records设得太大，一批拉几千条，单条再慢一点，直接拖垮整个消费线程。
4. 并行度够不够：消费者实例数是否小于分区数？有一部分分区是不是一直没人消费？Topic的热点key是不是导致单分区压力巨大？

每次我按这个顺序排查，基本都能在十分钟内找到瓶颈。大多数“Kafka慢”其实是配置和使用姿势慢，不是Kafka本身慢。

6. 顺序性问题的完整答案（含多线程消费）

6.1 全局有序为什么这么难

先扔结论：Kafka能严格保证的是单分区内有序，不是全局有序。想要Topic内全局有序，只有一条路：让这个Topic只有一个Partition。代价是吞吐直接退化为单机单盘能力，在多Broker集群里等于自废武功。

所以现实世界几乎没有人追求全局有序。大家要的其实是“同一业务主体（同一个订单、同一台设备、同一个用户）的消息有序”。这个诉求用分区机制是完全能解决的。

6.2 按Key分区 + 单分区串行：最常用的保序方案

标准套路是：生产端把业务主键当作key传入，让同一主键的消息哈希进同一个Partition；消费端保证一个Partition在同一时间只有一个线程处理。这两件事缺一不可。

我遇到过一种很常见的翻车：生产端明明传了key，但Topic在创建后中途加过Partition。哈希函数里分区数变了，老key的新消息可能被分到别的分区，原来那条有序链就断了。所以生产场景里Topic一旦建立，Partition数量最好固定，不要在业务流转中随意扩分区。扩分区这种事情，只适合在业务低峰做，并且要接受“扩完以后部分key的顺序屏障失效”这一事实。

6.3 消费端多线程保序的三种落地做法

很多团队说“我消费端用了多线程，怎么顺序乱了？”原因很直接：消费线程poll()拉回来一批消息，分散给多个Worker线程并行处理，Worker们速度不一致，顺序自然乱。解决思路有三种：

1. 单线程拉取 + 单线程处理：最无脑，顺序绝对保证，吞吐增加靠加消费者实例和分区数，不要靠线程。适合大多数业务。
2. 单线程拉取 + 按Partition路由的线程池：消费者线程把消息按分区号塞进不同的本地队列，每个队列配一个专属Worker线程串行处理。这样不同分区并行，分区内顺序不乱。这是目前用下来最均衡的方案。
3. 业务层排序兜底：处理完后把消息按业务序号排序再落库，或者依赖数据库唯一键+依赖约束判断顺序。适合跨分区也无法保证有序的极端场景，复杂度最高。

多线程消费还有一个坑：offset提交。如果批量拉回来的消息被分到多线程处理，Worker们完成时间参差不齐，你按整个Batch提交offset时，可能有消息还没处理完就被提交了。比较稳的做法是：在分区队列里，等一个分区内某个offset对应的消息处理完成后，再提交这个分区已处理的连续offset。很多框架（比如Spring Kafka）帮我们封装了些东西，但原理还是这一套。

7. 从原理回看集群部署与选型

7.1 集群安装最容易踩的3个坑

虽然这篇主讲原理，但部署经验能反过来加深原理理解。按“原理剖析（一）”的篇幅，我挑三个高频坑讲：

1. advertised.listeners配错：listeners是Broker实际监听的地址，advertised.listeners是告诉客户端“你应该连这个地址”的地址。很多人listeners写了内网IP，advertised却没配或者配了localhost，结果客户端永远连不上，报超时。这是Kafka部署的“头号翻车点”。
2. 副本因子小于min.insync.replicas：比如Topic副本数设了1，又全局配了min.insync.replicas=2，那么所有写入全部失败。逻辑上讲得通，但很多人在创建Topic时没看全局默认值，踩坑踩得莫名其妙。
3. num.partitions和default.replication.factor没提前约定：自动创建的Topic默认1副本、1分区，生产直接跑起来，后面想改麻烦得很。建议用脚本创建Topic，显式指定分区数和副本数，别依赖自动创建。

7.2 软硬件配置参考速查表

经常有朋友问“Kafka机器怎么配”，我给一个基于多年实测的参考表，注意这是通用经验，不是唯一答案：

7.3 Kafka适合什么、不适合什么

回到热词里的选型问题：Kafka、RabbitMQ、RocketMQ到底怎么选。原理看完了，答案其实已经浮出水面。Kafka的核心优势是大吞吐、高可扩展、可重放历史数据，最适合日志管道、事件驱动、流计算、数据同步这类“流量大、链路长”的场景。它的短板也很明显：单条消息延迟在毫秒级到十毫秒级，和RabbitMQ几毫秒的低延迟比没有优势；路由能力弱，不支持像RabbitMQ那样灵活的Exchange-Binding路由。

RabbitMQ适合系统内部模块间低延迟、需要灵活路由、消息量又没大到离谱的业务集成。RocketMQ则在功能和吞吐之间做了个很好的平衡，还提供了事务消息能力，而且中文社区和上手成本上有天然优势。选型不需要追热点，需要的是清楚自己那边是“大流量管道优先”还是“低延迟路由优先”，把原理吃透了，这些问题到现场一拍即合。

这几年帮人排查Kafka问题，我越来越觉得，Kafka之所以难，不是因为代码多难写，而是因为它是一个“模型驱动”的系统。绝大多数事故——消息丢失、消息重复、消费阻塞、顺序颠倒——最后都能回溯到我没理解“ISR决定安全边界、Offset决定消费进度、分区决定并行度、页缓存决定性能”这四个基本盘上。把这几个概念在脑子里画成图，配置和异常处理都有了坐标，你就不再是“照着网上教程瞎配”的玩家了。这一篇先讲到这，生产者和消费者的实操细节，包括事务、流处理与监控排障，后面继续拆。