数据库好系统解耦点？

Question

我们有两个系统，其中系统A向系统B发送数据。要求每个系统可以独立于另一个系统运行，如果另一个系统停机，它们都不会爆炸。问题是系统A在满足解耦要求的同时与系统B通信的最佳方式是什么。

系统B当前有一个进程，它轮询db表中的数据并处理已插入的任何新行。

一个提出的设计是系统A只是将数据插入到系统b的db表中，并让系统B通过现有过程处理新行。问题是这个解决方案是否满足解耦两个系统的要求？数据库是否被视为系统B的一部分，可能变得不可用并导致系统A爆炸？

另一种解决方案是系统A将数据放入MQ队列并拥有一个从MQ读取然后插入系统B数据库的进程。但这只是额外的开销吗？最终，MQ队列是否比db表更具容错性？

Answer 1

一般来说，数据库共享是一种紧密耦合，除非可能用于速度目的，否则不是首选。不仅是出于可用性目的，还因为系统A和B将在未来的几个点进行更改和升级，并且彼此之间应该具有最小的依赖性 - 消息传递是明显的依赖性，而共享数据库往往会咬你（或者你的继承人）在后期最不期望的时候。如果您使用数据库共享路由，至少使用专用表或视图使共享接口显式化。

有四种常见的整合水平：

1. 数据库共享
2. 文件共享
3. 远程过程调用
4. 消息传递

可以在各种情况下应用和组合，具有不同的可用性和可维护性。您对enterprise integration patterns site有一个很好的概述。

与任何中央集成基础架构一样，MQ应托管在具有高可用性，完全故障转移和c的环境中。还有其他队列解决方案允许您分发队列协调。

Answer 2

使用队列进行通信。不要通过数据库将数据从系统A“传递”到系统B.您将数据库用作庞大，昂贵，复杂的消息队列。

使用消息队列作为消息队列。

这不是“额外”开销。这是解耦系统的最佳方法。它被称为面向服务的体系结构（SOA），使用消息绝对是设计的核心。

MQ队列比DB表简单得多。

不要比较“容错”，因为RDBMS使用巨大的（几乎无法想象的）开销来实现合理的保证，以确保您的事务正确完成。锁定。缓冲。写队列。存储管理。等等。

可靠的消息队列实现使用一些后备存储来保持队列的状态。开销远远低于RDBMS。性能要好得多。与它进行交互要简单得多。

Answer 3

在SQL Server中，我会通过SSIS包或作业执行此操作（取决于记录的数量和我移动的复杂程度）。其他数据库也有ETL解决方案。我喜欢ETL解决方案，因为我可以记录已更改的内容和处理的错误，我可以发送由于某种原因不会转到其他系统的记录（数据结构在两个数据库之间很少相同）到持有表没有杀死剩下的进程。我也可以对数据进行更改，以便调整数据库差异（比如查找表值，比如db1中的已完成状态为5，db2中为7或者说db2有db1不需要的字段，而你如果为null，则必须向字段添加默认值。如果一个或另一个服务器关闭，则运行SSIS包的作业将失败，并且系统都不会受到影响，因此它会将数据库分离，因为使用触发器或复制不会。