الصفحة الرئيسية>المتعلقة بالبرمجة>جافا كود المصدر
تنزيل


Fork of Paper الذي يضيف تعدد المناطق إلى الخادم المخصص.

ملخص

تقوم مجموعات Folia بالقطع القريبة المحملة لتشكل "منطقة مستقلة". راجع وثائق PaperMC للحصول على تفاصيل دقيقة حول كيفية قيام Folia بتجميع القطع القريبة. كل منطقة مستقلة لها حلقة التجزئة الخاصة بها، والتي يتم تحديدها بمعدل التجزئة العادي في Minecraft (20TPS). يتم تنفيذ حلقات التجزئة على تجمع الخيوط بالتوازي. لم يعد هناك خيط رئيسي بعد الآن، حيث أن كل منطقة لديها فعليًا "الخيط الرئيسي" الخاص بها والذي ينفذ حلقة التجزئة بأكملها.

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

يعد Folia أيضًا مشروعًا خاصًا به، ولن يتم دمجه في Paper في المستقبل المنظور.

نظرة عامة أكثر تفصيلاً ولكن مجردة: نظرة عامة على المشروع.

التعليمات

ما هي أنواع الخوادم التي يمكنها الاستفادة من Folia؟

أنواع الخوادم التي تنشر اللاعبين بشكل طبيعي، مثل Skyblock أو SMP، ستستفيد أكثر من Folia. يجب أن يحتوي الخادم على عدد كبير من اللاعبين أيضًا.

ما هي الأجهزة التي ستعمل عليها Folia بشكل أفضل؟

من الناحية المثالية، لا يقل عن 16 النوى (وليس المواضيع).

كيفية تكوين فوليا بشكل أفضل؟

أولاً، يوصى بأن يتم إنشاء العالم مسبقًا بحيث يتم تقليل عدد سلاسل عمليات عامل النظام المطلوبة بشكل كبير.

ما يلي هو تقدير تقريبي للغاية يعتمد على الاختبار الذي تم إجراؤه قبل إصدار Folia على خادم الاختبار الذي قمنا بتشغيله والذي بلغ ذروته حوالي 330 لاعبًا. لذا، فهو ليس دقيقًا وسيتطلب مزيدًا من الضبط - ما عليك سوى اعتباره نقطة انطلاق.

ينبغي أن يؤخذ في الاعتبار العدد الإجمالي للنوى الموجودة على الجهاز. ثم قم بتخصيص المواضيع لـ:

  • netty IO: ~ 4 لكل 200-300 لاعب
  • خيوط نظام io: ~ 3 لكل 200-300 لاعب
  • عمال نظام القطعة إذا تم إنشاؤها مسبقًا، ~ 2 لكل 200-300 لاعب
  • ليس هناك أفضل تخمين للعاملين في نظام القطعة إذا لم يتم إنشاؤها مسبقًا، كما هو الحال في خادم الاختبار الذي قمنا بتشغيله، قدمنا ​​16 سلسلة ولكن إنشاء القطعة كان لا يزال بطيئًا عند حوالي 300 لاعب.
  • إعدادات جي سي: ؟؟؟؟ لكن إعدادات GC تقوم بتخصيص سلاسل الرسائل المتزامنة، وتحتاج إلى معرفة عددها بالضبط. ويتم ذلك عادةً من خلال العلامة -XX:ConcGCThreads=n . لا تخلط بين هذه العلامة و -XX:ParallelGCThreads=n ، حيث تعمل سلاسل GC المتوازية فقط عندما يتم إيقاف التطبيق مؤقتًا بواسطة GC وبالتالي لا ينبغي أخذها في الاعتبار.

بعد كل هذا التخصيص، يمكن تخصيص النوى المتبقية في النظام حتى تخصيص 80% (إجمالي الخيوط المخصصة < 80% من وحدات المعالجة المركزية المتاحة) لسلاسل التجزئة (ضمن التكوين العام، Threaded-regions.threads).

يرجع السبب وراء عدم تخصيص أكثر من 80% من النوى إلى حقيقة أن المكونات الإضافية أو حتى الخادم قد يستخدم سلاسل عمليات إضافية لا يمكنك تكوينها أو حتى التنبؤ بها.

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

توافق البرنامج المساعد

لا يوجد المزيد من الموضوع الرئيسي. أتوقع أن يتطلب كل مكون إضافي موجود مستوى معينًا من التعديل ليعمل في Folia. بالإضافة إلى ذلك، فإن تعدد مؤشرات الترابط من أي نوع يقدم ظروف سباق محتملة في البيانات التي يحتفظ بها البرنامج الإضافي - لذا، لا بد أن تكون هناك تغييرات يجب إجراؤها.

لذا، اجعل توقعاتك للتوافق عند 0.

خطط API

يوجد حاليًا الكثير من واجهات برمجة التطبيقات (API) التي تعتمد على الموضوع الرئيسي. أتوقع أن لا تكون أي مكونات إضافية متوافقة مع Paper متوافقة مع Folia. ومع ذلك، هناك خطط لإضافة واجهة برمجة التطبيقات (API) التي من شأنها أن تسمح لمكونات Folia الإضافية بالتوافق مع Paper.

