设计一个用于存储和管理光学镜头测试数据的后端系统，请说明系统架构、数据模型以及如何保证数据的一致性和可追溯性。

识光芯科IT实习生难度：中等

答案

1) 【一句话结论】采用微服务架构，整合关系型数据库（MySQL）、对象存储（MinIO）、时序数据库（InfluxDB），通过Saga模式保证分布式事务一致性，结合消息队列（Kafka）解耦服务，Redis缓存热点数据，实现光学镜头测试数据的结构化与非结构化存储，并确保数据一致性与可追溯性。

2) 【原理/概念讲解】系统分为数据层、服务层、接口层：

数据层：关系型数据库（MySQL）存储结构化数据（如测试任务、结果、元数据）；对象存储（MinIO）存储测试图像/视频（非结构化数据）；时序数据库（InfluxDB）记录测试过程中的时间序列数据（传感器读数、参数变化）。
服务层：测试数据管理服务（处理任务创建、结果提交）、图像处理服务（上传/下载图像）、版本控制服务（记录测试历史版本）、日志服务（记录所有操作）。
接口层：提供RESTful API（如提交测试结果、查询图像）。

类比：就像实验室的“实验报告”（关系型数据库）、“影像资料库”（对象存储）、“实时监测记录”（时序数据库），三者协同确保数据完整且可追溯。

3) 【对比与适用场景】

数据存储类型	定义	特性	使用场景	注意点
MySQL（关系型）	结构化数据存储	支持复杂查询（JOIN）、事务，写入性能适中	存储测试任务、结果、元数据（如镜头参数、测试标准）	写入性能一般，适合低频更新（如测试结果提交）
MinIO（对象存储）	非结构化数据存储	高扩展性、高吞吐量，适合存储大文件	存储测试图像、视频、报告PDF等非结构化数据	需要单独访问控制，查询需通过API
InfluxDB（时序）	时间序列数据存储	高写入性能（毫秒级），专为时间序列设计	记录测试过程中的实时参数（如焦距变化、传感器读数）、传感器数据	查询复杂度较高（需优化聚合查询），适合高频数据

4) 【示例】

数据模型（伪代码）：

-- 测试任务表（结构化）
CREATE TABLE test_tasks (
    task_id INT PRIMARY KEY,
    lens_id VARCHAR(50),
    test_params JSON,
    status VARCHAR(20),  -- 'pending', 'running', 'completed'
    created_at TIMESTAMP
);

-- 测试记录表（结构化）
CREATE TABLE test_records (
    record_id INT PRIMARY KEY,
    task_id INT,
    result JSON,
    timestamp TIMESTAMP,
    FOREIGN KEY (task_id) REFERENCES test_tasks(task_id)
);

-- 版本表（结构化）
CREATE TABLE test_versions (
    version_id INT PRIMARY KEY,
    task_id INT,
    version_number INT,
    created_at TIMESTAMP,
    FOREIGN KEY (task_id) REFERENCES test_tasks(task_id)
);

-- 测试图像表（非结构化关联）
CREATE TABLE test_images (
    image_id INT PRIMARY KEY,
    task_id INT,
    image_url VARCHAR(255),  -- MinIO存储的路径
    image_type VARCHAR(20),  -- 'photo', 'video'
    upload_time TIMESTAMP,
    FOREIGN KEY (task_id) REFERENCES test_tasks(task_id)
);

API请求示例（提交测试图像）：

{
  "task_id": 101,
  "image_url": "minio-bucket/image_101.jpg",
  "image_type": "photo",
  "timestamp": "2024-05-20T10:30:00Z"
}

5) 【面试口播版答案】
面试官好，我来设计一个用于存储和管理光学镜头测试数据的后端系统。核心思路是采用微服务架构，结合关系型数据库、对象存储（MinIO）和时序数据库，通过Saga模式保证数据一致性，同时用消息队列（Kafka）解耦服务，Redis缓存热点数据，实现高并发下的数据存储与可追溯性。

首先，系统分为数据层、服务层和接口层。数据层：用MySQL存储结构化数据（如测试任务、结果、元数据），用MinIO存储测试图像/视频（非结构化数据），用InfluxDB记录测试过程中的时间序列数据（传感器读数、参数变化）。服务层包括测试数据管理服务（处理任务创建、结果提交）、图像处理服务（上传/下载图像）、版本控制服务（记录测试历史版本）、日志服务（记录所有操作）。数据模型方面，测试任务表包含任务ID、镜头ID、测试参数；测试记录表存储测试结果和时间戳；版本表保存每次测试的版本信息；测试图像表关联任务ID，存储图像路径。

一致性保证：测试完成后，将结果写入MySQL，同时记录日志到InfluxDB，若任一失败则通过Saga模式回滚（如取消任务状态、删除已写入数据），确保数据强一致性。可追溯性：通过日志服务记录所有操作（如任务创建、结果提交），版本表保存历史版本，MinIO的图像可回溯查看，便于审计和问题排查。

这样既能高效存储结构化数据，又能实时记录时间序列数据和非结构化图像，同时保证数据一致性和可追溯性。

6) 【追问清单】

问：系统如何处理高并发测试请求？
回答要点：采用消息队列（如Kafka）解耦服务，缓存（Redis）提高读取性能，水平扩展服务实例（如用Kubernetes部署多个实例）。
问：非结构化数据（如测试图像）如何与结构化数据关联？
回答要点：通过任务ID关联，在测试图像表中存储MinIO的路径，查询时通过API获取图像，确保数据一致性。
问：Saga模式在测试失败时的补偿流程是怎样的？
回答要点：测试失败时，触发补偿事务，取消任务状态，删除已写入的测试记录和版本信息，回滚到测试前的状态。
问：如何保证数据备份和恢复？
回答要点：MySQL定期全量+增量备份，InfluxDB采用时间点恢复（TPR），MinIO的文件通过对象存储的备份功能，确保数据不丢失。

7) 【常见坑/雷区】

非结构化数据遗漏：直接用关系型数据库存储图像，导致写入性能低，应使用对象存储（如MinIO），避免数据模型复杂。
数据库选择不当：时序数据用关系型数据库，导致写入延迟，应选择InfluxDB等时序数据库。
一致性模型误解：认为强一致性适用于所有场景，实际测试过程中允许最终一致性，应采用Saga模式处理分布式事务。
高并发优化不足：未考虑消息队列解耦，导致服务耦合度高，应引入Kafka等消息队列，提高系统可扩展性。
可追溯性设计不足：仅记录操作日志，未保存历史版本，应设计版本表并记录版本号，支持回滚到历史版本。