当我服务的每个客户机都有自己的kafka消费者时，我会考虑架构模式。例如，有 events 主题，其中包含一些复制因子和一些分区数，我使用它们来实现可伸缩性。给定客户机的所有事件都属于一个分区（我使用 clientId 分区键）。每个客户都有自己的 offset . 所以我的api允许 offset 获取客户端事件。系统设计好吗？或者什么是获取事件的正确api设计？
events
clientId
offset
eivnm1vs1#
这个问题有点含糊，所以在提出建议之前，让我先说说我的猜测。发布事件的单个主题。这些事件必须通知一些客户端（它们是移动应用程序还是什么的？）当前的设计每个客户机有一个使用者，这意味着至少为一个客户机分配一个线程。对当前设计的关注随着用户数量的增加，线程的数量也必须增加，这意味着该方法不能线性扩展。成本随着用户数量的增加而增加。如果使用者线程失败怎么办？这可能导致对客户端的通知失败。建议使用kstreams消费。将kstreams视为比consumerapi更高级别的消费api。使用numthreads属性可以配置线程数。因此，单一的kstream将充当消费者池。有一个路由逻辑来找到客户机并通知。权衡：这种路由逻辑增加了延迟。
1条答案
按热度按时间eivnm1vs1#
这个问题有点含糊，所以在提出建议之前，让我先说说我的猜测。
发布事件的单个主题。
这些事件必须通知一些客户端（它们是移动应用程序还是什么的？）
当前的设计每个客户机有一个使用者，这意味着至少为一个客户机分配一个线程。
对当前设计的关注
随着用户数量的增加，线程的数量也必须增加，这意味着该方法不能线性扩展。成本随着用户数量的增加而增加。
如果使用者线程失败怎么办？这可能导致对客户端的通知失败。
建议
使用kstreams消费。将kstreams视为比consumerapi更高级别的消费api。
使用numthreads属性可以配置线程数。因此，单一的kstream将充当消费者池。
有一个路由逻辑来找到客户机并通知。
权衡：这种路由逻辑增加了延迟。