אידמפוטנטיות
Idempotency
אידמפוטנטיות (Idempotency) היא תכונה של פעולה שבה חזרה על אותה בקשה אינה מוסיפה השפעה מכוונת מעבר להפעלה הראשונה. באוטומציה משתמשים בה כדי שניסיון חוזר לא ייצור שוב את אותה פעולה עסקית.
עודכן ב־
איך זה קשור לאוטומציה?
אידמפוטנטיות חשובה כאשר אותה פעולה עלולה להישלח שוב אחרי כשל או אירוע כפול. המטרה היא שהניסיון החוזר לא ייצור תוצאה עסקית נוספת עבור אותה בקשה. מזהה יציב עוזר לקשר בין הניסיונות, אבל ההגנה דורשת גם דרך לשמור את מצב הפעולה ולמנוע משני ניסיונות להתקבל במקביל כפעולות חדשות.
מזהה אירוע אינו מזהה לקוח
לקוח יכול לשלוח שתי פניות שונות, ושתיהן תקינות. כתובת האימייל שלו יכולה לסייע באיתור כרטיס הלקוח, אבל אינה מוכיחה שמדובר באותו אירוע. לעומת זאת, שתי מסירות של אותה הודעת מקור יכולות לבקש לבצע שוב בדיוק את אותה פעולה עסקית.
לפני שבוחרים מפתח, מגדירים מה נחשב לאותה פעולה: אירוע מקור מסוים, במערכת מסוימת, שמבקש תוצאה מסוימת. אם המקור מספק מזהה אירוע יציב, שומרים אותו ואת ההקשר שלו. בניסיון חוזר של אותה פעולה לא מייצרים מפתח חדש רק משום שההרצה הקודמת לא החזירה תשובה.
אידמפוטנטיות מתארת את ההשפעה המכוונת, ולא מחייבת תשובת HTTP זהה בכל פעם. למשל, פעולה שמבקשת להסיר פריט יכולה להשאיר אותו חסר גם כשהתשובה לבקשה החוזרת שונה מהתשובה הראשונה.
למה חיפוש ואז יצירה עלולים ליצור כפילות
נניח ששני תהליכים מטפלים באותו אירוע. הראשון מחפש רשומה ולא מוצא. לפני שהוא מספיק ליצור אותה, גם השני מחפש ולא מוצא. שניהם ממשיכים ליצירה. החיפוש עבד בכל הרצה, אבל לא מנע את הכפילות בין ההרצות.
כדי לאכוף כלל ייחודיות נדרשת הגנה מתאימה ביעד. PostgreSQL מתעדת תוצאה אטומית של הוספה או עדכון באמצעות ON CONFLICT DO UPDATE, כל עוד אין שגיאה נפרדת שמונעת את הפעולה. זו הגנה על משפט מסוים במסד הנתונים, ולא הבטחה שכל תהליך עסקי שמפעיל אותו הוא אידמפוטנטי.
גם עדכון אטומי יכול להוסיף שוב ערך מצטבר או להפעיל פעולה נלווית. צריך לבחור מפתח וכלל טיפול בהתנגשות שמתאימים לפעולה הרצויה. סימון שמישהו התחיל לטפל באירוע אינו הוכחה שהטיפול הסתיים; ניסיון מתחרה ממתין לפי מדיניות מוגדרת או עובר לבדיקה של המצב.
מה עושים כשהתוצאה אינה ידועה
פסק זמן אינו אומר שהמערכת השנייה לא ביצעה את הבקשה. תחילה בודקים את התוצאה ביעד באמצעות מזהה מקור יציב, מזהה רשומה שנשמר או בדיקת מצב שהספק תומך בה. אם נמצא ביצוע שהושלם, משתמשים בתוצאה הקיימת במקום ליצור פעולה חדשה.
אם הספק מאפשר ניסיון חוזר, משתמשים באותו מפתח רק כל עוד ההגנה שהספק מתעד עדיין תקפה. אם אי אפשר לברר מה קרה או שהמפתח כבר אינו מוגן, משאירים מצב לא ידוע ומעבירים לבדיקת התאמה או לטיפול של אחראי התהליך. מפתח חדש אינו פתרון אוטומטי לחוסר ודאות.
הכללים תלויים גם בגרסת ה-API. Stripe מתעדת שב-API v1 נשמרת התשובה הראשונה לאחר שהביצוע התחיל, לרבות תשובות שגיאה מסוימות, ואילו ב-API v2 התנהגות הניסיון החוזר שונה. לכן לא מסיקים שכל שגיאה תיפתר אם נמשיך לשלוח שוב את אותה בקשה.
איפה מסתיימת ההגנה של מסד הנתונים
יצירת רשומה ושליחת הודעה הן שתי השפעות שונות. אם הרשומה נוצרה וההודעה נכשלה, הפעלה חוזרת של כל התהליך עלולה לחזור גם על שלב שכבר הצליח. שומרים בנפרד את הכוונה, המצב הידוע והתוצאה של הפעולות הנלוות.
פעולה אטומית במסד הנתונים אינה הופכת לבדה הודעת דואר או קריאה לשירות חיצוני לחלק מאותה עסקה. אם השירות החיצוני אינו מספק דרך מתאימה למנוע כפילות או לברר תוצאה, מתעדים את המגבלה ואת מסלול הטיפול הידני. טבלת הבדיקה כאן היא תבנית תכנון וקבלה, לא הוכחה שחיבור לספק כלשהו הופעל ונבדק.
אפשר לגלול את הטבלה לצדדים כדי לקרוא את כל העמודות.
| תרחיש | מפתח אירוע יציב | הפעולה המצופה | הראיה שצריך לאסוף |
|---|---|---|---|
| אותו אירוע מגיע שוב | event-demo-A | משתמשים בתוצאה שאושר כי ביצועה הושלם; לא יוצרים השפעה עסקית חדשה. | מזהה הרשומה המקורית והחוזרת ומספר הפעולות העסקיות בפועל. |
| שני ניסיונות במקביל | event-demo-A | אוכפים קבלה של פעולה אחת; הניסיון האחר ממתין לפי מדיניות או עובר לבירור. מצב בטיפול אינו מעיד שהפעולה הושלמה. | ההחלטה על קבלת הפעולה, מצבי ההרצות ומזהה הרשומה הסופית. |
| אותו מפתח עם תוכן שונה | event-demo-A | דוחים את ההתנגשות או דורשים בדיקה; לא מחזירים בשקט תוצאה להוראות אחרות. | תוצאת ההתנגשות והשוואה מצומצמת של התוכן, בלי מידע אישי מיותר. |
| חסר מפתח יציב | missing | דוחים או מעבירים לבדיקה; לא מייצרים מפתח פעולה חדש בכל ניסיון חוזר. | תוצאת האימות וראיה שלא התקבלה כתיבה חדשה. |
| פסק זמן אחרי כתיבה לשירות חיצוני | event-demo-A | בודקים תחילה לפי המזהה היציב. מנסים שוב באותו מפתח ספק רק כל עוד ההגנה המתועדת תקפה; אחרת מבררים את המצב. | מצב ביעד או תוצאה שנשמרה; תוצאה שלא הובררה נשארת לא ידועה. |
| הפעלה מחדש או ניסיון מאוחר | event-demo-A | משחזרים מצב מתמשך, בודקים את שמירת המפתח ומבררים פעולות נלוות בנפרד. | מצב הפעולה שנשמר ובדיקת התוצאה ביעד אחרי ההפעלה מחדש. |
דוגמאות שימוש באוטומציה
הדוגמאות להמחשה. את החיבורים והכללים מתאימים למערכות ולתהליך של העסק.
אותה הזמנה מגיעה שוב
בדוגמה להמחשה, תהליך יוצר משימת משלוח עם מזהה ההזמנה ומטרת הפעולה כמפתח ייחודי. אם לא התקבלה תשובה והאירוע נמסר שוב, בודקים אם המשימה כבר קיימת ומה מצבה לפני שמחליטים אם מותר להמשיך. מזהה הלקוח לבדו אינו מזהה של ההזמנה.
- מגדירים איזה אירוע ואיזו פעולה המפתח מייצג.
- שומרים את מפתח הפעולה ואת המצב במקום מתמשך.
- בודקים ביעד אם נוצרה משימה ומה המזהה שלה.
- משתמשים בתוצאה שהושלמה או משאירים את המקרה לבירור, בלי ליצור מפתח חדש באופן עיוור.
תוצאת הקבלה הרצויה היא משימת משלוח אחת לאותה פעולה, עם ראיה ביעד. זו ציפייה לבדיקה, לא תוצאת ניסוי שבוצע כאן.
הרשומה נוצרה, אבל מצב ההודעה אינו ידוע
בדוגמה נוספת, רישום פנייה ב-CRM הסתיים אך שליחת עדכון פנימי נשארה במצב לא ידוע. לא מתחילים מחדש את יצירת הפנייה. בודקים את הרשומה ואת מצב ההודעה בנפרד, ומגדירים לכל פעולה נלווית דרך התאוששות שמתאימה ליכולות השירות שלה.
באילו כלים זה רלוונטי?
מה חשוב לבדוק לפני שמיישמים?
- מניעת כפילויות בזיכרון זמני אינה מספיקה אחרי הפעלה מחדש. שמרו מזהה יציב, מצב ותוצאת ביצוע במקום מתמשך.
- אותו מפתח עם תוכן עסקי שונה הוא התנגשות שדורשת דחייה או בדיקה, ולא אישור שקט להחזיר תוצאה שאינה מתאימה לבקשה.
- מפתח חדש בכל ניסיון חוזר מונע מהשירות לזהות שמדובר באותה פעולה. אל תשתמשו בפרטים אישיים או רגישים כמפתח.
- רשומה במצב בטיפול אינה אישור שהפעולה הושלמה. מגדירים המתנה מוגבלת ומסלול בירור למצב תקוע או לא ידוע.
- משך שמירת המפתחות וכללי הניסיון החוזר תלויים בספק ובגרסת ה-API. אין חלון זמן אחיד שמתאים לכל שירות.
- חיפוש מקדים, הרצה ירוקה או אילוץ ייחודיות במסד הנתונים אינם הוכחה שנמנעה גם הודעה או פעולה חיצונית כפולה.