字节数据中台 top="1033">背景
动机
字节数据中台 top="1387">需求定义
使用下面的表格将具体场景定义清楚。
相关工作
在启动自研之前，我们评估了两个比较相关的方案，分别是 Flink 和 Kafka Streaming。Flink 是我们之前生产上使用的方案，在能力上是符合要求的，最主要的问题是长期的可维护性。在公有云场景，那个阶段 Flink 服务在火山引擎上还没有发布，我们自己的服务又有严格的时间线，所以必须考虑替代；在私有化场景，我们不确认客户环境一定有 Flink 集群，即使部署的数据底座中带有 Flink，后续的维护也是个头疼的问题。另外一个角度，作为通用流式处理框架，Flink 的大部分功能我们并没有用到，对于单条消息的流转路径，其实只是简单的读取和处理，使用 Flink 有些“杀鸡用牛刀”了。另一个比较标准的方案是 Kafka Streaming。作为 Kafka 官方提供的框架，对于流式处理的语义有较好的支持，也满足我们对于轻量的诉求。最终没有采用的主要考虑点是两个：
设计
概念说明
框架架构
整个框架主要由 MQ Consumer, Message Processor 和 State Manager 组成。
实现
线程模型
每个 Task 可以运行在一台或多台实例，建议部署到多台机器，以获得更好的性能和容错能力。
每台实例中，存在两组线程池：
两类 Thread 的性质分别如下：
StateManager
在 State Manager 中，会为每个 Partition 维护一个优先队列（最小堆），队列中的信息是 Offset，两个优先队列的职责如下：
MQ Consumer 会周期性的检查当前可以 Commit 的 Offset，情况枚举如下：
KeyBy 与 Delay Processing 的支持
因源头的 Topic 和消息格式有可能不可控制，所以 MQ Consumer 的职责之一是将消息统一封装为 Event。根据需求，会从原始消息中拼装出 Event Key，对 Key 取 Hash 后，相同结果的 Event 会进入同一个队列，可以保证分区内的此类事件处理顺序的稳定，同时将消息的消费与处理解耦，支持增大内部队列数量来增加吞吐。
Event 中也支持设置是否延迟处理属性，可以根据 Event Time 延迟固定时间后处理，需要被延迟处理的事件会被发送到有界延迟队列中，有界延迟队列的实现继承了 DelayQueue，限制 DelayQueue 长度, 达到限定值入队会被阻塞。
异常处理
Processor 在消息处理过程中，可能遇到各种异常情况，设计框架的动机之一就是为业务逻辑的编写者屏蔽掉这种复杂度。Processor 相关框架的逻辑会与 State Manager 协作，处理异常并充分暴露状态。比较典型的异常情况以及处理策略如下：
监控
为了方便运维，在框架层面暴露了一组监控指标，并支持用户自定义 Metrics。其中默认支持的 Metrics 如下表所示：
线上运维 Case 举例
实际生产环境运行时，偶尔需要做些运维操作，其中最常见的是消息堆积和消息重放。对于 Conusmer Lag 这类问题的处理步骤大致如下：
消息重放被触发的原因通常有两种，要么是业务上需要重放部分数据做补全，要么是遇到了事故需要修复数据。为了应对这种需求，我们在框架层面支持了根据时间戳重置 Offset 的能力。具体操作时的步骤如下：
总结
为了解决>
