Memulai dengan kebutuhan Optocam Zero

Optocam Zero memindai frame dari kamera dan menyimpannya ke lokasi pusat atau cloud. Raspberry Pi Zero sering beroperasi dengan konektivitas terbatas dan harus dapat mengirim/menyinkronkan gambar secara andal tanpa mengganggu jalur utama capture. Dalam paragraf pertama ini, jawaban inti: gunakan worker queue terpisah untuk mengelola kiriman gambar ke cache dan sistem distribusi, lalu sinkronkan cache lokal dengan worker queue yang menjamin konsistensi dan pemrosesan ulang (retry).

Sinkronisasi gambar berarti menyeimbangkan dua hal: throughput data (menjaga queue tetap bergerak) dan konsistensi cache (menghindari gambar kadaluarsa atau duplikat). Solusi ini harus menjaga latensi rendah agar preview tetap responsif.

Komponen arsitektur worker queue dan cache terdistribusi

Di lingkungan Raspberry Pi Zero, batasan memori dan CPU memaksa kita mengandalkan solusi ringan. Arsitektur yang efektif mencakup:

  • Worker queue yang mendistribusikan pekerjaan unggahan gambar ke sistem cache global. Redis Streams cocok karena menyediakan persistence ringan, consumer group untuk paralelisme terbatas, dan built-in acknowledgement.
  • Cache lokal pada Raspberry Pi (misalnya filesystem atau SQLite) sebagai cache utama untuk menampilkan preview.
  • Sinkronisasi terjadwal menggunakan worker untuk mengirim gambar baru dari cache lokal ke Redis, serta menangani ack/timeout.
  • Locking pada tingkat koordinasi worker (misalnya Redis simple lock) agar tidak ada dua worker mencoba memodifikasi entry cache yang sama.

Konfigurasi ini juga harus menyediakan backlog control untuk mencegah antrean menumpuk selama koneksi tidak stabil.

Desain worker queue dan mekanisme locking

Setiap gambar yang siap dikirim memasuki stream dengan payload minimal: ID gambar, path lokal, timestamp capture. Worker dibatasi 1-2 thread pada Raspberry Pi untuk menjaga resource.

Contoh alur:

  1. Gambar disimpan ke cache lokal dan metadata dimasukkan ke Redis Stream optocam:queue.
  2. Worker menggunakan consumer group untuk membaca entry. Ketika memproses, worker menetapkan lock di Redis (TTL pendek) untuk memastikan hanya satu worker yang menulis cache terdistribusi atau men-trigger upload.
  3. Jika upload gagal, worker membiarkan entry tetap di stream dan mengatur retry cap. Consumer melakukan XACK hanya setelah upload sukses.

Berikut contoh sederhana worker Redis Streams dengan Python (skrip harus dijalankan pada Pi atau server pendukung):

from redis import Redis

client = Redis()
stream = 'optocam:queue'
consumer_group = 'pi-zero'
consumer_name = 'worker-01'

while True:
    messages = client.xreadgroup(consumer_group, consumer_name, {stream: '>'}, count=1, block=5000)
    if not messages:
        continue
    for stream_name, entries in messages:
        for entry_id, payload in entries:
            lock_key = f"lock:{payload[b'image_id'].decode()}"
            if client.set(lock_key, consumer_name, nx=True, ex=30):
                try:
                    # proses upload/cache sinkron
                    upload_image(payload[b'path'].decode())
                    client.xack(stream, consumer_group, entry_id)
                finally:
                    client.delete(lock_key)
            else:
                client.xclaim(stream, consumer_group, consumer_name, min_idle_time=10000, message_ids=[entry_id])

Kunci ini memastikan worker lain tidak mengambil entry yang sama saat masih diproses.

Penanganan konsistensi cache dan backlog

Cache lokal mempertahankan versi gambar yang terakhir ditransfer. Untuk konsistensi:

  • Tambahkan field version/timestamp pada entry queue dan validasi sebelum menimpa cache terdistribusi.
  • Worker melakukan compare-and-set ketika menulis ke cache pusat.
  • Gunakan TTL pada entry cache untuk membersihkan gambar lama, lalu worker menyampaikan perintah refresh jika perlu.

Backlog terjadi saat jaringan down. Strategi:

  • Queue retention panjang: Redis Streams menyimpan hingga batas memori (configurable). Gunakan XDEL hanya setelah sukses.
  • Worker lokal memperkecil batch untuk mempercepat ack.
  • Terapkan mekanisme slow-lane untuk upload tersendat—misalnya worker kedua menangani hanya entry dengan timestamp lama.

Operasional: retry, latency, dan monitoring

Retry:

  • Gunakan XPENDING untuk melihat entry yang belum diack (stuck). Worker yang sama dapat XCLAIM entry setelah min_idle_time terlewati.
  • Tentukan batas retry: jika entry gagal setelah N kali (dilacak field retries), kirim notifikasi ke dashboard atau simpan di dead-letter queue.

Observabilitas latency:

  • Catat timestamp saat entry queue dibuat dan saat worker selesai upload. Hitung delta untuk memantau latensi end-to-end.
  • Gunakan metrics exporter (misalnya Prometheus client) untuk memonitor panjang queue, waktu proses rata-rata, dan tingkat error.
  • Gunakan log structured dengan konteks : image_id, consumer, retry_count.

Monitoring membantu mendeteksi apabila backlog bertambah, koneksi cloud down, atau worker kehabisan resource.

Kesimpulan

Menetapkan worker queue untuk cache gambar Raspberry Pi Zero membutuhkan perhatian detail terhadap locking, konsistensi cache, backlog, serta retry dan observabilitas. Platform seperti Redis Streams menyediakan primitives yang cukup ringan. Pastikan worker lokal memecah beban, mencatat metric latency, dan mengatur retry agar sistem Optocam Zero tetap responsif sekaligus andal.