פיתוח אתר מועדון כושר בעומס גבוה על 1С-Bitrix

פיתוח אתר מועדון כושר בעומס גבוה על 1С-Bitrix

לקוח מבקר באתר מועדון הכושר שלך ביום שני בערב, בוחר שיעור, לוחץ על "הזמן עכשיו" — ורואה "שגיאת שרת." או שלוח הזמנים נטען תוך 5 שניות. הארכיטקטורה לא מתוכננת לעומסי שיא. אנחנו צוות של מהנדסי 1С-Bitrix מוסמכים עם ניסיון של 8+ שנים, הפותר בעיות אלה במפתח אחד. אנחנו מתכננים מבנים בעלי עומס גבוה, מגדירים מטמון, משתלבים עם מערכות תשלום ו-CRM. אנחנו מבטיחים זמינות של 99.9% בשעות השיא. בואו נבחן את הפרויקט שלכם תוך יומיים עם בדיקה חינמית.

בעיות שאנחנו פותרים

תרחיש טיפוסי: לוח זמנים שבועי עם 300 שיעורים, 15 אולמות, 40 מאמנים. ללא אופטימיזציה נכונה, הסינון לוקח 800–1200 אלפיות השנייה. אנחנו מעבירים נתונים לבלוקים Highload — טבלאות שטוחות עם אינדקסים. זמן הסינון יורד ל-20–30 אלפיות השנייה — שיפור של פי 45 בהשוואה לבלוקי מידע רגילים. להלן נפרט את הצמתים המרכזיים של פרויקט כזה.

איך אנחנו מתכננים את לוח הזמנים לעומס גבוה

לוח הזמנים הוא האלמנט המרכזי של האתר. אם הוא איטי, הלקוח עובר לבוט טלגרם של המתחרה.

לאחסון לוח הזמנים, אנו משתמשים בבלוקים HL. בלוק מידע רגיל (מודל EAV) עם 300 שיעורים, 15 אולמות ו-40 מאמנים מייצר עשרות אלפי שורות בטבלת המאפיינים. סינון לפי שילוב של "אולם + יום + מאמן + כיוון" מביא לסדרה של JOINs שלוקחת 800–1200 אלפיות השנייה.

בלוק Highload הוא טבלת MySQL שטוחה. שורה אחת = שיעור אחד, כל השדות הם עמודות. הסינון משתמש באינדקסים רגילים.

מבנה HL FitnessSchedule:

עבור שיעורים חוזרים, אנו משתמשים ב-HL נפרד ScheduleTemplate. סוכן cron מייצר שיעורים ספציפיים פעם בשבוע. זה מאפשר למאמן לבטל שיעור ספציפי מבלי לשבור את כל לוח הזמנים.

סינון בצד הלקוח דרך DataManager::getList():

$result = $entityClass::getList([
    'filter' => [
        'UF_DATE' => $selectedDate,
        'UF_HALL_ID' => $hallId,
        'UF_STATUS' => 'active',
    ],
    'order' => ['UF_TIME_START' => 'ASC'],
]);

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

למה בלוקים Highload עדיפים על בלוקי מידע

עם 50,000 רשומות, בלוק HL מעבד סינון תוך 20 אלפיות השנייה, בעוד בלוק מידע לוקח 900 אלפיות השנייה — הפרש של פי 45. זה נובע מהיעדר שכבות EAV ומהשימוש באינדקסים ישירים. בלוקים HL תומכים ב-$result = $entityClass::getList([ 'filter' => [ 'UF_DATE' => $selectedDate, 'UF_HALL_ID' => $hallId, 'UF_STATUS' => 'active', ], 'order' => ['UF_TIME_START' => 'ASC'], ]); , קריטי לכתיבות טרנזקציוניות. ארכיטקטורה זו יעילה פי 3 משימוש בבלוקי מידע רגילים להזמנות במקביל.

הזמנה מקוונת עם מגבלות קיבולת ורשימת המתנה

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

תרחיש:

1. הלקוח לוחץ על "הזמן עכשיו"
2. המערכת בודקת: SELECT ... FOR UPDATE
3. אם כן — יוצרת רשומה ב-HL UF_BOOKED < UF_CAPACITY, מגדילה את FitnessBooking
4. אם לא — מציעה להצטרף לרשימת ההמתנה

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

פתרון — SQL גולמי עם UF_BOOKED:

