Kafka作为真相来源是推荐的吗？

Question

我们的应用程序需要非常高的写入吞吐量（在高峰时期每秒数千次写入），并且数据需要进入多个数据存储，如Elastic-Search、HDFS、Cassandra和Cache。（没有关系型数据库，谢天谢地）

如何处理这个问题是最好的方式？

将Kafka作为真相来源，让所有其他数据存储可以通过Spark/Storm流式传输读取，这是一个好主意吗？

Kafka会有数据丢失的风险吗？ 与直接写入Cassandra相比，数据丢失的潜在风险是否更大？

编辑：我看到的一个问题是，Cassandra强加的约束条件与Kafka强加的不同。由于Kafka不强制执行任何限制并且将接受任何数据，因此它可能会通过向Kafka写入数据给应用程序提供错误的成功事务感觉。由于某些约束条件在Cassandra中被违反，相同的数据可能无法成功写入Cassandra。来自Cassandra的约束失败示例：InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid INTEGER constant (500) for "name" of type text"。应用程序可能会经历某些数据类型的变化，而Kafka正在愉快地接受它，而下游的Cassandra消费者正在失败。（如何通过暂存、QA等阶段进行更改是另一回事）。因此，使用Kafka作为真相来源的风险在于它会提供错误的成功感觉。

- user2250246

Answer 1

把 Kafka 作为真相来源，所有其他数据存储都可以从中读取是一个好主意吗？

完全可以。Kafka 最初就是为这种模式设计的。即使 Kafka 现在已不仅仅是消息代理/发布-订阅系统，也在 Kafka 0.10 中添加了流处理功能。

Kafka 存在数据丢失的风险吗？

只要你的数据被确认（acked），就不存在数据丢失的风险。在 Kafka 中，你可以同步或异步地写入，还可以配置在生产者接收到“ack”之前需要有多少个代理副本复制了你的数据。详见 http://docs.confluent.io/current/clients/producer.html

Kafka 的数据丢失潜在风险比直接写入 Cassandra 更大吗？

我对 Casandra 不是很熟悉，但我认为 Casandra 并没有比 Kafka 提供更强的容错能力——这一切都取决于你配置的副本数量（你可以为 Casandra 和 Kafka 都进行配置）。

关于 Kafka 中可能存在损坏数据的情况：Kafka 不会检查任何写入的数据，它只处理代理侧的 byte[]。因此，是的，你应该在生产者上应用策略，以确保不会将损坏的数据写入主题。但是，你可以使用 AVRO 作为数据类型，这将有助于防止损坏的数据。

- Matthias J. Sax

---

谢谢Matthias。你应该在生产者上应用策略，以确保没有损坏的数据写入主题。实际上，这非常难做到，因为下游系统可能有各种约束条件，其中一些只能由下游系统进行检查。例如：如果下游系统是关系型数据库，则可能会执行某些外键检查或唯一键检查。这些检查只能由实际的下游工具完成。 - user2250246

是的。但如果不同的下游系统有不同的约束条件，没有一个系统可以完美地强制执行所有这些约束条件--要么应用最强的约束条件（从而限制了一些消费者），要么应用最弱的约束条件，而一些下游系统需要更强的约束条件。 Kafka 的想法是解耦生产者和消费者--生产者不应该决定消费者如何处理数据。因此，每个消费者都应该对数据应用自己的约束条件，并且只丢弃不符合其所需约束条件的数据。 - Matthias J. Sax

是的，这正是我的观点。基本上，问题是关于使用Kafka作为真相来源。常见的真相来源是像MySQL或Cassandra这样的数据库。所以我试图列举可能遇到的问题，当他们用Kafka替换他们的DB真相来源时。这不是Kafka的限制，可能是一种设计缺陷，因为上述问题替换了DB真相来源。因此，也有评论说，在Kafka生产者代码中预先强制执行所有SOT约束很困难。 - user2250246

是的，那很有道理。Kafka 大致上用于捕获“原始数据”。在这个意义上，如果你有一个 FK 约束，Kafka 将捕获有人尝试将某些内容插入到数据库中这一事实 —— 如果消费者数据库拒绝了此插入，则与此“原始事实”无关。如果数据库是“真相之源”，则用户会被告知插入失败，但是用户尝试插入的“事实”将丢失。Kafka 将捕获此事实，您需要一种方法向用户通信（可能是另一个主题），以检查 DB 插入是否成功。 - Matthias J. Sax

当尝试替换现有的“真相来源”数据库时，应记住上述内容，并准备好在进行替换时修复/面对约束问题。 - user2250246