我们有两个系统，系统A向系统B发送数据。要求每个系统都可以独立运行，如果另一个系统停机，两个系统都不会爆炸。问题在于系统A在满足解耦要求的同时与系统B进行通信的最佳方式是什么。数据库良好的系统解耦点？
系统B当前有一个轮询db表中的数据并处理已插入的新行的进程。
一个建议的设计是系统A只是将数据插入到系统b的数据库表中，并让系统B通过现有进程处理新行。问题是这个解决方案是否符合解耦两个系统的要求？数据库是否被认为是系统B的一部分，可能会变得不可用并导致系统A爆炸？
另一种解决方案是系统A将数据放入MQ队列中，并拥有一个从MQ中读取数据并插入到系统B数据库中的进程。但是这只是额外的开销？最终是一个MQ队列比数据库表更容错？
一般来说，数据库共享是一种紧密的耦合，除了可能用于速度目的之外，不是优选的。不仅出于可用性目的，还因为系统A和B将在未来的几个时间点进行更改和升级，并且对彼此的依赖性最小 - 消息传递是明显的依赖性，而共享数据库往往会咬你（或你的继承者）在最不可预料的后面。如果你使用数据库共享路由，至少应该使用专用表或视图来显式共享接口。
有整合的四种常见的层次：
可以在各种应用和组合情况，具有不同的可用性和可维护性。您对enterprise integration patterns site有很好的概述。
与任何中央集成基础架构一样，MQ应该托管在具有高可用性的环境中，完全故障切换& c。还有其他队列解决方案可让您分配队列协调。
使用队列进行通信。不要通过数据库将数据从系统A“传递”到系统B.您将数据库用作庞大，昂贵且复杂的消息队列。
使用消息队列作为消息队列。
这不是“额外”开销。这是分离系统的最佳方式。它被称为面向服务的体系结构（SOA），使用消息绝对是设计的核心。
MQ队列比数据库表简单得多。
不要比较“容错”，因为RDBMS使用巨大的（几乎不可想象的）开销来达到合理的保证您的事务正确完成的程度。锁定。缓冲。编写队列。存储管理。等等
可靠的消息队列实现使用一些后备存储来保持队列的状态。开销远远小于RDBMS。性能要好得多。交互起来要简单得多。
在SQL Server中，我会通过SSIS包或作业（取决于记录数和我正在移动的复杂度）来执行此操作。其他数据库也有ETL解决方案。我喜欢ETL解决方案，因为我可以记录更改内容和处理的错误日志，因此我可以将由于某种原因不会进入其他系统（两个数据库之间的数据结构几乎相同）的记录发送到某个存储库表没有杀死其余的过程。我还可以在数据流动时对数据进行更改，以调整数据库之间的差异（比如查找表值，比如说db1中的完成状态是5，db2中是7，或者说db2有一个必填字段，db1不会和您如果它为空，则必须将缺省值添加到该字段中）。如果其中一个或另一个服务器关闭，那么运行SSIS包的作业将失败，并且这两个系统都不会受到影响，因此它将使数据库与使用触发器或复制不相关。