$connection = \Bitrix\Main\Application::getConnection();
$connection->startTransaction();
$row = $entityClass::getList([
    'filter' => ['ID' => $scheduleId],
    'select' => ['UF_BOOKED', 'UF_CAPACITY'],
    // FOR UPDATE через raw SQL
])->fetch();
if ($row['UF_BOOKED'] < $row['UF_CAPACITY']) {
    // создаём бронирование
    $connection->commitTransaction();
} else {
    $connection->rollbackTransaction();
    // предлагаем waitlist
}

ה-ORM של Bitrix אינו תומך ב-SELECT ... FOR UPDATE, לכן אנו עוטפים את הקטע הקריטי ב-SQL גולמי.

רשימת ההמתנה מיושמת דרך HL נפרד $connection = \Bitrix\Main\Application::getConnection(); $connection->startTransaction(); $row = $entityClass::getList([ 'filter' => ['ID' => $scheduleId], 'select' => ['UF_BOOKED', 'UF_CAPACITY'], // FOR UPDATE через raw SQL ])->fetch(); if ($row['UF_BOOKED'] < $row['UF_CAPACITY']) { // создаём бронирование $connection->commitTransaction(); } else { $connection->rollbackTransaction(); // предлагаем waitlist } . כשמישהו מבטל הזמנה, סוכן בודק את רשימת ההמתנה ומעביר את האדם הראשון בתור, שולח SMS/push. זה מפחית אי-הגעה ב-30%.

ביטול: המועדון מאפשר ביטול 2–4 שעות לפני ההתחלה. הלוגיקה במטפל האירועים משווה את זמן הביטול.

מכירת מנויים דרך מודול המכירות

מנויים אינם מוצרים פשוטים. יש להם תקופת תוקף, מגבלת ביקורים ויכולת הקפאה.

סוגי מנויים מיושמים כאלמנטים של בלוק מידע עם מאפיינים:

• SELECT ... FOR UPDATE, FitnessWaitlist, DURATION_DAYS, VISIT_LIMIT, TYPE

ברכישה דרך FREEZE_ALLOWED, המנוי מתווסף לעגלה. לאחר התשלום, מטפל FREEZE_MAX_DAYS יוצר רשומה ב-HL Order::create() עם שדות: OnSaleOrderPaid, UserSubscription, UF_USER_ID, UF_START_DATE, UF_END_DATE, UF_VISITS_LEFT.

הקפאה: הלקוח לוחץ על "הקפא," המערכת בודקת מגבלות ומגדירה UF_IS_FROZEN. בביטול הקפאה, היא מחשבת מחדש UF_FREEZE_START.

אינטגרציה עם מערכות CRM של מועדונים

מועדוני כושר משתמשים ב-1С:Fitness Club או Mobifitness.

1С:Fitness Club — החלפה דרך CommerceML או REST API. אנו מסנכרנים שירותים, לוחות זמנים, לקוחות ומכירות. ההחלפה רצה דרך cron כל 15–30 דקות.

Mobifitness — REST API עם הרשאת טוקן. Bitrix משמש כחזית, Mobifitness כמערכת ראשית. HL UF_IS_FROZEN מאוכלס דרך סנכרון.

בחירת הארכיטקטורה תלויה במערכת הראשית.

חשבון אישי ללקוח

בנוי על מודול UF_END_DATE עם הרחבות:

• היסטוריית ביקורים — שאילתה מ-FitnessSchedule
• ביקורים שנותרו — main מ-FitnessBooking
• חידוש מנוי — כפתור שיוצר הזמנה
• הקפאה/ביטול הקפאה

אימות דרך טלפון עם קוד SMS (מודול UF_VISITS_LEFT).

פרופילי מאמנים

מאמנים הם בלוק מידע עם קישור לכיוונים. בעמוד הפרטים, אנו מציגים את לוח השיעורים של השבוע הנוכחי (בקשת AJAX ל-UserSubscription).

לוחות זמנים ועלויות יישום

מה כלול בעבודה

• בדיקה חינמית של הארכיטקטורה והעומסים הנוכחיים
• תכנון מבנים בעלי עומס גבוה (בלוקים HL, אינדקסים, טריגרים) — שיפור ביצועים מובטח של פי 45
• פיתוח לוח זמנים, הזמנות מקוונות עם רשימת המתנה, חשבון אישי
• אינטגרציה עם 1С:Fitness Club או Mobifitness (מפתחים מוסמכים)
• הגדרת מטמון מתויג ומצב מרוכב
• חיבור שערי תשלום (YuKassa, Sber, ATOL) עם SLA של 99.9% זמינות
• הכשרת מנהלים והעברת תיעוד
• 3 חודשי תמיכה טכנית לאחר ההשקה