实时流处理实战：引擎选型、架构设计与排障全指南

这个标题我盯了很久。做数据这行这些年，几乎每个季度都会收到类似的业务诉求——“我们要上实时数仓”“我们要做实时大屏”“这个报表能不能别等T+1了”。但真上手做的时候，就会发现“实时数据流处理”这几个字背后，藏着大量边界模糊、选型纠结、上线踩坑的问题。这篇文章就结合我个人的实战经验，把一个完整的实时流处理项目拆开揉碎，从概念、引擎选型、架构设计、代码实现，一直到上线后的监控排障，一次讲透，希望能给正在做技术选型或正在流处理泥潭里挣扎的朋友一点参考。

1. 先搞清楚：流处理中的“实时”到底指什么

1.1 无界数据才是流处理的真正舞台

我刚接触流处理时有个误区：以为流处理就是把原来跑批的数据改成每秒钟跑一次。后来才明白，流处理和批处理最本质的差异，在于数据形态。

批处理面对的是有界数据——数据已经全部到齐，存在表里静止不动，你想扫几遍就扫几遍。而流处理面对的是无界数据——事件像水流一样持续不断地涌过来，永远没有“全部到齐”的那一刻。

这个区别听起来简单，实际影响巨大。有界数据你可以先排序再计算，可以回溯任意时间点，数据迟到也无所谓，反正都在表里。但无界数据不行，它天然就是乱序的、迟到的、永不停歇的。你在做统计时，永远要面对一个灵魂拷问：“这个窗口到底关不关？还有没有数据会来？”

所以实时流处理的第一课，不是学API，而是建立一个世界观：你在处理的是一条永远在流动的河，而不是一潭静止的湖水。

1.2 三种“实时”的差别：很多人混为一谈

“实时”这个词被用滥了。实际上，业务方说的实时和你能交付的实时，往往不是同一个东西。

• 离线批处理：T+1甚至T+2，今天的数据明天才能看到。这是传统的跑批模式。
• 准实时（近实时）：分钟级延迟，通常是微批（Micro-batch），每几十秒甚至几分钟攒一批数据再处理。Spark Streaming的典型模式就是这种。
• 真实时（流式）：毫秒到秒级延迟，事件一到就处理，Flink这类引擎逐条处理或极小窗口处理。

这三者的差别，决定了你整个技术选型和架构设计的方向。我见过很多项目，业务方说要“实时大屏”，实际上分钟级刷新完全够用，结果技术团队为了做毫秒级延迟，投入了大几倍的开发和运维成本，最后发现根本没这个必要。

反过来也有。之前做一个风控项目，要求对高频异常交易做秒级阻断，这种场景下用微批就是灾难，你的批处理窗口还没跑完，资金已经出去了。

判断标准很简单：问清楚数据的业务时效要求，如果延迟30秒可以接受，那准实时方案成本能低很多；如果延迟必须控制在3秒以内，那就老老实实上真流处理引擎。

1.3 和批处理、微批处理的直观对比

用一张表把关键差异列一下：

这个对比能帮你在项目初期快速对齐期望，避免后面因为“实时”的定义扯皮。我个人现在做需求评审时，第一个问题永远是：你能接受的端到端延迟到底是多少秒？

2. 流处理的核心机制拆解：时间、水位线与窗口

2.1 用事件时间而不是处理时间：一个迟到的订单案例

流处理引擎处理事件时，有两个时间概念非常容易混淆：事件时间（Event Time）和处理时间（Processing Time）。

处理时间，是数据到达处理引擎时，机器当前的时间。事件时间，是数据本身携带的业务发生时间，比如用户下单的时间。

大多数新手刚上手时都喜欢用处理时间，因为不用考虑乱序，代码也好写。但一旦对数据准确性有要求，处理时间就会翻车。

我举一个真实的例子。某电商平台做实时销售统计，用户在23:59:58下单成功，这笔订单的数据因为网络抖动，在00:00:03才到达Flink作业。如果用处理时间统计，这笔订单会被算到第二天0点的那一分钟窗口里，导致前一天最后一分钟销售额少了这笔，第二天第一分钟又凭空多了一笔。对财务来说，这就是数据错误。

