Folia

Fork of Paper ซึ่งเพิ่มมัลติเธรดแบบแบ่งเขตให้กับเซิร์ฟเวอร์เฉพาะ

ภาพรวม

Folia จัดกลุ่มชิ้นส่วนที่บรรทุกไว้ใกล้เคียงเพื่อสร้าง "ภูมิภาคอิสระ" ดูเอกสาร PaperMC สำหรับรายละเอียดที่แน่นอนเกี่ยวกับวิธีที่ Folia จะจัดกลุ่มชิ้นใกล้เคียง แต่ละภูมิภาคที่เป็นอิสระจะมีวงวนของตัวเอง ซึ่งจะถูกทำเครื่องหมายที่อัตราปกติของ Minecraft (20TPS) ติ๊กลูปถูกดำเนินการบนเธรดพูลแบบขนาน ไม่มีเธรดหลักอีกต่อไป เนื่องจากแต่ละภูมิภาคมี "เธรดหลัก" ของตัวเองที่ดำเนินการติ๊กลูปทั้งหมดอย่างมีประสิทธิภาพ

สำหรับเซิร์ฟเวอร์ที่มีผู้เล่นกระจายจำนวนมาก Folia จะสร้างภูมิภาคที่กระจายออกไปจำนวนมาก และทำเครื่องหมายทั้งหมดพร้อมกันบนเธรดพูลขนาดที่กำหนดค่าได้ ดังนั้น Folia จึงควรปรับขนาดได้ดีสำหรับเซิร์ฟเวอร์เช่นนี้

Folia ก็เป็นโปรเจ็กต์ของตัวเองเช่นกัน ซึ่งจะไม่ถูกรวมเข้ากับ Paper ในอนาคตอันใกล้

ภาพรวมที่มีรายละเอียดมากขึ้นแต่เป็นนามธรรม: ภาพรวมโครงการ

คำถามที่พบบ่อย

เซิร์ฟเวอร์ประเภทใดบ้างที่สามารถได้รับประโยชน์จาก Folia?

ประเภทเซิร์ฟเวอร์ที่กระจายผู้เล่นออกไปตามธรรมชาติ เช่น skyblock หรือ SMP จะได้รับประโยชน์สูงสุดจาก Folia เซิร์ฟเวอร์ควรมีจำนวนผู้เล่นจำนวนมากเช่นกัน

Folia จะทำงานได้ดีที่สุดกับฮาร์ดแวร์ใด

ตามหลักการแล้ว อย่างน้อย 16 คอร์ (ไม่ใช่เธรด)

วิธีกำหนดค่า Folia ให้ดีที่สุด?

อันดับแรก ขอแนะนำให้สร้างโลกไว้ล่วงหน้าเพื่อลดจำนวนเธรดผู้ปฏิบัติงานระบบก้อนที่ต้องการลดลงอย่างมาก

ต่อไปนี้เป็นการประมาณการ คร่าวๆ โดยอิงจากการทดสอบก่อนที่ Folia จะวางจำหน่ายบนเซิร์ฟเวอร์ทดสอบที่เราใช้งานซึ่งมีผู้เล่นถึง 330 คนสูงสุด ดังนั้นจึงไม่ถูกต้องและจะต้องมีการปรับแต่งเพิ่มเติม - เพียงใช้เป็นจุดเริ่มต้น

ควรคำนึงถึงจำนวนคอร์ทั้งหมดที่มีอยู่ในเครื่องด้วย จากนั้นจัดสรรเธรดสำหรับ:

• netty IO :~4 ต่อผู้เล่น 200-300 คน
• chunk system io เธรด: ~3 ต่อผู้เล่น 200-300 คน
• พนักงานระบบก้อนหากสร้างไว้ล่วงหน้า ~2 ต่อผู้เล่น 200-300 คน
• ไม่มีการคาดเดาใด ๆ ที่ดีที่สุดสำหรับผู้ปฏิบัติงานระบบ chunk หากไม่ได้สร้างไว้ล่วงหน้า เนื่องจากในเซิร์ฟเวอร์ทดสอบที่เราเรียกใช้ เราได้ให้ 16 เธรด แต่การสร้าง chunk ยังคงช้าอยู่ที่ผู้เล่นประมาณ 300 คน
• การตั้งค่า GC: ???? แต่การตั้งค่า GC จะ จัดสรรเธรดที่เกิดขึ้นพร้อมกัน และคุณจำเป็นต้องทราบจำนวนเธรดที่แน่นอน โดยทั่วไปจะเป็นผ่านแฟล็ก -XX:ConcGCThreads=n อย่าสับสนการตั้งค่าสถานะนี้ด้วย -XX:ParallelGCThreads=n เนื่องจากเธรด GC แบบขนานจะทำงานเมื่อแอปพลิเคชันถูกหยุดชั่วคราวโดย GC เท่านั้น และด้วยเหตุนี้จึงไม่ควรนำมาพิจารณา

