אסטרטגיות הכנת מזומנים

1) מדוע מטמון והיכן לעשות זאת

• מהירות (p95/p99 נמוך יותר), עלות (פחות יציאה/מעבד), יציבות (פחות תלויות מתחת לשיא).
• החלקת שיא ובידוד מ ”שכנים רעשניים”.

1. לקוח (דפדפן/מובייל) - מטמון HTTP, IndexedDB, אחסון מקומי.

2. קשרי Edge/CDN - POP קרובים יותר למשתמש, מטמון סטטי וחלק מ ־ API.

3. L7-gateway/Reverse-proxy - Nginx/Transoy/Varnish (microcash, SWR).

4. מטמון שירות - Redis/Memced בתוך האשכול.

5. בתהליך - בזיכרון (קפאין/גויאבה/מפת LRU).

6. מטמון במסד הנתונים - ייצוגים חומריים, אינדקסים משניים.

כלל: מטמון קרוב ככל האפשר לצרכן, אבל לשמור את האמת פעם אחת.

2) תבניות מטמון

2. 1 מטמון בצד (”טעינה עצלה”)

היישום הראשון קורא מהמטמון; במקרה של החטאה - מהמקור, אז כותב למטמון.
מקצוענים: פשטות, שליטה. התחלות קרות, חלונות לא מתאימים.

2. 2 קריאה דרך

הקריאה היא תמיד דרך המטמון, אשר עצמו הולך למקור כאשר הוא מפספס (library/proxy layer).
נוח לרכז מדיניות TTL/serialization.

2. 3 כתיבה/כתיבה לאחור (כתיבה מאחור)

כתיבה דרך: לכתוב למטמון ומקור בצורה סינכרונית = עקביות גבוהה יותר, latency גבוה יותר.
כתוב-בחזרה: כתוב למטמון, הבזק אסינכרוני לכתוב למקור = מהיר, אבל סיכון לאובדן וקונפליקט.

2. 4 רענון מראש (פרואקטיבי)

מנבא ש ”טי-טי-אל יפוג בקרוב” ומעדכן את המפתח ברקע, מונע מנוסה.

2. 5 מטמון שלילי

חישוב ”אין נתונים/404/ריק” ל ־ TTL קצר מקטין את העומס על המקור.

2. 6 מיקרו ־ מזומנים

TLs (0 קצר מאוד. 5-5 אס) על L7 עבור ”כמעט דינמיקה” (רשימות, ראשי) - חד מפחית זנבות.

3) מטמון HTTP: כותרות ושליטה

3. 1 כותרות בסיסיות

'מטמון-בקרה': 'מקס-גיל', 's-maxage' (callate-called), 'ציבורי/פרטי', 'אין חנות', 'מעופש-בזמן-לבטל', 'מעופש-אם-טעות'.
מאשרים: 'Etag' (חשיש תוכן), 'Last-Modified'.
שאילתות עם תנאים: 'If-None-Match', 'If-Modified-Maying' # 304 Not Mutified.

3. 2 שינויים ומפתחות

'Vary: קבל-קידוד, אישור, עוגיות, לקבל-שפה' - יוצר אפשרויות מטמון שונות. למזער '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 מפתחות

מבנה: ”דייר: משתמש: (): פרופיל: v3” (כולל גרסת סכימה).
הימנע מח "ש במפתח.
עבור אוספים - פרמטרים של מפתח + שאילתה (מנורמל וממויין).

4. 2 TL ועקביות

TTL קצר מפחית חוסר התאמה אבל מגביר את החמצות.
עבור נתונים קריטיים - מאשרים ('ETag') ו-SWR (מעופש בזמן-חידוש).
לעיתים נדירות שינוי - ארוך TTL + ”פצצות” של נכות.

4. 3 Versioning/basting

עבור שינויים לא מתאימים, שנה את גירסת הקידומת/מפתח ('v2' v3 ').
עבור משאבים סטטיים - תוכן חשיש בשם הקובץ.

5) נכות: אסטרטגיות ומנהגים

5. 1 מחיקה ישירה

'Del מפתח '/' טיהור' על בא כוח. מירוצים בין הסרה לקוראים מרובים.

5. 2 מפתחות פונדקאית

