4 ms·
From the OP source - " How does this feature work? Under the covers it works in a way similar to TCP; each batch of messages sent to Kafka will contain a seque
by makr96 9y ago
From the OP source -
" How does this feature work? Under the covers it works in a way similar to TCP; each batch of messages sent to Kafka will contain a sequence number which the broker will use to dedupe any duplicate send. "
- phamilton 9y agoThis is basically it. I'm always amazed at how much reimplementation of TCP we see at a high level in distributed systems. Backpressure, message ordering, retries, etc. all work pretty well in TCP.
- zekrioca 9y agoProbably these new over-layers of abstractions are needed for some use-cases in for specialized and more performant networks. Otherwise, the simple fact of using TCP would be enough. But indeed, it is interesting to see the computing cycle reimplementations spinning over and over again.
- nehanarkhede 9y agoRe: TCP, it only maintains sequencing guarantees over the lifetime of a single connection. Obviously this is too weak of a guarantee for Kafka as leaders can change in a cluster. We've built idempotence in a way that makes the sequence number and producer ID part of the Kafka log. So it can provide idempotence even if brokers fail and new connections are established between the producer and broker
- phamilton 9y agoYeah, my point wasn't "TCP does this, that's all we need". It was just an observation about how we apply principles at a higher level.
- boredandroid 9y agoYes the idempotence part of this feature set is very similar to TCP (the transactional consumption and updates obviously aren't). But this isn't a reimplementation at all. TCP provides deduplication within the context of a connection tied to a process. If that connection is lost or the process dies then duplicates may occur. The feature in Kafka is much stronger as the "connection" is persistent and replicated with the log so effectively the "connection" fails over if the server dies.