Fetch the repository succeeded.
This action will force synchronization from 淡淡忧伤/ActiveMQ, which will overwrite any changes that you have made since you forked the repository, and can not be recovered!!!
Synchronous operation will process in the background and will refresh the page when finishing processing. Please be patient.
在使用消息队列时,主要解耦系统。 在使用消息队列时,又必须考虑消息发送与消费和使用系统的db事务保持一致。 在使用消息队列时,对消息丢失如何进行处理 在使用消息队列时,对重复消息如何进行处理
1.事务问题
在生产者端,发送消息->db操作和db操作->发送消息 是不同的情况
发送消息->db操作:消息发送成功而db操作失败,将会导致两个系统之间的数据严重不一致
db操作->发送消息:消息发送出现异常,通过事务可以将db操作进行回滚,这种情况不会系统的数据不一致造成影响
2.消息丢失问题
对于比较重要的消息,消费者系统不允许消息丢失,如何保证每条消息100%到达
3.重复消息问题
为了保证消息的幂等性:f(x)=a,f(f(x))=a,f(...(f(x)))=a
同一条消息重复消费多次与消费一次的效果一样
4.对于涉及到状态类型的消息
例如:订单状态的消息:第一条消息订单状态-订单已出库,第二条消息的订单状态-订单已送达
在极端情况下 第二条消息先于第一条消息被消息这消息,此时消费者系统的订单状态爱已经更改为订单已经出库
当第一条到达消费者时,消费者是否还需要消费,更改订单状态?
如何解决这些问题,尤其是使用一些开源的消息队列如:activeMQ,rabbitMQ等等
本项目是基于activeMQ消息队列来解决上述问题
需要在生产者系统的数据库中增加qmessage表,在消费者系统的数据库中增加n1_record和n2_record表
生产者端:先将消息存放于qmessage表中(确定消息时间戳),在消息消费成功时,再进行删除
同时增加定时job去扫描未被消费的消息,发送至activeMQ broker中
对使用者而言,生产者起始就是db操作,这样可以和业务的db操作保证在同一个事务中
消费者端:扫描消费记录表,确认消息是否重复消费,重复消费丢弃,不重复消息添加消息记录
对于状态流转的消息,需要业务标识和时间戳来判断消息当前消息是否是最新的
本项目不再更新,新的版本迁移至ReliableMessageSystem
详情请看:https://github.com/zjpjohn/ReliableMeageSystem
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。