用事件时间就不存在这个问题。事件时间是根据订单携带的23:59:58来归属窗口的，不管数据几点到，它都属于前一天最后一分钟。这才是数据集团队要的统计口径。

所以实时流处理的第一原则：能用事件时间就别用处理时间。这是无数人用血泪换来的经验。

2.2 水印（Watermark）：给“迟到”画一条线

事件时间好用，但引入了一个新问题：你怎么知道某个窗口的数据都到齐了？对于无界数据流，你永远不知道哪条数据是最后一条，所以引擎需要一种机制来判断“等到什么时候算结束”。

这个机制就是水印（Watermark）。水印本质上是一个时间戳的边界线：表示“早于这个时间的数据应该都到了，如果还没到，大概率是迟到了”。

比如说，你设置水印为“当前收到的最大的事件时间减去10秒”。这意味着引擎认为，比最新事件时间早10秒以上的数据都已经到达，可以触发窗口计算了。而在这10秒内迟到的数据，还能被容忍和接受。

水印设置多少是关键。设太短，等待时间短，延迟低，但乱序数据容易被丢掉，统计结果不准。设太长，窗口关闭得晚，延迟增高，但能容忍更多的乱序。

实际项目中，我一般根据业务重流量来估算：比如订单事件99%能在5秒内到达，那水印可以设为5秒或略高一点。如果业务要求尽量不丢数据，那就延长水印，同时用后面要讲的侧输出（Side Output）机制兜底。

2.3 窗口类型的选择逻辑

流处理里的窗口，决定了你按什么维度聚合数据。常见的三类窗口，各有各的适用场景：

• 滚动窗口（Tumbling Window）：固定大小，互不重叠，比如每5分钟统计一次。适合做周期性的聚合报表。
• 滑动窗口（Sliding Window）：固定大小，但有重叠，比如每5秒滑动一次、窗口大小1分钟。适合做趋势变化分析，你会发现每5秒刷新出来的近1分钟数据是连贯变化的。
• 会话窗口（Session Window）：不固定大小，根据活跃间隙切分，比如用户连续操作超过30秒无新事件，就认为会话结束。适合做用户行为分析。

选窗口类型的核心逻辑，是看业务对统计粒度的要求。这里有一个常被忽略的点：滑动窗口的每一条数据会落入多个窗口，导致计算量成倍增加。比如窗口1分钟、滑动1秒，每条事件要参与60次窗口计算。如果数据量很大，这种窗口对资源消耗非常明显，需要做好资源预估。

3. 引擎选型：Kafka Streams、Spark Streaming和Flink如何取舍

3.1 三个主流引擎的真实差异

我在做技术选型时，被问得最多的就是：到底该用Flink、Spark Streaming还是Kafka Streams？这个问题没有标准答案，但可以给一套非常实用的判断逻辑。

首先说Flink。它是真正意义上的流处理引擎，事件时间、状态管理、精确一次语义（Exactly Once）都是流处理里最完善的。它的内存状态管理能力和Checkpoint容错机制，让它在大规模复杂流计算场景下几乎是首选。代价是学习曲线陡，运维复杂度高，YARN/K8s上跑起来一堆配置要照顾。

然后是Spark Streaming。它本质上是微批——Spark的分布式计算引擎天生是为批处理设计的，流处理是模拟出来的。它把数据流切成一个个小批次，每个批次执行一次Spark任务。好处是生态成熟，和Spark SQL、MLlib集成顺畅，公司里已有Spark技术栈的话上手快。坏处是延迟下限受限，通常秒级起步，你很难做到100毫秒级别的响应。

最后是Kafka Streams。它不是独立集群，而是一个Java库，嵌在你的应用进程里。它直接从Kafka里读数据、处理、再写回Kafka。轻量、部署简单、无需额外运维集群，特别适合Kafka生态内的一些ETL、实时聚合场景。但它只适合做纯粹的Kafka到Kafka的计算，要和外部系统深度交互时，能力就比较有限。

3.2 选型决策表：从需求反推技术栈

我经常给团队推荐一个非常粗暴的决策矩阵：

这套决策表不是绝对权威，但它能帮你在一开始就排除掉明显不合适的选项。我个人的默认推荐是：如果预算允许、团队能啃下来，优先考虑Flink。因为流处理的复杂场景你早晚会遇到，用Flink一步到位，省得后面从Spark Streaming迁到Flink，那是更痛苦的过程。

