我已经为消息传递设置了一个RabbitMQ，集成工作正常。我正在向队列发送消息，并从队列中消费。但是我如何确定在执行任务后向队列发送消息？
例如，在将新项目添加到DataBase之后，我应该将消息发布到队列。
DBContext.SaveChanges(item);
//what if an error occurred at this moment.
QueueManager.Publish(item)
在这种情况下，最佳做法是什么？任何建议都将不胜感激。
我阅读了此解决方案解决方案。
但我认为应该有一个更好的解决方案，因为这种方法有两个问题：
微服务架构中的- 可能有些数据库不支持原子事务
- 它需要额外的数据操作和从数据库中删除记录的额外后台服务
如何确定在执行任务？
创建新表名Event，使用包含未发布事件记录的Event表。数据库调用完成后，在事件表中创建一个条目，并将该事件标记为NonPublished。将事件发布到队列后，将该记录更新为已发布事件。
如果应用程序无法发布事件(队列系统关闭，发布程序失败(，会发生什么情况？
编写一个定期运行的后台作业/cron作业，该作业将检查所有Unpublished事件并发布到队列，并使状态为 Published有关事件驱动微服务的更多信息，请参阅下面的链接。 https://www.nginx.com/blog/event-driven-data-management-microservices/
在微服务架构中，一些数据库可能不支持原子事务
我认为，如果您能够处于发布可能失败的位置，并且功能至关重要，那么原子事务支持就不能是可选的。所以，若失败，则尝试发布回滚事务。这意味着在解决方案中，确保事件最终发布到消息队列系统的最佳方式是，我甚至不喜欢使用异步发布。
如果功能不是关键的，那么您可以进行所有类型的优化，包括在日志中放入错误消息，以防偶尔发布失败。
它需要额外的数据操作和从数据库中删除记录的额外后台服务
通常，用户更喜欢安全的方法，而不是遗憾的方法。因此，当功能不重要时，这应该是可以的。
您可以使用微服务的弹性模式中的重试模式。
Retry–源应用程序可以立即重试以将请求发送到服务。如果特定故障是不寻常或罕见的，则在重复请求时成功的概率非常高。
延迟后重试–源应用程序可以在一段时间后重试将请求发送到云服务(通常呈指数级增长(。当故障事件是由云服务繁忙等原因引起时，这是一种常见的做法。如果故障是由更常见的连接或繁忙故障之一引起的，则应用程序必须等待一段时间后重试。
来源：重试模式
我不知道我是误解了你的问题，还是其他回答你问题的人误解了，但据我所知，如果SaveChanges((成功完成，你想向队列发布消息？通常情况下，该方法应该返回布尔值或您正在保存的对象，因此如果返回true/则可以发送消息。
类似这样的东西：
if(DBContext.SaveChanges(item)) {
QueueManager.Publish(item)
} else {
// Error handling
}