请说明 Apache Flume 中事务机制的工作流程，并阐述该机制如何保障数据在传输过程中的可靠性。

回答思路

1. 【回答框架 1】Flume 的事务机制围绕 Channel 展开，核心组件是 Source 和 Sink。Source 在写入 Channel 前开启事务，将采集到的 Event 批量放入 Channel 的 PutList；事务提交后，数据才正式写入 Channel 并对外可见。若写入过程中发生异常，事务回滚，本次数据不会进入 Channel。
2. 【回答框架 2】Sink 在从 Channel 取数时同样开启事务，将 Event 移入 TakeList；当 Sink 成功将数据发送到下游（如 HDFS、Kafka）后，事务才提交，并删除 Channel 中的对应数据。若下游写入失败，事务回滚，Event 仍保留在 Channel 中，可被再次尝试发送。
3. 【回答框架 3】可靠性保证依赖事务的原子性：要么整个批次成功写入或读取并提交，要么完全回滚，避免部分成功导致的丢失或重复。此外，Channel 本身具有持久化能力（如 File Channel 将数据落盘），配合事务的回滚机制，即使 Agent 进程重启，未提交的 Event 也能恢复。
4. 【回答框架 4】在实战中，应根据下游可靠性和吞吐要求选择 Channel 类型：Memory Channel 速度快但非持久，进程崩溃会丢数据；File Channel 或 Kafka Channel 可持久化，但吞吐和配置复杂度不同。事务大小（如 batchSize）影响吞吐与一致性窗口，需结合场景权衡。
5. 【关键点 1】事务分为 Put 事务（Source 写 Channel）和 Take 事务（Sink 读 Channel），各自独立管理。
6. 【关键点 2】提交成功才使数据可见或删除；任何一步失败均回滚，保证不丢失、不重复。
7. 【关键点 3】持久化 Channel（File、Kafka）结合事务，可跨进程恢复未提交数据，进一步提升可靠性。
8. 【关键点 4】数据可靠性级别受 Channel 类型和配置影响，Memory Channel 存在崩溃丢失风险。
9. 【易错点 1】混淆事务的提交时机，误以为 Source 写入 Channel 即算成功，实际需等到事务提交。
10. 【易错点 2】认为 Flume 事务能保证端到端精确一次，实际在异常场景下可能出现重复投递（如 Sink 提交后下游确认失败），需要下游幂等处理。
11. 【易错点 3】忽视 Channel 的持久化能力，默认所有 Channel 都具备完全不丢失的可靠性。