大型Kafka消息与小消息+ DB

Question

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

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 ->...

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

我的问题是：

1. 在什么时候（多少字节）消息开始对Kafka来说有点大？
2. 还有哪些其他优点和缺点需要考虑？

Answer 1

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

  

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

Answer 2

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

Benchmarking page from LinkedIn对邮件大小的影响有很好的解释。所以我会把它留在这里。

---

我主要在小的100字节消息上显示性能。较小的消息是消息传递系统的难题，因为它们放大了系统簿记的开销。我们可以通过在记录/秒和MB /秒两者中绘制吞吐量来显示这一点，因为我们会改变记录大小。

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

我们可以看到，对于10字节的消息，我们实际上只是通过获取锁定并将消息排入队列来进行CPU绑定 - 我们无法实际最大化网络。但是，从100字节开始，我们实际上看到网络饱和（尽管MB /秒继续增加，因为我们的固定大小的簿记字节变得占发送总字节数的比例越来越小。）

---

基于此，我不会过分担心您的消息大小，并且会继续使用您的第二个更简单的解决方案。