lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
หน้าแรก
AI
OPRR
ด่วน
ความลึก
กิจกรรม
BlockBeats Pro
เพิ่มเติม
การเงิน
พิเศษ
ระบบนิเวศบล็อกเชน
รายการ
พอดแคสต์
ข้อมูล
BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
Partnered With:

GitHub สร้างโครงสร้างพื้นฐาน Git ใหม่: AI 5,000 ตัวทำงานพร้อมกัน โดยจัดการ push โค้ดได้ 7,200 ครั้งต่อวินาทีในคลังเดียว

动察 Beating ข่าวด่วน AI,GitHub เปิดเผยสถาปัตยกรรมจัดเก็บ Git รุ่นใหม่ที่มีชื่อรหัสว่า Rubicon การทดสอบภายในแสดงให้เห็นว่า AI Agent จำนวน 5,000 ตัวสามารถทำงานพร้อมกันในคลังโค้ดเดียว โดยทำการ push โค้ดได้ 7,200 ครั้งต่อวินาที พร้อมทั้งรักษาความหน่วงในการอ่านให้อยู่ในระดับต่ำ


ในอดีต คลังโค้ดที่ยุ่งวุ่นวายที่สุดของ GitHub มีการเขียนเพียงไม่กี่สิบครั้งต่อวินาทีในช่วงเวลาสั้นๆ ตอนนี้ AI Agent จำนวนมากสามารถพัฒนาพร้อมกันได้ตลอด 24 ชั่วโมง ส่งโค้ดใหม่เข้ามาอย่างต่อเนื่อง การ commit แต่ละครั้งยังอาจกระตุ้นให้เกิดการทดสอบอัตโนมัติ ทำให้ Agent อื่นดาวน์โหลดเวอร์ชันล่าสุด ส่งผลให้ภาระการอ่านและเขียนของคลังเพิ่มขึ้นตามไปด้วย


วิธีแก้ปัญหาของ GitHub คือการแยกการจัดการ "จัดเก็บโค้ด" และ "อัปเดตสาขา" ออกจากกัน


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


ตัวอย่างเช่น เมื่อ Agent 1,000 ตัวพัฒนาซอฟต์แวร์พร้อมกัน บางตัวแก้ไขฟังก์ชันเข้าสู่ระบบ บางตัวแก้ไขฟังก์ชันชำระเงิน ตราบใดที่它們ทำงานในสาขาที่แตกต่างกัน โค้ดใหม่ก็สามารถบันทึกพร้อมกันได้ และสาขาก็สามารถอัปเดตแยกกันได้ ระบบจะต้องตัดสินว่าใครอัปเดตสำเร็จก่อนก็ต่อเมื่อมี Agent สองตัวแย่งกันอัปเดตสาขาเดียวกันพร้อมกันเท่านั้น


ในตอนแรก GitHub ให้ทุกสาขาใช้บันทึกการอัปเดตร่วมกันไฟล์เดียว แม้ AI Agent ต่างตัวจะแก้ไขสาขาที่แตกต่างกัน ก็ยังต้องแย่งกันอัปเดตไฟล์เดียวกัน ทำให้ประมวลผลได้เพียงไม่กี่ร้อยครั้งต่อวินาที GitHub จึงลองแยกบันทึกออกเป็นหลายส่วน เพื่อให้สาขาต่างๆ อัปเดตพร้อมกันได้ แต่การทำเช่นนี้ทำให้ทุกครั้งที่ตรวจสอบว่าคลังมีการเปลี่ยนแปลงหรือไม่ ต้องสอบถามทีละส่วน ส่งผลให้ความเร็วในการอ่านช้าลงแทน


ในที่สุด GitHub จึงพัฒนาบริการ Ref-CAS ที่จัดการการอัปเดตสาขาโดยเฉพาะ ช่วยให้สาขาต่างๆ อัปเดตพร้อมกันได้ และจะต้องจัดการข้อขัดแย้งเฉพาะเมื่อแก้ไขสาขาเดียวกันเท่านั้น พร้อมกันนั้นยังดูแลหมายเลขเวอร์ชันแบบรวมศูนย์ให้กับทั้งคลัง โปรแกรมอื่นเพียงตรวจสอบหมายเลขเวอร์ชันนี้ก็รู้ได้ว่าคลังมีการเปลี่ยนแปลงหรือไม่ โดยไม่จำเป็นต้องสอบถามทุกสาขาทีละแห่ง


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


Rubicon ของ GitHub ขณะนี้ยังอยู่ในช่วงทดสอบส่วนตัวแบบจำกัด และมีแผนที่จะขยายการเปิดให้ใช้งานในช่วงต้นปี 2027

ที่เกี่ยวข้องแนะนำ
นักพัฒนา เจ้าของเนื้อหา ผู้สร้างผลิตภัณฑ์ และผู้เริ่มต้นสามารถใช้งาน
โค้ดที่ตรงช่วยในการเรียกใช้งานโมเดล AI เท่าเพียง 1.6% ของโค้ดทั้งหมด
นักสืบบนบล็อกเชนเฝ้าติดตามอย่างต่อเนื่อง
แก้ไข/รายงาน
ส่ง
เพิ่มคลัง
เห็นได้เฉพาะตัวเอง
สาธารณะ
บันทึก
เลือกคลัง
เพิ่มคลัง
ยกเลิก
เสร็จสิ้น