Шматкарыстальніцкі рэжым і ідэмпотэнтнасць

# 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 выконвае запыты праз **абмежаваная роля Postgres** (`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 ``` Вынік такі **знешняя паводзіна дакладна адзін раз, нават калі дастаўка ўнутрана як мінімум адзін раз**Повторныя спробы па сваёй прыродзе бяспечныя, што дазваляе ажыццяўляць аднаўленне пасля павароту (гл. [Надзейная дастаўка і аднаўленне](/be/v1.0/architecture/delivery-outbox)) паўтарыць перапынены ход без адпраўкі кліенту таго ж самага ліста ці той жа самай адказу двойчы. > [!TIP] > Менавіта таму AiHummer можа забяспечыць гарантованую дастаўку і аўтаматычнае аднаўленне паваротаў > без звычайнага рызыкі паўторных паведамленняў — асноўай з'яўляецца ідэмпотэнтнасць > гарантыі пастаўкі заснаваны на ## Куды далей - Час працы, які кіруе паваротам: [Шлюз і паваротны рухавік](/be/v1.0/architecture/gateway-turn-engine). - Як адказы вяртаюцца толькі адзін раз: [Надзейная дастаўка і аднаўленне](/be/v1.0/architecture/delivery-outbox).