×

Loading...
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

My opinion: It seems you shouldn't put them together.

As a developer, you can use MQ to create messaging applications since it provides the functionality directly, you create messaging applications in almost the same way that you create other kinds of application.

A database is a database, it's not for dealing with the messaging, and can not provide you with the convinience of developing messaging applications.

I guess what made you put them together is you can store large amouth of data through MQ. That is because MQ keeps a IMDB(in memory database). The IM makes the diffrence: you can't store your data in hard drive, it's just for tempory data.

The above is just my own opinion and my understanding of MSMQ.
Report

Replies, comments and Discussions:

  • 工作学习 / IT技术讨论 / 比起用数据库,Message Queue可以举出哪些优越性呢?
    • message queue can not replace database, it's for asynchronous processing
      • 我没有看错吧?“message queue can not replace database”罚回去再看message queue文档100遍!
        • I am assumming you mean JMS or MSMQ by message queue.If this right, then I can say database can replace message queue but message queue can not replace database
    • 很多时侯用数据库可以做和Message Queue完全相同的事情,那给我一个使用Message Queue的理由啊。
      • if you use database to replace message queue, that means you are building your own JMS or MSMQ. can you do it better than IBM/MS?
        • 我做不过他们。但有时侯我并不需要mq的全部功能,很多时侯对于某个特定应用也许数据库会更方便一些。毕竟数据库提供比mq更强大的功能
          • I agree with you, if the task is simple, database is better.
      • 糊涂了,能先说说Database和Message Queue有什么相同的地方吗?
        • What JMS do for you is put your request for a method call to a queue to be executed later or when connection is available instead of running it immediately.
          What JMS do for you is put your request for a method call to a queue to be executed later or when connection is available instead of running it immediately.
          Using database to do the same thing, you can save your request to the database, and get the message from database later to process it.
          In a word it's for asynchronous processing.
          • 由于异步处理的特点,必须需要一个中间存储介质,数据库仅仅提供了这个介质,我不觉得因此就可以将database与message queue相比较。
            当然,对于特定的一步处理需求,也许数据库就可以(甚至,一个共享文件就可以了)
            Message Queue的大多数功能都是不容易用数据库实现的。
        • 它们都是用来管理数据的,一个偏重存储,一个偏重传输。但它们都支持数据存储和传输。mq可以理解成建立在数据库上的高级应用。
          • 从这个意义上说,可以举出1、高效率;2、平台中立;3、更多通讯支持;
            • 这个答案很好,能扩展开来更多讲讲吗?
              • 由于这个论题已经讨论到存储/传输这样的基本特性,我上面的回答其实也没什么太大意义。另外,如果要从coding角度谈,没什么不同。MQ是解决系统架构问题的,不是解决程序设计问题的。
    • 要搞清这个问题,先要搞清炉子和冰箱比有哪些优越性。
      • 微波炉与冰箱好像更有可比性些:D
    • 在使用MQ时,我把消息用它的API发送到MQ队列(MQ的数据库)里。如果使用数据库,我把消息放到数据库里。这并没有什么不同。但MQ提供一些高级功能,比如事务,可靠性,路由等,请从程序设计的角度上来谈有什么不同?
    • 我从上面的讨论似乎可以得出以下结论: 1)MQ可以联结各种平台,使程序不用考虑通讯对象(似乎数据库在这方面表现也不错)2)高效(谁能提供数据支持一下吗?)。还有其它的吗?
    • 数据库的读写要经过DBM,是一个庞大的复杂的应用程序,处理最终要交给os来办。msgq是操作系统的一部分,os本身进程之间的通讯都是通过msgq来完成的,效率可想而知。
      • 你如果是为了软件系统的独立性,可以考虑把两个大的模块之间的调用改为通过消息队列来通讯,这样比较灵活,。。。。。。
        你如果是为了软件系统的独立性,可以考虑把两个大的模块之间的调用改为通过消息队列来通讯,这样比较灵活,比如,可以同时发起多个守候进程来读消息对列,比调用强多了。但unix的消息队列很脆弱,体积有限,无法查询(我也许是错的。),功能有限。记住,消息队列就是为了甩开模块之间的调用才产生的。
    • My opinion: It seems you shouldn't put them together.
      As a developer, you can use MQ to create messaging applications since it provides the functionality directly, you create messaging applications in almost the same way that you create other kinds of application.

      A database is a database, it's not for dealing with the messaging, and can not provide you with the convinience of developing messaging applications.

      I guess what made you put them together is you can store large amouth of data through MQ. That is because MQ keeps a IMDB(in memory database). The IM makes the diffrence: you can't store your data in hard drive, it's just for tempory data.

      The above is just my own opinion and my understanding of MSMQ.