ตัวเลือกในการซิงโครไนซ์ไฟล์ 1 ล้านไฟล์กับเซิร์ฟเวอร์ระยะไกลได้อย่างมีประสิทธิภาพหรือไม่

27

ที่ บริษัท ฉันทำงานให้เรามีสิ่งที่เรียกว่า "เพลย์ลิสต์" ซึ่งเป็นไฟล์ขนาดเล็กประมาณ 100-300 ไบต์ต่อไฟล์ มีประมาณล้านคน ประมาณ 100,000 คนได้รับการเปลี่ยนแปลงทุกชั่วโมง เพลย์ลิสต์เหล่านี้จะต้องอัปโหลดไปยังเซิร์ฟเวอร์ระยะไกลอื่น ๆ 10 แห่งในแต่ละทวีปที่แตกต่างกันทุกชั่วโมง มันสำคัญมากที่ไฟล์ที่ถูกลบในต้นแบบนั้นจะถูกลบในแบบจำลองทั้งหมดด้วย ขณะนี้เราใช้ Linux สำหรับโครงสร้างพื้นฐานของเรา

ฉันกำลังคิดเกี่ยวกับการลอง rsync ด้วยตัวเลือก -W เพื่อคัดลอกไฟล์ทั้งหมดโดยไม่ต้องเปรียบเทียบเนื้อหา ฉันยังไม่ได้ลองเลย แต่บางทีคนที่มีประสบการณ์มากกว่ากับ rsync อาจบอกฉันได้ว่ามันเป็นตัวเลือกที่เหมาะสมหรือไม่?

ตัวเลือกอื่น ๆ ที่มีมูลค่าการพิจารณา?

ปรับปรุง:ฉันได้เลือกตัวเลือก lsyncd เป็นคำตอบ แต่เพียงเพราะมันเป็นที่นิยมที่สุด ทางเลือกที่แนะนำอื่น ๆ ก็มีผลในทางของตัวเอง

rsync optimization synchronization

— Zilvinas
แหล่งที่มา

1

คุณมีบันทึกที่ระบุว่ามีการเปลี่ยนแปลงหรือลบไฟล์ใดบ้าง

— Oliver

3

ถ้าเพียงเพลย์ลิสต์คือระเบียน mysql จากนั้นคุณสามารถใช้การจำลองแบบฐานข้อมูลและรับ mysql เพื่อหาสิ่งที่จำเป็นในการส่ง / รับ

— Matt

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

— Zilvinas

คุณต้องการให้การเปลี่ยนแปลงมีผลเฉพาะทุกชั่วโมงหรือไม่ หรือจำลองแบบทันทีก็ยอมรับได้?

— ขนม

1

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

— Oliver

39

เนื่องจากการอัปเดตทันทีนั้นเป็นที่ยอมรับคุณสามารถใช้lsyncdได้
มันเฝ้าดูไดเรกทอรี (inotify) และจะrsyncเปลี่ยนเป็นทาส
เมื่อเริ่มต้นมันจะทำแบบเต็มrsyncดังนั้นจะใช้เวลาสักครู่ แต่หลังจากนั้นจะมีการส่งการเปลี่ยนแปลงเท่านั้น
การเรียกดูซ้ำของไดเรกทอรีเป็นไปได้หากเซิร์ฟเวอร์ทาสไม่ทำงานการซิงค์จะถูกลองอีกครั้งจนกว่าจะกลับมา

ถ้านี่คือทั้งหมดในไดเรกทอรีเดียว (หรือรายการคงที่ของไดเรกทอรี) คุณยังสามารถใช้incron
ข้อเสียคือไม่อนุญาตให้มีการดูโฟลเดอร์ซ้ำและคุณจำเป็นต้องใช้ฟังก์ชั่นการซิงค์ด้วยตัวเอง

— ของที่กุขึ้น
แหล่งที่มา

เคล็ดลับอีกครั้งที่ยอดเยี่ยม :)

— Zilvinas

1

+1 นี่คือปัญหาการเชื่อมโยงกันแคชเป็นหลัก, จอภาพที่ผลักดันการเปลี่ยนแปลงเป็นทางออกที่ง่ายที่สุด lsyncdดำเนินการที่ ...

— Chris S

1

ฉันจะตรวจสอบlsyncdและinotifyใช้งานระบบเซิร์ฟเวอร์ของคุณโดยเฉพาะ มีการ จำกัด จำนวนนาฬิกา inotify ที่ใช้ได้ ฉันเชื่อว่าค่าเริ่มต้นอยู่ที่ประมาณ 1,500 หรือ 8000 ขึ้นอยู่กับรุ่น Linux ของคุณ เมล็ดส่วนใหญ่อนุญาตให้คุณเพิ่มขีด จำกัด ได้ แต่การตรวจสอบไฟล์ 1 ล้านไฟล์อาจมากกว่าที่เป็นจริง มันไม่ได้ผลสำหรับฉันในปี 2008 นอกจากนี้คิวเหตุการณ์ที่ไม่เปิดเผยสามารถล้นได้ซึ่งจะทำให้คุณสูญเสียกิจกรรมและคุณต้องมีวิธีการกู้คืนจากเหตุการณ์นั้น การปรับlsyncdใช้อย่างระมัดระวังและรายวันrsyncอาจใช้งานได้ในปี 2555 เพื่อครอบคลุมฐานของคุณ