3.3 消息队列选型不能忽略

引擎选完了，但别忘了上游的“水龙头”——消息队列。绝大多数实时流处理项目的入口都是消息队列，最常用的自然是Kafka，但其他选项也有存在的理由。

Kafka的吞吐量和消息回溯能力是它成为流处理标配的原因。你可以随时从某个offset重新消费数据，这在故障恢复时非常关键。而像Pulsar这种后来者，在存算分离、多租户隔离上更先进，但生态上还是比Kafka差一些。

如果项目规模不大、延迟要求又不高，用RabbitMQ或者RocketMQ也完全可以，关键是看它们和你的流处理引擎之间的连接器是否成熟。我记得之前在项目里用过一个不太常见的消息队列，Flink官方没有连接器，只能自己写Source，开发周期直接多了一周。所以做选型时，一定要先去查一下目标引擎对这个消息队列的官方支持情况，千万不要等到开发了才发现连接器是社区贡献的、还不稳定。

4. 从0到1搭一个实时订单风控链路：实战记录

4.1 业务需求与技术指标拆解

纸上谈兵说了这么多，来看一个我实际做过的项目：某电商平台的实时订单风控，核心需求是识别“高频下单异常行为”。

业务方给的原始需求很简单——“如果某个用户在一段时间内频繁下单，就把他的订单标记为风险订单，推送给运营确认”。但技术不能只到这个程度，必须把需求拆解成可执行的技术指标。

我最终和业务对齐出的完整需求是：在10秒内，同一用户提交订单次数大于等于5次，触发风控告警；端到端延迟不超过5秒；吞吐量按峰值预估支持每秒1万条订单事件；告警数据可以重复消费，方便后续回溯分析。

这里插一句，和业务对齐指标的过程比想象中要难。业务方最初说“一段时间”，但这个“一段”到底多长？5秒还是10秒？如果定义得太短，误报率会很高；太长又可能漏掉真正的风险。最后是拉上运营团队，统计了历史正常用户的下单间隔分布，才定下10秒这个阈值。

4.2 端到端架构和各层职责

架构设计遵循尽量简化的原则，整条链路只有四层：

• 数据源层：订单服务在用户提交订单时，把订单事件以JSON格式发送到Kafka的ods_orders这个Topic。这里有一个细节：消息必须带上业务时间字段，作为后面事件时间统计的依据。
• 消息层：Kafka负责削峰填谷和消息缓存，Topic设置3个分区，冗余因子设置3。
• 计算层：Flink消费Kafka里的订单消息，执行窗口聚合和风控规则判断。结果写到Kafka的另一个Topic。
• 输出层：风控告警服务消费Kafka里的结果Topic，写库并触发运营系统的告警通知。

这个架构看起来简单，但每层都经过了实际验证。尤其是Kafka的分区数，一开始我只设置了1个分区，Flink消费的时候发现并行度提不上去，吞吐只有预期的三分之一。把分区数调成3并且把Flink作业并行度也调成3之后，才把吞吐拉回来。这个坑后面还会细说。

4.3 Flink SQL实现核心规则

项目用的是Flink 1.15版本，Flink SQL已经足够成熟，完全可以用SQL实现这个风控逻辑，不用写DataStream API的Java代码。核心逻辑分三段：

第一段，建Kafka源表。注意用WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND声明水印，这样即使订单事件延迟到达，也能按事件时间正确归属窗口：

sql复制CREATE TABLE orders (
  order_id BIGINT,
  user_id BIGINT,
  amount DECIMAL(10, 2),
  status STRING,
  order_time TIMESTAMP(3),
  WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'ods_orders',
  'properties.bootstrap.servers' = 'localhost:9092',
  'properties.group.id' = 'flink-risk-group',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'json'
);

scan.startup.mode这里我故意设置成earliest-offset而不是latest-offset，原因是风控测试阶段需要消费到历史数据来判断规则是否合理。等到正式上线时，我会改成latest-offset，避免作业启动时把积压的旧消息全部处理一遍。

第二段，建告警结果Kafka表：

