哈特利夫 Java 一面：广告归因、订单幂等与消息积压

《面试题目》

1. 如何介绍自己的经历，以及广告项目中遇到的主要难点？
2. 广告业务如何进行归因，设备标识、深度归因、拉新和拉活之间是什么关系？
3. 如何保证转化订单上传的幂等性？
4. 高并发归因场景怎样限流，怎样防止 Kafka 消息持续积压？
5. 海外投放获取不到设备标识时，如何完成广告归因？

《参考解析》

订单上传先定义一次业务动作

重试、重复回调和重复消费都可能让同一订单被处理多次。可用业务订单号与事件类型共同标识一次转化事件，在持久化层设置唯一约束。接收方需要把去重记录和业务更新放在同一个事务边界内，避免已经记作成功但业务未写入。退款、支付成功等不同事件不能仅因订单号相同就全部合并。

积压要分清生产与消费

观察消息进入速率、消费速率及各分区积压，再定位消费者是卡在数据库、外部接口，还是某些异常消息的重复处理。增加消费者数量能否有效，还取决于分区数量和处理逻辑。需要同一订单有序时，分区键与消费端执行顺序都要保持一致，不能扩容后把业务顺序打乱。

没有设备标识时先明确能拿到什么

先区分安装归因、站内转化和再营销，列出平台实际提供的回传或来源信息，再确定可以计算的归因结果。拿不到稳定的跨端标识时，不应承诺逐用户精准串联；可以解释汇总归因与明细归因的差别，以及回传延迟、去重和窗口如何影响报表。原帖只简略提到了平台归因方案，没有提供完整实现过程。