设计一个高可用的分布式存储系统，用于存储360安全产品的日志数据（如安全卫士、浏览器的用户行为日志、威胁情报日志），需满足：1）支持PB级海量数据存储；2）故障节点下数据不丢失且恢复时间短；3）支持按时间、设备ID、威胁类型快速查询；4）保证数据安全（加密存储、访问控制）。请详细说明系统架构、数据分片策略、副本策略、查询优化方案等。
答案
1) 【一句话结论】
我设计的分布式存储系统采用时间范围与设备ID哈希的混合分片策略，结合3副本容错、冷热数据分层存储、端到端加密及密文索引，确保PB级日志存储的高可用、快速查询与数据安全。
2) 【原理/概念讲解】
首先解释数据分片：按时间范围（如天）划分分片，每个分片内按设备ID哈希分配数据块。类比：日志按天存入不同文件夹（分片），每个文件夹内按设备ID哈希放入子文件夹（分片内位置），查询时先找天文件夹，再找设备ID子文件夹，快速定位数据。
接着讲冷热数据分层：近期数据（0-30天）存SSD（高速存储），历史数据存HDD（低成本存储）。类比：近期日志像热文件，存高速SSD提升查询速度；历史日志像冷文件，存HDD降低成本。
副本策略：每个数据块存3副本，分布在不同机架/数据中心。故障时主节点故障，副本通过Raft协议（选举新主、同步数据），结合网络多路径传输，预计故障恢复时间≤3分钟。
数据安全：端到端加密（AES-256），写入前用KMS生成密钥加密数据，密钥每月轮换；访问控制用RBAC，定义角色（如分析师、运维），通过API网关验证权限。
查询优化：预计算时间索引（时间范围到分片的映射，B+树存储），设备ID索引（哈希表存储设备ID到数据块的映射），加密后用密文索引（时间索引哈希值加密后存储），减少解密次数。
3) 【对比与适用场景】
| 对比维度 | 单一时间分片 | 单一设备ID哈希分片 | 混合分片（时间+哈希） |
|---|---|---|---|
| 定义 | 按时间顺序分片（如每天一个分片） | 按设备ID哈希值分片 | 结合时间范围与设备ID哈希 |
| 特性 | 顺序写高效，随机读需跨分片 | 随机读高效，负载均衡 | 顺序写+随机读兼顾，避免热点 |
| 负载均衡 | 近期数据热点 | 设备ID分布均匀 | 时间+设备ID联合均匀 |
| 注意点 | 近期数据集中，查询慢 | 查询需反算分片，跨分片通信 | 实现复杂，需平衡分片粒度 |
| 适用场景 | 小规模时序日志 | 设备ID分布均匀的日志 | PB级安全日志（360） |
| 对比维度 | 2副本 | 3副本 | 5副本 |
|---|---|---|---|
| 故障容忍度 | 1故障 | 1故障 | 2故障 |
| 恢复时间 | 1-2分钟 | 2-5分钟（Raft+网络优化） | 5-10分钟 |
| 数据冗余 | 低 | 中 | 高 |
| 适用场景 | 小规模存储 | PB级大规模存储（360） | 极高可用（金融核心数据） |
4) 【示例】
写入日志请求（JSON）：
{
"log_type": "user_behavior",
"device_id": "device_123",
"timestamp": "2023-10-01T12:00:00Z",
"data": "click_homepage"
}
处理流程（伪代码）：
- 计算分片ID：
time_range = 2023-10-01→ 分片ID为shard_20231001；设备ID哈希 → 数据块ID为shard_20231001_hash(device_123)。 - 冷热判断：若时间在最近30天内，选择SSD节点；否则HDD节点。
- 加密：KMS生成AES-256密钥
key，加密数据为encrypted_data = aes_encrypt(data, key)。 - 写入3副本：跨机架写入3个副本，返回确认。
查询请求（JSON）：
{
"start_time": "2023-09-30T00:00:00Z",
"end_time": "2023-10-01T23:59:59Z",
"device_id": "device_123",
"threat_type": "malware"
}
处理流程（伪代码）：
- 定位时间分片：获取时间范围内的分片列表（如
shard_20230930、shard_20231001）。 - 读取近期数据：从SSD节点读取分片数据，解密后过滤时间、设备ID、威胁类型。
- 读取历史数据：从HDD节点读取历史分片数据，解密后过滤。
- 合并结果：按时间顺序合并近期与历史数据，返回查询结果。
5) 【面试口播版答案】
各位面试官好，我设计的分布式存储系统核心是混合分片+冷热分层+3副本+加密索引。数据按天分片，每个分片内按设备ID哈希，这样查询时能快速定位时间范围和设备。近期数据存SSD，历史存HDD，降低成本。3副本分布在机架间，故障恢复通过Raft，预计2-5分钟。加密用AES-256，密钥KMS管理，访问控制RBAC。查询时预计算时间索引，减少数据量，支持快速查询。整体满足360安全日志的海量存储、高可用、快速查询和安全需求。
6) 【追问清单】
-
问：分片策略为什么选择时间范围+哈希结合？比如范围分片和哈希分片各自的优势？
回答要点：时间范围分片保证日志的时序性，适合按时间顺序查询；设备ID哈希分片实现负载均衡，避免设备ID热点，结合两者平衡顺序写和随机读性能，避免单分片负载过高。 -
问：冷热数据分层中，如何判断数据是近期还是历史？比如30天的阈值如何确定？
回答要点：根据日志的访问频率，近期数据（如30天内）访问频率高，存SSD；历史数据访问少，存HDD。阈值可通过业务数据统计（如30天内的日志占查询量的80%）确定。 -
问：加密数据后，如何保证查询效率？比如解密开销？
回答要点：采用密文索引（时间索引哈希值加密后存储），查询时先定位数据块再解密；或对加密数据做哈希计算，减少解密次数，平衡安全与性能。 -
问：故障恢复时间2-5分钟是如何估算的？考虑了哪些因素？
回答要点：基于3副本和Raft协议，结合网络多路径传输，极端情况（如网络分区）下恢复时间可能延长，但正常情况下通过Raft快速选举新主并同步数据，预计2-5分钟内恢复。 -
问：访问控制中，用户角色变更时如何处理权限更新？
回答要点：基于RBAC，角色变更时更新权限规则，通过API网关重新验证权限，确保权限动态管理，不影响现有用户访问。
7) 【常见坑/雷区】
- 分片策略导致热点：若只按时间范围分片，近期数据集中在一个分片，导致查询慢，应结合哈希分片避免热点。
- 副本数量不足：若只设2副本，节点故障导致数据丢失，应考虑故障率，至少3副本保证可靠性。
- 查询优化没考虑索引：若查询需扫描所有数据，性能差，应预计算时间、设备ID索引，减少数据量。
- 安全措施不够具体：若只说加密，没说明密钥管理（KMS）、访问控制（RBAC），容易被反问细节。
- 冷热分层没量化：若没说明存储介质（SSD/HDD）和阈值，会被问成本与性能的权衡依据。