我有一个CRUD网络服务，我们的任务是尝试找出一种方法来确保在数据库出现故障时不会丢失数据。每个人都知道，如果数据库出现故障，我们将无法获得“读取”，但对于特定的操作子集，我们希望确保不会丢失数据。
我给人的印象是，这是0MQ，RabbitMQ或其中一个Microsoft MQ服务所涵盖的内容。虽然经过几天的阅读和研究，我甚至不确定我们在MQ服务中讨论的消息是否包括数据库操作。然而，我百分百肯定我可以排队尽可能多的你好世界。
如果我可以使用消息队列为数据库添加一层保护，我会倾向于使用Rabbit（因为它似乎会在崩溃时持续存在），但由于目标是Microsoft SQL服务器数据库，可能是其中一个解决方案（例如SQL Service Broker或MSMQ）更合适。
我现在还不确定的真正基本问题是我是否正在使用正确的牌组（可以这么说）。
由于需要高可用性的Web服务，如果数据库出现故障，它仍继续运行，将Rabbit MQ实例放在“Web服务和数据库”之间是否有意义？也许链中的正确链接是让RabbitMQ向网络服务器发送消息？
或者是否有其他解决方案可以实现这一目标？目前有很多想法在数据库中断或其他事情中找到一种卷起博客的方法......但是我们还处于足够早的阶段（至少我）不知道我是什么我要去做。
消息队列是否是正确的解决方案？
答案 0 :(得分：2)
在服务及其数据库操作之间引入消息队列肯定是提高服务可用性的一种方法。写入store-and-forward方案中的本地临时队列总是比写入远程数据库服务器更容易，只需要进行本地操作即可。
此外，通过使用排队，您可以更好地控制数据库在峰值时必须处理的数据库流量的数量和性质。数据库写入可以按不同顺序排队，路由甚至提交。
但是，为了做到这一点，您需要注意，当执行数据库写入时，它将被脱机处理。即使在几乎瞬间发生这种情况的情况下，您也会失去当前服务的同步特性给您带来的好处，即您的服务使用者始终可以知道数据库写入操作是否成功。
我在here之前写过这个主题。发布问题的用户也有类似的问题。无论您是否这样做，都必须根据消费者是否关心这一点做出决定。
至于技术堆栈，你正在考虑这个离线模型可以实现它们中的任何一个，可能的例外是Service Broker，它没有将井与代码集成（在这里看到我的答案：https://stackoverflow.com/a/45690344/569662）。
如果你正在使用Windows并且不太可能需要迁移，我会选择MSMQ（它支持通过事务性队列的持久消息传递），因为它是轻量级的并且是Windows的一部分。