მრავალმომხმარებლური რეჟიმი და idemპოტენტობა

# 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 არის **abonementi სურვილისამებრ**. თქვენ ააქტიურებთ მას, გადასცემდეთ გაშუქების გეითვეის მეორედ კავშირის სტრიქონს შეზღუდული როლისთვის: ```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 ``` შედეგი **მომართვა ზუსტად ერთხელ გარეგნობაში, მიუხედავად იმისა, რომ მიწოდება შიგნით ხდება რამდენჯერმე**. განმეორებითი მცდელობები უსაფრთხოა კონსტრუქციის მიხედვით, რაც საშუალებას აძლევს მოსახვევის აღდგენას (იხ. [დამოჯერებელი მიწოდება და აღდგენა](/ka/v1.0/architecture/delivery-outbox)) გაიმეოროთ შეწყვეტილი მოქმედება, რათა კლიენტი არ მიიღოს ერთი და იგივე წერილი ან ერთი და იგივე პასუხი ორჯერ. > [!TIP] > იმიტომ AiHummer შეუძლია შეთავაზოს გარანტირებული მიტანა და ავტომატური დაბრუნება > გართულებების განმეორებითი შეტყობინებების ჩვეულებრივი რისკის გარეშე — იდემპოტენტობა არის საფუძველი > რომლებზეც იმყარება მიწოდების გარანტიები. ## სად შემდეგ? - მოქმედების დრო, რომელიც აკონტროლებს შემობრუნებას: [გეითვეინი და შემობრუნებადი ძრავა](/ka/v1.0/architecture/gateway-turn-engine). - როგორ დაბრუნდება პასუხები ზუსტად ერთხელ: [დამოჯერებელი მიწოდება და აღდგენა](/ka/v1.0/architecture/delivery-outbox).