Առաքում, outbox և վերականգնում

Երբ turn-ն ավարտվում է, պատասխանը դեռ պետք է հասնի այն ալիքին, որտեղից եկել է — հուսալիորեն և ճիշտ մեկ անգամ։ AiHummer-ը կարգավորում է սա տրանզակցիոն outbox-ի, իդեմպոտենտ կողմնակի էֆեկտների և վերագործարկումից հետո turn-ի վերականգնման միջոցով։ Ընտրովի NATS bus-ը կարող է իրականացնել առաքումը ավելի մեծ տեղակայումների համար։

Երաշխավորված առաքում

Պատասխանը չի ուղարկվում անմիջապես turn-ի վերջում։ Փոխարենը այն հերթագրվում է outbox-ում՝ որպես այն աշխատանքի մաս, որը այն ստեղծել է, և առաքման աշխատողը վերցնում է այն ու ուղարկում սկզբնական ալիքին։ Քանի որ պատասխանը մշտապես գրանցվում է նախքան այն դուրս կգա, «պատասխանը ստեղծվել է» և «պատասխանը ուղարկվել է» միջև տեղի ունեցած խափանումը չի կարող կորցնել այն — վերագործարկման ժամանակ outbox-ի գրառումը դեռ այնտեղ է, և առաքումը վերսկսվում է։

turn produces reply
   └─▶ enqueue in outbox (durable)
         └─▶ delivery worker ─▶ originating channel
               └─ acknowledged ─▶ marked delivered

Առաքումը զուգակցված է իդեմպոտենտության հետ, որպեսզի այս առնվազն-մեկ-անգամ աշխատողը ապահովի ճիշտ-մեկ-անգամ արտաքին վարքագիծ. վերսկսման հարցում կայուն ledger key-ը և կողմնակի էֆեկտի արգելապատնեշը ապահովում են, որ վերաառաքված կամ վերարտադրված պատասխանը ուղարկվի ալիքին միայն մեկ անգամ (տես Բազմավարձակալություն և իդեմպոտենտություն)։

[!NOTE] «Ճիշտ-մեկ-անգամ»-ն այստեղ նկարագրում է արտաքինից տեսանելի արդյունքը. օգտատերը ստանում է պատասխանը մեկ անգամ։ Ներքին մակարդակում աշխատողը կարող է փորձել առաքել մեկից ավելի անգամ. իդեմպոտենտության շերտը այդ փորձերը կրճատում է մեկ տեսանելի ուղարկման։

Turn-ի վերականգնում վերագործարկումից հետո

Եթե gateway-ը վերագործարկվում է turn-ի կեսին — տեղակայում, խափանում, host-ի վերաբեռնում — աշխատանքը չի լքվում։ Turn-ի վերականգնումը վերարտադրում է ընդհատված turn-ը, որպեսզի այն կարողանա ավարտվել։ Սա անվտանգ է միայն այն պատճառով, որ կողմնակի էֆեկտները իդեմպոտենտ են. ցանկացած նամակ կամ ալիք-ուղարկում, որը արդեն տեղի է ունեցել նախքան վերագործարկումը, ճանաչվում է իր ledger key-ով և բաց է թողնվում, մինչդեռ չկատարված մասերը կատարվում են մինչև վերջ։ Օգտատերը տեսնում է մեկ ամբողջական պատասխան, այլ ոչ թե կիսատ կամ կրկնակի։

Ընտրովի NATS bus

Ըստ լռելյայնի՝ առաքումն աշխատում է ամբողջությամբ PostgreSQL-ի միջոցով, որը նվազագույն տեղակայումը պահում է մեկ gateway-ի և տվյալների բազայի սահմաններում։ Ավելի մեծ կամ բազմա-gateway կազմաձևերի համար կարող եք առաքումը դնել NATS bus-ի վրա՝ կարգավորելով նրա URL-ը.

# gateway.env
AIHUMMER_NATS_URL=nats://127.0.0.1:4222

Bus-ն իսկապես ընտրովի է — թողեք AIHUMMER_NATS_URL-ը չսահմանված, և outbox-ը կաշխատի առանց դրա։ Երբ առկա է, NATS-ը դառնում է տրանսպորտը, որի վրայով հոսում է առաքման աշխատանքը, ինչը հարմար է proxy-ի հետևում հորիզոնական մասշտաբավորված gateway-երի համար։

[!TIP] Առանց պարապուրդի թարմացումները աշխատեցնում են երկու կամ ավելի gateway հակադարձ proxy-ի հետևում։ Ժամանակացույցը մնում է մեկ-առաջնորդ Postgres advisory lock-ի միջոցով, և իդեմպոտենտ առաքումը նշանակում է, որ լրացուցիչ gateway-երը կարող են կիսել ծանրաբեռնվածությունը՝ առանց որևէ բան երկու անգամ ուղարկելու։

Ինչին հետևել

Առաքումն այն վայրն է, որտեղ հուսալիության խնդիրներն ի հայտ են գալիս առաջինը, ուստի դա է այն, ինչին պետք է հետևել։ AiHummer-ը հրում է հեռաչափությունը OTLP-ի միջոցով (AIHUMMER_OTEL_ENDPOINT) և մատակարարում Grafana վահանակներ. չկա Prometheus /metrics endpoint՝ քերելու համար։

Առաքման արդյունքներ — յուրաքանչյուր առաքման փորձի ելքը։ Ձախողումների աճող դրույքը մատնանշում է ալիքի կամ ներքև գծի խնդիր։
Outbox-ի խորություն — քանի պատասխան է սպասում առաքվելու։ Կայուն աճը նշանակում է, որ առաքումը հետ է մնում։
DLQ-ի խորություն — գրառումներ, որոնք սպառել են իրենց վերափորձերը և հայտնվել են dead-letter հերթում։ Ցանկացած DLQ-ի աճ արժանի է հետաքննության։

[!WARNING] Հետևեք սրանց turn-ի հապաղման և սխալների դրույքի հետ միասին։ Աճող outbox-ը կամ DLQ-ն վաղ նախազգուշացում է, որ ներքև գծի ալիքները վատթարացած են, նույնիսկ եթե turn-երն ինքնին դեռ հաջողվում են։

Ուր հաջորդիվ

Իդեմպոտենտությունը, որը առաքումը դարձնում է ճիշտ-մեկ-անգամ. Բազմավարձակալություն և իդեմպոտենտություն։
Շարժիչը, որն ի սկզբանե ստեղծում է պատասխանը. Gateway և turn engine։