צילומים חוזרים והכרות

1) מודל מסירה בסיסי

לפחות פעם אחת (ברירת מחדל) - האירוע יימסר ב-1 פעמים. ערבויות בדיוק-פעם אחת מושגות על ידי אידמפוטנטיות מקלט.
הכרה (ACK): רק כל 2xx (בדרך כלל 200/204) מהמקבל פירושו הצלחה. כל השאר מתפרש ככישלון ומוביל לחזרה.
תגובה 2xx לאחר הצבת האירוע בתורו, לא לאחר עיבוד עסקי מלא.

2) תבנית אירוע וכותרות חובה

Payload (דוגמה)

json
{
"id": "evt_01HXYZ",
"type": "order. created",
"occurred_at": "2025-11-03T18:10:12Z",
"sequence": 128374,
"source": "orders",
"data": { "order_id": "o_123", "amount": "49. 90", "currency": "EUR" },
"schema_version": 1
}

כותרות השולח

X-Webhook-ID: evt_01HXYZ' - זיהוי אירוע ייחודי (שימוש לשכפול).
”X-Webhook-Seq: 128374” - רצף מונוטוני (על ידי מנוי/נושא).
'X-חתימה: Sha256 = <base64 (hmac_sha256 (גוף, סוד)> "- HMAC-they is is is imported.
אקס ריטרי: 0,1,2... "הוא מספר הניסיון.
'X-Webhook-גרסה: 1' - ורסינציה חוזה.
(אופציונלי) 'Tracepart' - איתור קורלציה.

תגובה ממקבל

2xx - התקבל בהצלחה (לא יהיו חזרות נוספות עבור זה 'id').
410 Gone - endpoint נמחק/inactive gender מסתיים retrics ומנותק מנוי.
429/5xx/timeout - השולח חוזר על פי מדיניות המגש מחדש.

3) מדיניות חזרה

סולם גיבוי מומלץ (+ jitter)

”1, 3, 10, 30, 20, 10 מטר, 30 מטר, 2h, 6h, 24h” (לעצור אחרי הגבול, למשל 48-72 שעות).

כללים:

גיבוי מעריכי + jitter אקראי (20-30%) כדי להימנע מ ”אפקט העדר”.
קוורום שגיאות עבור כשלים זמניים (לדוגמה, נסה מחדש אם 5xx או זמן רשת).
כבוד 429: קבע מינימום ”מין” (Retry-After Header, חלון הגיבוי הבא).

פסקי זמן וגדלים

פסק זמן של החיבור, 3-5 שניות; סה "כ זמן תגובה 10 שניות

גודל הגוף תחת החוזה (לדוגמה, 256 KB), אחרת 413 = הלוגיקה ”chunking” או ”pull URL”.

4) אידמפוטנטיות ושכפול

יישום idempotent: עיבוד חזרות של אותו 'id' חייב להחזיר את אותה תוצאה ולא לשנות מצב שוב.
אחסון Dedup בצד הנמען: חנות (X-Webhook-ID, processed_at, chectsum) עם חלונות TTL (24-72 שעות).
מפתח קומפוזיטיבי: אם מספר נושאים: (subscription_id, event_id).

5) סדר ו ”אפקטים של פעם אחת בדיוק”

קשה להבטיח סדר קפדני במערכות מבוזרות. השתמש:

חלוקה לפי מפתח: אותה קבוצה לוגית (למשל, 'סדר _ id') תמיד נמצאת ב ”ערוץ” אחד של מסירה.
רצף: לדחות אירועים עם 'X-Webhook-Seq' הישן ולשים אותם במגרש החניה לפני החסרים מגיעים.

השפעות חד פעמיות מושגות באמצעות:

רישום של פעולות יישומיות (דפוס תיבת הדואר הנכנס),
Transactional upsart על ידי "event _ id' בבסיס הנתונים,
סאגות/פיצוי על תהליכים מורכבים.

6) רזולוציית שגיאה על ידי קודי מצב (טבלה)