sql复制CREATE TABLE alert_sink (
  user_id BIGINT,
  order_cnt BIGINT,
  window_start TIMESTAMP(3),
  window_end TIMESTAMP(3)
) WITH (
  'connector' = 'kafka',
  'topic' = 'dwd_order_alert',
  'properties.bootstrap.servers' = 'localhost:9092',
  'format' = 'json'
);

第三段，执行风控统计SQL。按事件时间开10秒滚动窗口，按用户分组统计下单次数，用HAVING过滤出次数超过阈值的记录：

sql复制INSERT INTO alert_sink
SELECT
  user_id,
  COUNT(*) AS order_cnt,
  TUMBLE_START(order_time, INTERVAL '10' SECOND) AS window_start,
  TUMBLE_END(order_time, INTERVAL '10' SECOND) AS window_end
FROM orders
WHERE status = 'CREATED'
GROUP BY
  user_id,
  TUMBLE(order_time, INTERVAL '10' SECOND)
HAVING COUNT(*) >= 5;

整段SQL不到30行，却实现了实时窗口聚合和阈值过滤，这是传统Java开发完全没法比的效率。这里有一个实际生产中的考量：如果风控规则经常变，比如阈值从5改成8，SQL是动态修改比较麻烦。这种情况下可以考虑把阈值参数放到配置中心，通过Flink的配置参数动态绑定，或者改用DataStream API把规则做成可配置的。不过对于一次性固定的规则，SQL就是最优解。

4.4 参数配置的默认值与调优起点

SQL写完了，作业跑起来之前，有一堆配置需要确认。很多新手在本地IDE里跑通了SQL，一上生产就各种故障，问题往往就出在这里。

首先是Checkpoint配置。Flink的容错完全依赖Checkpoint，但默认是关闭的。必须显式开启，并且设置间隔。间隔太短，比如5秒一次，频繁做快照会严重影响性能；太长，比如10分钟一次，故障恢复时丢的数据和重放的工作量都很大。我的经验是60秒一次作为起点，高峰期再根据实际表现调整。

其次是重启策略。生产环境千万不要用默认的重启策略，否则作业遇到异常会无限重启。我会固定配置为固定延迟重启，最多尝试3次，间隔10秒：

yaml复制execution.checkpointing.interval: 60s
execution.checkpointing.mode: EXACTLY_ONCE
execution.checkpointing.min-pause: 30s
restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 3
restart-strategy.fixed-delay.delay: 10s
state.backend: rocksdb
state.backend.rocksdb.memory.managed: true

最后是状态后端。这个项目状态量不大，用HashMap或RocksDB都可以。但如果状态量上到GB级别，一定选RocksDB，否则GC就会成为杀手。

5. 端到端延迟到底能做到多少：指标拆解与调优思路

5.1 把“延迟”拆开看：采集、传输、计算、输出

业务方问“延迟多少”，你不能简单地回答“3秒”。因为端到端延迟是整条链路所有环节耗时的总和，你得能拆开来看。

实时流处理项目的端到端延迟，大体由四段组成：

• 采集延迟：业务系统产生事件到消息被写入Kafka之间的耗时。
• 传输延迟：消息在Kafka内部复制、分区、落盘的时间。
• 计算延迟：Flink读取消息到输出结果消息的耗时，包括等待窗口触发的时间。
• 输出延迟：结果被下游系统消费并写入数据库、推送给前端的时间。

每一段的优化手段完全不同。采集延迟你要优化SDK上报逻辑；传输延迟要看Kafka的配置和负载；计算延迟要看Flink的并行度、窗口大小和状态访问；输出延迟则取决于下游目标系统的写入性能和是否需要批量写入优化。

如果排查延迟问题时，只看整条链路的平均值，你根本定位不到瓶颈在哪。正确的做法是每跳之间打点，把每一段的耗时单独记录下来。

5.2 我实测的一组延迟数据

这里分享一组我在压力测试环境实测到的数据，仅供参考，不同机器配置差距会很大：

这个数据说明一个非常重要的结论：对于有窗口的聚合计算，端到端延迟的“地板”基本由窗口大小决定。你设了10秒的滚动窗口，就算Flink执行再快，一条中午12:00:01的事件也要等到12:00:10窗口关闭才能输出结果。

