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

Question

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

Answer 1

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

复制

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

拆分

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

数据库的每次服务

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

多语言存储

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

Answer 2

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