在设计一个使用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 ->...第二种方法消除了在数据库中保存和加载数据的所有副作用，如果我这样做，那么我的代码就更好了，我的单元有时可以成为一个纯函数。我也减少了数据库的负载。缺点是这个消息可能很大，消息传递系统通常被设计成快速处理小消息。
我的问题是：
对于Kafka来说，消息在什么时候（多少字节）开始显得有点大？
还有哪些优点和缺点需要考虑？
2条答案
按热度按时间zbwhf8kr1#
Kafka的大信息没有错。一个潜在的问题是，代理和消费者必须解压缩消息，从而使用他们的ram。因此，如果尺寸大，它可以对ram施加压力（但我不确定什么尺寸可以给你明显的结果）。
linkedin的基准页面很好地解释了消息大小的影响。所以我就把它留在这里。
我主要展示了100字节小消息的性能。较小的消息对于消息传递系统来说是一个更困难的问题，因为它们放大了系统记账的开销。当我们改变记录大小时，我们可以通过以记录/秒和mb/秒为单位绘制吞吐量来显示这一点。
所以，正如我们所料，这个图表显示了我们每秒可以发送的原始记录数随着记录的增大而减少。但是，如果我们看看mb/秒，我们会发现随着消息变大，实际用户数据的总字节吞吐量会增加：
我们可以看到，对于10字节的消息，我们实际上受到cpu的限制，仅仅获取锁并将消息排队发送，我们实际上无法最大限度地扩展网络。但是，从100字节开始，我们实际上看到了网络饱和（尽管mb/秒继续增加，因为我们的固定大小簿记字节在发送的总字节中所占的百分比越来越小）。
基于此，我不会太担心您的消息的大小，只会继续您的第二个更简单的解决方案。
yks3o0rb2#
这个
message.max.bytes属性定义服务器可以接收的最大消息大小。默认值为1000000文件说服务器可以接收的最大消息大小。重要的是，此属性必须与用户使用的最大获取大小保持同步，否则不受约束的生产者将能够发布对用户来说太大而无法使用的消息。