软件架构阅读笔记10
京东到家的系统高可用
- 通过强大的基础服务平台让应用、JVM、Docker、物理机所有健康指标一目了然;
- 7*24小时智能监控告警让开发无须一直盯着监控;
- 数据与业务相辅相成，用数据验证业务需求，迭代业务需求，让业务需求都尽可能的收益最大化，库存系统的开发同学只需要关注业务需求;
- 大版本上线前相应的测试同学会跟进帮你压测，防止上线后潜在的性能瓶颈;
举例：
一件商品有1000个库存，现在有1000个用户，每个用户计划同时购买1000个。
- （实现方案1）如果用户加入购物车时进行库存预占，那么将只能有1个用户将1000个商品加入购物车。
- （实现方案2）如果用户提交订单时进行库存预占，那么将也只能有1个用户将1000个商品提单成功，其它的人均提示“库存不足，提单失败”。
- （实现方案3）如果用户提交订单&支付成功时进行库存预占，那么这1000个人都能生成订单，但是只有1个人可以支付成功，其它的订单均会被自动取消。
采用2
- 用户可能只是暂时加入购物车，并不表示用户最终会提单并支付。
- 所以在购物车进行库存校验并预占，会造成其它真正想买的用户不能加入购物车的情况，但是之前加车的用户一直不付款，最终损失的是公司。
- 方案3会造成生成1000个订单，无论是在支付前校验库存还是在支付成功后再检验库存，都会造成用户准备好支付条件后却会出现99.9%的系统取消订单的概率，也就是说会给99.9%的用户体验到不爽的感觉。
- 数据表明用户提交订单不支付的占比是非常小的（相对于加入购物车不购买的行为），目前京东到家给用户预留的最长支付时间是30分钟，超过30分钟订单自动取消，预占的库存自动释放
- 方案2也可能由于用户下单预占库存但最终未支付，造成库存30分钟后才能被其它用户使用的情况，但是相较于方案1，方案3无疑是折中的最好方案。
重复订单问题：
- 用户善意行为：app上用户单击“提交订单”按钮后由于后端接口没有返回，用户以为没有操作成功会再次单击“提交订单”按钮
- 用户恶意行为：黑客直接刷提单接口，绕过App端防重提交功能
- 提单系统重试：比如提单系统为了提高系统的可用性，在第一次调用库存系统扣减接口超时后会重试再次提交扣减请求
解决：
- 用户善意行为：app侧在用户第一次单击“提交订单”按钮后对按钮进行置灰，禁止再次提交订单
- 用户恶意行为：采用令牌机制，用户每次进入结算页，提单系统会颁发一个令牌ID（全局唯一），当用户点击“提交订单”按钮时发起的网络请求中会带上这个令牌ID,这个时候提单系统会优先进行令牌ID验证，令牌ID存在&令牌ID访问次数=1的话才会放行处理后续逻辑，否则直接返回
- 提单系统重试：这种情况则需要后端系统（比如库存系统）来保证接口的幂等性，每次调用库存系统时均带上订单号，库存系统会基于订单号增加一个分布式事务锁
