Окуялардын дедупликациясы

1) Эмне үчүн дедупликация керек

• инварианттар бузулган (кош эсептен чыгаруу, кайталап электрондук почта/SMS, "эки жолу түзүлгөн" заказ);
• чыгымдар (кайталап жазуу/кайра иштетүү) өсөт;
• аналитика бурмаланган.

Дедупликациянын максаты - транспорттун жол берилген кайталоолорунда, көбүнчө демпотенттүүлүк менен бирге бир жолу байкалган эффектти камсыз кылуу.

2) Дедупликацияны кайда жайгаштыруу керек (деңгээлдер)

1. Edge/API-шлюз - Биз 'Idempotency-Keu '/дене + кол менен ачык дубли кесип.
2. Брокер/агым - ачкыч/секвенция боюнча логикалык дедупликация, ката кетиргенде coalescing (азыраак - наркынан улам).
3. Иш-чара кабыл алуучу (consumer) - негизги жер: Inbox/ачкыч жадыбалы/кэш.
4. Синк (BD/кэш) - уникалдуу ачкычтар/UPSERT/версиялар/компакция.
5. ETL/талдоо - убакыт терезе жана мамычалардын ачкычы боюнча дедуп.

Эреже: мүмкүн болушунча эртерээк, бирок жалган таасирлердин наркын жана репликанын зарылдыгын эске алуу менен.

3) Дедупликация ачкычтары

3. 1 Табигый (артыкчылык)

`payment_id`, `order_id`, `saga_id#step`, `aggregate_id#seq`.
Туруктуулукка жана мааниге кепилдик берет.

3. 2 компоненттери

`(tenant_id, type, external_id, version)` или `(user_id, event_ts_truncated, payload_hash)`.

3. 3 изи (fingerprint)

Hash талаалар (тартипти/регистрлерди нормалдаштыруу), кошумча 'HMAC (secret, payload)'.

3. 4 ырааттуулугу/версия

Monoton 'seq' per aggregate (оптимисттик кулпу/чыгаруу).

Анти-үлгү: "UUID рандом" бизнес маңызы менен байланышы жок - дедуп мүмкүн эмес.

4) Убактылуу терезелер жана тартиби

Дедупликация терезеси - окуя кайра келе турган мезгил (адатта 24-72ч; каржы үчүн - узак).
Out-of-order: кечигүүгө жол (lateness). Агымдык алкактарда - event time + watermarks.
Sliding/Fix-window дедуп: "Акыркы N мүнөттө ачкычты көрдүңүзбү? ».
Sequence-aware: эгер 'seq' акыркы иштетилген ≤ - дубль/кайталоо.

5) Маалыматтар жана ишке ашыруу түзүмдөрү

5. 1 так эсепке алуу (exact)

Redis SET/STRING + TTL: 'SETNX key 1 EX 86400' → "биринчи жолу - иштеп чыгуу, башкача - SKIP".
LRU/LFU кэш (in-proc): тез, бирок volatile → гана биринчи тоскоолдук катары жакшы.
SQL уникалдуу индекстер + UPSERT: "киргизүү же жаңыртуу" (демпотенттик эффект).

5. 2 Болжолдуу структуралар (probabilistic)

Bloom/Cuckoo filter: арзан эс, жалган (жалган positive) мүмкүн. ачык-айкын "ызы-чуу" үчүн ылайыктуу (мисалы, телеметрия), каржы/буйрутмалар үчүн эмес.
Count-Min Sketch: "ысык" дубль коргоо үчүн жыштык баа.

5. 3 Агым шарттары

Kafka Streams/Flink: keyed state store c TTL, терезеде ачкыч боюнча дедуп; checkpoint/restore.
Watermark + allowed lateness: кеч окуялардын терезесин башкарат.

6) Транзакциялык үлгүлөр

6. 1 Inbox (кириш таблица)

pseudo
BEGIN;
ins = INSERT INTO inbox(id, received_at) ON CONFLICT DO NOTHING;
IF ins_not_inserted THEN RETURN cached_result;
result = handle(event);
UPSERT sink with result; -- idempotent sync
UPDATE inbox SET status='done', result_hash=... WHERE id=...;
COMMIT;

Кайталоо жазууну көрөт жана эффектти кайталабайт.

6. 2 Outbox

Бизнес-жазуу жана бир иш-чара → жарыялоочу брокерге берет. Керектөөчүдөн эки жолу жок кылбайт, бирок "тешиктерди" жок кылат.