קשר את המסמך עם קבוצת תגיות (קטגוריה/מחבר). נכות - על ידי תג.
Trust Varnish/Edge - 'Surrogate-Key: מאמר: 42 תגית: מחבר: 7' + 'BAN TAG: מחבר: 7'.

5. 3 נכות מונעת אירועים

פאב/סאב (קפקא/NATS): כאשר המקור משתנה, אנו מפרסמים את האירוע ”לא חוקי”.
צרכני המטמון מקשיבים ומוחקים מפתחות/עדכון.

5. 4 שני שלבים

ראשית, אנו מסמנים את המפתח המיושן (TTL רך), משרתים את המעופש, מעדכנים אותו ברקע ומחליפים אותו באופן אטומי.

6) התמודדות עם מנוסה/ערימת כלבים ומפתחות חמים

6. 1 בקשה להתגבש (singleflight)

מפיק אחד מעדכן את המפתח, השאר מחכים לתוצאה (mutex/label ”עדכונים”).

6. 2 ג 'יטר ו ־ TTL

הוספת אקראיות (net10-20%) ל ־ TTL כדי להימנע מנפיחות סינכרונית.

6. 3 רך-TTL + קשה-TTL

לפני TTL רך, אנו מגישים מן המטמון, במקביל עם הדק רענון; אנחנו מחשיבים פספוס.

6. 4 מפתחות חמים

מטמונים מקומיים מעל משותפים (שתי שכבות).
שכפול מפתח חם לשברים מרובים ובחירה אקראית (קריאה בלבד).
הגבלת קצב לעדכון מפתח מסוים.

6. 5 דוגמה של Redis + Lua (סקיצה של singleflight)

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 פינוי

LRU: פשוט וטוב למקומות.
LFU: טוב יותר עבור ”מפתחות ארוכים” חמים.
ARC/TYLFU: איזון רזנציה/תדר.

7. 2 כניסה

אל תתנו לחפצים ענקיים נדירים (מסנני בלום/TINLFU).
דחיסה של ערכים גדולים (LZ4/Zstd) בגבול הגודל/latency.

8) שרטוט וטופולוגיות

8. 1 חשיש עקבי

מפיץ באופן סטטי מפתחות לצמתים, מפחית את התנועה בזמן צמיחת אשכול/דחיסה.

8. 2 רדיס/טופולוגיות ממוקדות

Redis Cluster (חריצים/שברים), סנטינל (feilover), שכפול קריאה בלבד.
Memcashed היא כרישה בצד הלקוח (ketama hashing), ללא שכפול ברמת השרת.

8. 3 מבוזר + מקומי

Cascade: in-proc (micro-TTL/LRU) # Redis (TTL ארוך יותר) # source.
תיזהר עם המעי הגס והמטמון.

9) קצה, CDN ומטמון L7

9. 1 מיקרו-מטמון לפני 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 שליח (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 לכה (מפתחות פונדקאית)

השתמש 'פונדקאית מפתח' ו 'איסור' על תגיות עבור קצוות נכות.

10) מטמון ועקביות נתונים

10. 1 קרא ־ אתה ־ כותב

עבור פרופילי משתמש/סל מחזור, לספק או TTLs קצרים, כתיבה דרך, או סימון לקוח (מעקף עבור N שניות לאחר כתיבה).

10. 2 בסופו של דבר נגד חזק

להמלצה/אנליטית - בסופו של דבר + TTL ארוך.
למדינאות כסף/הזמנה - TTL קצר, אימות, לפעמים ללא מטמון על נתיבים קריטיים.

10. 3 אינווריאנטים

אל מטמון שדות המשפיעים על ביטחון/ACLs ללא TTL קפדני ואימות מחדש.

11) יכולת תצפית, SLO וניהול

11. 1 מדדים

hit_ratio, byte_hit_ratio, miss_rate.
stampede_prevented_total, refresh_ahead_total, ban/purge_total.
Latency: p50/p95/p99 ממטמון נגד מקור.
hot_keys_topN וה-QPS/בייטים שלהם.

11. 2 יומנים ועקבות

Log 'X-Cache: HIT/MISS/STALE/UDATING.
בעקבות, סמן את מקור התגובה ('מטמון = אמת', 'tier = ege' service 'local').

11. גישה 3 SLO

דוגמה: "עבור API/קטלוג p99 ms 250, מטמון פגע ב-85% וברח מ-0. אחוז אחד של בקשות "

