კეშტის სტრატეგიები

1) რატომ უნდა გააკეთოთ ეს?

• სიჩქარე (p95/p99 ქვემოთ), ღირებულება (ნაკლები egress/CPU), სტაბილურობა (ნაკლები დამოკიდებულება მწვერვალის ქვეშ).
• მწვერვალების შერყევა და იზოლაცია „ხმაურიანი მეზობლებისგან“.

1. კლიენტი (ბრაუზერი/მობილური) - HTTP ქეში, IndexedDB, ადგილობრივი სცენა.

2. Edge/CDN - POP კვანძები მომხმარებელთან უფრო ახლოს, API- ს სტატიკასა და ნაწილზე.

3. L7 კარიბჭე/Reverse-proxy - Nginx/Envoy/Varnish (მიკროკეში, SWR).

4. მომსახურების ქეში - Redis/Memcached კლასტერში.

5. შიდა პროცესორი - მეხსიერება (Caffeine/Guava/LRU-map).

6. კეში DD- ში - მატერიალური იდეები, მეორადი ინდექსები.

წესი: მაქსიმალურად დაუახლოვდით მომხმარებელს, მაგრამ ერთხელ შეინახეთ ჭეშმარიტება.

2) კეშტის ნიმუშები

2. 1 Cache-aside (“lazy loading”)

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

2. 2 Read-through

კითხვა ყოველთვის არის ქეშის მეშვეობით, რომელიც თავად მიდის წყაროსთან გამოტოვების დროს (ბიბლიოთეკა/პროსპექტის ფენა).
მოსახერხებელია TTL/სერილიზაციის პოლიტიკის ცენტრალიზაცია.

2. 3 Write-through / Write-back (write-behind)

Write-through: ქეში ჩაწერა და წყარო სინქრონულად შეესაბამება ზემოთ, ლატენტობა უფრო მაღალია.
Write-back: ქეში ჩაწერა, წყაროში ასინქრონული ფლეშ ჩაწერა სწრაფად, მაგრამ ზარალის და კონფლიქტების რისკი.

2. 4 Refresh-ahead (proactive)

პროგნოზირებს „TTL მალე ამოიწურება“ და განაახლებს კლავიშს სტამპედის თავიდან ასაცილებლად.

2. 5 Negative caching

მოკლე TTL- ზე კეშირება „არ არსებობს მონაცემები/404/ცარიელი“ ამცირებს დატვირთვას წყაროზე.

2. 6 Micro-caching

ძალიან მოკლე TTL (0. 5-5 ს) L7- ზე „თითქმის დინამიკისთვის“ (სიები, მთავარი) - მკვეთრად ამცირებს კუდებს.

3) HTTP ქეში: სათაურები და კონტროლი

3. 1 ძირითადი სათაურები

`Cache-Control`: `max-age`, `s-maxage` (для shared кэшей), `public/private`, `no-store`, `stale-while-revalidate`, `stale-if-error`.
მიმღები: 'ETag' (შინაარსის ჰაში), 'Last-Modified'.
პირობების მოთხოვნები: 'If-None-Match', 'If-Modified-Since' - 304 Not Modified.

3. 2 Vary და გასაღებები

'Vary: Accept-Encoding, Authorization, Cookie, Accept-Language' - ქმნის ქეშის სხვადასხვა ვარიანტს. მინიმუმამდე დაიყვანეთ 'Vary' ისე, რომ არ „აფეთქდეს“ კარდინალობა.

3. 3 HTTP პასუხის მაგალითი

Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60
ETag: "a1b2c3"
Vary: Accept-Encoding

4) გასაღებების დიზაინი და TTL

4. 1 გასაღებები

სტრუქტურირება: 'tenant: user: {id}: profile: v3' (ჩართეთ სქემის ვერსია).
მოერიდეთ PII გასაღები.
კოლექციებისთვის - კლავიში + მოთხოვნის პარამეტრები (ნორმალიზებული და დალაგებული).