— โปรเก่า

2

จริงๆแล้วมันจะiontifyอยู่ในไดเรกทอรีไม่ใช่ไฟล์แต่ละไฟล์ คุณสามารถดูไดเรกทอรีได้กี่ไดเรกทอรี ตรวจสอบ/proc/sys/fs/inotify/max_user_watches(ปกติ 8192)

— ขนม

2

ด้วยไดเรกทอรี ~ 50k inotify อาจจะไม่ดี เมื่อเราลองใช้วิธีที่คล้ายกันในปี 2009 ด้วยไดเรกทอรี 100k มันใช้วิธีเคอร์เนลเป็นเวลานานในการสมัครสมาชิกไดเรกทอรีทั้งหมด สำหรับ @OldPro มันไม่ได้ผลสำหรับเรา

— neovatar

11

พิจารณาใช้ระบบแฟ้มกระจายเช่นGlusterFS ถูกออกแบบกับการจำลองแบบและความเท่าเทียมในใจ GlusterFS อาจไต่ขึ้นถึง 10 เซิร์ฟเวอร์อย่างราบรื่นมากขึ้นกว่าโซลูชั่นเฉพาะกิจที่เกี่ยวข้องกับ inotify rsyncและ

สำหรับกรณีการใช้งานนี้โดยเฉพาะเราสามารถสร้างไดรฟ์ข้อมูล GlusterFS 10 เซิร์ฟเวอร์จำนวน 10 แบบจำลอง (เช่น 1 แบบจำลอง / อิฐต่อเซิร์ฟเวอร์) ดังนั้นแต่ละแบบจำลองจะเป็นมิรเรอร์ที่แน่นอนของแบบจำลองอื่น ๆ ทุกรายการในปริมาณ GlusterFS จะเผยแพร่การปรับปรุงระบบไฟล์ไปยังแบบจำลองทั้งหมดโดยอัตโนมัติ

ลูกค้าในแต่ละสถานที่จะติดต่อกับเซิร์ฟเวอร์ในพื้นที่ของตนดังนั้นการเข้าถึงไฟล์แบบอ่านอย่างรวดเร็ว คำถามสำคัญคือว่าเวลาแฝงการเขียนอาจต่ำหรือไม่ วิธีเดียวที่จะตอบคำถามนี้ก็คือลองทำดู

— สตีเว่นวันจันทร์
แหล่งที่มา

+1 สำหรับ Glusterfs

— Tom O'Connor

8

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

แก้ไข: ด้วยการทำงานเล็กน้อยคุณสามารถใช้วิธี inotify / log watch เพื่อคัดลอกไฟล์ได้ทันทีที่มีการดัดแปลงเกิดขึ้น

— สเวน
แหล่งที่มา

5

ทางเลือกเพิ่มเติม:

แทรกงานลงในRabbitMQหรือGearmanเพื่อปิดแบบอะซิงโครนัสและลบ (หรือเพิ่ม) ไฟล์เดียวกันบนเซิร์ฟเวอร์ระยะไกลทั้งหมดเมื่อใดก็ตามที่คุณลบหรือเพิ่มไฟล์บนเซิร์ฟเวอร์หลัก
จัดเก็บไฟล์ในฐานข้อมูลและใช้การจำลองแบบเพื่อให้เซิร์ฟเวอร์ระยะไกลซิงค์
ถ้าคุณมี ZFS คุณสามารถใช้ การจำลองแบบ ZFS
SAN บางตัวมีการจำลองแบบไฟล์ ฉันไม่รู้ว่าจะใช้งานอินเทอร์เน็ตได้ไหม

— Ladadadada
แหล่งที่มา

4

นี้น่าจะเป็นกรณีที่ที่เหมาะสำหรับการใช้งานนิทานสำหรับMongoDBและอาจGridFS เนื่องจากไฟล์มีขนาดค่อนข้างเล็ก MongoDB เพียงอย่างเดียวจึงน่าจะเพียงพอแม้ว่าอาจจะสะดวกในการใช้ GridFS API

MongoDB เป็นฐานข้อมูล nosql และ GridFS เป็นโครงสร้างการจัดเก็บไฟล์ที่อยู่ด้านบน MongoDB มีจำนวนมากที่สร้างขึ้นในตัวเลือกสำหรับการจำลองแบบและshardingดังนั้นจึงควรระดับดีมากในกรณีที่ใช้งานของคุณ

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

— neovatar
แหล่งที่มา

0

ฉันจะใช้ S3 แบ็กเอนด์และจากนั้นก็ติดตั้งที่เซิร์ฟเวอร์ทั้งหมดที่ฉันต้องการ - ด้วยวิธีนี้ทุกคนซิงค์กันทันที

— มิสเตอร์ไอทีกูรู
แหล่งที่มา

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

— Chris S

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

— Mister IT Guru

0

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

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

— Supr
แหล่งที่มา