קוד תגובה	ערך לשולח	פעולה
2xx	ACK התקבל	אנחנו שוקלים מועבר, לעצור את רטריי
4xx (למעט 410/429)	שגיאה מתמדת (טעינה/אישור)	הכנס DLQ, הודע על אינטגרציה
410	נקודת סוף נמחקה/מנותקת	עצור מגשים מחדש, בטל מנוי
408/429	עומס/פסק זמן זמני	חזור על ידי חזרה/Jitter; תן דעתך ל "Retry-After &pos
5xx	שגיאת שרת זמנית	חזור על ידי חזרה/Jitter
3xx	אל תשתמש בשינויים עבור פתקי אינטרנט	התייחס לשגיאת הגדרות

7) אבטחת ערוץ

חתימת HMAC של כל הודעה; בדוק במקלט עם ”חלון הזמן” (התקפות מחץ ומחזור).
MTLS עבור תחומים רגישים (LCC/תשלומים).
רשימת נתונים של כתובות יוצאות, TLS 1. 2 +, HSTS.
מזעור PII: אל תשלח נתונים אישיים מיותרים; תחפושת ביומנים.
סיבוב של סודות: שני מפתחות תקפים (פעיל/הבא אחריו) וכותרת ה-X-Key-Id' כדי לציין את זה הנוכחי.

8) תורים, תורים ושידורים חוזרים

יש לכתוב אירועים לתור היציאה/רישום בצד השולח (עבור שידור חוזר אמין).
אם המקסימום של מגשים מחדש הוא חורג, האירוע עובר ל-DLQ (תור אותיות מתות) עם הסיבה.
הילוך חוזר API (עבור מקבל/אופרטור): הצבה מחדש על ידי 'id'/זמן טווח/נושא, עם הגבלת RPS וחתימה/אישור נוסף.

הילוך חוזר דוגמה API (שולח):


POST /v1/webhooks/replay
{ "subscription_id": "sub_123", "from": "2025-11-03T00:00:00Z", "to": "2025-11-03T12:00:00Z" }
→ 202 Accepted

9) חוזה וגרסה

גרסה של האירוע (”schema _ version” field) ושל ההובלה (”X-Webhook-Version”).
הוספת שדות רק כאפשרות; על מחיקה - הגירה מינורית ותקופת מעבר (כתיבה כפולה).
סוגי אירועים של מסמכים, דוגמאות, סכימות (סכימות JSON), קודי שגיאה.

10) יכולת תצפית ו ־ SLO

מטריצות מפתח השולח:

'delivery _ success _ rate' (2xx/כל הניסיונות), 'ראשון _ ניסיון _ הצלחה _ retefost
"retries _ total", "max _ retry _ age _ seconds", "diq _ countespos
latency _ p50/p95 '(occurred_at ack_received_at)

מקבלי מטריצות מפתח:

”ac _ latency” (קבל = 2xx), ”עיבוד _ latency” (equeue air נעשה)
"duplicates _ total", "inflid _ grating _ total", "out _ of _ order _ total&fos

דוגמאות SLO:

99. 9% מהאירועים מקבלים את ה-ACK הראשון תוך 60 שניות (28d).

DLQ על 0. 1% מהסך הכולל; שידור חוזר של ”די-אל-קיו” 24 שעות.

11) עיתוי והפסקות רשת

השתמש ב ־ UTC בשדות הזמן; לסנכרן NTP.
שלח ”התרחש _ at” ותתקן ”delived _ at” לקרוא את הפיגור.
עם הפסקות ארוכות, הרשת/endpoint _ מצטברת בתור, מגבילה את הצמיחה (backpressure + quatas).

12) גבולות והיגיינה מומלצים

RPS למנוי (למשל. 50 RPS, פרץ 100) + concurncy (למשל. 10).
מקס. גוף: 64-256 KB; עבור יותר - ”הודעה + URL” וחתימה הורדה.
שמות אירועים ב 'נחש. מקרה 'או' נקודה. סוג '(' סדר. נוצר ').
חוסר אונים מוחלט של פעולות כתיבה של המקבל.