4. 2 TTL და კოორდინაცია

მოკლე TTL ამცირებს შეუსაბამობას, მაგრამ ზრდის შეცდომებს.
კრიტიკული მონაცემებისთვის - მოქმედი ('ETag') და SWR (stale-while-revalidate).
იშვიათად ცვალებადი ადამიანებისთვის - ინვალიდობის გრძელი TTL + „უსახლკარობა“.

4. 3 ვერსია/გაფიცვა

შეუთავსებელი ცვლილებებით - შეცვალეთ პრეფიქსი/გასაღების ვერსია ('v2-v3').
სტატიკური რესურსებისთვის - შინაარსი hash ფაილის სახელით.

5) ინვალიდობა: სტრატეგია და პრაქტიკა

5. 1 პირდაპირი მოცილება

'DEL key '/' PURGE' მარიონეტებისთვის. საშიშროება: რბოლა მოცილებასა და მრავალჯერადი მკითხველს შორის.

5. 2 Tegi/Surrogate keys

დაუკავშირეთ დოკუმენტი ტეგების ერთობლიობას (კატეგორია/ავტორი). ინვალიდობა - ჭდეზე.
В Varnish/Edge — `Surrogate-Key: article:42 tag:author:7` + `BAN tag:author:7`.

5. 3 ღონისძიება შეზღუდული შესაძლებლობის მქონე

Pub/Sub (Kafka/NATS): როდესაც წყარო იცვლება, ჩვენ ვაქვეყნებთ მოვლენას „invalidate“.
ქეშის კონსიუმერები უსმენენ და აშორებენ კლავიშებს.

5. 4 ორფაზიანი

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

6) ბრძოლა stampede/dogpile და ცხელი გასაღებები

6. 1 Request coalescing (singleflight)

ერთი პროდიუსერი განაახლებს კლავიშს, დანარჩენი შედეგს ელოდება (mutex/ეტიკეტი „განახლებულია“).

6. 2 Jitter к TTL

დაამატეთ უბედური შემთხვევა (± 10-20%) TTL- ს, რათა თავიდან აიცილოთ სინქრონული შეშუპება.

6. 3 Soft-TTL + hard-TTL

სანამ soft-TTL ემსახურება ქეში, პარალელურად გამომწვევი რეფრესი; hard-TTL - ჩვენ შეცდომებს ვთვლით.

6. 4 ცხელი გასაღებები

ადგილობრივი ქეში ზემოთ (ორი-ტიერი).
ცხელი გასაღების რეპლიკაცია რამდენიმე ხუმრობით და რანდომიული არჩევანი (მხოლოდ read-only- ისთვის).
კონკრეტული გასაღების განახლება.

6. 5 Redis + Lua- ს მაგალითი

lua
-- SETNX lock with TTL to avoid deadlocks local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "LOCKED"
else return "WAIT"
end

7) გადაადგილების პოლიტიკა და ქეში ჩასმა

7. 1 Eviction

LRU: მარტივი და კარგი ადგილისთვის.
LFU: უკეთესია „გრძელი“ ცხელი კლავიშებით.
ARC/TinyLFU: ჩანაწერების/თავისუფლების ბალანსი.

7. 2 Admission (შესასვლელი)

ნუ დაუშვებთ გიგანტურ იშვიათ ობიექტებს (TinyLFU/Bloom ფილტრები).
დიდი მნიშვნელობების კომპრესია (LZ4/Zstd) საზღვარზე „ზომა/ლატენტობა“.

8) შარდვა და ტოპოლოგია

8. 1 Consistent hashing

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

8. 2 Redis/Memcached ტოპოლოგია

Redis Cluster (slots/shards), Sentinel (faylover), რეპლიკაცია read-only.
Memcached - ketama hashing კლიენტი, სერვერის დონეზე რეპლიკაციის გარეშე.

8. 3 ადგილობრივი + განაწილებული