على سبيل المثال، برنامج جدولة بوكيت. يعتمد برنامج جدولة Bukkit بطبيعته على موضوع رئيسي واحد. يسمح برنامج RegionScheduler الخاص بـ Folia وEntityScheduler من Folia بجدولة المهام إلى "العلامة التالية" لأي منطقة "تمتلكها" إما موقعًا أو كيانًا. يمكن تنفيذها على الورق العادي، باستثناء أنها مجدولة لسلسلة المحادثات الرئيسية - في كلتا الحالتين، سيتم تنفيذ المهمة على سلسلة الرسائل التي "تمتلك" الموقع أو الكيان. وينطبق هذا المفهوم بشكل عام، حيث يمكن النظر إلى الورقة الحالية (ذات الخيوط المفردة) على أنها "منطقة" عملاقة واحدة تشمل جميع القطع في جميع العوالم.

لم يتم اتخاذ قرار بعد بشأن إضافة واجهة برمجة التطبيقات هذه إلى Paper نفسه مباشرةً أو إلى Paperlib.

القواعد الجديدة

أولاً، يكسر Folia العديد من المكونات الإضافية. لمساعدة المستخدمين في معرفة المكونات الإضافية التي تعمل، سيتم فقط تحميل المكونات الإضافية التي تم وضع علامة واضحة عليها من قبل المؤلف (المؤلفين) للعمل مع Folia. من خلال وضع "folia-supported: true" في plugin.yml الخاص بالمكون الإضافي، يمكن لمؤلفي المكون الإضافي وضع علامة على المكون الإضافي الخاص بهم على أنه متوافق مع مؤشرات الترابط المتعددة الإقليمية.

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

وهذا يعني أن المكونات الإضافية المتوافقة مع Folia تحتاج إلى الاستفادة من واجهة برمجة التطبيقات (API) مثل RegionScheduler وEntityScheduler لضمان تشغيل التعليمات البرمجية الخاصة بها في سياق مؤشر الترابط الصحيح.

بشكل عام، من الآمن افتراض أن المنطقة تمتلك بيانات قطعة في 8 قطع تقريبًا من مصدر الحدث (أي يكسر اللاعب الكتلة، وربما يمكنه الوصول إلى 8 قطع حول تلك الكتلة). لكن هذا غير مضمون - يجب أن تستفيد المكونات الإضافية من واجهة برمجة التطبيقات (API) للتحقق من سلسلة الرسائل القادمة لضمان السلوك الصحيح.

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

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

إضافات واجهة برمجة التطبيقات الحالية

لفهم إضافات واجهة برمجة التطبيقات (API) بشكل صحيح، يرجى قراءة نظرة عامة على المشروع.

  • تعمل RegionScheduler وAsyncScheduler وGlobalRegionScheduler وEntityScheduler كبديل لـ BukkitScheduler. يتم استرداد برنامج جدولة الكيان عبر Entity#getScheduler، ويمكن استرداد باقي برامج الجدولة من فئات Bukkit/Server.
  • Bukkit#isOwnedByCurrentRegion لاختبار ما إذا كانت المنطقة الموقوتة الحالية تمتلك مناصب/كيانات

سياقات الموضوع لواجهة برمجة التطبيقات (API).

لفهم إضافات واجهة برمجة التطبيقات (API) بشكل صحيح، يرجى قراءة نظرة عامة على المشروع.

القواعد العامة للإبهام:

  1. يتم استدعاء أوامر الكيانات/اللاعبين في المنطقة التي تمتلك الكيان/اللاعب. يتم تنفيذ أوامر وحدة التحكم في المنطقة العالمية.

  2. يتم استدعاء الأحداث التي تتضمن كيانًا واحدًا (أي فواصل اللاعبين/حظر الأماكن) على الكيان المالك للمنطقة. يتم استدعاء الأحداث التي تتضمن إجراءات على كيان ما (مثل تلف الكيان) في المنطقة التي تمتلك الكيان المستهدف.

  3. تم إهمال مُعدِّل الأحداث غير المتزامن - تعتبر جميع الأحداث التي يتم إطلاقها من المناطق أو المنطقة العالمية متزامنة ، على الرغم من عدم وجود مؤشر ترابط رئيسي بعد الآن.

واجهة برمجة التطبيقات المعطلة الحالية

  • معظم واجهات برمجة التطبيقات التي تتفاعل مع البوابات/إعادة إنشاء اللاعبين/بعض واجهات برمجة تطبيقات تسجيل دخول اللاعبين معطلة.
  • تعتبر جميع واجهات برمجة تطبيقات لوحة النتائج معطلة (هذه حالة عالمية لم أكتشف كيفية تنفيذها بشكل صحيح بعد)
  • تحميل/تفريغ العالم
  • الكيان #النقل الفضائي. لن يعود هذا أبدًا تحت أي ظرف من الظروف، استخدم teleportAsync
  • يمكن أن يكون أكثر

إضافات API المخطط لها

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

تغييرات واجهة برمجة التطبيقات المخططة

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

معلومات مافين

  • Maven Repo (لـ folia-api): 
< repository >
    < id >papermc</ id >
    < url >https://repo.papermc.io/repository/maven-public/</ url >
</ repository >
  • معلومات القطعة الأثرية: 
< dependency >
    < groupId >dev.folia</ groupId >
    < artifactId >folia-api</ artifactId >
    < version >1.20.1-R0.1-SNAPSHOT</ version >
    < scope >provided</ scope >
</ dependency >

رخصة

يصف ملف PATCHES-LICENSE ترخيص تصحيحات API والخادم، الموجودة في ./patches وأدلته الفرعية إلا في حالة الإشارة إلى خلاف ذلك.

تعتمد الشوكة على مثال شوكة PaperMC الموجود هنا. وعلى هذا النحو، فهو يحتوي على تعديلات عليه في هذا المشروع، يرجى الاطلاع على مستودع معلومات ترخيص الملفات المعدلة.

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل