可靠MQ设计

各位,

我们团队在可靠MQ的设计上,出现了一些分歧性的意见,想拿出来和大家讨论讨论:

1,消息的可靠性设计,目前有2种模式:模式1是采用Notify的方式,先发送半消息,业务操作成功后最后提交完整消息,同时提供业务操作的检查接口,这种模式实现消息的最终一致性;模式2将业务数据和消息数据先都存在业务数据库里面,通过数据库的事务保证一致性,随后将消息转发给MQ。模式1的缺点是业务侵入性高,方案比较复杂,需要重新实现;模式2的缺点是消息数据可能会散落在各个地方,包括业务系统,而且可以集成现有MQ。

2,消息去重设计,也有2种模式:模式1是消费者根据自己的业务实现去重,模式2是在消费者端增加一个数据库表专门记录已经消费过的消息,不需要消费者根据业务去做去重。

不知道大家怎么看?

mq

3个回答

看Notify这个词我就知道又是蛋疼的淘系同学。
方案1、各种Check让人很蛋疼,但如果内部是需要垮库事务、分布式调用的场景的,我还真离不开他。让我可以在Check接口中回滚垮库、冲正其他系统的数据。

方案2、简单,非常适合事务都集中在一个库上的业务系统。后端挂上精卫拉binlog还是杠杠的,而且还和业务数据保持一个事务,清爽!

所以,两个我都要。done。

iteye_4740
iteye_4740 哈,原来是这样。我们没有类似于精卫这类中间件,目前采用定时轮询的方式将数据同步到MQ服务器。
7 年多之前 回复
vlinux
vlinux 将Message的信息写到和业务数据库同库的表中,这样可以利用DB事务确保消息一定能随着业务的成功也写入。然后精卫拉binlog同步给NotifyServer
7 年多之前 回复
iteye_4740
iteye_4740 精卫拉binlog怎么理解,能详细说说么?
7 年多之前 回复
vlinux
vlinux PS下,我说的跨库事务不是真的2PC,而是每个库一个事务,失败了用Notify的Check回滚、冲正
7 年多之前 回复

支持模式2 :D

说实在的,2个方案我都没有看懂,但就我的观点提供一点建议。

问题1,可靠性设计,这个问题如果转换一下,假设你问的不是MQ,而是数据库,就成了“数据库的可靠性设计”,如果你是在开发一个数据库,那是一个严肃的问题,如果你是在使用数据库,那可能是搞错方向了,换成“怎么使用事务保证数据的可靠性”之类的,可能更确切。MQ产品,据我所知,其本身而言,和数据库一样,对交给它的消息也需要提供可靠性保证,当然如果你把MQ的消息存储配成存在内存中,或不用事务提交,那就不保证了,就像你操作数据库的时候不用事务一样。

问题2,去重,据我所知,MQ除了要保证一条消息一定要送达外(即问题1),还要保证只被消费一次(当然,如果你愿意,也可以消费多次),如果你说的去重是指一条消息可能会被收到多次(从你的方案2推测的),那应该先好好了解一下MQ;如果是指业务上本身就会有重复内容的消息,那当然只能在业务上去处理了,就像数据库里,你可以主键都不要,插入内容完全相同的数据行,至于能不能重复,或重复的怎么处理,那完全上业务上的问题了。

在MQ环境里,一条消息无非是经过:生产(发送)、存储转发、消费(接收)三个环节,MQ在每个环节都需要提供可靠性保证,如向MQ发送一条消息,那到底有没有发出去,要有明确的回馈,就像向数据库里插入一条记录,到底有没有插进去,必须通过事务的成功或失败明确的回馈给客户端,这样的可靠性保证,应该通过数据库、MQ自身的机制来实现,而不能转移的应该层面。存储转发就不用说了,肯定不能一条消息莫名其妙的消失掉,也不能凭空多出消息来。消费的时候也是一样,一条消息到底有没有被消费掉,也是通过事务机制来控制的,不可能一条消息被消费掉了,下次去取又来了,不然这个MQ产品就是不可用的(当然你不发送ACK,故意让它留在broker上除外)

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