კასკადი: in-proc (mikro-TTL/LRU) - Redis (TTL უფრო გრძელი) - წყარო.
ფრთხილად იყავით TTL- ის ბისექსუალებით და ქეშის წამყვანებით.

9) Edge, CDN და L7 ქეში

9. 1 Micro-cache на Nginx

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:100m inactive=10m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
if ($skip_cache) { add_header Cache-Control "no-store"; }
proxy_cache api;
proxy_cache_valid 200 2s;       # micro-cache proxy_cache_use_stale error timeout updating;
proxy_cache_background_update on;   # SWR add_header X-Cache $upstream_cache_status;
proxy_pass http://upstream;
}
}

9. 2 Envoy (SWR და პირობები)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. file_system_http_cache. v3. FileSystemHttpCacheConfig cache_path: "/var/cache/envoy"

9. 3 Varnish (Surrogate keys)

გამოიყენეთ 'Surrogate-Key' და 'ban' კონტეინერების ინვალიდობისთვის.

10) კეში და მონაცემთა შესაბამისობა

10. 1 Read-your-writes

მომხმარებლის პროფილებისთვის/კალათებისთვის, უზრუნველყეთ მოკლე TTL, ან ჩაწერა ქეშის საშუალებით, ან კლიენტის ეტიკეტირება (ჩაწერის შემდეგ N წამში).

10. 2 Eventual vs Strong

სარეკონსტრუქციო/ანალიტიკური - საღამოს + გრძელი TTL.
შეკვეთების ფულისთვის/სტატუსისთვის - მოკლე TTL, შესაბამისობა, ზოგჯერ კრიტიკულ გზებზე ქეშის გარეშე.

10. 3 ინვარიანტები

ნუ დააყოვნებთ ველებს, რომლებიც გავლენას ახდენენ უსაფრთხოებაზე/ACL, მკაცრი TTL- ის გარეშე და ხელახლა შემოწმება.

11) დაკვირვება, SLO და კონტროლი

11. 1 მეტრიკა

hit_ratio (общий и per-route), byte_hit_ratio, miss_rate.
stampede_prevented_total, refresh_ahead_total, ban/purge_total.
ლატენტობა: p50/p95/p99 წყაროდან ქეში.
Hot _ keys _ topN და მათი QPS/ბაიტი.

11. 2 ლოგიკა და ტრეკები

განათავსეთ 'X-Cache: HIT/MISS/STALE/განახლება'.
ტრეისებში აღნიშნეთ პასუხის წყარო ('cache = true', 'tier = edge' service 'ადგილობრივი').

11. 3 SLO მიდგომა

მაგალითი: "API/catalog p99-250 ms, cache hit - 85%, stampede - 0. მოთხოვნის 1%."

11. 4 Runbooks

„გამოტოვება იზრდება“, შეამოწმეთ TTL, დათბობა/ინვალიდობა, ცხელი ქეში, ქაშის ზომა და მიღების პოლიტიკა.

12) უსაფრთხოება და მრავალ ტენანტობა

შეიტანეთ tenant-id გასაღებებში (და 'Vary' HTTP- ში).
ნუ დააყოვნებთ პირად პასუხებს, როგორც 'public'.
დაშიფვრა ქეში მგრძნობიარე მონაცემებით ან შეინახეთ მხოლოდ არა-PII/ID.

13) ტიპიური რეცეპტები

13. 1 კატალოგი/ფირზე (თითქმის დინამიკა)

Edge-მიკროკეში 1-3 + SWR, შიგნით - Redis 15-60 წმ, ინვალიდობა განახლების მოვლენებზე.

13. 2 მომხმარებლის პროფილი

Cache aside ერთად TTL 30-120 წმ, bypass 5-10 პროფილის განახლების შემდეგ (cookie/heder), ან write-through.

13. 3 Valyuto კურსები/საცნობარო წიგნები

გრძელი TTL (წუთი) + მიზნობრივი ინვალიდობა ახალი მონაცემების გამოქვეყნებისას; 'ETag' პირობითი GET- ისთვის.

