Microservices 多个微服务共享同一数据库时的微服务设计

我在inteview上被问到一个问题，我做了很多研究，但没有得到明确的答案。我只是想知道最佳实践，所以请帮助我-

如果有10个微服务，并且在理想情况下，它应该有自己的数据库。但是，如果10个微服务与公共数据库交互，那么这里应该进行调整，您将如何使其一致

我的想法是，理想情况下，最好的选择是像oracle sql这样的数据库，它遵循acid属性，确保写操作正在进行，acid属性得到维护，但他对答案不满意……理想情况下，如果有一个数据库，那么一次只能有一个数据库进行写操作，并且在一个数据库写入另一个数据库时有机会进行写操作服务可以读取陈旧数据，这样他就不需要陈旧数据

我建议使用缓存，这样我们首先在缓存中写入，然后在db中写入，这样其他服务可以从缓存中读取并获取更新的值

---

他对此并不满意……请分享你的想法。我浏览了多个博客，但没有得到任何令人满意的答案。

首先，我想让你知道，没有严格的规则规定不同的微服务需要不同的数据库。 相反，规则是

服务必须是松散耦合的，以便它们可以独立地开发、部署和扩展。
因此，模式可以是每个服务的
数据库或共享数据库。

在您的例子中，它是一种共享数据库模式。通常，人们不会喜欢它，因为他们认为他们的服务将直接访问其他服务的数据（在本例中，它将是一个表）。这是不正确的，因为如果您的服务依赖于其他服务的数据或数据库模式，那么您的服务就不会是松散耦合的服务，也不会独立扩展

In the microservices world, each microservice’s persistent data is private to that service and accessible only via its API. 

回到你的案例，我不知道为什么你的面试官不相信数据库引擎的酸性特征，因为你使用的是同一个数据库，因为同样的场景也可能发生在每个服务的数据库设计中。假设同一个应用程序的两个线程，一个在写，另一个在读，可以在相同的情况下结束。
我想他可能期待着一个不同的答案，比如分布式事务和SAGA模式等，这在本例中并不相关。
在给定的上下文中，
一致性
意味着什么？有ACID一致性和逻辑一致性（在业务层上）。您是否熟悉术语“最终一致性”

？对于最终一致性，您需要有一个副本和一个副本。他希望更新后的结果最终不一致。为了最终一致，你需要有一个副本：不是真的，虽然你是对的，但它可以在db的单个实例中显示，考虑到涉及到队列和利用它们进行通信的服务。