使用acid属性提交到类似kafka+的日志数据库?

uujelgoq  于 2021-06-07  发布在  Kafka
关注(0)|答案(1)|浏览(346)

我计划测试如何使这种架构工作:
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)以实现快速事件存储吗?

piv4azn7

piv4azn71#

提供的问题的简单(1)答案:
正确设置事务隔离级别可能足以实现一致性,并且不必担心数据库回滚。您仍然可以偶尔创建不一致性,除非您将隔离级别设置为“serializable”。即使这样,你也可以保证始终如一,但仍然可能有不受欢迎的行为。例如,客户机创建一个客户,并使用异步api快速连续地放置一个发票,然后发票事件首先命中您的备份系统。在这种情况下,invoice事件将失效,客户机需要重试,希望此时已创建客户。如果您控制客户端并强制它们使用syncapi,那么很容易避免。
是否可以在关系数据库中存储事件取决于预期的数据集大小、硬件和访问模式。我是postgres的超级粉丝,你可以做很多事情来快速查找事件。我的经验法则是——如果你的手术台大小在2300-300gb以下,而且你有一台像样的服务器,那么postgres是一个不错的选择。对于事件源,通常没有连接,一种常见的访问模式是按id获取所有事件(可选地受时间戳限制)。postgres擅长这种查询,只要你能巧妙地索引。但是,事件订阅者将需要拉取这些数据,因此如果您有数千订阅者,则可能不太好,这在实践中很少发生。
“概念上正确”的回答:如果您仍然希望采用流式处理方法并从根本上解决争用条件,那么您必须在系统中的所有事件中提供事件排序保证。例如,您需要能够订购“添加客户1”事件和“为客户1创建发票”事件,以便随时保证一致性。对于分布式系统来说,这是一个很难解决的问题(例如向量时钟)。您可以使用一些适用于您的特定情况的巧妙技巧来缓解这种情况,例如,在上面的示例中,您可以在事件到达后端之前通过“customerid”对事件进行分区,然后您可以保证与同一客户相关的所有事件都将按创建顺序(大致)进行处理。
如果需要的话,我很乐意澄清我的观点。
(1) 简单vs简单:强制链接

相关问题