第1章：核心需求分析
交易系统这活儿，我干了十几年。每次新项目启动，老板总会问：你要什么？我说五个词：快、稳、准、能扩、安全。说白了，就是低延迟、高可用、数据一致性、可扩展性、安全性。
这五个词，每个背后都是一堆坑。我一个个拆开讲。
1.1 低延迟：微秒级的生死线
交易系统里，延迟就是钱。我见过一个场景：某券商行情推送慢了10微秒，套利策略直接亏了上百万。你想想看，微秒级是什么概念？
1微秒 = 0.000001秒。一次网络中断，可能就几十毫秒。嗯，这里要注意，微秒级延迟，意味着你不能用常规的TCP/IP协议栈。
- 内核旁路：用DPDK、Solarflare这类技术，绕过操作系统内核，直接从网卡拿数据。我在项目中遇到过，用DPDK后延迟从10微秒降到2微秒。
- 内存计算：别用磁盘，别用数据库。数据全放内存里，用共享内存或者内存数据库。我习惯用Redis Cluster，但要注意持久化策略。
- 零拷贝：数据从网卡到应用，中间不要复制。用mmap或者sendfile系统调用。我曾经因为多了一次memcpy，延迟多了3微秒，排查了两天。
核心指标：端到端延迟 < 10微秒，99.9%的请求在5微秒内完成。
避坑指南：我曾经以为CPU主频越高越好，结果发现L3缓存命中率才是关键。交易系统里，数据局部性比CPU频率重要得多。
1.2 高可用：99.999%的承诺
五个9，一年宕机时间不超过5.26分钟。这要求，说白了就是系统不能停。我见过很多团队，拍胸脯说能做到，结果一上线就跪。
为什么会这样？因为高可用不是靠一个组件，而是靠整个架构设计。
- 冗余设计：所有组件都要有备份。主备切换、多活部署。我建议用N+2冗余，而不是N+1。多一台备用，关键时刻能救命。
- 故障检测：心跳检测、超时重试。但要注意，心跳间隔不能太短，否则网络抖动会引发误切换。我习惯用3次失败才切换的策略。
- 优雅降级：系统部分功能不可用时，不能全挂。比如行情服务挂了，交易功能还能用。我记得有一次，数据库主库挂了，我们自动切到只读副本，用户只感觉到查询慢了，交易完全没受影响。
警告：别迷信自动切换。我曾经遇到过，自动切换脚本把两个节点都切成了主节点，导致数据分裂。一定要加人工确认环节。
1.3 数据一致性：不能多一分，不能少一厘
交易系统里，数据一致性是底线。你想想看，如果A转给B 100万，结果A扣了钱，B没收到，或者A没扣钱，B收到了，这系统谁敢用？
我习惯用强一致性，而不是最终一致性。虽然性能会差一点，但安全。
- 分布式事务：用两阶段提交（2PC）或者三阶段提交（3PC）。但2PC有阻塞问题，我建议用TCC（Try-Confirm-Cancel）模式，性能更好。
- 幂等性：同一个请求，重复执行多次，结果一样。我习惯在请求里加唯一ID，服务端做去重。我曾经因为没做幂等，导致一笔订单被扣了两次钱，赔了用户不少。
- 状态机：每个交易都有明确的状态流转。比如：待支付 -> 支付中 -> 已支付 -> 已结算。状态不能回退，除非有明确的冲正操作。
核心原则：宁可系统不可用，也不能数据不一致。这是金融系统的铁律。
1.4 可扩展性：从百万到亿级
交易量是会涨的。你今天设计支持100万笔/秒，明天可能就要1000万笔/秒。可扩展性，说白了就是系统能不能加机器就扛得住。
我见过很多系统，一开始设计时没考虑扩展，后来改得痛不欲生。
- 无状态设计：应用层不要存任何状态。状态全放到缓存或者数据库里。这样加机器就能线性扩展。
- 分片策略：数据按用户ID、订单ID等维度分片。我习惯用一致性哈希，这样加机器时数据迁移量最小。
- 异步解耦：用消息队列解耦上下游。比如下单后，发一条消息给清算系统，清算系统慢慢处理。这样下单链路不会因为清算慢而阻塞。
避坑指南：我曾经以为分片越多越好，结果发现分片太多会导致管理复杂、跨分片查询慢。建议分片数控制在100以内，每个分片的数据量在1TB左右。
1.5 安全性：守住钱袋子
金融系统是黑客的重点目标。安全性，不只是防外部攻击，还要防内部泄露。
- 传输加密：所有网络通信都用TLS 1.3。别用自签名证书，用正规CA。我见过有人为了省事，用HTTP明文传输，结果被中间人攻击，交易数据被篡改。
- 身份认证：双因素认证（2FA）是标配。密码+短信验证码，或者密码+硬件令牌。我建议用OAuth 2.0 + JWT，但JWT的过期时间要设短，比如15分钟。
- 审计日志：所有操作都要记录，谁、什么时间、做了什么、结果如何。日志不能删改，要存到专门的审计系统里。我曾经因为审计日志没做好，被监管罚了200万。
警告：别以为内网就安全。内部人员泄露数据的案例比比皆是。一定要做权限最小化，每个员工只能看到自己需要的数据。
1.6 核心需求关系图
这五个需求不是孤立的，它们互相影响。我画了一张图，帮你理清关系。
这张图里，低延迟是性能基础，高可用靠冗余保障，数据一致性靠事务支撑，可扩展性提供弹性，安全性做加密防护。五个点缺一不可。
1.7 需求优先级矩阵
实际项目中，这五个需求不可能同时做到极致。我习惯用优先级矩阵来权衡。
| 需求 | 优先级 | 可妥协程度 | 我的建议 |
|---|---|---|---|
| 数据一致性 | P0（最高） | 不可妥协 | 强一致性，宁可系统不可用 |
| 安全性 | P0 | 不可妥协 | 加密、认证、审计全上 |
| 低延迟 | P1 | 可适当放宽 | 微秒级是目标，但别牺牲一致性 |
| 高可用 | P1 | 可适当放宽 | 99.999%是目标，但允许计划内维护 |
| 可扩展性 | P2 | 可阶段性实现 | 先支持当前量，再考虑未来扩展 |
个人经验：我习惯先保证数据一致性和安全性，再优化延迟和可用性。扩展性可以后面慢慢加。你想想看，系统再快，数据错了有什么用？
好了，核心需求分析就这些。记住这五个词：快、稳、准、能扩、安全。后面每一章，我都会围绕这五个点展开。
公众号:蓝海资料掘金营，微信deep3321