请描述在 Flume 架构中，针对数据流传输过程中可能出现的丢失（loss）与重复（duplication）问题，通常有哪些处理策略和技术手段？

回答思路

1. 【回答框架 1】针对数据丢失，Flume 的 Source 和 Sink 基于事务机制：Channel 持久化（如 File Channel）可防宕机丢失，Sink 在事务提交后才确认事件，保障 at-least-once 语义。若需更强保障，可配置可靠的 Agent 链路并监控 Channel 容量告警。
2. 【回答框架 2】针对数据重复，Flume 默认事务可能造成事件重放，产生重复。可通过在 Sink 侧实现幂等写入（如将事件 ID 写入目标存储唯一键）或在上游对事件附加全局唯一 ID，在消费端点做去重。
3. 【回答框架 3】使用拦截器可在 Source 端清洗或标记重复事件，但去重需依赖外部存储（如 Redis 或数据库）维护已处理 ID，Flume 自身不提供全局去重。
4. 【回答框架 4】可结合 Flume 的 Channel 容量、Sink 批量提交及监控告警（如 Ganglia）来动态调整，减少因背压或故障导致的丢失风险。
5. 【回答框架 5】若严格要求不丢不重，可设计 Flume 配合消息队列（如 Kafka）实现端到端至少一次语义，由下游做幂等消费。
6. 【关键点 1】Flume 通过 Source-Channel-Sink 事务提供至少一次语义，File Channel 持久化降低宕机丢失风险。
7. 【关键点 2】重复源于故障重放，需要下游幂等或外部去重机制。
8. 【关键点 3】可靠性需平衡吞吐与配置，结合监控和告警完善。
9. 【关键点 4】端到端不丢不重需借助外部存储或消息队列实现。
10. 【关键点 5】拦截器只能预处理，无法保证全局去重。
11. 【易错点 1】误以为 Flume 事务能保证精确一次，实际为至少一次，重复需另行处理。
12. 【易错点 2】忽略 Channel 持久化配置，使用内存 Channel 在宕机时易丢失数据。
13. 【易错点 3】将去重完全依赖 Flume 本身，缺乏外部状态，导致重复事件污染下游。