13) דוגמאות: שולח ומקבל

13. 1 Sender (פסאודוקודה)

python def send_event(event, attempt=0):
body = json. dumps(event)
sig = hmac_sha256_base64(body, secret)
headers = {
"X-Webhook-Id": event["id"],
"X-Webhook-Seq": str(event["sequence"]),
"X-Retry": str(attempt),
"X-Signature": f"sha256={sig}",
"Content-Type": "application/json"
}
res = http. post(endpoint, body, headers, timeout=10)
if 200 <= res. status < 300:
mark_delivered(event["id"])
elif res. status == 410:
deactivate_subscription()
else:
schedule_retry(event, attempt+1) # backoff + jitter, respect 429 Retry-After

13. 2 מקלט (פסאודו-קוד)

python
@app. post("/webhooks")
def handle():
body  = request. data headers = request. headers assert verify_hmac(body, headers["X-Signature"], secret)
evt_id = headers["X-Webhook-Id"]
if dedup_store. exists(evt_id):
return, "" 204 enqueue_for_processing (body) # fast path. dedup_store put(evt_id, ttl=723600)
return, "" 202 # or 204

14) בדיקות ושיטות תוהו ובוהו

מקרים שליליים: חתימה לא תקפה, 429/5xx, פסק זמן, 410, מטען גדול.
התנהגות: מחוץ לסדר, שכפולים, עיכובים של 1-10 דקות, הפסקה של 24 שעות.
עומס: פרץ 10 ×; בדוק אם יש תרמיל גב והתמדה של DLQ.
חוזים: סכימת JSON, ראשי חובה, סוגי אירועים יציבים.

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

[ ] 2xx = ACK, וחזרה מהירה לאחר החקירה

[ ] גיבוי מעריכי + ג 'יטר, כבוד' Retry-after &fos

[ ] IDEMPOTENCY ו-X-Webhook-ID (מגש TTL)

[ ] חתימות HMAC, סיבוב סודי, mTLS אופציונלי

[ ] DLQ + שידור חוזר של API, ניטור והתראות

[ גבולות ]: פסקי זמן, RPS, גודל גוף

[ סדר ]: מחיצה לפי מפתח או ”רצף” + ”מגרש חניה”

[ תיעוד ]: תרשימים, דוגמאות, קודי שגיאה, גרסאות

[ ] בדיקות כאוס: עיכובים, שכפולים, כשל רשת, שידור חוזר ארוך

16) מיני ־ FAQ

אני תמיד צריך לענות על 200?
כל 2xx נחשב כהצלחה. 202/204 הוא תרגול רגיל עבור ”מקובל לעמוד בתור”.

האם ניתן לעצור את ההילוכים החוזרים?
כן, תגובה 410 ו/או דרך הקונסולה/API של השולח (uncuberbe).

מה לגבי מטען גדול?
שלח ”הודעה + כתובת מאובטחת”, חתום על בקשת ההורדה והתקן TTL.

איך להבטיח סדר?
מחיצה על ידי מפתח + 'רצף'; במקרה של חוסר התאמה - ”מגרש חניה” ושידור חוזר.

סך הכל

חוברות אינטרנט אמינות הן סמנטיקה ACK (2xx) ברורה, חזרות סבירות עם backoff + jitter, אידמפוטנציה קפדנית ושכפול, אבטחה כשירה (HMAC/mTLS), תורים + DLQ + הילוכים חוזרים, ויכולת תצפית שקופה. לתקן את החוזה, להיכנס לגבולות ומדדים, באופן קבוע להפעיל תרחישי כאוס - והאינטגרציה שלך תפסיק ”לשפוך” בכישלונות הראשונים.

צילומים חוזרים והכרות

כותרות השולח

תגובה ממקבל

פסקי זמן וגדלים

סך הכל

צרו קשר

חיבור מהיר

הווידאו יעודכן בקרוב

אנחנו עמוסים מאוד בפרויקטים כרגע