分布式应用程序中的数据库瓶颈

Question

我现在到处都听说了 SOA 和分布式应用程序。我想了解一些与保持单一数据源响应相关的最佳实践，或者如果您在每台服务器上都有数据副本，那么如何更好地同步这些数据库以使其保持更新？

Answer 1

这个问题有很多答案，为了选择最合适的解决方案，您需要仔细考虑您存储的数据类型以及您想用它做什么。

复制

这是许多 RDBMS 的传统机制，通常依赖于 RDBMS 提供的功能。复制具有延迟，这意味着尽管服务器可以独立处理负载，但它们可能不一定会读取最新数据。对于特定系统，这可能是也可能不是问题。当复制是双向的时，两个数据库上的同时更改可能会导致需要以某种方式解决的冲突。根据您的数据，选择可能很简单（即审计日志 => 都附加），也可能很困难（即酒店房间预订 - 取消一个？选择替代酒店？）。您还必须考虑在复制网络链接断开的情况下该怎么办（即您是否拒绝对两个数据库、一个数据库进行更新，或者允许数据库分流并在以后解决冲突）。这完全取决于您拥有的确切数据类型。对于读取繁重的系统，一种可能的折衷方案是使用单向复制到许多数据库进行读取，并将所有写入操作发送到源数据库。这始终是可用性和一致性之间的权衡（请参阅CAP Theorem）。 RDBMS 和复制的优势在于您可以轻松地以复杂的方式查询整个数据集，并有更多机会 通过使用数据项的关系链接删除重复。

分片

如果您的数据可以清晰地划分为不相交的子集（例如不同的客户），那么数据项之间所有可能的关系链接都包含在每个子集中（例如客户 -> 订单）。然后，您可以将每个子集放在单独的数据库中。这就是 NoSQL 数据库背后的原理，或者正如 Martin Fowler 所说的“Aggregate-Oriented Databases”。这种方法的缺点是它需要更多的工作来对整个数据集运行查询，因为您必须查询所有数据库然后组合结果（例如 map-reduce）。另一个缺点是，在分离数据时，您可能需要复制一些数据（例如，客户分片 -> 订单可能意味着产品数据被复制）。数据模式也很难管理，因为它独立于多个数据库，这就是为什么大多数 NoSQL 数据库都是无模式的。

每个服务的数据库

在微服务方法中，建议每个微服务应该有自己的专用数据库，不允许任何其他微服务（不同类型的）访问。因此，管理客户联系信息的微服务将数据存储在与管理客户订单的微服务不同的数据库中。可以使用全局唯一 ID 或 URI（特别是如果微服务是 RESTful）等在数据库之间建立链接。这样做的缺点是对整个数据集执行复杂查询更加困难（特别是因为所有访问都应该去通过不直接访问数据库的微服务 API）。

多语言存储

我过去的许多项目都涉及一个放置所有数据的 RDBMS。这些数据中的一些非常适合关系模型，但大部分不适合。例如，分层数据可能更好地存储在图形数据库中，股票报价存储在面向列的数据库中，html 模板存储在 NoSQL 数据库中。微服务的趋势是转向一种模型，将数据集的不同部分放置在根据需要选择的存储提供程序中。

Answer 2

如果您想为每个微服务保留不同的数据库副本并且想要实现最终的一致性，那么您可以使用 Kafka Connect。我可以简单地告诉您，kafka connect 将监视您的 DBS，并且每当有任何更改时，它都会读取日志文件并将这些记录的事件作为消息添加到队列中，然后另一个数据库是该队列的订阅者可以执行相同的语句也在他们身边。 Kafka connect 不是唯一的框架，您可以搜索并找到其他框架或应用程序以实现相同的实现。