11. 4 ספרי ריצות

TTL, חימום/נכות, מפתחות חמים, גודל מטמון ומדיניות קבלה.

12) בטיחות וריבוי דירות

מוטבע דייר-id במפתחות (וב 'Vary' עבור HTTP).
אל תטמון תגובות פרטיות כ ”ציבוריות”.
הצפן מטמון עם מידע רגיש או לאחסן רק לא PII/ID.

13) מתכונים טיפוסיים

13. 1 קטלוג/טייפ (כמעט דינמי)

1-3 S + SWR, בפנים רדיס עבור 15-60 S, נכות על ידי עדכון אירועים.

13. 2 פרופיל משתמש

מטמון בצד עם TTL 30-120 S, לעקוף 5-10 S לאחר עדכון פרופיל (עוגייה/כותרת), או לכתוב דרך.

13. 3 קורסים/ספרי עיון

TTL ארוך (דקות-שעות) + נכות מטרה כאשר נתונים חדשים מתפרסמים; 'Etag' לגטים מותנים.

13. 4 תוצאות חיפוש

קצה-מיקרו-קש 1-2 S, בפנים - רענון-קדימה והתלכדות, נורמליזציה של פרמטרים שאילתה במפתח.

14) אנטי דפוסים

מזומנים ללא נכות: תקווה רק עבור TTL = חלונות ארוכים של חוסר שייכות.
Giant 'Vary': ”פיצוץ” של אפשרויות?
מטמון יחיד עבור prod/ניסויים = זיהום.
אין הגנה מפני קפיצות מקור בבהלה כאשר TTL פג תוקף.
מזומן/זכויות/מטמון ACL ללא ערבויות מחמירות.
דחיסה של ”כל דבר ברצף” - מעבדים נוספים, הידרדרות של פי-99 בחפצים קטנים.

15) רשימת מימושים

[ ] הגדר את רמות המטמון ואת מטרותיהם (קצה/שירות/מקומי).

[ מפתחות עיצוב ] (וסטיונינג, דייר, פרמטר נורמליזציה).

[ ] בחר את התבנית (מטמון בצד/קריאה דרך/רענון-קדימה).

[ הגדרת ] TTL/רך-TTL/jitter, מאפשרת SWR.

[ ] יישום פחם/סינגלפנס, הגנה במנוסה.

[ ] ארגון נכות (אירועים, תגיות, טיהור/איסור).

[ ] הזן להיט-ratio/latency metrics ו-X-Cache 'לוחות מחוונים.

[ ] לבצע בדיקות מפתח חמות.

[ ] לכתוב SLO וספרים.

[ ] בדוק את הבידוד הביטחוני/דייר ו 'וארי'.

16) FAQ

ש: מה לבחור - מטמון בצד או לקרוא דרך?
א ': עבור שירותים פשוטים - מטמון בצד. אנו זקוקים לריכוזיות ולמדיניות בודדת.

Q: כיצד להבין את ה ־ TTL האופטימלי?
א ': התחלה מהתיישנות מותרת, תדירות עדכונים וקצב פגיעה במטרה; להוסיף ג 'יטר ולצפות p95/p99/עלות.

Q: מתי כתיבה לאחור מתאימה?
א. עבור זרמים בעלי עומס גבוה, כאשר בסופו של דבר העקביות מקובלת ויש תור/יומן אמין עבור ”הוספה”.

קיו: האם ניתן למקד את התגובות המוסמכות? ‏

א ': כן, אבל סימן' פרטי 'ו/או כולל דייר/משתמש במתג/Vary. עבור מטמון לקוחות פרטי.

קיו: איך לחמם את המטמון?
א. רשימות של מפתחות פופולריים, תולעי רקע, שידור חוזר של יומנים, חימום לפני שחרור/שיא (יום שישי השחור וכו ').

17) סיכומים

כתיבה יעילה היא עיצוב מפתח + TTL + סביר תבנית שנבחרה היטב, משופרת על ידי נכות באירוע, SWR/רענון-קדימה, והגנה במנוסה. Tier המטמון (לקוח/קצה/שירות), הוספת יכולת תצפית ו-SLO - ולקבל זנבות איחור יציבים, עלות צפויה והתאוששות שיא.