หลังจากการจัดสรรทั้งหมดนั้น แกนประมวลผลที่เหลืออยู่ในระบบจนถึงการจัดสรร 80% (เธรดทั้งหมดที่จัดสรร < 80% ของ cpus ที่พร้อมใช้งาน) สามารถจัดสรรให้กับ Tickthreads ได้ (ภายใต้การกำหนดค่าส่วนกลาง threaded-regions.threads)

เหตุผลที่คุณไม่ควรจัดสรรคอร์เกิน 80% เนื่องมาจากข้อเท็จจริงที่ว่าปลั๊กอินหรือแม้แต่เซิร์ฟเวอร์อาจใช้เธรดเพิ่มเติมที่คุณไม่สามารถกำหนดค่าหรือคาดเดาได้

นอกจากนี้ ข้างต้นเป็นเพียงการเดาคร่าวๆ ตามจำนวนผู้เล่น แต่มีความเป็นไปได้สูงว่าการจัดสรรเธรดจะไม่เหมาะสม และคุณจะต้องปรับแต่งตามการใช้งานของเธรดที่คุณเห็น

ความเข้ากันได้ของปลั๊กอิน

ไม่มีหัวข้อหลักอีกต่อไป ฉันคาดหวังว่า ทุก ปลั๊กอินที่มีอยู่จะต้องมีการปรับเปลี่ยนในระดับ หนึ่ง เพื่อให้ทำงานใน Folia นอกจากนี้ มัลติเธรด ทุกชนิด จะทำให้เกิดสภาวะการแข่งขันที่เป็นไปได้ในข้อมูลที่ปลั๊กอินเก็บไว้ ดังนั้นจึงจำเป็นต้องมีการเปลี่ยนแปลงอย่างแน่นอน

ดังนั้นคาดหวังความเข้ากันได้ไว้ที่ 0

แผน API

ปัจจุบันมี API จำนวนมากที่ต้องอาศัยเธรดหลัก ฉันคาดว่าโดยพื้นฐานแล้วจะไม่มีปลั๊กอินที่เข้ากันได้กับ Paper เพื่อเข้ากันได้กับ Folia อย่างไรก็ตาม มีแผนที่จะเพิ่ม API ซึ่งจะทำให้ปลั๊กอิน Folia สามารถใช้งานร่วมกับ Paper ได้

ตัวอย่างเช่น Bukkit Scheduler Bukkit Scheduler อาศัยเธรดหลักเพียงเธรดเดียว RegionScheduler ของ Folia และ EntityScheduler ของ Folia ช่วยให้การจัดกำหนดการงานเป็น "ขีดถัดไป" ของภูมิภาคใดก็ตามที่ "เป็นเจ้าของ" ไม่ว่าจะเป็นสถานที่หรือเอนทิตี สิ่งเหล่านี้สามารถนำไปใช้บน Paper ทั่วไปได้ เว้นแต่จะกำหนดเวลาให้กับเธรดหลัก - ในทั้งสองกรณี การดำเนินการของงานจะเกิดขึ้นบนเธรดที่ "เป็นเจ้าของ" สถานที่หรือเอนทิตี แนวคิดนี้นำไปใช้โดยทั่วไป เนื่องจากกระดาษในปัจจุบัน (แบบเธรดเดียว) สามารถมองได้ว่าเป็น "ภูมิภาค" ขนาดยักษ์หนึ่งเดียวที่รวมเอาชิ้นส่วนทั้งหมดในโลกทั้งหมด

ยังไม่ได้ตัดสินใจว่าจะเพิ่ม API นี้ลงใน Paper โดยตรงหรือใน Paperlib

กฎเกณฑ์ใหม่

