Rocketmq应用逻辑

rocketmq:
1）rim开票中台作为消费者：只从mq中指定的topic取数据
2）rim开票中台作为生产者，回写消费的消息成功与否的结果，向mq写数据时，会存在多个topic，一个业务系统对应一个topic，
而一个系统中的不同业务请求可以用不同的tag进行区分
记忆总结：一个消费者业务系统对应一个topic，即topic时根据消费者来定的，
比如：rim作为消费者的时候，相当于别的系统调用rim的接口，所以别的系统发送的topic必须与rim消费时定的topic保持一致；
而rim作为生产者回写处理结果的时候，别的业务系统是消费者，所以回写消息时，会对应多个topic，
然后别的系统读取各自对应的topic中的信息

rim中台为nbi非商提供开票申请和开票作废接口，都是通过http的形式进行同步调用，其他的系统的开票申请时调用的汉生系统进行开票，
但是现在汉生系统需要进行下线，因此其他系统的开票申请也改为调用rim的开票接口，考虑到rim的开票接口压力增大，可能会抗不住
压力，因此采用rocketmq进行异步开票，rim作废消费者从mq中指定的topic进行消费，而其他业务系统也是将开票申请发送到同一个topic，
而rim在进行消息消费后，不管成功与否，都需要将处理结果以发送到mq，此时rim作废消息的生产者，而其他业务系统作为消息的消费者，
每个业务系统取不同的topic中的内容进行消费，因此rim就需要在发送消息到mq的时候指定不同的topic，因此需要在rim中的配置表中
配置不同的系统对应的topic，rim根据系统业务系统的系统编码从配置表中取出对应的topic进行消息发送。由于开票接口采用mq的形式
进行异步处理，而作废接口采用同步的形式进行作废，就会引发一个问题：开票申请发送到mq后，rim中台还没有进行消费，在对应的
申请单表中还没有对应的申请数据，而此时业务系统调用了作废接口对申请进行作废，由于申请数据不存在，所以无法作废，因此新增
一张作废申请表保存作废申请的相关数据，当rim消费mq中的开票申请的消息时，不是直接进行开票的相关逻辑，而是需要先判断在
作废申请表中是否存在对应的作废申请数据，如果存在，则需要对申请单进行作废的逻辑处理，并删除作废申请表中对应的数据；如果在
作废申请表中不存在作废请求，才进行相关的开票逻辑。