التخزين متعدد الطبقات في API Gateway يتحدى تحديات حركة المرور العالية

مع استمرار نمو استخدام واجهات برمجة التطبيقات (APIs) في التطوير الحديث، زاد الطلب على بوابة API فعالة وموثوقة. تعمل بوابة API كنقطة دخول واحدة لجميع طلبات API الواردة، مما يسمح بإدارتها وتوزيعها بكفاءة عبر خدمات مصغرة مختلفة. بينما توفر بوابة API العديد من الفوائد، قد تواجه تحديات عند التعامل مع سيناريوهات حركة المرور العالية.

آلية التخزين المؤقت في APISIX

يوضح المخطط التالي آلية التخزين المؤقت الفعالة التي تستخدمها APISIX لتقليل زمن الوصول وتحسين الأداء. من خلال تخزين الاستجابات على مستويات متعددة، يمكن لـ APISIX تقليل الحمل على الخوادم العلوية وتوفير تجربة أكثر استجابة للعملاء.

Client <-- HTTP Request --> APISIX Worker
    (Check LRU Cache in process level)
    (No cache hit)
    (Check Shared DICT Cache in data plane level)
        (Lock not acquired)
            (Acquire lock, check cache)
                (Cache hit)
                (Return cached response, release locks)
                (Cache miss)
                    (Query Redis)
                        (Acquire Mutex)
                            (Query Redis)
                                (Cache miss)
                                    (Retrieve response from upstream)
                                    (Cache response in shared DICT cache)
                                    (Return response to client)
                                (Cache hit)
                                    (Copy response to shared DICT cache)
                                    (Return cached response to client)
                                (Release Redis Mutex)
                        (Release lock)
    (Cache hit)
        (Return cached response)

LRU: التخزين المؤقت في المستوى الأول في APISIX على مستوى العامل الواحد

يعتبر LRU (الأقل استخدامًا مؤخرًا) في مستوى العامل في APISIX مكونًا حاسمًا مسؤولًا عن تخزين البيانات التي يتم الوصول إليها بشكل متكرر داخل كل عملية عمل. يستخدم نظام التخزين المؤقت هذا خوارزمية طرد LRU، مما يسمح بتخزين واسترجاع البيانات بكفاءة مع إعطاء الأولوية للتعامل مع البيانات الأقل استخدامًا مؤخرًا. من خلال تخزين البيانات التي يتم الوصول إليها بشكل متكرر في الذاكرة، تقلل APISIX بشكل كبير من زمن الوصول والتكاليف عند الاستعلام عن مصادر البيانات الخارجية، مثل قواعد التوجيه أو رموز المصادقة، مما يعزز سرعة استجابة النظام.

من خلال هذه الآلية الذكية للتخزين المؤقت، تستخدم APISIX موارد النظام بكفاءة عند التعامل مع عدد كبير من الطلبات، مما يحسن الأداء العام واستقرار النظام. توفر APISIX، مع ذاكرة التخزين المؤقت LRU المتقدمة، للمطورين حلًا موثوقًا وفعالًا لبوابة API، مما يسهل التواصل السلس مع الخدمات الخارجية.

Shared Dict: التخزين المؤقت في المستوى الثاني في APISIX على مستوى العقدة

ذاكرة القاموس المشتركة (shared dict) بين جميع عمليات العمل في عقدة APISIX واحدة. تعمل كذاكرة تخزين مؤقت مركزية للبيانات التي يتم الوصول إليها بشكل شائع، بما في ذلك بيانات استجابة API أو رؤوس الاستجابة. يمكن لعمليات العمل المتعددة الوصول إلى هذه الذاكرة المؤقتة وتحديثها في نفس الوقت لضمان اتساق البيانات وتجنب تكرار البيانات غير الضروري.

تتمتع ذاكرة القاموس المشتركة هذه بأداء متميز، حيث تستفيد من تقنيات متقدمة مثل تأمين الذاكرة وهياكل البيانات الفعالة. هذا يمكنها من تحقيق هدف تقليل التنافس وزيادة الإنتاجية. من خلال تأمين الذاكرة، تتحكم بشكل فعال في الوصول المتزامن، مما يضمن الاتساق أثناء عمليات القراءة والكتابة المتزامنة عبر عمليات العمل المتعددة. يتيح تصميم هياكل البيانات الفعالة لذاكرة القاموس المشتركة تنفيذ عمليات استرجاع البيانات والتحديث بشكل أسرع، مما يعزز الأداء العام.

يضيف إدخال ذاكرة القاموس المشتركة أداءً وقابلية توسع أكبر إلى مستوى البيانات في APISIX، مما يوفر للمطورين أداة موثوقة للتفوق في التعامل مع البيانات والطلبات على نطاق واسع.

آلية التخزين المؤقت متعدد الطبقات في APISIX

يوضح الرسم البياني التالي آلية التخزين المؤقت متعدد الطبقات في APISIX، والتي تشبه مبدأ القمع. على وجه التحديد، تستخدم ذاكرة التخزين المؤقت L1 ذاكرة LRU داخل العامل، وذاكرة التخزين المؤقت L2 هي ذاكرة مشتركة بين العمال المتعددين، وذاكرة التخزين المؤقت L3 هي قاعدة بيانات Redis خارج بوابة API.

إليك مثال لتوضيح ذلك: عندما يقوم 10000 طلب مستخدم بالاستعلام عن البيانات من خلال APISIX، بافتراض أن معدل الضرب في ذاكرة التخزين المؤقت L1 هو 90%، سيتم إرجاع 9000 طلب مباشرة. ثم سيتم استعلام الـ 1000 طلب المتبقية في ذاكرة التخزين المؤقت L2. بافتراض أن معدل الضرب في ذاكرة التخزين المؤقت L2 هو أيضًا 90%، فإن 100 طلب ستستمر في الاستعلام في ذاكرة التخزين المؤقت L3، Redis. قبل أن تستعلم هذه الطلبات في Redis، ستستعلم أولاً عن mutex (الاستبعاد المتبادل) لضمان أن طلبًا واحدًا فقط يستعلم في Redis في كل مرة، مما يمنع تأثير Dogpile.

الخلاصة

من خلال الاستفادة من إمكانيات التخزين المؤقت متعدد الطبقات، تتعامل APISIX بكفاءة مع غالبية طلبات العملاء دون الحاجة إلى الاستعلام المتكرر عن مكونات تخزين البيانات الخارجية مثل Redis أو Postgres. لا يقلل هذا بشكل كبير من زمن الوصول العام فحسب، بل يعزز أيضًا إنتاجية بوابة API، مما يوفر للشركات حلًا فعالًا وقويًا يسهل التواصل مع الخدمات الخارجية. يضمن التصميم الأمثل قوة النظام، مما يمكن APISIX من التعامل بمرونة مع سيناريوهات التزامن العالي وتوفير بيئة تطوير أكثر موثوقية وأداءً للمهندسين.