船舶设备运行数据需要长期存储以进行性能分析和故障追溯，请设计一个高可用、可扩展的存储方案，并说明如何保证数据的完整性和一致性？

1) 【一句话结论】：针对船舶设备运行数据（时序数据，高写入率、海量增长），采用分布式对象存储（如Ceph），结合一致性哈希分片、机架感知多副本冗余，通过Raft协议保证强一致性，并实现冷热数据分离（热数据SSD、冷数据HDD/归档），构建高可用、可扩展的长期存储方案，满足性能分析和故障追溯需求。

2) 【原理/概念讲解】：老师口吻，解释关键概念：

• 数据分片（Sharding）：按设备ID哈希（如MD5）映射到不同存储节点，避免热点。例如船舶发动机数据，不同发动机的运行数据分散到不同节点，避免某一节点压力过大。
• 副本放置（Replication）：每个数据块存储3个副本，分布在不同机架（机架感知策略），避免机架故障导致数据丢失。例如副本1在机架A，副本2在机架B，副本3在机架C。
• 一致性协议（Raft）：采用Raft共识算法保证多副本同步，写入时所有副本写入成功后返回，故障时从日志和副本恢复，确保强一致性，适合故障追溯的精确性。
• 冷热数据分离（Lifecycle Management）：热数据（近期，如30天内）存SSD，冷数据（历史，超30天）迁移到HDD/归档，通过增量备份和校验和验证一致性，降低成本。

3) 【对比与适用场景】：

存储方案	定义	关键特性	使用场景	注意点
分布式时序数据库（如InfluxDB）	专为时序数据设计	分片+副本，支持水平扩展，内置压缩索引	船舶设备实时数据采集、实时分析	长期存储需归档，扩展性受限于时序特性
分布式对象存储（如Ceph）	对象存储，基于块/文件/对象	数据分片+多副本，高可用，可扩展	海量非结构化/结构化数据，长期存储	写入延迟较高，需客户端适配
关系型数据库（如MySQL）	结构化数据，ACID事务	单机/主从，强一致性，扩展性有限	结构化设备参数、配置	扩展性差，不适合海量时序数据
NoSQL数据库（如MongoDB）	非关系型，支持灵活Schema	分片，最终一致性	设备日志、配置	一致性依赖应用层，故障追溯需额外设计

4) 【示例】：伪代码展示数据写入与冷数据迁移：

// 1. 数据写入（设备运行数据）
function writeDeviceMetrics(deviceId, ts, metrics) {
    shardId = hash(deviceId) % numShards  // 一致性哈希分片
    replicas = getReplicas(shardId, rackAware = true)  // 机架感知副本
    for (rep in replicas) {
        send("PUT", rep, metrics, ts)
    }
    if (allAcked()) return "写入成功"
    else return "写入失败，副本同步异常"
}

// 2. 冷数据迁移（冷热分离）
function migrateColdData() {
    coldData = selectData(timestamp < now() - 30days)  // 触发条件：超30天
    backup(coldData)  // 增量备份
    for (item in coldData) {
        send("MIGRATE", item, hddStorage)  // 迁移到HDD
    }
    verifyChecksum(coldData)  // 验证一致性
}

5) 【面试口播版答案】：面试官您好，针对船舶设备运行数据的长期存储需求，我设计的方案是采用分布式对象存储系统（如Ceph），结合一致性哈希分片、机架感知多副本冗余，并通过Raft协议保证强一致性。具体来说，数据按设备ID哈希分片到不同节点，每个数据块存储3个副本，分布在不同机架，避免单点故障。写入时所有副本同步成功后返回，确保数据一致性。扩展性方面，新增节点时自动加入分片，数据会自动迁移，无需停机。同时，实现冷热数据分离，近期数据存储在SSD，历史数据迁移到HDD，降低成本。数据完整性通过副本校验和事务日志保证，故障时从副本和日志恢复，满足性能分析和故障追溯的需求。

6) 【追问清单】：

• 问：数据分片的具体算法？如何避免热点？
  回答：用设备ID的哈希分片（如MD5），结合虚拟节点（虚拟节点数远大于物理节点数），均匀分散负载。
• 问：冷数据迁移时如何保证数据一致性？
  回答：迁移前做增量备份（快照），迁移后验证校验和，迁移过程中暂停写入冷数据。
• 问：存储节点故障恢复时间？如何保证数据不丢失？
  回答：多副本冗余，故障节点自动检测替换，恢复时间几分钟内；通过副本校验和日志确保数据不丢失。
• 问：数据一致性模型为什么选强一致性？
  回答：故障追溯需精确时间线，强一致性确保写入后立即全局可见，避免数据不一致影响分析。
• 问：分片键调整（如从设备ID改时间范围）对现有数据的影响？
  回答：通过分片迁移工具调整crush map，先迁移数据再更新路由表，尽量减少停机时间。

7) 【常见坑/雷区】：

• 忽略数据分片算法细节（如只说“分片”），导致工程落地性不足。
• 副本放置策略不明确（如只说“多副本”），机架故障时数据丢失风险。
• 冷热数据分离未说明触发条件/一致性保证，存储成本控制不合理。
• 扩展性设计未考虑分片调整的复杂性（如新增节点数据迁移是否停机）。
• 一致性模型选择错误（如用最终一致性），导致故障追溯数据不一致。