交易系统设计与原则
墨菲定律
- 任何事都没有表面看起来那么简单。
- 所有的事都会比你预计的时间长。
- 会出错的事总会出错。
- 如果你担心某种情况发生，那么它就更有可能发生。
康威定律
- 组织沟通方式会通过系统设计表达出来。
- 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
- 线型系统和线型组织架构间有潜在的异质同态特性。
- 大的系统组织总是比小系统更倾向于分解。
https://yq.aliyun.com/articles/8611
高并发原则
无状态 应用无状态，配置文件有状态。
拆分 一个大而全的系统是按照功能模块拆分系统。
- 系统维度：按照系统功能/业务拆分，比如商品系统、购物车、订单、支付、分账、结算等。
- 功能维度：对一个系统进行功能拆分，优惠券创建系统、领券系统、用券系统。
- 读写维度：使用读写分离，读服务考虑使用缓存提升性能，写服务量大可以考虑分库分表，聚合读取场景下考虑数据异构拆分系统然后将分散在多处的数据聚合到一处存储。
- AOP 维度：面向切面编程，根据访问特征按照 AOP 进行拆分。处理日志记录，性能统计，安全控制，事务处理，异常处理等等。
- 模块维度：按照基础模块特征进行拆分，比如分库分表、数据库连接池；代码结构按照三层划分。
服务化 进程内服务 → 单机远程服务 → 集群手动注册服务 → 自动注册和服务发现 → 服务的分组/隔离/路由 → 服务治理。
消息队列 使用消息队列可以实现服务解耦、异步处理、流量削峰/缓冲等。
大流量缓冲
数据校对：使用异步机制会存在消息丢失的情况，需要考虑定期去扫描原始表，对数据进行校对和问题的补偿。
数据异构
- 数据异构，比如订单分库分表，按照订单ID进行划分，对于异构意义不大不大的字段（库存价格）考虑异步加载，合并并发请求等。
- 数据闭环，通过 MQ 机制接收数据变更，然后把原子化数据存储到合适的存储引擎，然后将数据聚合，把多个数据源拿过来，然后存储到KV存储中。如果一次需要多个数据，可以考虑使用 Hash Tag 机制将相关数据聚合到一个实例。
- 前端展示，减少前端拿数据的数量。
缓存银弹
- 浏览器端缓存，通过设计过期时间进行控制，适用于不太敏感的数据。
- APP 客户端缓存，为了防止瞬间流量冲击，把相关的静态文件下发到客户端缓存。
- CDN 缓存，将一些活动页、图片、视频等资源推送到离用户进的 CDN 节点。一般是通过推送机制和拉取机制。
- 接入层缓存，例如 Nginx 层，通过 URL 重写、一致性哈希、代理缓存等机制实现。
- 应用层缓存
- 分布式缓存
并发化 将串行获取的数据通过并发化获取。
高可用原则
- 降级 主要的是设计一个降级开关。
- 开关集中化管理，通过推送机制将开关推送到各个应用。
- 可降级的多级读服务，按照读写维度进行调用降级。
- 开关前置化，将开关前置到 Nginx 接入层，对流量请求拦截或一小部分放流。
- 业务降级，把同步调用改成异步调用，或者优先处理高优先级数据或包含特征的数据，合理分配流量进入系统，以保障系统可用。
- 限流 为了防止恶意请求流量、恶意攻击，防止流量超出系统峰值。
- 恶意请求只访问到 cache。
- 穿透到后端的应用流量可以考虑使用 Nginx 层做处理。
- 对于恶意 IP 使用 Nginx 层进行屏蔽。
- 原则是限制流量穿透到后端薄弱的应用层。
- 切流量 应对多机房环境某机房挂了或者机架挂了，或者不可抗拒的自然灾害，这时异地多活机房就很重要了。我们要做的就是能及时将异常的地方下线，流量切到正常的服务下。
- DNS，切换机房入口。
- LVS/HAProxy，切换故障的接入层。
- Nginx，切换故障的应用层。
- 可回滚 当服务出错时，通过版本话机制回滚到最近的一个正确版本。
业务设计原则
- 防重设计，比如结算页面防止重复提交。
- 幂等设计，在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
- 流程可定义，两个流程彼此分离，在需要的时候进行关联，或者复用一些理赔流程。
- 状态与状态机，在设计交易订单系统，会存在正向状态和逆向状态，需要记录订单的状态轨迹并记录相关日志。还需要考虑并发状态修改的问题。
- 后台系统操作的反馈，对后台系统操作场景能及时预览最终效果。
- 后台系统审批，对于一些敏感操作记录日志，设计审批流程，保证操作可追溯、可审计。
- 文档和注释，无需多说。
- 备份，代码仓库的备份和管理。