所以如果你想压低延迟，但业务上又要做聚合，方法只有一个：缩短窗口时间，或改用滑动窗口。但滑动窗口的计算量又会上来，这就需要结合吞吐量做权衡。

5.3 吞吐优先还是延迟优先

不同业务对吞吐和延迟的权衡完全不同。比如做实时大屏，延迟多一点少一点没人感知得到，但吞吐千万不能拉胯，数据积压了告警大屏就瞎了。而做实时风控，延迟就是生命线，哪怕降低一点吞吐也要保证毫秒级响应。

调优时要先明确你的优先级。通常来说，以下参数会同时影响吞吐和延迟：

• 并行度：并行度越高，吞吐越大，但作业管理和状态备份的开销也越大，过多的并行度反而会增加调度延迟。
• 缓冲大小：Flink每个TaskManager内部都有输入输出缓冲，缓冲越大吞吐越好但延迟越高。
• 窗口大小：和延迟直接相关，上面已经说过。
• Checkpoint间隔：间隔越短，故障恢复越快，但频繁快照会抢CPU资源。

我现在做调优的套路是：先定延迟上限，然后反推窗口和并行度，再压测看吞吐，不够就把并行度往上加，加到某个点吞吐不再上升就查瓶颈是Kafka还是Flink还是下游。这套流程走下来，绝大多数项目都能在半天内摸到性能天花板。

6. 最容易翻车的三个点：乱序、状态与背压

6.1 乱序和迟到数据：allowedLateness与侧输出配合

即使设置了水印，实际情况中依然会有数据错过水印边界而迟到。以我们的风控项目为例，用户下单可能发生在移动端弱网环境，消息在本地队列等了几十秒才上报。这时Flink的窗口已经触发了，消息才姗姗来迟。

处理迟到的数据，有两条路径。一是用allowedLateness，它允许窗口在触发后继续等待一小段时间，在这段时间内到达的迟到数据会被重新计算；二是用侧输出（Side Output），把已经迟到的数据单独扔到一个输出流，后续用另一个链路去补算。

我的经验是两条路径同时使用。allowedLateness设为10秒，覆盖常规的网络抖动；超过10秒的极端迟到数据，走侧输出到Kafka的延迟队列，由离线修正任务每天跑一次，重算后修正报表。这样既保证了实时性，又留了一条兜底路径。

这里有个容易误解的点：allowedLateness不是越多越好。设置过长，窗口结果迟迟不产出，还会因为状态无法清理导致内存持续增长。一定结合你的业务数据到达分布来定，并用侧输出来兜极端场景。

6.2 状态后端和Checkpoint的配置陷阱

Flink的状态管理是它区别于其他引擎的核心能力之一，但也是配置陷阱最多的地方。

最大的坑是Checkpoint频繁超时。项目早期，我的Checkpoint设置的是30秒一次，数据量一大，每次快照还没做完下一次又来了，状态后端忙不过来，Checkpoint连续失败，最后作业直接重启。后来我把间隔改成60秒，并且设置了min-pause为30秒——这个参数的意思是两次Checkpoint之间至少间隔30秒，防止快照堆积。加上状态后端用RocksDB，降低大状态快照对JVM堆内存的冲击，问题才解决。

第二个坑是状态大小没有监控。状态在Flink里是隐式增长的，刚开始几百MB，跑几天几个GB，你毫无察觉，等发现时GC已经把整个作业拖垮了。建议从第一天起就给状态大小加监控告警，超过阈值就查是状态没有清理、还是key的粒度太粗导致状态膨胀。

6.3 背压：流处理系统的“堵车”信号

背压是流处理系统里最常见的性能现象。简单说，就是下游处理不过来，把压力传导到了上游。形象点说，就像高速公路上前方堵车，后面的车只能一辆辆减速排队。

Flink Web UI上能直接看到背压状态，Source端和中间算子的inPoolUsage和outPoolUsage指标如果持续高于90%，基本可以判定存在背压。

背压的根源通常有三个：一是下游算子并行度不足，处理速度跟不上输入速率；二是某个算子里有耗时操作，比如访问外部数据库、调用远程API；三是状态访问瓶颈，RocksDB的随机读太慢拖了整体吞吐。

