גישה נכונה לביצוע פעולות ארוכות ומנותקות

ExtraSi

New member
גישה נכונה לביצוע פעולות ארוכות ומנותקות

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

לוגית ברור מה יש לבצע, השאלה היא מה המנגנון הנכון לבצע זה,
כלומר, כל הזמן מתווספים נתונים ל DB, וצריך תהליך רקע שדוגם את הנתונים, מבצע את הפעולות שתארתי לעיל ומעדכן את ה DB בתוצאות.

מניסיון העבר בד"כ מייצרים Windows Service שרץ באופן קבוע על השרת,
הוא דוגם את הטבלה ב DB כל X דקות, מבצע את הפעולות, מעדכן את הרשומות הרלוונטיות ב DB עם הנתונים החדשים וכותב תאור של כל מה שבוצע לטבלת Log.

האם זה אכן הכיוון הנכון?
 

izackv

New member
יש עניין של עומס?

אם שלב מסויים נכשל, יש דרישה לבטל שלבים שכבר בוצעו?
יש דרישה שהפעולות יוכלו לרוץ על שרתים אחרים מאשר שרת הווב?
יש דרישה שירוץ במקביל יותר מתהליך אחד?
למשל - 1000 משתמשים ביקשו באותו זמן בקשה מסויימת, וכרגע שלב א' של הטיפול בבקשה צריך לרוץ 1000 פעמים.
האם ירוץ תהליך אחד שיטפל ב 1000 רשומות?
האם נדרש להרים 1000 תהליכים במקביל?
האם נדרש להרים 1000 תהליכים בצורה סדרתית (אחד אחרי השני, עד לסיום התור)?

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

עבור תהליך פשוט שרץ בשרת ספציפי - קרון-טאב עם סקריפט פשוט יספיקו.

עבור תהליך פשוט שמצריך סקילביליות גבוהה (מספר גבוה של בקשות מטופלות במקביל, לפעמים על מספר שרתים) יש פתרונות Q למיניהן (אישית אוהב את ZMQ) שמאפשרים כל מיני סוגים של פאבלישר-סבסקרייברז וכדומה.

--
בלי קשר לאיזה פתרון מתאים - חשוב לזכור לבנות מנגנון לוגים ברור שיבצע מעקב אחרי הפעולות בצורה שתאפשר תקשורת יעילה מול המשתמש הסופי...
 

ExtraSi

New member


 
למעלה