რა არის განაწილებული ქეში და როგორ ვმართოთ მისი შეფერხებები?

Question

IT Interview Practice · Accepted Answer

**განაწილებული ქეში აპლიკაციის რამდენიმე ეგზემპლარს ქსელით მონაცემების ხელახლა გამოყენების საშუალებას აძლევს.** მიზანია ძვირი სამუშაოს განმეორების თავიდან აცილება, სიახლისა და მარცხის მკაფიო წესებით.

წარმოიდგინეთ სამი backend ეგზემპლარი, რომლებიც ერთ კატალოგს კითხულობს. პროცესის შიდა ქეშით თითოეული საკუთარ ასლს მართავს. საერთო სერვისით ერთის ჩაწერილ მნიშვნელობას სხვებიც იყენებს. ქეშის სერვისი თავადაც რამდენიმე კვანძზე შეიძლება მუშაობდეს.

## 1. გადაწყვიტეთ, რისი ქეშირებაა უსაფრთხო

დაიწყეთ მონაცემის მიღების ფასითა და დასაშვები სიძველით. პროდუქტის აღწერამ მცირე დაყოვნება შეიძლება აიტანოს, შესყიდვის საბოლოო მარაგის შემოწმებას კი ავტორიტეტული მონაცემი სჭირდებოდეს.

გასაღებმა სრული შედეგი უნდა განსაზღვროს, tenant-ის, ენისა და სხვა მნიშვნელოვანი შეყვანის ჩათვლით. სხვაგვარად სწრაფმა ქეშმა სხვა კლიენტის მონაცემი შეიძლება დააბრუნოს. გამძლე ბიზნესჩანაწერების ავტორიტეტი ბაზაში დატოვეთ, რადგან ქეშის მნიშვნელობები შეიძლება გაქრეს.

## 2. განახლებამდე კითხვის გზა გაიარეთ

გავრცელებული მიდგომაა cache-aside: აპლიკაცია ქეშს ამოწმებს, არყოფნისას ბაზას კითხულობს და შედეგს ვადით, TTL-ით ინახავს.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

ეს განმეორებით კითხვას ამცირებს, როცა ბევრ მოთხოვნას ერთი მნიშვნელობა სჭირდება. თუმცა ქსელურ გამოძახებებსა და დამოკიდებულებას ამატებს; ქეში მაშინ ღირს, როცა დაზოგილი სამუშაო ამ ხარჯს აღემატება. იხილეთ [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. განსაზღვრეთ განახლების ხილვადობა

კატალოგისთვის პრაქტიკული დასაწყისია ბაზის განახლების commit და შემდეგ ქეშირებული პროდუქტის გაუქმება. შემდეგი მკითხველი მას თავიდან ჩატვირთავს. მაგრამ რბოლა რჩება: მკითხველმა ძველი მნიშვნელობა commit-მდე შეიძლება აიღოს და გაუქმების შემდეგ ქეშში ჩაწეროს.

TTL ახალი ქეშირებული ასლის სიცოცხლეს ზღუდავს; არ იძლევა გარანტიას, რომ ყოველი კითხვა ბოლო ჩაწერას მაშინვე ხედავს. თუ ძველი უფლება, ფასი ან ბალანსი ოპერაციის წესს არღვევს, ავტორიტეტულ წყაროსთან შეამოწმეთ ან ვერსიებზე დაფუძნებული განახლება მკაფიო გარანტიებით შექმენით. თანმიმდევრულობა ბიზნესოპერაციით აირჩიეთ და არა ვარაუდით, რომ Redis ყველაფერს აგვარებს.

## 4. ქეშში არყოფნა გათიშვად არ აქციოთ

პოპულარული ჩანაწერის ვადის გასვლისას ბევრი მომთხოვნი ბაზას ერთად შეიძლება მიადგეს. ეს cache stampede-ია. ქეშის გათიშვა იმავე პრობლემას მრავალ გასაღებზე ქმნის.

- ერთ გასაღებზე ერთდროული ჩატვირთვები გააერთიანეთ, რათა ნაკლებმა მოთხოვნამ აღადგინოს; განსაზღვრეთ კოორდინაცია ერთ პროცესს მოიცავს თუ ყველას.
- ვადები განსხვავებული გახადეთ, რათა ბევრი ჩანაწერი ერთად არ ამოიწუროს. ეს განახლებას ანაწილებს, მაგრამ ყველა ცხელი გასაღების პრობლემას არ აგვარებს.
- განახლებისას ძველი მნიშვნელობა მხოლოდ მაშინ დააბრუნეთ, თუ ბიზნესი მოძველებულ მონაცემს უშვებს.
- ქეშის მოკლე timeout გამოიყენეთ და ბაზაზე სათადარიგო ნაკადი შეზღუდეთ. ნაწილის უარყოფა შეიძლება სჯობდეს ბაზის გადატვირთვასა და ყველა მოთხოვნის ჩავარდნას.

ეს გზები მიზანმიმართულად გამოცადეთ. ნორმალურ რეჟიმში მაღალი hit rate ქეშის გაქრობისას ქცევაზე ცოტას გვეუბნება.

## 5. რეალური დაბრკოლების მიხედვით გაიზარდეთ

შარდინგი გასაღებებს კვანძებს შორის ყოფს; რეპლიკაცია ასლებს ხელმისაწვდომობის ან კითხვისთვის ინახავს. ისინი სხვადასხვა პრობლემას აგვარებს. Redis Cluster განლაგებისთვის hash slot-ებს იყენებს, ამიტომ დამატებითი კვანძი ერთი ცხელი გასაღების სამუშაოს ავტომატურად არ ყოფს. იხილეთ [Redis Cluster-ის სპეციფიკაცია](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

აკონტროლეთ hit rate, დაყოვნება, timeout, მეხსიერება, გაძევებები და ბაზის დატვირთვა. გაძევება მეხსიერების სამართავად მნიშვნელობის წაშლას ნიშნავს და TTL-მდეც შეიძლება მოხდეს. ქეშის ჩანაწერი ბიზნესმონაცემებისა ან რიგის სამუშაოს გარანტირებულ მუდმივ საცავად არ ჩათვალოთ.

კატალოგისთვის მკაფიო გასაღებებიანი cache-aside-ით, სიახლის პოლიტიკითა და დაცული სათადარიგო გზით დავიწყებდი. კვანძებს მხოლოდ გაზომილი, განაწილებით რეალურად მოსაგვარებელი სიმძლავრის პრობლემისას დავამატებდი. **კარგი ქეშის დიზაინი ხსნის ქცევას როგორც მნიშვნელობის არსებობისას, ისე არყოფნის ან მცდარობისას.**

1. გადაწყვიტეთ, რისი ქეშირებაა უსაფრთხო

2. განახლებამდე კითხვის გზა გაიარეთ

3. განსაზღვრეთ განახლების ხილვადობა

4. ქეშში არყოფნა გათიშვად არ აქციოთ

5. რეალური დაბრკოლების მიხედვით გაიზარდეთ

დაკავშირებული კითხვები