تم النشر في 6 يونيو • نُشر في الأصل على موقع mustafaerbay.com.tr
الفرق بين تشغيل تكامل سلسلة التوريد باستخدام مكالمات REST API المتزامنة وتدفق البيانات المستند إلى بنية Outbox للمعاملات غير المتزامنة هو الفرق بين توقف خط الإنتاج أو استمرار تشغيله. في الهياكل الكلاسيكية المتجانسة أو الخدمات الصغيرة المكتوبة على عجل، يعد إرسال طلب HTTP POST إلى نظام مورد خارجي وانتظار "200 OK" أكثر أخطاء التصميم شيوعًا. عندما تفشل واجهة برمجة التطبيقات الخارجية في الاستجابة لمدة 15 ثانية أو ينقطع الاتصال، تظل معاملة PostgreSQL الداخلية مفتوحة، وتتراكم الأقفال على مستوى الصف، وفي النهاية يتم استنفاد تجمع الاتصال.
في هذا التحليل التشريحي، أقوم بتشريح بنية تدفق البيانات التي قمت بإنشائها أثناء تطوير نظام تخطيط موارد المؤسسات (ERP) للإنتاج - الذي يدير مئات من حركات المخزون وطلبات الموردين في الثانية - عبر جميع طبقاته. بدءًا من أقفال قاعدة البيانات وحتى تجزئة الشبكة، ومن شاشات المشغلين في الوقت الفعلي إلى تحليل مخاطر الموردين المدعوم بالذكاء الاصطناعي، سأشرح كل شيء باستخدام الأساليب التي قمت بتنفيذها شخصيًا في هذا المجال.
من الطلب إلى الإنتاج: تشريح الشراء وحجز المخزون
عند إدخال أمر ما، وهو الرابط الأول في سلسلة التوريد، يعد اتساق كميات المخزون بمثابة عتبة حرجة. في نظام تخطيط موارد المؤسسات (ERP) للإنتاج، تخيل أن 10 مندوبي مبيعات مختلفين يحاولون حجز نفس المواد الخام المهمة (على سبيل المثال، ملف سبائك فولاذي خاص) في نفس الوقت بالضبط. إذا تم ترك مستوى عزل قاعدة البيانات الخاصة بك عند الإعداد الافتراضي للقراءة، فإن "الحجز المزدوج" - أي الحجز المتكرر لنفس المخزون لطلبين مختلفين - أمر لا مفر منه.
للتغلب على هذه المشكلة، أستخدم آلية قفل متشائمة مع SELECT ... FOR UPDATE على PostgreSQL. ومع ذلك، هناك خطر كبير هنا: طريق مسدود. إذا حاولت المعاملة A قفل المخزون X أولاً ثم المخزون Y، بينما تحاول المعاملة B في نفس الوقت قفل المخزون Y أولاً ثم المخزون X، فسيتم قفل النظام. طريقة منع ذلك هي فرز معرفات المخزون دائمًا في طبقة التطبيق قبل إرسالها إلى قاعدة البيانات.