Բազմօգտագործողական ռեժիմ և իդեմպոտենտություն

# gateway.env
# Owner pool — runs migrations and privileged maintenance
AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable
# Restricted role — activates RLS for normal request traffic
AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable

side-effect requested
   └─▶ compute resume-stable ledger key
         └─▶ barrier: key already committed?
               ├─ yes ─▶ skip (no double-send)
               └─ no  ─▶ perform effect ─▶ commit key

AiHummer սա է **բազմօգտագործողական**: մեկ մուտքագծային կետ կարող է սպասարկել մի քանի աշխատանքի տարածքներ մեկ տվյալների բազայից, այն պահելով դրանց տվյալները առանձին: Երկու մեխանիզմներ դա ապահովում են անվտանգ **Անվտանգություն մեջպետային մակարդակով Postgres-ում (RLS)** կարդալու/գրելունը մեկուսացնելու համար և **իդեմպոտենտության շերտ** երբեմնկանալը և շրջադարձի վերականգնումը իրական աշխարհում կողմնակի ազդեցությունը կրկնել չպիտի։ **Շերտ։** Ծրագրային տողերի մակարդակով բազմաբնակարանային մեկուսացումը կառավարվում է վճարովի տարբերակով **ԱԿԸ** աստիճանը — չի հանդիսանում անվճար/համայնքային հարթակի մաս; իդեմպոտենտության շերտը հանդիսանում է միջուկի մաս: ## Վարձակալների մեկուսացում՝ զանգվածային անվտանգության մակարդակով Իզոլացումը ապահովվում է տվյալների բազայի մակարդակում, այլ ոչ միայն ծրագրի կոդում: AiHummer-ը կատարում է հարցումներն այն միջոցով **սպառիչ դեր Playgres** (`aihummer_app`) որի վրա կիրառվել են RLS քաղաքականությունները, ուստի տվյալների բազան ինքն իրեն մերժում է այն տողերը, որոնք չեն պատկանում ակտիվ վարձակալին. RLS դա **գնորդի ցանկությամբ անդամակցություն**Դուք այն ակտիվացնում եք, փոխանցելով անցվող տողը երկրորդ կապի համար, սահմանափակված դերի համար: ```ini # gateway.env # Owner pool — runs migrations and privileged maintenance AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable # Restricted role — activates RLS for normal request traffic AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable ``` > [!NOTE] > Հոսթային սարքում համար տեղադրիչը տեղադրում է `AIHUMMER_DB_APP_URL` > ավտոմատ կերպով, այդ պատճառով RLS-ը ըստ լռության ներառված է նորմալ տեղադրման մեջ։ Եթե > փոփոխականը չկա, դարպասը աշխատում է միայն սեփականատիրոջ պուլի վրա և RLS-ը ակտիվ չէ > ակտիվ։ ### Մեծացման հեռանկար յուրաքանչյուր վարձույթը համար Սահմանափակ դերի շրջանակներում յուրաքանչյուր հարցումը սահմանափակվում է իր վարձակալով՝ դարպասը կապի վրա սահմանում է ընթացիկ վարձակալության համատեքստը, որպեսզի RLS քաղաքականությունները կիրառվեն ճիշտ աշխատանքային տարածքին: `WHERE tenant_id = …` Ֆիլտրերը ամենուր ձեռքով չեն ստեղծվում; քաղաքականությունը դրանք կիրառում է կենտրոնացված կարգով, ինչը նշանակում է, որ բաց ֆիլտրը չի կարող անցկացնել մյուս վարձակալի տողերը: ### Համակարգ / շրջանցման ռեժիմ Որոշ աշխատանք օրինականորեն միջվարձակալական է՝ ֆոնային գործընթացներ, պլանավորողներ և սպասարկման առաջադրանքներ, որոնք աշխատում են ամբողջ օրինակով։ Դրանք իրականացվում են **համակարգ / շրջանցման ռեժիմ** մորթք նրանք կարողանան տեսնել այն, ինչ նրանց պետք է։ Շրջանցումը նախատեսված է վստահված ներքին աշխատակիցների համար, այլ ոչ թե հարցումների մշակման ուղիների համար։ > [!WARNING] > **Միգրացիաները միշտ իրականացվում են սեփականատիրոջ պուլի մեջ**, երբեք սահմանափակ դերում։ > Ունենալու սեփականակի միացումը իրավունքներ ունի սխեմայի փոփոխության և RLS կիրառման համար > պետագիրություն; սահմանափակ դերը դիտմամբ դա չի անում։ Պահպանեք երկու կապը > տողերը տարբեր են և տրամադրում են `aihummer_app` միայն այն դերակատարությունը, որը նրան անհրաժեշտ է: ## Իդեմպոտենտ կողմնակի ազդեցություններ Քայլը կարող է հանգեցնել իրական կողմնակի ֆետակների՝ էլեկտրոնային հասցեի ուղարկմանը, հաղորդագրության ուղարկմանը կրկին ալիքին։ Եթե քայլը կրկնվում է՝ ժամանակավոր սխալի պատճառով կամ այն պատճառով, որ գեյթվեյը վերաբացվել է քայլի կեսին, իսկ վերականգնումը այն կրկին վերարտադրում է — դրանք կողմնակի ազդեցություններ պետք է **ոչ** կրկնվելու է երկու անգամ: AiHummer-ը դա ապահովում է երկու միաժամանակ աշխատող մասերի միջոցով: ### Ռեզյումե-կայուն ռեգիստրի բանալի Յուրաքանչյուր բարդ կողմնակի երևույթ գրանցվում է դեմ **կայուն ռեզյումեի գրանցման բանալի**: բանալին, որը որոշված ձևով ստացվում է քայլից, այնպես որ նույն քայլը կրկնելը հաշվարկում է *հենց նույն* բանալին, ոչ թե նորը։ Ռեեստրը հիշում է, թե որոնք բանալիները արդեն օգտագործվել են։ ### Ետադարձ ազդեցության խոչընդոտ Նախքան ազդեցությունը, օրինակ **փոստ** կամ **ուղարկման-ալիք** կատարվում է, այն անցնում է միջոցով **կողմնակի ազդեցության պատնեշ** որ ստուգում է օրագիրը։ Եթե այս բանալին արդեն գործել է, խոչընդոտը փակվում է և էֆեկտը բաց է թողնվում; եթե ոչ, էֆեկտը կատարվում է և բանալին ֆիքսվում է։ ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Արդյունք **վարվելակերպը ճշգրիտ մեկ անգամ արտաքնածվում, նույնիսկ եթե առաքումը ներսում տեղի է ունենում առնվազն մեկ անգամ**. Կրկնակի փորձերը անվտանգ են կառույցով, ինչը թույլ է տալիս պտույտի վերականգնումը (հետ նայեք: [Հուսալի առաքում և վերականգնում](/hy/v1.0/architecture/delivery-outbox)) կրկնել ընդմիջված քայլը, որպեսզի հաճախորդը նույն նամակը կամ նույն պատասխանը կրկին չստանա։ > [!TIP] > Ստորեւ հենց այն պատճառով է, որ AiHummer-ը կարող է առաջարկել երաշխավորված առաքում և պտույտի ավտոմատ վերականգնում > կրկնակի հաղորդումների սովորական ռիսկի բացակայությամբ՝ իդեմպոտենտությունը հիմքն է > միավորվածների վրա, որոնց վրա հիմնվում են մատակարարման երաշխիքները։ ## Որտեղից հետո - Մակարդակը, որը կառավարում է պտույտը: [Գեյթ և պտտվող շարժիչ](/hy/v1.0/architecture/gateway-turn-engine). - Ինչպես պատասխանները վերադարձվում են ճիշտ մեկ անգամը: [Հուսալի առաքում և վերականգնում](/hy/v1.0/architecture/delivery-outbox).