Warning: mkdir(): No space left on device in /var/www/tg-me/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/golang_books/--): Failed to open stream: No such file or directory in /var/www/tg-me/post.php on line 50
Golang Books | Telegram Webview: golang_books/982 -
Telegram Group & Telegram Channel
🛠️ История создания “storage-agnostic” message queue

Автор — Fahim Faisaal — делится опытом разработки гибкой очереди задач на Go, которая может использовать любые хранилища: in-memory, Redis, SQLite и др. :contentReference[oaicite:0]{index=0}

Контекст:
Занимаясь на Go, автор вдохновился инструментами из Node.js экосистемы (BullMQ, RabbitMQ) и захотел сделать что-то похожее, но с нуля, без зависимостей. Так родилась идея — сначала он создал Gocq (Go Concurrent Queue): простую concurrent-очередь, работающую через каналы :contentReference[oaicite:1]{index=1}.

Основная проблема

Gocq отлично работал в памяти, но не поддерживал устойчивое хранение задач.
Автор задумался: а можно ли сделать очередь, не зависящую от конкретного хранилища — так, чтобы её можно было подключить к Redis, SQLite или совсем без них?
🧱 Как это реализовано в VarMQ

После рефакторинга Gocq был разделён на два компонента:
1. Worker pool — пул воркеров, обрабатывающих задачи.
2. Queue interface — абстракция над очередью, не зависящая от реализации.

Теперь воркер просто берёт задачи из очереди, не зная, где они живут. :contentReference[oaicite:2]{index=2}

---

### 🧠 Пример использования

- In-memory очередь:

w := varmq.NewVoidWorker(func(data any) {
// обработка задачи
}, 2)
q := w.BindQueue()


- С SQLite-поддержкой:

import "github.com/goptics/sqliteq"

db := sqliteq.New("test.db")
pq, _ := db.NewQueue("orders")
q := w.WithPersistentQueue(pq)


- С Redis (для распределённой обработки):

import "github.com/goptics/redisq"

rdb := redisq.New("redis://localhost:6379")
pq := rdb.NewDistributedQueue("transactions")
q := w.WithDistributedQueue(pq)


В итоге воркер обрабатывает задачи одинаково — независимо от хранилища. :contentReference[oaicite:3]{index=3}

Почему это круто


- Гибкость: адаптеры позволяют легко менять хранилище без правок воркера.
- Минимальные зависимости: в ядре — zero-deps, весь функционал — через адаптеры.
- Self-hosted и легковесно: можно развернуть локально или в продакшене.
- Написано на Go: использует горутины и каналы, удобен и эффективен.

📣 Отзывы сообщества

На Reddit отметили, что автор добился "queue system that doesn’t care if your storage is Redis, SQLite, or even in-memory" :contentReference[oaicite:4]{index=4}

🔗 Ссылки
- Статья: A Story of Building a Storage‑Agnostic Message Queue на DEV :contentReference[oaicite:5]{index=5}
- GitHub VarMQ (Var-storage-agnostic message queue): репозиторий с кодом адаптеров и примерами использования :contentReference[oaicite:6]{index=6}

Итог: VarMQ — это элегантное решение на Go для создания задач-очереди, универсально по отношению к хранилищу: выбрал нужный адаптер — и система работает.

📌 Читать



tg-me.com/golang_books/982
Create:
Last Update:

🛠️ История создания “storage-agnostic” message queue

Автор — Fahim Faisaal — делится опытом разработки гибкой очереди задач на Go, которая может использовать любые хранилища: in-memory, Redis, SQLite и др. :contentReference[oaicite:0]{index=0}

Контекст:
Занимаясь на Go, автор вдохновился инструментами из Node.js экосистемы (BullMQ, RabbitMQ) и захотел сделать что-то похожее, но с нуля, без зависимостей. Так родилась идея — сначала он создал Gocq (Go Concurrent Queue): простую concurrent-очередь, работающую через каналы :contentReference[oaicite:1]{index=1}.

Основная проблема

Gocq отлично работал в памяти, но не поддерживал устойчивое хранение задач.
Автор задумался: а можно ли сделать очередь, не зависящую от конкретного хранилища — так, чтобы её можно было подключить к Redis, SQLite или совсем без них?
🧱 Как это реализовано в VarMQ

После рефакторинга Gocq был разделён на два компонента:
1. Worker pool — пул воркеров, обрабатывающих задачи.
2. Queue interface — абстракция над очередью, не зависящая от реализации.

Теперь воркер просто берёт задачи из очереди, не зная, где они живут. :contentReference[oaicite:2]{index=2}

---

### 🧠 Пример использования

- In-memory очередь:


w := varmq.NewVoidWorker(func(data any) {
// обработка задачи
}, 2)
q := w.BindQueue()


- С SQLite-поддержкой:

import "github.com/goptics/sqliteq"

db := sqliteq.New("test.db")
pq, _ := db.NewQueue("orders")
q := w.WithPersistentQueue(pq)


- С Redis (для распределённой обработки):

import "github.com/goptics/redisq"

rdb := redisq.New("redis://localhost:6379")
pq := rdb.NewDistributedQueue("transactions")
q := w.WithDistributedQueue(pq)


В итоге воркер обрабатывает задачи одинаково — независимо от хранилища. :contentReference[oaicite:3]{index=3}

Почему это круто


- Гибкость: адаптеры позволяют легко менять хранилище без правок воркера.
- Минимальные зависимости: в ядре — zero-deps, весь функционал — через адаптеры.
- Self-hosted и легковесно: можно развернуть локально или в продакшене.
- Написано на Go: использует горутины и каналы, удобен и эффективен.

📣 Отзывы сообщества

На Reddit отметили, что автор добился "queue system that doesn’t care if your storage is Redis, SQLite, or even in-memory" :contentReference[oaicite:4]{index=4}

🔗 Ссылки
- Статья: A Story of Building a Storage‑Agnostic Message Queue на DEV :contentReference[oaicite:5]{index=5}
- GitHub VarMQ (Var-storage-agnostic message queue): репозиторий с кодом адаптеров и примерами использования :contentReference[oaicite:6]{index=6}

Итог: VarMQ — это элегантное решение на Go для создания задач-очереди, универсально по отношению к хранилищу: выбрал нужный адаптер — и система работает.

📌 Читать

BY Golang Books




Share with your friend now:
tg-me.com/golang_books/982

View MORE
Open in Telegram


Golang Books Telegram | DID YOU KNOW?

Date: |

For some time, Mr. Durov and a few dozen staffers had no fixed headquarters, but rather traveled the world, setting up shop in one city after another, he told the Journal in 2016. The company now has its operational base in Dubai, though it says it doesn’t keep servers there.Mr. Durov maintains a yearslong friendship from his VK days with actor and tech investor Jared Leto, with whom he shares an ascetic lifestyle that eschews meat and alcohol.

Telegram Gives Up On Crypto Blockchain Project

Durov said on his Telegram channel today that the two and a half year blockchain and crypto project has been put to sleep. Ironically, after leaving Russia because the government wanted his encryption keys to his social media firm, Durov’s cryptocurrency idea lost steam because of a U.S. court. “The technology we created allowed for an open, free, decentralized exchange of value and ideas. TON had the potential to revolutionize how people store and transfer funds and information,” he wrote on his channel. “Unfortunately, a U.S. court stopped TON from happening.”

Golang Books from jp


Telegram Golang Books
FROM USA