靖远热电的智能电表数据通过物联网平台采集，如何保证数据的一致性和实时性？请设计一个数据采集与处理方案，包括数据采集层、传输层、处理层及数据丢失处理？

1) 【一句话结论】通过分层设计（采集层校验+协议、传输层可靠协议+QoS、处理层流处理+实时处理、数据丢失层缓存+重传），从采集到处理全链路保障数据一致性与实时性。

2) 【原理/概念讲解】老师口吻，解释各层核心概念：
数据采集层：智能电表通过Modbus/DTU协议上报数据，需添加CRC校验和（类似“身份证号校验”，确保采集时数据无错）；
传输层：采用MQTT协议（QoS1保证至少一次送达，QoS2保证恰好一次），结合设备资源限制，避免TCP的高延迟（TCP适合后台批量同步，MQTT适合实时场景）；
处理层：使用Kafka作为消息队列缓冲，Flink实时处理流数据（类似“流水线加工”，低延迟完成清洗、聚合等操作）；
数据丢失处理：设备端本地缓存未发送数据（队列长度限制为10条），传输失败后重传；处理层通过消息重试（如重试3次）和补偿任务（从Kafka重试消费）恢复丢失数据。

3) 【对比与适用场景】

传输层技术	定义	特性	适用场景	注意点
TCP	面向连接的可靠传输协议	提供确认、重传、流量控制，确保数据不丢	对数据完整性要求极高，延迟可接受（如后台批量同步）	延迟较高，不适合实时性要求高的场景
MQTT QoS1	MQTT协议的保证至少一次传输	服务器确认消息，客户端收到确认后可删除，未确认则重传	智能电表等资源受限设备，实时性要求高，允许少量重复	需要考虑重传成本，适合低延迟场景
MQTT QoS2	MQTT协议的保证恰好一次传输	双向确认，确保消息只送达一次	对数据一致性要求极高（如关键告警数据）	延迟略高于QoS1，设备资源消耗稍高

4) 【示例】
最小方案示例：

• 采集层：智能电表每5秒通过Modbus协议上报电表读数（含CRC校验和），校验失败则丢弃并重试；
• 传输层：电表通过DTU设备连接物联网平台，采用MQTT协议（QoS1）将数据发送至Kafka主题“electricity_data”；
• 处理层：Kafka消费者（Flink StreamTask）实时消费数据，进行异常值过滤、每分钟总用电量聚合，并写入ClickHouse实时数据库；
• 数据丢失处理：电表端本地缓存未发送数据（队列长度10条），传输失败后重传；Flink处理时若检测到消息丢失，触发补偿任务从Kafka重试消费。

5) 【面试口播版答案】
“面试官您好，针对靖远热电智能电表数据采集的一致性与实时性需求，我设计了一个分层方案：

• 数据采集层：智能电表通过Modbus协议每5秒上报数据，并添加CRC校验和，确保采集时数据无错；
• 传输层：采用MQTT协议（QoS1）保证至少一次送达，结合设备资源限制，避免TCP的高延迟；
• 处理层：数据先进入Kafka缓冲，再由Flink实时处理（低延迟），同时写入实时数据库；
• 数据丢失处理：设备端缓存未发送数据（队列长度10条），传输失败后重传；处理层通过消息重试和补偿机制恢复丢失数据。
  这样从采集到处理全链路保障数据一致性与实时性。”

6) 【追问清单】

• 问题1：为什么选择MQTT而不是TCP？
  回答要点：MQTT资源消耗低（适合智能电表），QoS1保证实时性，而TCP延迟高，不适合实时场景。
• 问题2：如何保证数据一致性？
  回答要点：采集层CRC校验，传输层MQTT QoS1保证至少一次，处理层Flink事务处理（如exactly-once语义）。
• 问题3：设备故障时如何处理？
  回答要点：设备端本地缓存数据，故障恢复后重传；处理层通过状态管理（如Flink checkpoint）保证处理一致性。
• 问题4：实时性如何衡量？
  回答要点：从电表上报到处理结果写入数据库，延迟控制在1-2秒内（通过MQTT低延迟+流处理框架优化）。

7) 【常见坑/雷区】

• 坑1：忽略采集层校验，导致数据错误未被捕获；
• 坑2：用UDP传输数据，导致数据丢失无法恢复；
• 坑3：处理层采用批处理（如Hadoop），无法满足实时性要求；
• 坑4：数据丢失处理未设计本地缓存，设备故障时数据丢失无法恢复；
• 坑5：未考虑QoS选择，QoS2虽然可靠但延迟高，不适合资源受限设备。