银行交易数据量庞大（日均TB级），且需支持实时查询（如账户余额查询、交易明细查询）。请设计一个分布式数据库方案，说明选型（如TiDB/ClickHouse）、数据分片策略、索引设计及数据一致性保障。
三菱日联银行Global Markets难度：困难
答案
1) 【一句话结论】：针对银行TB级交易数据与实时查询需求，采用TiDB（分布式MySQL）结合冷热分离方案，通过哈希分片、混合索引及分布式事务（强隔离级别SERIALIZABLE），平衡高并发事务与实时分析，历史数据归档至对象存储，确保账户余额查询强一致性，支持低延迟交易明细查询。
2) 【原理/概念讲解】：分布式数据库需解决数据分片、一致性、冷热分离。
- 数据冷热分离：高频实时数据存TiDB（行存，支持事务），历史数据（如>30天）归档至对象存储（如S3），归档时事务提交，延迟监控（如归档延迟>5分钟触发告警），确保历史数据与实时表一致。
- 分片策略：账户ID哈希分片（32个分片），均匀分布（通过负载均衡器或TiDB内置分片算法），热点分片时动态调整分片（如扩容或重分片）。
- 索引设计：实时表设复合索引（account_id, created_at），加速按时间范围查询；物化视图（列存，预聚合）加速分析查询（如账户总交易额）。
- 一致性保障：TiDB Raft协议强一致性，分布式事务（两阶段提交），金融事务用SERIALIZABLE隔离级别（锁定所有读写的行，避免脏读），读写分离（读从副本，副本负载均衡，延迟<50ms），读副本优先响应高负载查询。
3) 【对比与适用场景】：
| 特性/方案 | TiDB（分布式MySQL） | ClickHouse（列式分析型） |
|---|---|---|
| 定义 | 基于MySQL生态的分布式数据库，支持行存+列存混合存储，兼容ACID事务 | 高性能列式数据库，专为实时分析设计，弱事务（最终一致性） |
| 核心特性 | 事务支持（ACID）、分布式事务、MySQL兼容语法、混合存储（行存列存）、冷热分离 | 强分析性能、列式存储、支持实时计算、写入延迟较高（适合批量分析） |
| 使用场景 | 事务型业务（账户余额、交易记录，需高并发写与低延迟读）、实时分析（如实时账单） | 大规模数据分析、报表、市场行情分析（如历史交易数据统计） |
| 注意点 | 分片键需均匀分布（避免热点），复杂事务可能影响性能；冷热分离需合理归档策略（事务提交+延迟监控）；需配置强隔离级别（SERIALIZABLE）保障金融一致性 | 不支持复杂事务，写入延迟高，不适合实时事务；列存索引对分析查询优化，但事务处理能力弱；写入延迟可能影响实时查询 |
4) 【示例】：
- 实时交易表（TiDB，行存）：
CREATE TABLE transaction_realtime ( log_id BIGINT AUTO_INCREMENT PRIMARY KEY, account_id BIGINT, amount DECIMAL(18,2), type ENUM('DEPOSIT','WITHDRAWAL'), created_at TIMESTAMP, INDEX idx_account_time (account_id, created_at) USING HASH, SHARDING KEY HASH(account_id) BUCKETS 32 ) ENGINE = TiDB; - 历史交易归档表（对象存储，JSON）：
{ "log_id": 123456, "account_id": 1001, "amount": 1000.00, "type": "DEPOSIT", "created_at": "2023-10-01 10:00:00", "archived_at": "2023-11-01 00:00:00" } - 归档流程（伪代码）：
def archive_transactions(): cutoff = datetime.now() - timedelta(days=30) with db.transaction(): result = db.execute("SELECT * FROM transaction_realtime WHERE created_at < %s", [cutoff]) for row in result: s3.put_object( Bucket='bank-archive', Key=f"transactions/{row['account_id']}/{row['log_id']}.json", Body=json.dumps(row) ) if time.time() - start_time > 300: # 超过5分钟 alert("归档延迟超过5分钟") - 跨分片预聚合物化视图（TiDB，列存）：
CREATE MATERIALIZED VIEW transaction_aggregated AS SELECT account_id, SUM(amount) as total_amount, COUNT(*) as transaction_count FROM transaction_realtime WHERE created_at >= '2023-10-01' GROUP BY account_id WITH DATA;
5) 【面试口播版答案】：
面试官您好，针对银行TB级交易数据与实时查询需求，我建议采用TiDB结合冷热分离的分布式方案。首先，TiDB的混合存储（行存+列存）和分布式架构能平衡高并发事务与实时分析，比如账户余额查询用行存索引加速，交易明细分析用列存物化视图。数据分片上，采用基于账户ID的哈希分片，将账户数据分散到32个节点，避免热点，减少跨分片查询。对于历史数据，超过30天的交易归档至对象存储，归档时通过事务提交确保数据一致性，延迟监控避免延迟影响。索引设计方面，实时表设置时间+账户ID的复合索引，物化视图预聚合数据，提升分析查询性能。一致性保障通过TiDB的分布式事务（两阶段提交）和强隔离级别（SERIALIZABLE），读写分离的读副本负载均衡（延迟<50ms），满足实时查询需求。总结来说，这个方案能有效支持高并发、低延迟的账户余额与交易明细查询，同时通过冷热分离优化存储成本。
6) 【追问清单】：
- 问题1：如何保障历史数据归档时的数据一致性？
回答要点：归档时通过TiDB事务（两阶段提交），确保数据从实时表迁移至对象存储时原子性，归档延迟超过5分钟触发告警，避免数据不一致。 - 问题2：跨分片查询时，物化视图的刷新频率如何设置？
回答要点：根据查询负载，设置每小时刷新一次，或动态调整（如查询负载高时增加刷新频率），避免刷新延迟影响实时分析查询。 - 问题3：分片键选择账户ID是否会导致热点分片？
回答要点：采用哈希分片，结合负载均衡器或TiDB内置算法，确保数据均匀分布，热点分片时通过扩容或重分片调整分片数量。 - 问题4：金融事务如何设置强隔离级别？
回答要点：在TiDB中配置事务隔离级别为SERIALIZABLE，锁定所有读写的行，避免脏读，保障账户余额查询的强一致性。
7) 【常见坑/雷区】：
- 坑1：冷热分离归档策略不合理（如频繁归档导致实时表数据量仍大，或归档延迟导致历史数据与实时表不一致）。
- 坑2：分片键选择不当（如时间范围分片，新数据集中，导致热点分片，查询延迟高）。
- 坑3：索引设计未考虑分析查询（如仅设主键，未创建物化视图，导致分析查询延迟高，影响用户体验）。
- 坑4：忽略事务隔离级别（金融业务需高隔离，设置不当导致脏读，如账户余额查询时未加锁，导致余额不一致）。
- 坑5：读写分离未考虑负载均衡（读副本固定，导致查询延迟波动，影响实时查询响应时间）。