Nail/SQS-service
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc: durability SendMessageBatch + billing (предусмотрен, выключен)

Browse Source
This commit is contained in:
Repinoid
2026-10-10 16:19:54 +03:00
parent a341508b6d
commit 607aebb8ef
2 changed files with 23 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
HISTORY/2026-10-10-session-log.md
+5
View File
@@ -122,6 +122,11 @@
- Нужно для ЛЮБОГО multi-instance варианта; в одном процессе — страховка. - Нужно для ЛЮБОГО multi-instance варианта; в одном процессе — страховка.
- Проверено: индекс заполнен (`hlen ssq:tenant_ak` = 1), регрессий нет. - Проверено: индекс заполнен (`hlen ssq:tenant_ak` = 1), регрессий нет.
### 2.15. Durability batch + billing
- `SendMessageBatch` переведён на `SaveMessagesSync` (было async) + не персистит дубли (коммит `3559414`).
- Проверено: batch в пустую очередь пережил рестарт.
- Billing — предусмотрен (модуль есть), но выключен (`BILLING_PG_HOST` не задан). Решение: включить позже.
## 3. Грабли (для повторного использования) ## 3. Грабли (для повторного использования)
1. **`proxy_set_header Host $host` теряет порт** → SigV4 `SignatureDoesNotMatch`. 1. **`proxy_set_header Host $host` теряет порт** → SigV4 `SignatureDoesNotMatch`.
doc/thinking/vm-public-entrypoint-2026-10-10.md
+18
View File
@@ -155,3 +155,21 @@ curl -sS https://sqs.sinefo.ru/health
**Почему пока два листенера в одном процессе, а не два процесса:** состояние (очереди/тенанты) — **Почему пока два листенера в одном процессе, а не два процесса:** состояние (очереди/тенанты) —
in-memory; два процесса разъедутся (админка создаст тенанта в своей памяти — data-plane его не увидит). in-memory; два процесса разъедутся (админка создаст тенанта в своей памяти — data-plane его не увидит).
Полноценный процесс-split — после Шага 3 (Redis как источник истины). Полноценный процесс-split — после Шага 3 (Redis как источник истины).
## 11. Надёжность записи (durability) и billing (2026-10-10)
### 11.1. Синхронная запись критичных операций
- `SendMessage` — sync (`SaveMessageSync`, фикс P1.1) ✅
- `DeleteMessage` / `DeleteMessageBatch` — sync (`DeleteMessagePersist`/`DeleteMessagesPersist`) ✅
- **`SendMessageBatch` — ИСПРАВЛЕНО (коммит `3559414`):** было `SaveMessages` (async) → стало
`SaveMessagesSync` (ответ 200 только после записи всех сообщений; при ошибке — откат append).
Заодно: не персистим дубли (раньше в Redis попадали дубликаты, которых нет в очереди).
- Проверено: batch из 2 сообщений в пустую очередь **пережил рестарт** сервиса.
- Остаётся async: `SaveQueue` (метаданные очереди: FIFO-состояние, duplicates) и метаданные
в Create/Delete/SetAttributes/Purge/Tags — потеря возможна только в узком окне при крахе;
сами сообщения защищены.
### 11.2. Billing — предусмотрен, но НЕ включён
- Модуль есть (`app/billing`, PG-воркер + буфер), включается через `BILLING_PG_HOST` (сейчас не задан).
- Решение: **оставить выключенным**; включать, когда появятся реальные клиенты/тарификация.
- Учёт операций уже рассчитан под биллинг — при включении заработает без изменений ядра.