每Pipeline不能多个Sink的问题

[loggie-io]

每Pipeline不能多个Sink的问题

[mmaxiaolei]

一个pipeline多sink的核心问题在于不同消费速率的sink如何合理的给source ack。大致有3个方案：

• 按照最慢的那个sink去ack source，那其他sink必然受最慢的那个sink影响。特别是当有个sink挂掉的时候，其他sink也得不到数据，这是我们不希望发生的
• 分别记录不同sink的ack offset。这个对于source端的实现要求很高。特别是loggie reload或者挂掉重启的时候，需要根据不同的offset读取多份数据，这基本和多个pipelie没有什么区别
• 使用可持久化的queue(比如file queue)。由queue去维持不同sink的ack offset。这个方案会有2次”事务“，source到queue和queue到sink的确认，性能影响较大

内部有讨论过配置上支持多sink，但是实现上其实是多个pipeline的形式。有更好的方案欢迎大家提issue或者pr。至于多个sink不同的拦截器(和配置)的问题，其实可以很方便支持，类似source.Interceptor中的belongTo

[ethfoo]

#123

[ethfoo]

可能opentelementry-collector的多pipeline复用source的方式才可以解决这个问题？

我印象中，opentelemetry-collector虽然配置里只配置里一个source，但是实际上运行的时候会生成多个pipeline吧。这样本质上和Loggie配置多个pipeline去实现多个sink一样了。（可能配置上看起来会简洁一点？）

多Sink实现上的挑战，最本质的点还在于source和sink的（采集-> 发送）进度同步问题。
A. 单source改造：如果只有一个source，那么需要这个source感知到多个sink的发送进度(offset)，这样才能保证不丢失(at least once)，但这样对source要求太高不合适，而且可能对sink有强依赖。
B. 单持久化队列：退而求次，如果有一个持久化队列，那么只需要source发送到queue后，就认为发送成功，这样source采集的进度就可以在source-> queue端同步。多sink场景下，依然需要保证queue->sink->的事务，实现的复杂性放在了queue里。（需要所有的sink ack后才能删除queue里的数据？）
C. 一对一的sink持久化队列：在这种情况下，即使有多个queue，每个queue对应一个sink，仍然存在多个sink的发送进度不同步的问题（某个sink不可用实际上也可以理解为这个sink发送的进度慢），这个时候，一般的策略可能也就是某一个queue满了，则阻塞source，否则source仍然需要感知并维护多个queue的ack，但是这样依旧会导致sink之间互相影响。

所以，综合看起来，其实配置一个另外的pipeline去做多sink，缺点可能只有额外的source的资源，对比持久化队列所占的资源，可能还更少一点。这里面的trade-off，感觉需要再进一步的讨论。

看起来老哥你研究的还挺深的，欢迎加Loggie bot，我们再详细探讨。https://loggie-io.github.io/docs/getting-started/overview/#_3

[JeffPhoneix]

好的，已加。感谢master答疑解惑