Pulsar Function输入输出topic能否相同？是否属于反模式？

首先给出明确结论：这种用法不是通用意义上的反模式，但在你描述的场景下属于不良实践，存在多个可预见的风险，更推荐用拆分Topic的方案实现相同逻辑。

同Topic方案的核心风险 #

• 无限循环风险：如果没有做严格的消息特征过滤，你的Function会消费到自己写回Topic的已转换消息，反复执行转换逻辑，最终产生大量无效消息占满集群存储和带宽。要规避这个问题，你必须在消息属性中新增专属标记位，例如添加msg_status: raw标记原始未处理消息，msg_status: processed标记已转换消息，Function仅消费带msg_status: raw的消息。
• 资源浪费：同一个Topic同时存储原始、已转换两类消息，存储成本直接翻倍，同时所有下游消费端（包括你在用的Cassandra Sink）都需要额外执行过滤逻辑才能拿到自己需要的消息，会消耗不必要的计算资源。
• 运维难度提升：出现消息丢失、重复消费、数据错误等问题时，你无法通过Topic维度直接区分消息所处的处理阶段，必须逐消息查属性才能定位问题，排查效率会大幅降低。

适用同Topic方案的特殊场景 #

只有当你需要实现消息的原地增强（比如给所有消息补全统一的元数据字段，且仅补全一次）、且Topic本身的消息量级非常小的时候，才适合用同Topic的方案，否则都推荐拆分Topic。

你的场景最优实现方案 #

拆分两个独立Topic：

1. 原始消息Topic：接收上游未处理的消息，作为Pulsar Function的输入源
2. 处理后消息Topic：接收Function转换后的消息，作为Cassandra Sink的唯一输入源
   该方案完全规避了上述所有风险，逻辑分层清晰，无论资源消耗还是运维成本都远低于同Topic方案。

如果受业务限制必须使用同Topic方案，必须严格落实以下校验规则：

• 所有消息必须带明确的状态标记，Function消费端配置自定义过滤器，仅处理未转换的原始消息
• 开启Pulsar Function的幂等写入配置，避免同一条消息被重复转换写入
• Cassandra Sink的过滤逻辑做多重校验，避免脏数据写入数据库

内容的提问来源于stack exchange，提问作者Saverio Guzzo