5

This is not so much of a coding question per se, but more of a architecture design for real-time streaming application. We have the following setup:

  • Multiple embedded IoT devices in the field (so low memory, but option to have some extended local storage)
  • They all are streaming their data in real-time to a Kafka cluster, acting as producers and then we have post-processing applications that act as consumers and help store the data in a database.
  • Now sometimes these IoT devices would loose connection to one of the nodes in the Kafka cluster, since the network connections in the field are not always reliable. These sort of disconnections could last up to a day typically.

Now I understand that Kafka takes care of nodes (acting as brokers) failing in the cluster, but what if I have a situation where the producer just does not have a good network connection and just cannot publish its data to the Kafka topic because it cannot see it?

We cannot afford to loose any data, but the good news is that we have expandable storage options for the embedded IoT devices where we could save the data when the IoT device goes offline and then stream it when the connection is back up. Is this something that is recommended with Kafka? In particular I have the following questions:

  1. Does Kafka have a built in way for the producers to have some kind of offline on-disk (NOT in-memory) storage cache?
  2. How does Kafka deal with messages to topics that just cannot be sent, due to network connectivity issues? Is there a way to just schedule them in a queue and then wait until the connection to the cluster is back up?
  3. What kind of local storage options could I use which I can easily interface with as my on-disk cache?
  4. How about having a redundant local time-series database (on the embedded device's storage) just collecting all the data stream and then have an agent take care of the sending of the data to the Kafka cluster, and then clean the database up when it gets an acknowledgement from the Kafka broker?
  5. Are there any other ways to deal with these situations where the Kafka Producers have intermittent connection to the cluster and can just sent the stream data in chunks when it is connected?
OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
Atif Ali
  • 2,186
  • 2
  • 12
  • 23
  • I am going thorough the documentation too in case I find some suggestions or hints in there and so far I have found the section here: https://kafka.apache.org/intro.html (Kafka as a Storage System) and then there is some information regarding persistence here: https://kafka.apache.org/documentation/#design. I'll keep looking but I am hoping that somebody has already dealt with this issue before and can enlighten me or point me in the right direction! – Atif Ali Dec 11 '19 at 17:54
  • I've found, but not tried, this library https://github.com/artiship/rocks-kafka-producer, which claims to cache messages first before forwarding them to Kafka. – aSemy Oct 15 '22 at 05:46

1 Answers1

4

Kafka producer doesn't provide offline mode, not is it able to stream data in chunks AFAIK. What I suggest you do is have a callback for the producer send, and on failure, write the content of the message to local storage. Then you should have a background thread that picks all flushed data from local storage and endlessly try to send it using a producer. Basically it's the naive approach for your suggestion with time-series DB on the device. But whether it's FS or DB on the device, that's the only approach to meet your needs.

Lior Chaga
  • 1,424
  • 2
  • 21
  • 35
  • 3
    Just a side note for anyone who ever stumbles on this again, we ended up going with using a MQTT based messaging system which basically perfectly fit our needs as described in my original question. Feel free to share any different suggestions that have worked for you! – Atif Ali Mar 15 '21 at 15:45
  • @AtifAli what was the MQTT messaging system that you chose? Can you share the link to that library? I'm in a similar situation. Unreliable producer connection. Need to protect data from loss even before it reaches the broker! – azmath Jun 08 '22 at 07:57
  • @azmath should be ok to use any usual broker/client library. Nothing special. Here is a list you can pick from based on your application: [MQTT Implementations](https://en.wikipedia.org/wiki/Comparison_of_MQTT_implementations) – Atif Ali Jun 08 '22 at 08:07