From e805e7b782e6d1484278bb1b4550cbd6e0d50080 Mon Sep 17 00:00:00 2001
From: Roy Mayan <>
Date: Mon, 9 Jun 2025 20:54:44 +0300
Subject: [PATCH] Translating - Consistency and Availability Patterns
---
README-he.md | 140 ++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 133 insertions(+), 7 deletions(-)
diff --git a/README-he.md b/README-he.md
index 8f5d1369..5862cbbf 100644
--- a/README-he.md
+++ b/README-he.md
@@ -695,7 +695,7 @@
-## ביצועים (performance) מול סקילביליות (scalability)
+## ביצועים (Performance) מול סקילביליות (Scalability)
@@ -715,7 +715,7 @@
-## שיהוי (latency) מול תפוקה (throughput)
+## שיהוי (Latency) מול תפוקה (Throughput)
@@ -731,7 +731,7 @@
-## זמינות (availability) מול עקביות (consistency)
+## זמינות (Availability) מול עקביות (Consistency)
@@ -746,10 +746,10 @@
במערכות מחשוב מבוזרות, ניתן לתמוך רק בשניים מתוך שלושת התנאים הבאים:
- - עקביות (Consistency) – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.
- - זמינות (Availability) - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.
- - יכולת חלוקה (Partition Tolerance) - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.
-
+
עקביות (Consistency) – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.
+
זמינות (Availability) - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.
+
יכולת חלוקה (Partition Tolerance) - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.
+
*ניתן לצאת מנקודת הנחה שרשתות לא אמינות - כך שנהיה חייבים לתמוך ב-״Partition tolerance״.
לכן, נצטרך לבחור אחד משני האחרים - זמינות או עקביות.*
@@ -770,3 +770,129 @@
* [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem)
* [CAP FAQ](https://github.com/henryr/cap-faq)
* [The CAP theorem](https://www.youtube.com/watch?v=k-Yaq8AHlFA)
+
+
+
+כאשר קיימים מספר עותקים של אותם נתונים, עלינו להחליט כיצד לסנכרן ביניהם כדי שלקוחות יקבלו תצוגה עקבית של המידע.
+ניזכר בהגדרה של עקביות מתוך [משפט CAP](#cap-theorem): כל קריאה מקבלת את הכתיבה העדכנית ביותר או שגיאה.
+
+### עקביות חלשה (Weak Consistency)
+
+לאחר כתיבה, קריאות עשויות לראות או לא לראות את הערך החדש שנכתב. הגישה כאן היא של best effort - המאמץ הטוב ביותר.
+
+גישה זו נפוצה במערכות כמו memcached. עקביות חלשה מתאימה למקרים של מערכות זמן-אמת, כמו VoIP, שיחות וידאו, ומשחקים מרובי משתתפים.
+לדוגמה, אם אתה בשיחת טלפון ומאבד קליטה לכמה שניות, כשאתה חוזר אתה לא שומע מה שנאמר בזמן שלא הייתה קליטה.
+
+### עקביות לא מיידית (Eventual Consistency)
+
+לאחר כתיבה, הקריאות יראו בסופו של דבר את מה שנכתב (בדרך כלל תוך מספר מילישניות). הנתונים משוכפלים באופן אסינכרוני.
+
+גישה זו נפוצה במערכות כמו DNS ומייל. עקביות לא מיידית מתאימה למערכות ששומרות על זמינות גבוהה במיוחד.
+
+### עקביות חזקה (Strong Consistency)
+
+לאחר כתיבה, הקריאות יראו תמיד את הערך החדש שנכתב. השכפול מתבצע באופן סינכרוני.
+
+גישה זו נפוצה במערכות קבצים ובמסדי נתונים רלציוניים (RDBMS). עקביות חזקה מתאימה למערכות שדורשות טרנזקציות.
+
+### מקורות וקריאה נוספת
+
+- [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html)
+
+
+
+## דפוסי זמינות (Availability Patterns)
+
+
+
+קיימים שני דפוסים משלימים לתמיכה בזמינות גבוהה: **מעבר אוטומטי (fail-over)** ו-**שכפול (replication)**.
+
+### גיבוי בזמן כישלון (Fail-Over)
+
+#### אקטיבי-פסיבי (Active-Passive)
+
+במבנה אקטיבי-פסיבי, נשלחים heartbeat-ים בין השרת הפעיל לשרת הרזרבי (הפסיבי). אם ה-heartbeat נקטע, השרת הפסיבי לוקח את כתובת ה-IP של הפעיל וממשיך את השירות.
+
+משך זמן ההשבתה תלוי אם השרת הפסיבי פועל מראש במצב 'חם' (hot standby), או שיש להפעילו ממצב 'קר' (cold standby). רק השרת הפעיל מקבל תעבורה.
+
+סוג זה נקרא גם Master-Slave.
+
+#### אקטיבי-אקטיבי (Active-Active)
+
+במבנה אקטיבי-אקטיבי, שני השרתים מקבלים תעבורה ומחלקים ביניהם את העומס.
+
+אם השרתים חשופים פומבית, שרת ה-DNS צריך לדעת על כתובות ה-IP הציבוריות של שניהם. אם השרתים פנימיים, על לוגיקת האפליקציה להכיר את שניהם.
+
+סוג זה נקרא גם Master-Master.
+
+### חסרונות של מעבר אוטומטי
+
+
+ - מעבר אוטומטי מוסיף חומרה ועלות תפעולית.
+ - קיימת אפשרות לאובדן נתונים אם המערכת הפעילה קורסת לפני שהספיקה לשכפל את המידע למערכת הפסיבית.
+
+
+### שכפול (Replication)
+
+#### עבור Master-Slave/Master-Master
+
+נושא זה נדון בפירוט נוסף בחלק על [מסדי נתונים](#database):
+
+- [Master-slave replication](#master-slave-replication)
+- [Master-master replication](#master-master-replication)
+
+### זמינות במספרים
+
+נהוג למדוד זמינות לפי זמן פעילות (uptime) או חוסר פעילות (downtime)כאחוז מהזמן שבו השירות פועל. המדד הנפוץ הוא לפי מספר התשיעיות — לדוגמה: שירות עם זמינות של 99.99% מתואר כבעל ארבע תשיעיות.
+
+#### זמינות של 99.9% — שלוש תשיעיות
+
+| Duration | Acceptable downtime|
+|---------------------|--------------------|
+| Downtime per year | 8h 45min 57s |
+| Downtime per month | 43m 49.7s |
+| Downtime per week | 10m 4.8s |
+| Downtime per day | 1m 26.4s |
+
+#### זמינות של 99.99% — ארבע תשיעיות
+
+| Duration | Acceptable downtime|
+|---------------------|--------------------|
+| Downtime per year | 52min 35.7s |
+| Downtime per month | 4m 23s |
+| Downtime per week | 1m 5s |
+| Downtime per day | 8.6s |
+
+#### זמינות במקביל לעומת בטור
+
+אם שירות מורכב ממספר רכיבים שעלולים להיכשל, הזמינות הכוללת של השירות תלויה באופן שבו הם מסודרים - בטור או במקביל.
+
+###### בטור
+
+כאשר שני רכיבים עם זמינות קטנה מ-100% מסודרים בטור, הזמינות הכוללת יורדת:
+
+```
+Availability (Total) = Availability (Foo) * Availability (Bar)
+```
+
+אם גם `Foo` וגם `Bar` זמינים ברמה של 99.9%, הזמינות הכוללת שלהם בטור תהיה 99.8%.
+
+###### במקביל
+
+הזמינות הכוללת עולה כאשר שני רכיבים בעלי זמינות קטנה מ־100% פועלים במקביל:
+
+```
+Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
+```
+
+אם גם `Foo` וגם `Bar` זמינים ברמה של 99.9%, הזמינות הכוללת שלהם במקביל תהיה 99.9999%.
+
+