Шматарэндарнасць і ідэмпатэнтнасць

AiHummer шматарэндарны: адзін шлюз можа абслугоўваць шмат працоўных прастораў з адной базы даных, трымаючы іх даныя асобна. Два механізмы робяць гэта бяспечным — Postgres Row-Level Security (RLS) для ізаляцыі чытання/запісу і узровень ідэмпатэнтнасці, каб паўторы і аднаўленне ходу ніколі не дублявалі рэальны пабочны эфект.

Ізаляцыя арэндараў з Row-Level Security

Ізаляцыя забяспечваецца на ўзроўні базы даных, а не толькі ў кодзе праграмы. AiHummer выконвае запыты праз абмежаваную ролю Postgres (aihummer_app), да якой ужытыя палітыкі RLS, так што база даных сама адхіляе радкі, якія не належаць актыўнаму арэндару.

RLS уключаецца апцыянальна. Вы актывуеце яе, даючы шлюзу другі радок злучэння для абмежаванай ролі:

# 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 гарантуе гэта дзвюма сумесна працуючымі часткамі.

Устойлівы да аднаўлення ключ рэестра

Кожны пабочны эфект запісваецца супраць устойлівага да аднаўлення ключа рэестра: ключа, які дэтэрмінавана выводзіцца з ходу, так што прайграванне таго ж ходу вылічае той самы ключ, а не новы. Рэестр памятае, якія ключы ўжо былі адпрацаваны.

Бар’ер пабочных эфектаў

Перад тым, як выканаецца эфект, такі як пошта ці адпраўка ў канал, ён праходзіць праз бар’ер пабочных эфектаў, які правярае рэестр. Калі гэты ключ ужо спрацаваў, бар’ер кароткае замыкае, і эфект прапускаецца; калі не, эфект выконваецца, і ключ фіксуецца.

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

Вынік — роўна-аднаразовыя знешнія паводзіны, нягледзячы на тое, што дастаўка ўнутры “хаця б адзін раз”. Паўторы бяспечныя па канструкцыі, што і дазваляе аднаўленню ходу (гл. Дастаўка, outbox і аднаўленне) прайграваць перарваны ход без таго, каб кліент атрымаў той самы email ці той самы адказ двойчы.

[!TIP] Менавіта таму AiHummer можа прапанаваць гарантаваную дастаўку і аўтаматычнае аднаўленне ходу без звычайнай рызыкі дублюючых паведамленняў — ідэмпатэнтнасць з’яўляецца асновай, на якой пабудаваны гарантыі дастаўкі.

Куды далей

Рантайм, які кіруе ходам: Шлюз і рухавік ходу.
Як адказы вяртаюцца роўна адзін раз: Дастаўка, outbox і аднаўленне.