RocketMQ消息中间件(六上)-订单系统的问题分析解答，MySQL中的binLog日志是什么？和大数据团队数据传输有什么关系呢？

前言

在rocketMQ一中，分析了很多图文说明订单系统可能会遇到的一些问题，这次继续来分析和解决这些问题，或者是换句话讲，引入了MQ对叮当系统进行了哪些质一样的改变?

一个订单系统中存在的问题：

1、下单核心流程环节太多，性能比较差。
2、订单退款的流程可能面临退款失败的风险。
3、关闭过期订单的时候，存在扫描大量订单数据的问题。
4、跟第三方物流系统耦合在一起，性能存在抖动的风险。
5、大数据团队要获取订单数据，存在不规范直接查询订单数据库的问题。
6、做秒杀活动时候，订单数据库压力比较大。

1.下单核心流程环节太多，性能比较差

【先看下下单环节的图】

每次支付完一个订单后都需要做同样的这些操作：

· 更新订单状态
· 扣减库存
· 增加积分
· 发放优惠券
· 发送短信
· 通知发货

导致的问题：一次核心链路执行时间过长，可能长达几秒钟！这不完犊子了，只要够快，穷就追不上我【=.=】

如何解决呢？ 首先回想一下什么叫做异步，什么叫做同步，这个问题基本上在概念上来说就已经解决了。
【图看起来表达比较清楚】

解释下：
例如：更新订单状态需要30ms，扣减库存需要80ms，调用第三方短信需要200ms，调用仓储和发货500ms，促销系统200ms，积分系统200ms，还不算网络波动等其他的情况，整个链路执行完，客户要在页面转好几秒中的时间。
【优化后：更新订单状态30ms，扣减库存80ms，总共110ms就可以响应回去了，客户端是很爽的，其他的操作异步的从mq中获取数据执行自己要处理的业务逻辑，这样就不会影响到整个订单核心链路的性能了】
问题貌似得到了解决的方案，但是还存在很多细节问题：思考下，如果消息没有发送成功怎么办？发送成功了，消费者没有消费怎么办？消费者消费了，业务代码执行失败怎么办？要想代码写的好，必须要有洁癖，提前思考的准备，这些问题在后面陆陆续续都会得到一定的解答，但是这个也不算难，可以思考思考

这里贴段代码生产者和消费者是如何发送消息和消费消息的：

首先对之前的业务逻辑做一定的改动【也就是本文的图一】：
1.改造系统，订单系统除掉调用积分系统，促销系统，推送系统以及仓储系统的业务逻辑，改成发送一个消息到MQ中；
2.另外的积分系统、促销系统、推送系统和仓储系统都要从MQ中获取消息，根据消息来执行自己的业务逻辑；

producer生产者代码编写：
1.引入rocketMQ-client的依赖；
2.下面展示一些 生产者的内联代码片。

// An highlighted block
public class RocktProducer{
   
//这个是rocket的生产者类，用这个生产者类发送消息到MQ
private static DefaultMQProducer producer；

static{
   
//构建一个producer实例对象
producer  = new DefaultMQProducer("order_producer_group");
//为producer设置nameServer的地址，可以拉取路由信息
//这样才知道每个topic的数据分散在哪些broker机器上
//然后此可以把消息发送到broker上去
producer.