我计划测试如何使这种架构工作：
http://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/
所有数据都作为事实存储在日志中，但发布更改时的验证必须针对表。例如，如果我发送一个“createinvoicewithcustomer1”，我将需要验证客户是否存在以及其他内容，然后当验证通过时，提交到日志并将当前更改放到表中，这样表就有了最新的信息，我就有了所有更改的历史记录。
我可以将日志放入表中的数据库（我使用postgresql）。然而，我担心这样做的可伸缩性，而且，我希望从多个客户机和pg的其他rdbms的事件流，我知道让我这样做没有轮询。
但是如果我使用kafka，我担心两个存储之间的acid，所以kafka可能会得到错误的数据，pg回滚或者类似的东西。
所以：
1-可以保持rdbms和日志存储之间的一致性吗？2-可以实时支持并调整pg（或其他rdbms）以实现快速事件存储吗？
1条答案
按热度按时间piv4azn71#
提供的问题的简单（1）答案：
正确设置事务隔离级别可能足以实现一致性，并且不必担心数据库回滚。您仍然可以偶尔创建不一致性，除非您将隔离级别设置为“serializable”。即使这样，你也可以保证始终如一，但仍然可能有不受欢迎的行为。例如，客户机创建一个客户，并使用异步api快速连续地放置一个发票，然后发票事件首先命中您的备份系统。在这种情况下，invoice事件将失效，客户机需要重试，希望此时已创建客户。如果您控制客户端并强制它们使用syncapi，那么很容易避免。
是否可以在关系数据库中存储事件取决于预期的数据集大小、硬件和访问模式。我是postgres的超级粉丝，你可以做很多事情来快速查找事件。我的经验法则是——如果你的手术台大小在2300-300gb以下，而且你有一台像样的服务器，那么postgres是一个不错的选择。对于事件源，通常没有连接，一种常见的访问模式是按id获取所有事件（可选地受时间戳限制）。postgres擅长这种查询，只要你能巧妙地索引。但是，事件订阅者将需要拉取这些数据，因此如果您有数千订阅者，则可能不太好，这在实践中很少发生。
“概念上正确”的回答：如果您仍然希望采用流式处理方法并从根本上解决争用条件，那么您必须在系统中的所有事件中提供事件排序保证。例如，您需要能够订购“添加客户1”事件和“为客户1创建发票”事件，以便随时保证一致性。对于分布式系统来说，这是一个很难解决的问题（例如向量时钟）。您可以使用一些适用于您的特定情况的巧妙技巧来缓解这种情况，例如，在上面的示例中，您可以在事件到达后端之前通过“customerid”对事件进行分区，然后您可以保证与同一客户相关的所有事件都将按创建顺序（大致）进行处理。
如果需要的话，我很乐意澄清我的观点。
（1） 简单vs简单：强制链接