ขั้นแรก Folia แบ่งปลั๊กอินจำนวนมาก เพื่อช่วยเหลือผู้ใช้ในการพิจารณาว่าปลั๊กอินใดใช้งานได้ เฉพาะปลั๊กอินที่ผู้เขียนทำเครื่องหมายอย่างชัดเจนให้ทำงานกับ Folia เท่านั้นที่จะถูกโหลด ด้วยการใส่ "folia-supported: true" ลงใน Plugin.yml ของปลั๊กอิน ผู้เขียนปลั๊กอินสามารถทำเครื่องหมายปลั๊กอินของตนว่าเข้ากันได้กับมัลติเธรดแบบแบ่งเขต

กฎสำคัญอีกข้อหนึ่งคือขอบเขตต่างๆ ทำเครื่องหมาย แบบคู่ขนาน และไม่ พร้อมกัน พวกเขาไม่เปิดเผยข้อมูล พวกเขาไม่คาดหวังที่จะแบ่งปันข้อมูล และการแบ่งปันข้อมูล จะ ทำให้ข้อมูลเสียหาย รหัสที่ทำงานในภูมิภาคหนึ่งไม่ว่าในกรณีใดก็ตาม ไม่สามารถเข้าถึงหรือแก้ไขข้อมูลที่อยู่ในภูมิภาคอื่นได้ เพียงเพราะว่ามัลติเธรดอยู่ในชื่อ ไม่ได้หมายความว่าทุกอย่างปลอดภัยสำหรับเธรดแล้ว อันที่จริง มีเพียง ไม่กี่ อย่างเท่านั้นที่ทำให้เธรดปลอดภัยเพื่อให้สิ่งนี้เกิดขึ้น เมื่อเวลาผ่านไป จำนวนการตรวจสอบบริบทของเธรดจะเพิ่มขึ้น แม้ว่า จะมีการลงโทษด้านประสิทธิภาพก็ตาม ไม่มีใคร จะใช้หรือพัฒนาสำหรับแพลตฟอร์มเซิร์ฟเวอร์ที่บั๊กสุดๆ และเป็นวิธีเดียวที่จะป้องกันและค้นหาสิ่งเหล่านี้ ข้อบกพร่องคือการทำให้การเข้าถึงที่ไม่ดีล้มเหลว อย่างหนัก ที่แหล่งที่มาของการเข้าถึงที่ไม่ดี

ซึ่งหมายความว่าปลั๊กอินที่เข้ากันได้กับ Folia จำเป็นต้องใช้ประโยชน์จาก API เช่น RegionScheduler และ EntityScheduler เพื่อให้แน่ใจว่าโค้ดทำงานบนบริบทของเธรดที่ถูกต้อง

โดยทั่วไป จะปลอดภัยที่จะสรุปได้ว่าภูมิภาคเป็นเจ้าของข้อมูลก้อนประมาณ 8 ชิ้นจากแหล่งที่มาของเหตุการณ์ (เช่น ผู้เล่นทำลายบล็อก อาจสามารถเข้าถึง 8 ชิ้นรอบๆ บล็อกนั้นได้) แต่ไม่รับประกันว่าปลั๊กอินควรใช้ประโยชน์จาก API การตรวจสอบเธรดที่กำลังจะมีขึ้นเพื่อให้แน่ใจว่ามีการทำงานที่ถูกต้อง

การรับประกันความปลอดภัยของเธรดเพียงอย่างเดียวนั้นมาจากข้อเท็จจริงที่ว่าภูมิภาคเดียวเป็นเจ้าของข้อมูลในบางกลุ่ม และหากภูมิภาคนั้นทำเครื่องหมายถูก ก็หมายความว่าจะสามารถเข้าถึงข้อมูลนั้นได้อย่างเต็มที่ ข้อมูลนี้เป็นข้อมูลเอนทิตี/ชิ้น/POI โดยเฉพาะ และไม่เกี่ยวข้องกับข้อมูลปลั๊กอิน ใดๆ เลย

กฎมัลติเธรดปกติใช้กับข้อมูลที่ปลั๊กอินจัดเก็บ/เข้าถึงข้อมูลของตนเองหรือของปลั๊กอินอื่น - events/commands/etc ถูกเรียกแบบ ขนาน เนื่องจากภูมิภาคกำลังทำเครื่องหมาย แบบขนาน (เราไม่สามารถเรียกพวกมันในลักษณะซิงโครนัสได้ เนื่องจากจะทำให้เกิดปัญหาการหยุดชะงักและทำให้ประสิทธิภาพลดลง) ไม่มีวิธีง่ายๆ ในการทำเช่นนี้ ขึ้นอยู่กับว่ามีการเข้าถึงข้อมูลใดบ้าง บางครั้งคอลเลกชันที่เกิดขึ้นพร้อมกัน (เช่น ConcurrentHashMap) ก็เพียงพอแล้ว และบ่อยครั้งที่คอลเลกชันที่เกิดขึ้นพร้อมกันที่ใช้อย่างไม่ระมัดระวังจะ ซ่อน เฉพาะปัญหาเธรด ซึ่งแทบจะแก้ไขข้อบกพร่องไม่ได้เลย