6. 3 уникалдуу индекстер/UPSERT

sql
INSERT INTO payments(id, status, amount)
VALUES ($1, $2, $3)
ON CONFLICT (id) DO NOTHING; -- "create once"

sql
UPDATE orders
SET status = $new, version = version + 1
WHERE id=$id AND version = $expected; -- optimistic blocking

6. 4 Агрегаттарды чыгаруу

Иш-чара 'event' болсо колдонулат. version = aggregate. version + 1`. Болбосо - дубль/кайталоо/чыр-чатак.

7) Дедуп жана брокерлер/агымдар

7. 1 Kafka

Idempotent Producer кириш эки кыскартат.
Transactions атомдук ofset + чыгаруу жазууларды коммитирлөөгө мүмкүндүк берет.
Compaction: per key акыркы маанисин сактайт - пост-фактум дедуп/коалиция (төлөмдөр үчүн эмес).
Consumer-side: state store/Redis/DB терезе ачкычтары үчүн.

7. 2 NATS / JetStream

Ack/редоставка → at-least-once. Керектөөчү дедуп (Inbox/Redis).
JetStream sequence/durabot керектөөчүнүн кайталоо аныктоо жөнөкөйлөтүү.

7. 3 кезек (Rabbit/SQS)

Visibility timeout + кайталап жеткирүү → ачкыч + дедуп-stor керек.
SQS FIFO 'MessageGroupId '/' DeduplicationId' менен жардам берет, бирок TTL терезелери провайдер менен чектелет - бизнес талап кылса, ачкычтарды узак сактаңыз.

8) Сактоо жана аналитика

8. 1 ClickHouse/BigQuery

Терезе боюнча дедуп: 'ORDER BY key, ts' и 'argMax '/' anyLast' шарты менен.

sql
SELECT key,
anyLast(value) AS v
FROM t
WHERE ts >= now() - INTERVAL 1 DAY
GROUP BY key;

Же "уникалдуу" окуялардын материалдык катмары (негизги/версия боюнча мердж).

8. 2 Логи/телеметрия

Айталы approximate-dedup (Bloom) боюнча ingest → тармак/диск үнөмдөө.

9) кайра иштетүү, реплика жана арткы

Дедуп ачкычтар Replay (TTL ≥ Replay терезе) башынан керек.
Backfill үчүн ('key #source = batch2025') версиясы бар ачкыч мейкиндигин же жеке "өрүктөрдү" колдонуңуз.
Натыйжанын артефакттарын (hash/version) сактаңыз - бул кайталоолордо "fast-skip" ылдамдатат.

10) Метрика жана байкоо

'dedup _ hit _ total '/' dedup _ hit _ rate' - кармалган дубль үлүшү.
'dedup _ fp _ rate' ыктымалдык чыпкалар үчүн.
'window _ size _ seconds' чыныгы (telemetry late arrivals боюнча).
`inbox_conflict_total`, `upsert_conflict_total`.
`replayed_events_total`, `skipped_by_inbox_total`.
tenant/key/type боюнча профилдер: кайсы жерде эң көп дубль жана эмне үчүн.

Логи: `message_id`, `idempotency_key`, `seq`, `window_id`, `action=process|skip`.

11) Коопсуздук жана купуялык

PII ачкычка салбаңыз; хэш/псевдонимдерди колдонуңуз.
Кол тамга үчүн - HMAC (жашыруун, canonical_payload) чыр-чатак/жасалма болтурбоо үчүн.
Ачкычтарды сактоо мөөнөтү комплаенс (GDPR retenshn) менен шайкеш келет.

12) аткаруу жана наркы

In-proc LRU ≪ Redis ≪ SQL операция үчүн жашыруун/наркы.
Redis: арзан жана тез, бирок ачкычтар жана TTL көлөмүн эске алуу; chardat 'tenant/hash'.
SQL: p99 кымбат, бирок күчтүү кепилдик жана аудитория берет.
Probabilistic чыпкалар: абдан арзан, бирок мүмкүн FP - "кошумча SKIP" маанилүү эмес жерде колдонуу.

13) Анти-үлгүлөрү

"Бизде Kafka exactly-once бар - ачкычтын кереги жок". Керек - көк/бизнес катмарында.
Өтө кыска TTL үчүн ачкычтар → реплика/кечигүү эки берет.
Global Single Dedup Store → hotspot жана SPOF; tenant/ачкычы менен шардана эмес.
Дедуп эс - жоготуу жараяны = толкун дубль.
Акча/буйрутмалар үчүн Bloom - жалган positive мыйзамдуу ишин ажыратат.
Макулдашылбаган канонизация payload - маанисине окшош билдирүүлөр боюнча ар кандай хэштер.
Көз жаздымда калтыруу - кеч окуялар ката менен белгиленет.

14) Киргизүү чек-тизмеси

• табигый ачкычын аныктоо (же курама/изи).
• Дедуп терезени жана 'lateness' саясатын орнотуу.
• деңгээл тандоо (I): edge, consumer, sink; карап көрөлү.
• Inbox/UPSERT ишке ашыруу; агымдар үчүн - keyed state + TTL.
• approximate тоскоолдук керек болсо - Bloom/Cuckoo (гана критикалык эмес домендер үчүн).
• Replay шайкештикти (TTL ≥ Replay/Backfill терезе).
• Metrics 'dedup _ hit _ rate', чыр-чатактар ​ ​ жана терезе лагдары; dashbord per-tenant.
• Game Day: Таймауттар/Retrains, Replay, out-of-order, күзүндө кэш.
• документтештирүү канонизациялоо жана ачкычтарды чыгаруу.
• "ысык ачкычтар" жана узун терезелер боюнча жүктөө сыноолорду жүргүзүү.

15) Конфигурация/коддун мисалдары

15. 1 Redis SETNX + TTL (тосмо)

lua
-- KEYS[1] = "dedup:{tenant}:{key}"
-- ARGV[1] = ttl_seconds local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "PROCESS"
else return "SKIP"
end

15. 2 PostgreSQL Inbox

sql
CREATE TABLE inbox (
id text PRIMARY KEY,
received_at timestamptz default now(),
status text default 'received',
result_hash text
);
-- In the handler: INSERT... ON CONFLICT DO NOTHING -> check, then UPSERT in blue.

15. 3 Kafka Streams (терезеде дедуп)

java var deduped = input
.selectKey((k,v) -> v.idempotencyKey())
.groupByKey()
.windowedBy(TimeWindows. ofSizeWithNoGrace(Duration. ofHours(24)))
.reduce((oldV,newV) -> oldV)   // first wins
.toStream()
.map((wKey,val) -> KeyValue. pair(wKey. key(), val));

15. 4 Flink (keyed state + TTL, псевдо)

java
ValueState<Boolean> seen;
env. enableCheckpointing(10000);
onEvent(e):
if (!seen.value()) { process(e); seen. update(true); }

15. 5 NGINX/API-шлюз (edge боюнча Idempotency-Key)

nginx map $http_idempotency_key $idkey { default ""; }
Proxy the key to the backend; backend solves deadup (Inbox/Redis).

16) FAQ

Q: тандоо үчүн эмне: дедуп же таза боштук?
A: Адатта, экөө тең: дедуп - тез "чыпкасы" (үнөмдөө), демпотенттик - туура таасир кепилдик.

Q: Кандай TTL койду?
A: мүмкүн болуучу кайра жеткирүү максималдуу убакыт ≥ + запасы. Адатта 24-72h; каржы жана кийинкиге калтырылган тапшырмалар үчүн - күндөр/жумалар.

Q: Кийинки окуяларды кантип иштетүү керек?
A: орнотуу 'allowed lateness' жана сигнал 'late _ event'; кеч - өзүнчө бутагы аркылуу (recompute/skip).

Q: Мен телеметрия агымын дедуплициялоо мүмкүнбү?
A: Ооба, edge боюнча approximate-чыпкалар (Bloom), бирок FP эске алуу жана маанилүү бизнес таасирлерин колдонууга болбойт.

Q: Dedup арткы тоскоолдук?
A: Ачкыч мейкиндигин бөлүү ('key #batch2025') же арткы убакыттын босогосун өчүрүү; TTL ачкычтар гана онлайн терезелерди камтышы керек.

17) Натыйжалары

Дедупликация - бул композиция: туура ачкыч, терезе жана мамлекеттик түзүлүш + транзакциялык үлгүлөр (Inbox/Outbox/UPSERT) жана тартип жана кеч окуялар менен аң-сезимдүү иштөө. Барьерлерди эң арзан жерде жайгаштыруу, көк боёктордогу демпотенттүүлүктү камсыз кылуу, 'dedup _ hit _ rate' өлчөө жана репликаларды/фейлдерди сыноо - ошондуктан сиз "эффективдүү exactly-once" аласыз.