בורר פרוקסי מעגלי משותף ב-Go
השאירו בורר פרוקסי של Go חי בין בקשות, הגנו על מצב הבחירה המשותף והבדילו בין בחירת מסלול לבין התבוננות ביציאה שלו.
בורר יכול להסתובב בצורה מושלמת ועדיין לבחור שוב ושוב בפרוקסי הראשון. הטעות היא יצירה מקרית של בורר חדש לכל בקשה, מה שמאפס את המונה שלו לפני שיש לו בחירה שנייה לעשות.
בנו את הבורר פעם אחת והחזיקו אותו יחד עם ה-transport. רשימת פרוקסי ה-HTTP יכולה לספק מועמדים ציבוריים של HTTP לקבוצת כתובות ה-URL כאשר הבקשות מתירות מתווכים ציבוריים. התחילו ברשימת כתובות URL של פרוקסי שכבר אומתה ואינה ריקה:
func rotatingProxy(urls []*url.URL) func(*http.Request) (*url.URL, error) {
var mu sync.Mutex
next := 0
return func(*http.Request) (*url.URL, error) {
mu.Lock()
selected := urls[next]
next = (next + 1) % len(urls)
mu.Unlock()
return selected, nil
}
}
היישום הסובב חייב לדחות רשימה ריקה, לאמת את כתובות ה-URL ולהשתמש ביבואים הרגילים net/http, net/url ו-sync. הרשימה צריכה להישאר בלתי משתנה כל עוד הבורר הזה משתמש בה, או להיות מוחלפת באמצעות עיצוב מסונכרן בנפרד.
צרפו את הפונקציה המוחזרת ל-http.Transport אחד שנשמר. ה-mutex מגן על רצף הבחירה בין קריאות חוזרות במקביל. הוא אינו דורש להחזיק מנעול בזמן שבקשת רשת איטית מסתיימת.
אל תכלו מסלול רק כדי להדפיס אותו
קריאה נוספת לבורר עבור הודעת אבחון מקדמת את המונה שוב. הפלט הזה עשוי לתאר את המועמד הבא במקום את המועמד שהבקשה שאתם חוקרים השתמשה בו. תַּעדו את הבחירה בתוך קריאת ה-backcall האמיתית עם מזהה נקודת קצה בטוח.
הפעלת backcall אינה הוכחה לכך שבקשה נמסרה בהצלחה. הפניות מחדש או ניסיונות transport נוספים יכולים לסבך הנחה פשוטה של „קריאת יישום אחת, בחירה אחת“. אם תהליך עבודה חייב לשמור מסלול אחד לאורך כמה פעולות, בחרו את המסלול הזה בגבול תהליך העבודה במקום להשתמש ב-backcall מסתובב גלובלי.
גם סבב מעגלי אינו מבטיח יציאות ציבוריות נפרדות. הוא מתזמן נקודות קצה. הזהות הסופית נשארת תכונה של המסלול שכל נקודת קצה מספקת.