13. 4 ძებნა

Edge-მიკროკეში 1-2 წმ, შიგნით - refresh-ahead და coalescing, გასაღები query პარამეტრების ნორმალიზება.

14) ანტი შაბლონები

ქეში ინვალიდობის გარეშე: მხოლოდ TTL- ს იმედი არის გრძელი შეუსაბამობის ფანჯრები.
Giant 'Vary': ვარიანტების „აფეთქება“ დაბალია hit-rate.
ერთი cash/experiments - დაბინძურება.
TTL- ის ამოწურვისას წყაროზე stampede პიკის დაცვა არ არსებობს.
ფულის/უფლებების ქეში/ACL მკაცრი გარანტიების გარეშე.
„ზედიზედ“ კომპრესია ზედმეტი CPU, მცირე ობიექტებში p99 გაუარესება.

15) განხორციელების სია

• დაადგინეთ კეშის დონე და მათი მიზნები (edge/service/ადგილობრივი).
• შეიმუშავეთ გასაღებები (ვერსია, ტენანტი, პარამეტრების ნორმალიზაცია).
• შეარჩიეთ ნიმუში (cache-aside/read-through/refresh-ahead).
• პარამეტრი TTL/soft-TTL/jitter, ჩართეთ SWR.
• გააცნობიერეთ coalescing/singleflight, დაცვა stampede.
• ორგანიზება გაუწიეთ ინვალიდობას (მოვლენები, ჭდეები, purge/ban).
• შეიყვანეთ hit-ratio/ლატენტობის მეტრიკები და დაშბორდები 'X-Cache'.

ჩაატარეთ დატვირთული ტესტები ცხელი კლავიშებით.

• დაწერეთ SLO და runbooks.
• შეამოწმეთ უსაფრთხოება/იზოლაცია და 'Vary'.

16) FAQ

Q: რა უნდა აირჩიოთ - cache-aside ან read-through?
A: მარტივი სერვისებისთვის - cache aside. ჩვენ გვჭირდება ცენტრალიზაცია და ერთიანი პოლიტიკა - read-through.

Q: როგორ გავიგოთ ოპტიმალური TTL?
A: მოერიდეთ დასაშვებ დაღლილობას, განახლების სიხშირეს და მიზნობრივ hit-rate- ს; დაამატეთ jitter და დააკვირდით r95/r99/ღირებულებას.

Q: როდის არის შესაფერისი write-back?
A: უაღრესად დატვირთული ნაკადებისთვის, სადაც შერჩევითი თანმიმდევრულობა მისაღებია, არსებობს საიმედო ხაზი/ლოგა „დასაწერად“.

Q: შესაძლებელია უფლებამოსილი პასუხების კაშხალი?
A: დიახ, მაგრამ ჩადეთ 'პირადი' და/ან ჩართეთ ტენანტი/მომხმარებელი გასაღებად/' Vary '. სამგზავრო კონფიდენციალურობისთვის - კლიენტის ქეში.

Q: როგორ გავათბოთ ქეში?
A: პოპულარული გასაღებების სიები, ფონი-ფონი, მეტყველება ლოგოებიდან, გაათბეთ გამოშვებამდე/მწვერვალამდე (შავი პარასკევი და ა.შ.).

17) შედეგები

ეფექტური კაშხალი არის კლავიშების დიზაინი + გონივრული TTL + კომპეტენტურად შერჩეული ნიმუში, რომელიც აძლიერებს შეზღუდული შესაძლებლობის მქონე მოვლენებს, SWR/refresh-ahead და იცავს stampede- ს. განათავსეთ ქეში დონეზე (კლიენტი/edge/სერვისი), დაამატეთ დაკვირვება და SLO - და მიიღეთ სტაბილური ლატენტობის კუდები, პროგნოზირებადი ღირებულება და პიკის დატვირთვისადმი წინააღმდეგობა.