海元的小站

1. 案例介绍1.1 业务分析模拟电商网站购物场景中的【下单】和【支付】业务 1）下单 用户请求订单系统下单 订单系统通过RPC调用订单服务下单 订单服务调用优惠券服务，扣减优惠券 订单服务调用调用库存服务，校验并扣减库存 订单服务调用用户服务，扣减用户余额 订单服务完成确认订单 2）支付 用户请求支付系统 支付系统调用第三方支付平台API进行发起支付流程 用户通过第三方支付平台支付成功后，第三方支付平台回调通知支付系统 支付系统调用订单服务修改订单状态 支付系统调用积分服务添加积分 支付系统调用日志服务记录日志 1.2 问题分析问题1用户提交订单后，扣减库存成功、扣减优惠券成功、使用余额成功，但是在确认订单操作失败，需要对库存、库存、余额进行回退。 如何保证数据的完整性？ 使用MQ保证在下单失败后系统数据的完整性 问题2用户通过第三方支付平台（支付宝、微信）支付成功后，第三方支付平台要通过回调API异步通知商家支付系统用户支付结果，支付系统根据支付结果修改订单状态、记录支付日志和给用户增加积分。 商家支付系统如何保证在收到第三方支付平台的异步通知时，如何快速给第三方支付凭 ...

1. MQ介绍1.1 为什么要用MQ消息队列是一种“先进先出”的数据结构 其应用场景主要包含以下3个方面 应用解耦 系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。 使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。 流量削峰 应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。 一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总不能下单体验要好。 处于经济考量目的： 业务系统正常时段的QP ...