半导体生产过程中产生大量实时数据（如晶圆温度、压力）。请设计一个数据采集与存储系统，确保数据的实时性和一致性，并说明如何处理消费电子旺季（Q4）的数据量激增。
答案
1) 【一句话结论】：采用边缘设备实时采集数据，通过消息队列缓冲，结合实时时序数据库（如InfluxDB）存储核心数据，并同步至分布式对象存储（如S3），通过水平扩展和缓存策略应对Q4数据激增，确保数据实时性（亚秒级延迟）与一致性（最终一致性保障业务可接受范围）。
2) 【原理/概念讲解】：数据采集系统分为三层：
- 边缘层：传感器（如晶圆温度、压力传感器）实时采集数据，通过低延迟协议（如MQTT短连接）传输。
- 传输层：消息队列（如Kafka）解耦设备与后端，缓冲高并发数据，避免数据丢失。
- 存储层：实时时序数据库（如InfluxDB）存储核心实时数据（支持时间序列的写入与查询），历史数据同步至分布式对象存储（如S3）。
实时性通过低延迟传输（MQTT）和实时数据库（亚秒级写入）实现；一致性通过最终一致性（消息队列保证顺序，数据库事务保证关键数据一致性），结合CAP理论，选择CP（强一致性，牺牲部分可用性，适合关键数据）或CA（强一致性+可用性，适合非关键但实时性要求高的数据）。
类比：医院心电监护仪实时记录心率，数据通过无线传输到服务器，服务器用实时数据库存储每个时间点的数据，确保不漏掉任何心跳，高峰期（急诊室）服务器扩容，保证数据不丢失。
3) 【对比与适用场景】：
| 对比项 | 实时数据库（InfluxDB） | 传统关系型数据库（MySQL） |
|---|---|---|
| 定义 | 专为时间序列数据设计，支持高写入速率 | 通用的关系型数据库，支持结构化数据 |
| 特性 | 时间索引、聚合函数、高写入延迟（亚秒） | 事务支持、ACID，写入延迟较高 |
| 使用场景 | 晶圆温度、压力等实时监控数据 | 业务逻辑处理、用户数据存储 |
| 注意点 | 不适合复杂查询，需优化写入性能 | 查询灵活，但写入延迟高，不适合实时 |
4) 【示例】：
系统架构：
- 边缘设备：晶圆温度传感器（每秒采集1次数据），通过MQTT协议发送到Kafka集群。
- 消息队列：Kafka作为缓冲，设置10个分区（每个分区处理不同晶圆数据），支持高吞吐。
- 实时数据库：InfluxDB集群（3节点），配置时间序列数据库，接收Kafka数据，写入速度1万条/秒（Q4扩容至5节点）。
- 分布式存储：S3存储历史数据，定期导出数据（每天）存入S3，保留1年数据。
高峰处理：Q4时，增加Kafka分区（10→20），扩容InfluxDB节点（3→5），Redis作为缓存（临时存储最近1小时数据），高峰时先写入Redis，再异步写入InfluxDB，延迟控制在100ms内。
伪代码（Kafka生产者）：
import pika
import json
from datetime import datetime
def send_data(sensor_id, temp, pressure):
connection = pika.BlockingConnection(pika.ConnectionParameters('kafka-server'))
channel = connection.channel()
channel.queue_declare(queue='semiconductor-data')
message = json.dumps({'sensor_id': sensor_id, 'temp': temp, 'pressure': pressure, 'timestamp': str(datetime.now())})
channel.basic_publish(exchange='', routing_key='semiconductor-data', body=message)
connection.close()
5) 【面试口播版答案】：
面试官您好，针对半导体生产实时数据采集与存储，我设计一个分层系统。首先，边缘层用传感器实时采集数据（如晶圆温度），通过MQTT协议发送到Kafka消息队列，解决设备与后端解耦。传输层用Kafka缓冲，支持高并发，避免数据丢失。存储层分两部分：核心数据用InfluxDB（实时时序数据库），支持亚秒级写入，保证实时性；历史数据同步到S3（分布式对象存储），保留长期数据。为了应对Q4旺季，我们会水平扩展Kafka分区（增加处理能力），扩容InfluxDB集群（提升写入吞吐），并加入Redis缓存（临时存储实时数据，缓解高峰压力），确保数据实时性（延迟控制在100ms内）和一致性（最终一致性，满足业务需求）。这样既能保证日常实时监控，又能应对旺季数据激增。
6) 【追问清单】：
- 问：数据量具体多大？比如Q4数据量是平时的多少倍？
答：假设Q4数据量是平时的3倍，通过水平扩展和缓存策略，仍能保持延迟在100ms内。 - 问：如何保证数据一致性？比如是否需要强一致性？
答：采用最终一致性，消息队列保证数据顺序，InfluxDB事务保证关键数据一致性，适合实时监控场景。 - 问：系统成本如何？比如扩容成本？
答：通过云服务（如AWS）弹性扩容，成本可控，Q4高峰期按需付费，平时缩容。 - 问：数据清洗在采集端还是后端？
答：在边缘设备做初步过滤（如异常值检测），后端InfluxDB做聚合分析，减少后端压力。 - 问：如果数据采集设备故障，如何处理？
答：Kafka的持久化机制（如日志存储），确保数据不丢失，设备恢复后重新采集并补发数据。
7) 【常见坑/雷区】：
- 坑1：只使用传统数据库（如MySQL），忽略实时性，导致写入延迟高，无法满足实时监控需求。
- 坑2：Q4处理只说扩容，没考虑缓存或分片，导致高峰期延迟过高。
- 坑3：一致性误解，认为强一致性是必须的，导致系统可用性低，无法应对数据激增。
- 坑4：数据采集协议选择不当，如用HTTP长连接，导致延迟高，影响实时性。
- 坑5：未考虑数据持久化策略，如只存储实时数据，历史数据丢失，无法做长期分析。