Splaycast

用于复制流，类似于广播。

与更通用且功能强大的 tokio::sync::broadcast 相比，Splaycast 更适用于特定应用，并且更适合处理大量订阅者。

关于

此工具的开发是为了解决在具有 10,000 - 200,000 个订阅者的 tokio::sync::broadcast 上观察到的高竞争问题。这表现为 Tokio 指标中的缓慢轮询，接收者获取消息的延迟极高 - 数百毫秒或更糟。

基准测试

我实现了一个通用的基准测试核心，它对广播和 Splaycast 都适用，以测试它们在不同场景中的差异 - 改变队列深度、订阅者数量和线程数量。在订阅者数量非常少的情况下，tokio::sync::broadcast 仍然是更好的选择。

在约 128 个订阅者处有一个拐点，此时 Splaycast 开始脱颖而出，到 16384 个订阅者时，与 Splaycast 相比，差距是 12.27ms，而与 tokio::sync::broadcast 相比是 43.6ms。这些测试是在 64gb M1 笔记本上进行的，因此尽管相对差异是相关的，但您应该对绝对测量持怀疑态度。

队列深度为 4，X 轴上的“输入大小”是订阅者数量的 4 倍。您可以看到，随着订阅者数量的增加，Splaycast 的行为与订阅者呈线性关系，但与广播相比，具有更低的常数因子。

如果我们仔细观察图表的底部，我们可以更明确地看到行为。这里，相同的队列深度=4和"输入大小"意味着4x订阅者数量，您可以看到，在256个订阅者或以下，您使用哪种Stream splitter并没有太大区别。但是在512个及以上的订阅者数量时，差异变得越来越明显。