排查时我的顺序是：先看是哪个环节背压，再开火焰图看耗时分布。之前有个项目就是因为在Flink里调了一个外部HTTP接口做数据富化，每个事件都等一次网络往返，背压直接顶到Source。后来把接口调用改成批量异步查询，用Async I/O把吞吐拉回来了。

7. 上线后的监控与一次真实故障排查

7.1 关键监控指标清单

实时流处理作业上线后，没有监控就等于裸奔。我经历过凌晨3点被电话吵醒，迷迷糊糊打开面板发现作业已经重启了12次的惨痛经历，从那以后，监控这块我是宁可多不可少。

以下是我每个流处理项目必配的指标：

• 作业存活状态：作业是否在运行，是否频繁重启。
• Kafka消费延迟：消费组Lag，这个指标最直观地反映数据是否积压。
• Checkpoint状态：成功还是失败，耗时多久，间隔是否正常。
• 背压状态：各算子的背压比例。
• 处理速率：每秒处理多少条事件，和正常基线对比。
• 状态大小：状态后端存储量是否异常增长。
• 端到端延迟：通过埋点数据计算整条链路的延迟。
• 输出结果数：比如风控告警数量，数量突变说明计算可能有问题。

这些指标最好能配置到统一的告警平台，一旦超过阈值就通过电话、短信、企业内部IM同时通知。

7.2 一次延迟飙高的完整排查链路

说一次实际出过的故障。某个周五下午，监控面板突然飘红，Kafka消费Lag从0涨到10万，Flink作业延迟从2秒飙到30秒。业务方的告警推送也延迟了，运营电话直接打到我手机上。

我当时的排查链路是这样的：

第一步，看Flink作业状态。作业还在运行，没有重启，但背压指标显示某个算子已经是100%高背压。这说明问题在作业内部，而不是Kafka源端挂了。

第二步，看瓶颈算子的日志。发现有大量Connection timeout异常。定位到问题算子是一个调用外部用户画像服务的异步I/O算子，下游服务在下午开始超时。

第三步，验证根因。我去看了下游服务的监控，发现该服务的响应时间在下午就出现明显攀升，CPU使用率接近100%。对比发布记录，发现这个服务下午刚发过一个新版本。

第四步，回滚与恢复。下游服务回滚后，Flink作业的背压肉眼可见地消退，消费Lag在10分钟内被追平，延迟恢复正常。

这个案例的关键点在于：流处理作业的延迟问题，根源有时候根本不在流处理引擎内部，而在下游依赖服务。这也是我把“外部依赖调用”列为最易翻车点的原因。所有离开Flink进程的网络调用，都可能成为背压触发器，必须要有超时、重试、熔断和降级机制，缺一个都不行。

7.3 升级与状态迁移的注意点

最后说一个容易被忽视的运维问题——作业升级。

流处理作业不是离线任务，改完代码重启就行。流处理作业往往带着状态，直接重启可能导致状态丢失或者状态不兼容。

做作业升级时，我的经验是：如果逻辑变更不涉及状态结构变化，可以走无状态升级，简单重启加载最新Checkpoint就行。但如果改了聚合逻辑或状态类型，就必须让作业停止前先执行Savepoint（手动快照），然后基于Savepoint恢复新版本作业。在迁移前一定要在测试环境先跑一遍完整流程，确认旧状态能被新作业正确加载。

还有一个坑：升级后检查点路径是否保存正确。有一次我升级作业后，新作业一直找不到Savepoint路径，折腾了大半天才发现路径少了个前缀。

最后分享一点我的个人体会

做了这么多年数据相关的工作，我最大的感受是：实时数据流处理的技术门槛其实没那么高，难的是对业务逻辑的理解、对数据特征的敬畏、对细节的执着。Flink可以让你快速写出一个跑起来的作业，但一个稳定扛住生产流量的系统，需要对水印、状态、背压这些机制有真正深入的理解。尤其当你遇到乱序、数据倾斜、状态膨胀这些“自然规律”时，经验和敬畏能让你少走很多弯路。

如果你正准备搭一套实时流处理系统，我特别建议先从小场景切入，把数据模型、延迟指标、监控体系跑通，再逐步扩展到更多业务线。不要一上来就搞一个大而全的实时数仓，那可能是你踩过最大的坑。流处理系统是越跑越能看到问题的系统，先活下来，再优化，这是我一直坚持的原则。