การเพิ่ม API ปัจจุบัน

เพื่อให้เข้าใจถึงการเพิ่ม API อย่างถูกต้อง โปรดอ่านภาพรวมโครงการ

• RegionScheduler, AsyncScheduler, GlobalRegionScheduler และ EntityScheduler ทำหน้าที่แทน BukkitScheduler ตัวกำหนดเวลาเอนทิตีจะถูกดึงข้อมูลผ่านทาง Entity#getScheduler และตัวกำหนดเวลาที่เหลือสามารถดึงข้อมูลจากคลาส Bukkit/Server
• Bukkit#isOwnedByCurrentRegion เพื่อทดสอบว่าภูมิภาคปัจจุบันเป็นเจ้าของตำแหน่ง/เอนทิตีหรือไม่

บริบทของเธรดสำหรับ API

เพื่อให้เข้าใจถึงการเพิ่ม API อย่างถูกต้อง โปรดอ่านภาพรวมโครงการ

กฎทั่วไปทั่วไป:

1. คำสั่งสำหรับเอนทิตี/ผู้เล่นจะถูกเรียกในภูมิภาคซึ่งเป็นเจ้าของเอนทิตี/ผู้เล่น คำสั่งคอนโซลดำเนินการในภูมิภาคส่วนกลาง

2. เหตุการณ์ที่เกี่ยวข้องกับเอนทิตีเดียว (เช่น การบล็อกผู้เล่นแบ่ง/วาง) จะถูกเรียกในเอนทิตีที่เป็นเจ้าของภูมิภาค เหตุการณ์ที่เกี่ยวข้องกับการดำเนินการกับเอนทิตี (เช่น ความเสียหายของเอนทิตี) จะถูกเรียกใช้ในภูมิภาคที่เป็นเจ้าของเอนทิตีเป้าหมาย

3. ตัวแก้ไขอะซิงก์สำหรับเหตุการณ์เลิกใช้งานแล้ว - กิจกรรมทั้งหมดที่เริ่มทำงานจากภูมิภาคหรือภูมิภาคส่วนกลางจะถือเป็น แบบซิงโครนัส แม้ว่าจะไม่มีเธรดหลักอีกต่อไปก็ตาม

API ที่เสียหายในปัจจุบัน

• API ส่วนใหญ่ที่โต้ตอบกับพอร์ทัล / ผู้เล่นที่เกิดใหม่ / API การเข้าสู่ระบบของผู้เล่นบางคนใช้งานไม่ได้
• API กระดานคะแนนทั้งหมดถือว่าใช้งานไม่ได้ (นี่คือสถานะสากลที่ฉันยังไม่ทราบวิธีการนำไปใช้อย่างเหมาะสม)
• การขนถ่ายโลก
• เอนทิตี#เทเลพอร์ต สิ่งนี้จะไม่กลับมาไม่ว่าในกรณีใด ๆ ใช้ teleportAsync
• อาจจะมากกว่านี้

การเพิ่ม API ที่วางแผนไว้

• เหตุการณ์อะซิงโครนัสที่เหมาะสม ซึ่งจะทำให้ผลลัพธ์ของเหตุการณ์เสร็จสมบูรณ์ในภายหลังในบริบทของเธรดอื่น สิ่งนี้จำเป็นสำหรับการดำเนินการบางอย่าง เช่น การเลือกตำแหน่งวางไข่ เนื่องจากจำเป็นต้องมีการโหลดก้อนแบบอะซิงโครนัสเมื่อเข้าถึงข้อมูลก้อนที่อยู่นอกภูมิภาค
• การขนถ่ายโลก
• มาที่นี่เพิ่มเติม

การเปลี่ยนแปลง 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 ที่พบได้ที่นี่ ด้วยเหตุนี้จึงมีการแก้ไขในโปรเจ็กต์นี้ โปรดดูที่เก็บข้อมูลใบอนุญาตของไฟล์ที่แก้ไข