### MQ消息重复消费解决方案 1. 消息中增加版本号标识，消费端只接受比当前消费端版本号高的消息； 示例： |messageId | 业务标识 | 版本号 | |:-|:-|:-| |1xxx | 101 | 1.0 | |2xxx | 101 | 2.0 | |1xxx | 101 | 1.0 | 上面第一条消息被消费端接收处理成功后，消费端更新版本号为1.0，当第二条消息被接收时，因为消息版本号大于消费端当前版本号，处理后更新版本号为2.0，当第三条消息过来时因为当前消费端版本号大于消息本身的版本号，直接丢弃；--该方案能解决重复消费问题； 2. 消息中增加版本号标识，且消费端只接受比当前版本大1的消息； 该方案用于处理对消息顺序有要求的场景，示例： 消息1 ==> 1xxx + 101 + 结算消息 + 2.0 消息2 ==> 2xxx + 101 + 扣款消息 + 1.0 如果消息1先到达消费端，消费完成后，消费端版本号变为2.0，那么消息2到达时因为消息版本号比消费端版本号低，直接被丢弃了，那么造成的后果就是，某一笔业务没有被扣款就把钱结算给供应商了 以上两种方案都是使用版本号机制来控制消息的重复消费，使用版本号的最大问题是： * 对发送方必须要求消息带业务版本号。 * 下游必须存储消息的版本号，对于要严格保证顺序的。 3. 状态机 根据业务流程制定业务状态流转机制，比如"待支付"状态的订单，只能接受"支付成功"或"支付失败"的消息；实际操作中可以针对不同的业务场景或不同的状态流转发送不同topic的消息； 4. 利用日志表记录消息消费记录：利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息(该方案仅能解决重复消费问题)； ### MQ消息不可达 1. 消息生产者在往MQ里面发消息的同时，为保证系统的高可靠，可同步往消息的中间系统写一条记录，包括：消息ID|业务ID|TOPIC，那么如果消息没有及时到达消费端(网络异常/消息阻塞)，消费端可利用JOB定时查询自己关心的消息(TOPIC+时间条件)以便及时处理，可作为一种补偿机制；中间件可定期删除过期数据