大 Kafka 消息与小消息 + DB答案

【问题标题】：Large Kafka messages vs small messages + DB大 Kafka 消息与小消息 + DB
【发布时间】：2015-03-06 15:59:43
【问题描述】：

在设计一个使用 Kafka 来分离/并行工作单元的系统时，我发现我有 2 个选择：

Data -> manipulate data -> store in DB -> send ID as message -> load data from DB using ID in message ->...

Data -> manipulate data -> send data as message -> load data from message ->...

第二个选项摆脱了在数据库中保存和加载数据的所有副作用代码，如果我这样做，那么我的代码会更好，我的单元有时可以成为一个纯函数。我也减少了数据库的负载。缺点是此消息可能很大，而消息传递系统通常设计为快速处理小消息。

我的问题是：

在什么时候（多少字节），对于 Kafka 而言，消息开始显得有点大？
还有哪些其他优点和缺点需要考虑？

【问题讨论】：

标签： architecture messaging apache-kafka

【解决方案1】：

kafka 中的大消息没有错。一个潜在的问题是代理和消费者必须解压缩消息并因此使用它们的 RAM。所以如果尺寸很大，它会对 RAM 施加压力（但我不确定什么尺寸能给你带来可见的结果）。

Benchmarking page from LinkedIn 很好地解释了消息大小的影响。所以我就把它留在这里。

我主要展示了 100 字节小消息的性能。较小的消息对于消息传递系统来说是更难的问题，因为它们会放大系统记账的开销。当我们改变记录大小时，我们可以通过以记录/秒和 MB/秒为单位绘制吞吐量来显示这一点。

因此，正如我们所料，这张图显示我们每秒可以发送的原始记录数随着记录变大而减少。但是，如果我们查看 MB/秒，我们会发现真实用户数据的总字节吞吐量随着消息变大而增加：

我们可以看到，对于 10 字节的消息，我们实际上是受 CPU 限制的，仅通过获取锁并将消息排入队列以进行发送——我们实际上无法最大化网络。但是，从 100 字节开始，我们实际上看到了网络饱和（尽管随着我们的固定大小的簿记字节在发送的总字节中所占的百分比越来越小，MB/秒继续增加）。

基于此，我不会太担心您的消息的大小，而是会继续您的第二个更简单的解决方案。

【讨论】：

@shmish111 不仅包含消息大小的部分，还包含整个文档。很酷的一点是，它是新的，来自真正了解 kafka 并在大型项目中使用它的人。
也让我想到，Kafka 可以在具有某种 CQRS 的环境中用作写入速度非常快的数据存储。例如，我们目前在 cassandra 中有文档作为“事实来源”，并且它们都有 TTL，如果信息单独存储以供查询（例如在弹性搜索中），Kafka 可以用更高的写入能力代替它。我们可能会大大减少我们使用的盒子的数量......

【解决方案2】：

kafka 代理配置中的message.max.bytes 属性定义了服务器可以接收的最大消息大小。默认值为1000000文档说

服务器可以接收的消息的最大大小。重要的是，此属性与您的消费者使用的最大获取大小同步，否则不守规矩的生产者将能够发布太大而消费者无法消费的消息。

【讨论】：

您知道消息大小是否对性能有很大影响吗？
对于非常大的消息大小的生产者/消费者可能会耗尽内存。由于Kafka消费者没有流式传输消息的概念，他们必须分配内存才能消费大消息。您可以尝试的一种选择是使用压缩。但这真的取决于您的用例。