redis流消费群体数量上限？
Upper limit on number of redis streams consumer groups?
我们正在考虑使用 Redis 流作为集群范围的消息传递总线，其中集群中的每个节点都有一个唯一的 ID。这个想法是，每个节点在生成时都会创建一个具有该唯一 ID 的消费者组到中央 redis 流，以保证集群中的每个节点都能获得每条消息的副本。在编排环境中，集群节点将动态生成和删除，每个节点都有一个唯一的 ID。随着时间的推移，我可以看到这导致有 100 甚至 1000 个 old/unused 消费者群体都订阅了同一个 redis 流。
我的问题是 - Redis 可以处理的消费者组数量是否有上限，大量（未使用的）消费者组是否有任何实际处理成本？似乎消费者组只是存储在 redis 中的一个指针，它指向流中的最后一个读取条目，并且仅在该组的消费者执行范围 XREADGROUP 时才被访问。这会让我假设（不深入研究 Redis 代码）消费者群体的数量真的无关紧要，除了消费者群体指针会吃掉的少量 RAM。
现在，我明白我们应该更聪明，一个节点应该在它被杀死时删除它自己的消费者组，或者我们应该定期清理它，但是如果一个消费者组只是 redis 中的一条记录，我不确定是否值得付出努力 - 至少在开发的 MVP 阶段。
TL;DR;
我的理解是否正确，给定流的消费者组数量没有实际限制，除非使用，否则它们没有处理成本？
你的理解是正确的，CG的数量没有实际限制，不会影响运行性能。
也就是说，除了浪费的 RAM（这可能会变得很重要，具体取决于组中的消费者数量和 PEL 条目），这会增加 XINFO STREAM ... FULL 和 [=11 调用的时间复杂度=] 因为这些列出了 CG。一旦你拥有大量的 CG，对这些的每次调用都会变慢（并在服务器执行时阻塞服务器）。
因此，我仍然建议为“过时的”CG 实施某种类型的“垃圾收集”，也许在 MVP 完成后立即实施。与任何计算资源（例如磁盘 space、网络、互斥量...）一样，天下没有免费的午餐，CG 也需要管理。
P.S。 IIUC，您计划在每个组中使用一个消费者，并让每个 CG/consumer 对应于您应用集群中的一个节点。如果是这种情况，我不确定您是否需要 CG，您可以使用更简单的 XREAD（而不是 XREADGROUP），同时将最后一个 ID 保留在节点本地。
OTOH，假设我遗漏了一些东西并且确实需要这种使用模式，我想 Redis 能够通过为空闲组提供某种形式的到期来更好地支持它。
我们正在考虑使用 Redis 流作为集群范围的消息传递总线，其中集群中的每个节点都有一个唯一的 ID。这个想法是，每个节点在生成时都会创建一个具有该唯一 ID 的消费者组到中央 redis 流，以保证集群中的每个节点都能获得每条消息的副本。在编排环境中，集群节点将动态生成和删除，每个节点都有一个唯一的 ID。随着时间的推移，我可以看到这导致有 100 甚至 1000 个 old/unused 消费者群体都订阅了同一个 redis 流。
我的问题是 - Redis 可以处理的消费者组数量是否有上限，大量（未使用的）消费者组是否有任何实际处理成本？似乎消费者组只是存储在 redis 中的一个指针，它指向流中的最后一个读取条目，并且仅在该组的消费者执行范围 XREADGROUP 时才被访问。这会让我假设（不深入研究 Redis 代码）消费者群体的数量真的无关紧要，除了消费者群体指针会吃掉的少量 RAM。
现在，我明白我们应该更聪明，一个节点应该在它被杀死时删除它自己的消费者组，或者我们应该定期清理它，但是如果一个消费者组只是 redis 中的一条记录，我不确定是否值得付出努力 - 至少在开发的 MVP 阶段。
TL;DR; 我的理解是否正确，给定流的消费者组数量没有实际限制，除非使用，否则它们没有处理成本？
你的理解是正确的，CG的数量没有实际限制，不会影响运行性能。
也就是说，除了浪费的 RAM（这可能会变得很重要，具体取决于组中的消费者数量和 PEL 条目），这会增加 XINFO STREAM ... FULL 和 [=11 调用的时间复杂度=] 因为这些列出了 CG。一旦你拥有大量的 CG，对这些的每次调用都会变慢（并在服务器执行时阻塞服务器）。
因此，我仍然建议为“过时的”CG 实施某种类型的“垃圾收集”，也许在 MVP 完成后立即实施。与任何计算资源（例如磁盘 space、网络、互斥量...）一样，天下没有免费的午餐，CG 也需要管理。
P.S。 IIUC，您计划在每个组中使用一个消费者，并让每个 CG/consumer 对应于您应用集群中的一个节点。如果是这种情况，我不确定您是否需要 CG，您可以使用更简单的 XREAD（而不是 XREADGROUP），同时将最后一个 ID 保留在节点本地。
OTOH，假设我遗漏了一些东西并且确实需要这种使用模式，我想 Redis 能够通过为空闲组提供某种形式的到期来更好地支持它。