Web Analytics

system-design-primer

⭐ 318813 stars Thai by donnemartin

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

ช่วย แปล คู่มือนี้!

The System Design Primer


แรงจูงใจ

เรียนรู้วิธีออกแบบระบบขนาดใหญ่
>
เตรียมตัวสำหรับสัมภาษณ์การออกแบบระบบ

เรียนรู้วิธีออกแบบระบบขนาดใหญ่

การเรียนรู้วิธีออกแบบระบบที่สามารถขยายขนาดได้จะช่วยให้คุณเป็นวิศวกรที่ดีขึ้น

การออกแบบระบบเป็นหัวข้อที่กว้าง มี แหล่งข้อมูลจำนวนมากกระจายอยู่ทั่วอินเทอร์เน็ต เกี่ยวกับหลักการออกแบบระบบ

repo นี้คือ การรวบรวมแหล่งข้อมูลอย่างเป็นระเบียบ เพื่อช่วยให้คุณเรียนรู้วิธีสร้างระบบขนาดใหญ่

เรียนรู้จากชุมชนโอเพ่นซอร์ส

นี่คือโปรเจกต์โอเพ่นซอร์สที่มีการอัปเดตอย่างต่อเนื่อง

ยินดีรับการมีส่วนร่วม!

เตรียมตัวสำหรับสัมภาษณ์การออกแบบระบบ

นอกเหนือจากการสัมภาษณ์เขียนโค้ดแล้ว การออกแบบระบบยังเป็น องค์ประกอบสำคัญ ของ กระบวนการสัมภาษณ์ทางเทคนิค ในหลายบริษัทเทคโนโลยี

ฝึกตอบคำถามสัมภาษณ์การออกแบบระบบที่พบบ่อย และ เปรียบเทียบ ผลลัพธ์ของคุณกับ ตัวอย่างคำตอบ: การอภิปราย โค้ด และไดอะแกรม

หัวข้อเพิ่มเติมเพื่อเตรียมสัมภาษณ์:

บัตรคำ Anki


ชุด บัตรคำ Anki ที่ให้มาใช้เทคนิคการทบทวนแบบเว้นระยะ เพื่อช่วยให้จดจำแนวคิดสำคัญในการออกแบบระบบ

เหมาะสำหรับใช้ขณะเดินทาง

แหล่งข้อมูลการเขียนโค้ด: แบบฝึกหัดโค้ดเชิงโต้ตอบ

กำลังมองหาแหล่งข้อมูลเพื่อเตรียมตัวสำหรับ การสัมภาษณ์โค้ดดิ้ง?


ลองดูรีโปซิทอรีที่เกี่ยวข้อง Interactive Coding Challenges ซึ่งมีชุดบัตรคำ Anki เพิ่มเติม:

การมีส่วนร่วม

เรียนรู้จากชุมชน

สามารถส่ง pull request เพื่อช่วยได้อย่างอิสระ:

เนื้อหาที่ต้องปรับปรุงจะถูกจัดไว้ ระหว่างการพัฒนา

ตรวจสอบ แนวทางการมีส่วนร่วม

ดัชนีหัวข้อการออกแบบระบบ

สรุปหัวข้อต่างๆเกี่ยวกับการออกแบบระบบ รวมถึงข้อดีข้อเสีย ทุกสิ่งล้วนเป็นการแลกเปลี่ยนข้อดีข้อเสีย.
>
แต่ละส่วนมีลิงก์ไปยังแหล่งข้อมูลเชิงลึกเพิ่มเติม


คู่มือการศึกษา

หัวข้อที่แนะนำให้ทบทวนตามระยะเวลาสัมภาษณ์ของคุณ (สั้น, กลาง, ยาว)

Imgur

ถาม: สำหรับการสัมภาษณ์ ฉันจำเป็นต้องรู้ทุกอย่างที่นี่หรือไม่?

ตอบ: ไม่ คุณไม่จำเป็นต้องรู้ทุกอย่างที่นี่เพื่อเตรียมตัวสำหรับสัมภาษณ์

สิ่งที่คุณจะถูกถามในการสัมภาษณ์ขึ้นอยู่กับตัวแปรต่างๆ เช่น:

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

เริ่มต้นจากภาพรวมและค่อยๆ เจาะลึกในบางส่วน การรู้พื้นฐานในหัวข้อการออกแบบระบบที่สำคัญหลายๆ ด้านจะช่วยได้ ปรับแต่งคู่มือด้านล่างนี้ตามระยะเวลาที่คุณมี ประสบการณ์ของคุณ ตำแหน่งงานที่คุณสมัคร และบริษัทที่คุณสมัคร

| | สั้น | ปานกลาง | นาน | |---|---|---|---| | อ่านหัวข้อ การออกแบบระบบ เพื่อเข้าใจภาพรวมการทำงานของระบบ | :+1: | :+1: | :+1: | | อ่านบทความบางส่วนจาก บล็อกวิศวกรรมของบริษัท ที่คุณสมัครงาน | :+1: | :+1: | :+1: | | อ่านกรณีตัวอย่าง สถาปัตยกรรมในโลกจริง | :+1: | :+1: | :+1: | | ทบทวน วิธีการรับมือกับคำถามสัมภาษณ์การออกแบบระบบ | :+1: | :+1: | :+1: | | ฝึกทำ คำถามสัมภาษณ์การออกแบบระบบพร้อมคำตอบ | บางข้อ | หลายข้อ | ส่วนใหญ่ | | ฝึกทำ คำถามสัมภาษณ์การออกแบบเชิงวัตถุพร้อมคำตอบ | บางข้อ | หลายข้อ | ส่วนใหญ่ | | ทบทวน คำถามสัมภาษณ์การออกแบบระบบเพิ่มเติม | บางข้อ | หลายข้อ | ส่วนใหญ่ |

วิธีรับมือกับคำถามสัมภาษณ์การออกแบบระบบ

วิธีจัดการกับคำถามสัมภาษณ์การออกแบบระบบ

การสัมภาษณ์ออกแบบระบบเป็น การสนทนาแบบเปิด โดยคุณควรเป็นผู้นำการสนทนา

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

ขั้นตอนที่ 1: สรุปกรณีใช้งาน ข้อจำกัด และสมมติฐาน

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

ขั้นตอนที่ 2: สร้างการออกแบบระดับสูง

สรุปภาพรวมการออกแบบระดับสูงโดยระบุองค์ประกอบสำคัญทั้งหมด

ขั้นตอนที่ 3: ออกแบบส่วนประกอบหลัก

ลงรายละเอียดสำหรับแต่ละส่วนประกอบหลัก ตัวอย่างเช่น หากคุณถูกขอให้ ออกแบบบริการย่อ URL ให้พูดถึง:

ขั้นตอนที่ 4: ขยายการออกแบบ

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

อภิปรายแนวทางแก้ไขและข้อแลกเปลี่ยนที่อาจเกิดขึ้น ทุกอย่างมีข้อแลกเปลี่ยน แก้ไขจุดคอขวดโดยใช้ หลักการออกแบบระบบที่ปรับขนาดได้

การคำนวณแบบหยาบๆ

คุณอาจถูกขอให้ประมาณค่าด้วยมือ ดู ภาคผนวก สำหรับแหล่งข้อมูลต่อไปนี้:

แหล่งข้อมูลและการอ่านเพิ่มเติม

ดูที่ลิงก์ต่อไปนี้เพื่อให้เข้าใจมากขึ้นว่าควรคาดหวังอะไรบ้าง:

คำถามสัมภาษณ์ออกแบบระบบพร้อมคำตอบ

คำถามสัมภาษณ์ออกแบบระบบที่พบบ่อย พร้อมตัวอย่างการอภิปราย โค้ด และไดอะแกรม
>
คำตอบเชื่อมโยงไปยังเนื้อหาในโฟลเดอร์ solutions/

| คำถาม | | |---|---| | ออกแบบ Pastebin.com (หรือ Bit.ly) | คำตอบ | | ออกแบบไทม์ไลน์และค้นหา Twitter (หรือฟีดและค้นหา Facebook) | คำตอบ | | ออกแบบเว็บครอว์เลอร์ | คำตอบ | | ออกแบบ Mint.com | คำตอบ | | ออกแบบโครงสร้างข้อมูลสำหรับโซเชียลเน็ตเวิร์ก | คำตอบ | | ออกแบบ key-value store สำหรับ search engine | คำตอบ | | ออกแบบฟีเจอร์จัดอันดับยอดขายตามหมวดหมู่ของ Amazon | คำตอบ | | ออกแบบระบบที่ขยายรองรับผู้ใช้หลักล้านบน AWS | คำตอบ | | เพิ่มคำถามออกแบบระบบ | ร่วมสมทบ |

ออกแบบ Pastebin.com (หรือ Bit.ly)

ดูแบบฝึกหัดและคำตอบ

Imgur

ออกแบบไทม์ไลน์และค้นหา Twitter (หรือฟีดและค้นหา Facebook)

ดูแบบฝึกหัดและคำตอบ

Imgur

ออกแบบเว็บครอว์เลอร์

ดูแบบฝึกหัดและคำตอบ

Imgur

Design Mint.com

View exercise and solution

Imgur

Design the data structures for a social network

View exercise and solution

Imgur

Design a key-value store for a search engine

View exercise and solution

Imgur

Design Amazon's sales ranking by category feature

View exercise and solution

Imgur

Design a system that scales to millions of users on AWS

View exercise and solution

Imgur

Object-oriented design interview questions with solutions

Common object-oriented design interview questions with sample discussions, code, and diagrams.
>
Solutions linked to content in the solutions/ folder.

>Note: This section is under development

| Question | | |---|---| | ออกแบบแฮชแมป | คำตอบ | | ออกแบบแคชแบบ least recently used | คำตอบ | | ออกแบบศูนย์บริการลูกค้า | คำตอบ | | ออกแบบสำรับไพ่ | คำตอบ | | ออกแบบที่จอดรถ | คำตอบ | | ออกแบบเซิร์ฟเวอร์แชท | คำตอบ | | ออกแบบอาร์เรย์วงกลม | ร่วมสมทบ | | เพิ่มคำถามการออกแบบเชิงวัตถุ | ร่วมสมทบ |

หัวข้อการออกแบบระบบ: เริ่มต้นที่นี่

ใหม่กับการออกแบบระบบ?

ก่อนอื่น คุณต้องเข้าใจหลักการทั่วไปเกี่ยวกับสิ่งเหล่านี้ การใช้งาน และข้อดีข้อเสีย

ขั้นตอนที่ 1: ทบทวนวิดีโอบรรยายเรื่องการขยายระบบ

บรรยาย Scalability ที่ Harvard

ขั้นตอนที่ 2: ทบทวนบทความเกี่ยวกับการขยายระบบ

Scalability

ขั้นตอนถัดไป

ต่อไป เราจะมาดูการชั่งน้ำหนักในระดับสูง:

โปรดจำไว้ว่า ทุกอย่างคือการชั่งน้ำหนัก

จากนั้นเราจะเจาะลึกในหัวข้อเฉพาะ เช่น DNS, CDN และโหลดบาลานเซอร์

ประสิทธิภาพเทียบกับความสามารถในการขยายตัว

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

อีกวิธีหนึ่งในการมองประสิทธิภาพเทียบกับความสามารถในการขยายตัว:

แหล่งข้อมูลและอ่านเพิ่มเติม

ความหน่วงเทียบกับอัตราการส่งผ่านข้อมูล

ความหน่วง คือเวลาที่ใช้ในการดำเนินการบางอย่างหรือเพื่อสร้างผลลัพธ์บางอย่าง

อัตราการส่งผ่านข้อมูล คือจำนวนของการกระทำหรือผลลัพธ์ดังกล่าวต่อหน่วยเวลา

โดยทั่วไป คุณควรมุ่งเน้นไปที่ อัตราการส่งผ่านข้อมูลสูงสุด พร้อม ความหน่วงที่ยอมรับได้

แหล่งข้อมูลและอ่านเพิ่มเติม

ความพร้อมใช้งานเทียบกับความสอดคล้อง

ทฤษฎี CAP


ที่มา: ทบทวนทฤษฎี CAP

ในระบบคอมพิวเตอร์แบบกระจาย คุณสามารถรองรับได้เพียงสองในสามของการรับประกันดังต่อไปนี้:

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

#### CP - ความสอดคล้องและความทนทานต่อการแบ่งเครือข่าย

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

#### AP - ความพร้อมใช้งานและความทนทานต่อการแบ่งเครือข่าย

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

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

แหล่งข้อมูลและอ่านเพิ่มเติม

รูปแบบความสอดคล้อง

เมื่อมีการสำเนาข้อมูลเดียวกันหลายชุด เราต้องตัดสินใจว่าจะซิงโครไนซ์ข้อมูลเหล่านั้นอย่างไร เพื่อให้ลูกค้ามีมุมมองข้อมูลที่สอดคล้องกัน จำคำนิยามของความสอดคล้องจาก ทฤษฎี CAP - ทุกการอ่านจะได้รับการเขียนล่าสุดหรือเกิดข้อผิดพลาด

ความสอดคล้องแบบอ่อน (Weak consistency)

หลังจากการเขียน การอ่านอาจเห็นหรือไม่เห็นข้อมูลนั้นก็ได้ โดยใช้วิธีที่ดีที่สุดเท่าที่จะทำได้

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

ความสอดคล้องแบบสุดท้าย (Eventual consistency)

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

แนวทางนี้พบได้ในระบบเช่น DNS และอีเมล ความสอดคล้องแบบสุดท้ายเหมาะกับระบบที่ต้องการความพร้อมใช้งานสูง

ความสอดคล้องแบบเข้มงวด (Strong consistency)

หลังจากการเขียน ข้อมูลที่อ่านจะสามารถเห็นการเปลี่ยนแปลงทันที ข้อมูลจะถูกจำลองแบบแบบซิงโครนัส

แนวทางนี้พบได้ในระบบไฟล์และ RDBMS ความสอดคล้องแบบเข้มงวดเหมาะกับระบบที่ต้องการธุรกรรม

แหล่งข้อมูลและอ่านเพิ่มเติม

รูปแบบความพร้อมใช้งาน

มีรูปแบบเสริมสองแบบเพื่อรองรับความพร้อมใช้งานสูง: การสลับไปยังตัวสำรอง (fail-over) และ การจำลองแบบ (replication)

การสลับไปยังตัวสำรอง (Fail-over)

#### แอคทีฟ-พาสซีฟ (Active-passive)

ในการสลับแบบแอคทีฟ-พาสซีฟ จะมีการส่งสัญญาณหัวใจระหว่างเซิร์ฟเวอร์ที่ทำงาน (active) และเซิร์ฟเวอร์สำรอง (passive) ที่อยู่ในโหมด standby หากสัญญาณหัวใจขาดหาย เซิร์ฟเวอร์สำรองจะรับที่อยู่ IP ของเซิร์ฟเวอร์ active และเริ่มให้บริการต่อ

ระยะเวลาการหยุดทำงานขึ้นอยู่กับว่าเซิร์ฟเวอร์สำรองอยู่ในโหมด 'hot' standby หรือจะต้องเริ่มต้นจาก 'cold' standby เซิร์ฟเวอร์ active เท่านั้นที่รับส่งข้อมูล

การสลับแบบแอคทีฟ-พาสซีฟนี้ยังเรียกว่า master-slave failover

#### แอคทีฟ-แอคทีฟ (Active-active)

ในการสลับแบบแอคทีฟ-แอคทีฟ เซิร์ฟเวอร์ทั้งสองจะจัดการทราฟฟิกและแบ่งโหลดร่วมกัน

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

การสลับแบบแอคทีฟ-แอคทีฟนี้ยังเรียกว่า master-master failover

ข้อเสีย: การสลับไปยังตัวสำรอง (failover)

การจำลองข้อมูล

#### แบบ Master-slave และ Master-master

หัวข้อนี้มีการพูดถึงเพิ่มเติมในส่วน ฐานข้อมูล:

ความพร้อมใช้งานในตัวเลข

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

#### ความพร้อมใช้งาน 99.9% - สาม 9

| ระยะเวลา | เวลาหยุดทำงานที่ยอมรับได้ | |---------------------|--------------------| | หยุดทำงานต่อปี | 8ชั่วโมง 45นาที 57วินาที | | หยุดทำงานต่อเดือน | 43นาที 49.7วินาที | | หยุดทำงานต่อสัปดาห์ | 10นาที 4.8วินาที | | หยุดทำงานต่อวัน | 1นาที 26.4วินาที |

#### ความพร้อมใช้งาน 99.99% - สี่ 9

| ระยะเวลา | เวลาหยุดทำงานที่ยอมรับได้ | |---------------------|--------------------| | หยุดทำงานต่อปี | 52นาที 35.7วินาที | | หยุดทำงานต่อเดือน | 4นาที 23วินาที | | หยุดทำงานต่อสัปดาห์ | 1นาที 5วินาที | | หยุดทำงานต่อวัน | 8.6วินาที |

#### ความพร้อมใช้งานแบบขนาน vs แบบเรียงลำดับ

หากบริการประกอบด้วยหลายองค์ประกอบที่มีโอกาสล้มเหลว ความพร้อมใช้งานโดยรวมของบริการขึ้นอยู่กับว่าองค์ประกอบเหล่านั้นอยู่ในลำดับหรือขนานกัน

###### แบบเรียงลำดับ

ความพร้อมใช้งานโดยรวมจะลดลงเมื่อมีสององค์ประกอบที่มีความพร้อมใช้งานน้อยกว่า 100% ต่อเนื่องกัน:

Availability (Total) = Availability (Foo) * Availability (Bar)

หากทั้ง Foo และ Bar มีความพร้อมใช้งานอยู่ที่ 99.9% แต่ละตัว ความพร้อมใช้งานรวมกันในลำดับจะเหลือ 99.8%

###### แบบขนาน

ความพร้อมใช้งานโดยรวมจะเพิ่มขึ้นเมื่อมีสององค์ประกอบที่มีความพร้อมใช้งาน < 100% ทำงานแบบขนานกัน:

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
ถ้าทั้ง Foo และ Bar มีความพร้อมใช้งาน 99.9% แต่ละตัว ความพร้อมใช้งานรวมกันแบบขนานจะเป็น 99.9999%

ระบบชื่อโดเมน


ที่มา: การนำเสนอความปลอดภัยของ DNS

ระบบชื่อโดเมน (DNS) ทำหน้าที่แปลงชื่อโดเมน เช่น www.example.com เป็นที่อยู่ IP

DNS มีลำดับชั้น โดยมีเซิร์ฟเวอร์ที่เชื่อถือได้ไม่กี่ตัวอยู่ระดับบนสุด เราเตอร์หรือ ISP จะให้ข้อมูลเกี่ยวกับเซิร์ฟเวอร์ DNS ที่จะติดต่อเมื่อทำการค้นหา เซิร์ฟเวอร์ DNS ระดับล่างจะเก็บแคชการจับคู่ซึ่งอาจล้าสมัยได้เนื่องจากการเผยแพร่ DNS ที่ล่าช้า ผลลัพธ์ DNS ยังสามารถถูกแคชโดยเบราว์เซอร์หรือระบบปฏิบัติการของคุณในระยะเวลาหนึ่ง โดยกำหนดจาก time to live (TTL)

บริการเช่น CloudFlare และ Route 53 ให้บริการ DNS แบบจัดการ บริการ DNS บางตัวสามารถจัดเส้นทางทราฟฟิกด้วยวิธีต่างๆ:

ข้อเสีย: DNS

แหล่งข้อมูลและอ่านเพิ่มเติม

เครือข่ายการส่งมอบเนื้อหา (Content delivery network)


ที่มา: เหตุผลในการใช้ CDN

เครือข่ายการส่งมอบเนื้อหา (CDN) คือเครือข่ายพร็อกซีเซิร์ฟเวอร์ที่กระจายอยู่ทั่วโลก มีหน้าที่ให้บริการเนื้อหาจากตำแหน่งที่ใกล้กับผู้ใช้มากที่สุด โดยทั่วไปไฟล์แบบสถาติก เช่น HTML/CSS/JS, รูปภาพ และวิดีโอ จะถูกให้บริการผ่าน CDN แม้ว่า CDN บางตัว เช่น CloudFront ของ Amazon จะรองรับเนื้อหาแบบไดนามิกด้วย การแก้ไข DNS ของเว็บไซต์จะบอกลูกค้าว่าควรติดต่อเซิร์ฟเวอร์ใด

การให้บริการเนื้อหาจาก CDN สามารถปรับปรุงประสิทธิภาพได้อย่างมากในสองลักษณะ:

Push CDN

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

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

Pull CDN

Pull CDN จะดึงเนื้อหาใหม่จากเซิร์ฟเวอร์ของคุณเมื่อผู้ใช้คนแรกขอเนื้อหานั้น คุณจะปล่อยให้เนื้อหาอยู่บนเซิร์ฟเวอร์และแก้ไข URL เพื่อชี้ไปที่ CDN ส่งผลให้การร้องขอครั้งแรกช้ากว่าจนกว่าเนื้อหาจะถูกแคชบน CDN

ค่า time-to-live (TTL) จะกำหนดระยะเวลาการแคชเนื้อหา Pull CDN ช่วยลดพื้นที่จัดเก็บบน CDN แต่สามารถเกิดการรับส่งข้อมูลซ้ำซ้อนหากไฟล์หมดอายุก่อนที่เนื้อหาจะมีการเปลี่ยนแปลงจริง

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

ข้อเสีย: CDN

แหล่งข้อมูลและการอ่านเพิ่มเติม

ตัวกระจายโหลด (Load balancer)


ที่มา: รูปแบบการออกแบบระบบที่ปรับขยายได้

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

ตัวกระจายโหลดสามารถติดตั้งเป็นฮาร์ดแวร์ (ราคาแพง) หรือซอฟต์แวร์เช่น HAProxy

ประโยชน์เพิ่มเติม ได้แก่:

เพื่อป้องกันปัญหาความล้มเหลว มักจะมีการตั้งค่าตัวกระจายโหลดหลายตัว ทั้งในโหมด active-passive หรือ active-active

ตัวกระจายโหลดสามารถกำหนดเส้นทางการรับส่งข้อมูลตามตัวชี้วัดต่างๆ ได้แก่:

การกระจายโหลดชั้นที่ 4

ตัวกระจายโหลดชั้นที่ 4 จะพิจารณาข้อมูลใน เลเยอร์ขนส่ง เพื่อใช้ตัดสินใจว่าจะกระจายคำขออย่างไร โดยทั่วไปจะเกี่ยวข้องกับที่อยู่ IP ต้นทางและปลายทาง และพอร์ตในส่วนหัว แต่จะไม่ดูเนื้อหาของแพ็กเก็ต ตัวกระจายโหลดชั้นที่ 4 จะส่งต่อแพ็กเก็ตเครือข่ายไปและกลับจากเซิร์ฟเวอร์ต้นทาง โดยดำเนินการ Network Address Translation (NAT)

การกระจายโหลดชั้นที่ 7

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

ด้วยต้นทุนด้านความยืดหยุ่น การบาลานซ์โหลดเลเยอร์ 4 ต้องการเวลาน้อยกว่าและทรัพยากรคอมพิวเตอร์น้อยกว่าเลเยอร์ 7 แม้ว่าผลกระทบต่อประสิทธิภาพจะน้อยมากในฮาร์ดแวร์ทั่วไปยุคใหม่

การขยายแนวนอน

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

#### ข้อเสีย: การขยายแนวนอน

ข้อเสีย: ตัวบาลานซ์โหลด

แหล่งข้อมูลและอ่านเพิ่มเติม

รีเวิร์สพร็อกซี (เว็บเซิร์ฟเวอร์)


แหล่งที่มา: วิกิพีเดีย

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

ประโยชน์เพิ่มเติมประกอบด้วย:

ตัวโหลดบาลานเซอร์ vs รีเวิร์สพร็อกซี่

ข้อเสีย: รีเวิร์สพร็อกซี่

แหล่งข้อมูลและอ่านเพิ่มเติม

เลเยอร์แอปพลิเคชัน


ที่มา: แนะนำการออกแบบสถาปัตยกรรมระบบสำหรับการขยายขนาด

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

Worker ในชั้นแอปพลิเคชันยังช่วยเปิดใช้งาน การทำงานแบบอะซิงโครนัส ได้อีกด้วย

ไมโครเซอร์วิส

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

ตัวอย่างเช่น Pinterest อาจมีไมโครเซอร์วิสดังนี้: โปรไฟล์ผู้ใช้, ผู้ติดตาม, ฟีด, การค้นหา, อัปโหลดรูปภาพ ฯลฯ

การค้นหาบริการ

ระบบอย่าง Consul, Etcd, และ Zookeeper สามารถช่วยให้บริการค้นหาซึ่งกันและกันโดยติดตามชื่อ, ที่อยู่, และพอร์ตที่ลงทะเบียน Health checks ใช้ตรวจสอบความสมบูรณ์ของบริการและมักดำเนินการโดยใช้ HTTP endpoint ทั้ง Consul และ Etcd มี key-value store ในตัวซึ่งมีประโยชน์สำหรับจัดเก็บค่าคอนฟิกและข้อมูลที่ใช้ร่วมกันอื่น ๆ

ข้อเสีย: ชั้นแอปพลิเคชัน

แหล่งข้อมูลและอ่านเพิ่มเติม

ฐานข้อมูล


ที่มา: การขยายระบบรองรับผู้ใช้ 10 ล้านคนแรก

ระบบจัดการฐานข้อมูลเชิงสัมพันธ์ (RDBMS)

ฐานข้อมูลเชิงสัมพันธ์เช่น SQL คือการรวบรวมรายการข้อมูลที่ถูกจัดระเบียบในรูปแบบตาราง

ACID คือชุดคุณสมบัติของ ธุรกรรม ฐานข้อมูลเชิงสัมพันธ์

มีเทคนิคมากมายในการขยายฐานข้อมูลเชิงสัมพันธ์: การจำลองแบบมาสเตอร์-สเลฟ, การจำลองแบบมาสเตอร์-มาสเตอร์, เฟเดอเรชั่น, ชาร์ดดิง, การลดการทำปกติ, และ การปรับแต่ง SQL

#### การจำลองแบบมาสเตอร์-สเลฟ

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


ที่มา: Scalability, availability, stability, patterns

##### ข้อเสีย: การจำลองแบบมาสเตอร์-สเลฟ

#### การจำลองแบบมาสเตอร์-มาสเตอร์

ทั้งสองมาสเตอร์ให้บริการการอ่านและเขียน และประสานงานกันในการเขียน หากมาสเตอร์ใดมาสเตอร์หนึ่งล่ม ระบบยังคงให้บริการทั้งอ่านและเขียนได้


ที่มา: Scalability, availability, stability, patterns

##### ข้อเสีย: การจำลองแบบมาสเตอร์-มาสเตอร์

##### ข้อเสีย: การทำสำเนา (replication)

##### แหล่งข้อมูลและอ่านเพิ่มเติม: การทำสำเนา (replication)

#### การแบ่งกลุ่ม (Federation)


ที่มา: Scaling up to your first 10 million users

Federation (หรือการแบ่งกลุ่มตามหน้าที่) คือการแยกฐานข้อมูลตามฟังก์ชัน เช่น แทนที่จะใช้ฐานข้อมูลเดียวแบบ monolithic คุณอาจมีฐานข้อมูลสามส่วน: forums, users และ products ส่งผลให้การอ่านและเขียนข้อมูลแต่ละฐานข้อมูลลดลง และลดความล่าช้าในการทำสำเนา ฐานข้อมูลขนาดเล็กทำให้ข้อมูลจำนวนมากถูกเก็บในหน่วยความจำได้มากขึ้น ส่งผลให้ cache hit เพิ่มขึ้นเนื่องจาก locality ของ cache ดีขึ้น เมื่อไม่มี master กลางที่คอย serialize การเขียน คุณสามารถเขียนแบบขนานได้ ส่งผลให้ throughput เพิ่มขึ้น

##### ข้อเสีย: Federation

##### แหล่งข้อมูลและอ่านเพิ่มเติม: Federation

#### การแบ่งส่วนข้อมูล (Sharding)


ที่มา: Scalability, availability, stability, patterns

Sharding คือการกระจายข้อมูลไปยังฐานข้อมูลต่าง ๆ โดยแต่ละฐานข้อมูลจะจัดการข้อมูลเพียงบางส่วนเท่านั้น ตัวอย่างเช่นฐานข้อมูลผู้ใช้ เมื่อจำนวนผู้ใช้เพิ่มขึ้น ก็จะมีการเพิ่ม shard ในคลัสเตอร์

เช่นเดียวกับข้อดีของ federation การ sharding จะช่วยลดปริมาณการอ่านและเขียน ลดการทำซ้ำข้อมูล และเพิ่มโอกาสในการ cache hit ขนาดของดัชนีก็ลดลง ซึ่งโดยทั่วไปจะช่วยให้ประสิทธิภาพดีขึ้นด้วยการ query ที่เร็วขึ้น หาก shard ใดล่ม shard อื่น ๆ ยังสามารถทำงานได้ตามปกติ แม้ว่าคุณจะต้องเพิ่มการทำ replication เพื่อป้องกันการสูญหายของข้อมูลก็ตาม เช่นเดียวกับ federation ไม่มี master กลางที่เป็นศูนย์กลางในการ serialize การเขียน ทำให้สามารถเขียนข้อมูลแบบขนานและ throughput เพิ่มขึ้น

วิธีการ sharding ฐานข้อมูลผู้ใช้ที่พบบ่อย คือการใช้ตัวอักษรแรกของนามสกุลผู้ใช้ หรือใช้ตำแหน่งทางภูมิศาสตร์ของผู้ใช้

##### ข้อเสีย: sharding

##### แหล่งที่มาและอ่านเพิ่มเติม: sharding

#### Denormalization

Denormalization คือการปรับปรุงประสิทธิภาพการอ่านโดยแลกกับประสิทธิภาพการเขียนในบางกรณี โดยเขียนข้อมูลสำรองซ้ำในหลายตารางเพื่อลดความจำเป็นในการ join ที่มีต้นทุนสูง RDBMS บางตัวเช่น PostgreSQL และ Oracle รองรับ materialized views ที่ช่วยจัดการข้อมูลสำรองและทำให้ข้อมูลคัดลอกซ้ำกันมีความสอดคล้องกัน

เมื่อข้อมูลถูกกระจายด้วยเทคนิคอย่าง federation และ sharding การจัดการ join ข้าม data center จะมีความซับซ้อนมากขึ้น การ denormalization อาจช่วยหลีกเลี่ยงความจำเป็นในการ join ที่ซับซ้อนเหล่านี้

ในระบบส่วนใหญ่ การอ่านมักจะมากกว่าการเขียน 100:1 หรือถึง 1000:1 การอ่านที่ต้อง join ฐานข้อมูลซับซ้อนอาจมีต้นทุนสูงมาก ใช้เวลาทำงานกับดิสก์นาน

##### ข้อเสีย: denormalization

###### แหล่งที่มาและอ่านเพิ่มเติม: denormalization

#### การปรับแต่ง SQL

การปรับแต่ง SQL เป็นหัวข้อที่กว้างและมี หนังสือ จำนวนมากที่เขียนไว้เป็นข้อมูลอ้างอิง

สิ่งสำคัญคือการ ทดสอบสมรรถนะ และ วิเคราะห์ประสิทธิภาพ เพื่อจำลองและค้นหาคอขวด

การทดสอบและวิเคราะห์ประสิทธิภาพอาจชี้ให้เห็นถึงการปรับแต่งดังต่อไปนี้

##### ปรับแต่ง schema ให้เหมาะสม

##### ใช้อินเด็กซ์ที่ดี

##### หลีกเลี่ยงการ join ที่สิ้นเปลือง

##### แบ่งตารางออกเป็นส่วน ๆ

##### ปรับแต่งแคชคำสั่งค้นหา (query cache)

##### แหล่งข้อมูลและอ่านเพิ่มเติม: การปรับแต่ง SQL

NoSQL

NoSQL คือการจัดเก็บข้อมูลในรูปแบบ key-value store, document store, wide column store หรือ graph database ข้อมูลจะถูกทำให้ไม่เป็นปกติ (denormalized) และโดยทั่วไปการ join จะทำในโค้ดแอปพลิเคชัน ฐานข้อมูล NoSQL ส่วนมากจะไม่มีธุรกรรม ACID ที่แท้จริงและเน้นที่ eventual consistency

BASE มักถูกใช้เพื่ออธิบายคุณสมบัติของฐานข้อมูล NoSQL เมื่อเปรียบเทียบกับ ทฤษฎี CAP ฐานข้อมูล BASE เลือกความพร้อมใช้งานมากกว่าความถูกต้อง

นอกจากเลือก SQL หรือ NoSQL การเข้าใจประเภทฐานข้อมูล NoSQL ที่เหมาะกับการใช้งานก็เป็นประโยชน์ เราจะพูดถึง key-value stores, document stores, wide column stores และ graph databases ในหัวข้อถัดไป

#### Key-value store

นามธรรม: hash table

Key-value store โดยทั่วไปจะรองรับการอ่านและเขียนแบบ O(1) และมักจัดเก็บข้อมูลในหน่วยความจำหรือ SSD ฐานข้อมูลแบบนี้สามารถจัดเรียงคีย์ตาม ลำดับตัวอักษร เพื่อให้ดึงข้อมูลช่วงคีย์ได้อย่างมีประสิทธิภาพ Key-value store สามารถจัดเก็บข้อมูลเมตากับค่าได้

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

Key-value store เป็นพื้นฐานของระบบที่ซับซ้อนกว่า เช่น document store และในบางกรณีคือ graph database

##### แหล่งข้อมูลและอ่านเพิ่มเติม: key-value store

#### Document store

นามธรรม: คีย์-แวลูสโตร์ที่จัดเก็บเอกสารเป็นค่า

Document store จะเน้นที่เอกสาร (XML, JSON, ไบนารี ฯลฯ) ซึ่งเอกสารจะเก็บข้อมูลทั้งหมดสำหรับอ็อบเจกต์หนึ่ง ๆ Document store จะมี API หรือภาษาคิวรีสำหรับการค้นหาตามโครงสร้างภายในของเอกสารเอง หมายเหตุ หลาย key-value store มีฟีเจอร์ในการทำงานกับ metadata ของค่า ทำให้เส้นแบ่งระหว่าง storage ทั้งสองประเภทนี้ไม่ชัดเจน

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

Document store บางตัวเช่น MongoDB และ CouchDB มีภาษาคิวรีที่คล้าย SQL สำหรับคิวรีที่ซับซ้อน DynamoDB รองรับทั้งคีย์-แวลูและเอกสาร

Document store มีความยืดหยุ่นสูงและมักใช้กับข้อมูลที่เปลี่ยนแปลงเป็นครั้งคราว

##### แหล่งข้อมูลและอ่านเพิ่มเติม: document store

#### Wide column store


ที่มา: SQL & NoSQL, ประวัติย่อ

นามธรรม: แมพซ้อน ColumnFamily>

Wide column store มีหน่วยข้อมูลพื้นฐานเป็น column (คู่ชื่อ/ค่า) column สามารถจัดกลุ่มใน column families (คล้ายกับตาราง SQL) super column families จะกลุ่ม column families เพิ่มขึ้น คุณสามารถเข้าถึงแต่ละ column โดยใช้ row key และ column ที่มี row key เดียวกันจะรวมกันเป็นแถว แต่ละค่าสามารถมี timestamp สำหรับการจัดเวอร์ชันและแก้ไขข้อขัดแย้ง

Google ได้เปิดตัว Bigtable เป็น wide column store ตัวแรก ซึ่งมีอิทธิพลต่อ HBase ที่ใช้ในระบบ Hadoop และ Cassandra จาก Facebook สโตร์อย่าง BigTable, HBase และ Cassandra จะจัดคีย์ตามลำดับพจนานุกรม ทำให้สามารถดึงข้อมูลช่วงคีย์ที่ต้องการได้อย่างมีประสิทธิภาพ

Wide column store มีความพร้อมใช้งานสูงและขยายขนาดได้ดี มักใช้กับชุดข้อมูลขนาดใหญ่มาก

##### แหล่งข้อมูลและอ่านเพิ่มเติม: wide column store

#### ฐานข้อมูลแบบกราฟ


ที่มา: ฐานข้อมูลแบบกราฟ

นามธรรม: กราฟ

ในฐานข้อมูลแบบกราฟ แต่ละโหนดคือเรคคอร์ดและแต่ละเส้นเชื่อมคือความสัมพันธ์ระหว่างสองโหนด ฐานข้อมูลกราฟถูกปรับแต่งเพื่อแสดงความสัมพันธ์ที่ซับซ้อน เช่น มีคีย์ต่างประเทศจำนวนมากหรือความสัมพันธ์แบบ many-to-many

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

##### แหล่งข้อมูลและอ่านเพิ่มเติม: กราฟ

#### แหล่งข้อมูลและอ่านเพิ่มเติม: NoSQL

SQL หรือ NoSQL


ที่มา: การเปลี่ยนผ่านจาก RDBMS ไป NoSQL

เหตุผลสำหรับ SQL:

เหตุผลสำหรับ NoSQL:

ตัวอย่างข้อมูลที่เหมาะกับ NoSQL:

##### แหล่งที่มาและอ่านเพิ่มเติม: SQL หรือ NoSQL

แคช


ที่มา: รูปแบบการออกแบบระบบที่ขยายขนาดได้

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

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

การแคชฝั่งลูกข่าย

แคชสามารถอยู่ฝั่งลูกข่าย (OS หรือเบราว์เซอร์), ฝั่งเซิร์ฟเวอร์ หรืออยู่ในชั้นแคชโดยเฉพาะ

การแคช CDN

CDN ถือว่าเป็นประเภทหนึ่งของแคช

การแคชเว็บเซิร์ฟเวอร์

Reverse proxy และแคชอย่างเช่น Varnish สามารถให้บริการคอนเทนต์แบบสถิตและไดนามิกโดยตรง เว็บเซิร์ฟเวอร์ยังสามารถแคชคำร้องขอและคืนผลลัพธ์โดยไม่ต้องติดต่อกับแอปพลิเคชันเซิร์ฟเวอร์

การแคชฐานข้อมูล

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

การแคชแอปพลิเคชัน

แคชในหน่วยความจำเช่น Memcached และ Redis เป็น key-value store ที่อยู่ระหว่างแอปพลิเคชันของคุณกับที่เก็บข้อมูล เนื่องจากข้อมูลอยู่ใน RAM จึงเร็วกว่าฐานข้อมูลทั่วไปที่ข้อมูลอยู่บนดิสก์ RAM มีข้อจำกัดมากกว่าดิสก์ ดังนั้น อัลกอริทึมการลบแคช เช่น least recently used (LRU)) จะช่วยลบข้อมูลที่ไม่ได้ใช้งานและเก็บข้อมูลที่ถูกใช้งานบ่อยไว้ใน RAM

Redis มีคุณสมบัติเพิ่มเติมดังนี้:

มีหลายระดับที่คุณสามารถทำการแคช ซึ่งแบ่งออกเป็นสองประเภทหลัก: คำสั่งฐานข้อมูล และ อ็อบเจกต์:

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

การแคชในระดับการคิวรีฐานข้อมูล

เมื่อใดก็ตามที่คุณคิวรีฐานข้อมูล ให้แฮชคิวรีเป็นคีย์และเก็บผลลัพธ์ไว้ในแคช วิธีนี้มีปัญหาเกี่ยวกับการหมดอายุ:

การแคชในระดับอ็อบเจกต์

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

ข้อเสนอแนะเกี่ยวกับสิ่งที่ควรแคช:

เมื่อใดควรอัปเดตแคช

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

#### Cache-aside


ที่มา: From cache to in-memory data grid

แอปพลิเคชันรับผิดชอบในการอ่านและเขียนข้อมูลจากสตอเรจ แคชจะไม่ติดต่อกับสตอเรจโดยตรง แอปพลิเคชันจะดำเนินการดังนี้:

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user

Memcached มักจะถูกใช้งานในลักษณะนี้

การอ่านข้อมูลซ้ำที่ถูกเพิ่มเข้าไปในแคชจะมีความรวดเร็ว Cache-aside หรือที่เรียกอีกชื่อว่า lazy loading จะมีการแคชเฉพาะข้อมูลที่ถูกเรียกใช้งาน ซึ่งช่วยหลีกเลี่ยงการเติมข้อมูลที่ไม่ถูกเรียกใช้เข้าไปในแคช

##### ข้อเสีย: cache-aside

#### Write-through


ที่มา: Scalability, availability, stability, patterns

แอปพลิเคชันจะใช้แคชเป็นแหล่งจัดเก็บข้อมูลหลัก โดยอ่านและเขียนข้อมูลกับแคช ในขณะที่แคชรับผิดชอบการอ่านและเขียนกับฐานข้อมูล:

โค้ดแอปพลิเคชัน:

set_user(12345, {"foo":"bar"})

โค้ดแคช:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)
การเขียนแบบ Write-through เป็นการดำเนินการที่ช้ากว่าโดยรวมเนื่องจากต้องมีการเขียนข้อมูล แต่การอ่านข้อมูลที่พึ่งเขียนล่าสุดจะเร็วมาก โดยทั่วไปผู้ใช้จะยอมรับความล่าช้าได้มากกว่าเมื่ออัปเดตข้อมูลมากกว่าการอ่านข้อมูล ข้อมูลในแคชจะไม่ล้าสมัย

##### ข้อเสีย: write through

#### Write-behind (write-back)


ที่มา: Scalability, availability, stability, patterns

ในการเขียนแบบ Write-behind แอปพลิเคชันจะดำเนินการดังนี้:

##### ข้อเสีย: write-behind

#### Refresh-ahead


ที่มา: From cache to in-memory data grid

คุณสามารถกำหนดค่าแคชให้รีเฟรชรายการที่เข้าถึงล่าสุดโดยอัตโนมัติก่อนหมดอายุ

Refresh-ahead สามารถลด latency ได้มากกว่า read-through หากแคชสามารถทำนายได้อย่างแม่นยำว่ารายการใดจะถูกใช้งานในอนาคต

##### ข้อเสีย: refresh-ahead

ข้อเสีย: แคช

แหล่งข้อมูลและการอ่านเพิ่มเติม

ความไม่ประสานกัน (Asynchronism)


ที่มา: Intro to architecting systems for scale

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

คิวข้อความ (Message queues)

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

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

Redis มีประโยชน์ในฐานะ message broker ที่เรียบง่ายแต่ข้อความอาจสูญหายได้

RabbitMQ เป็นที่นิยมแต่คุณต้องปรับตัวเข้ากับโปรโตคอล 'AMQP' และจัดการโหนดของคุณเอง Amazon SQS เป็นบริการที่โฮสต์อยู่แต่สามารถมีความหน่วงสูงและมีโอกาสที่ข้อความจะถูกส่งซ้ำสองครั้ง

คิวงาน (Task queues)

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

Celery รองรับการตั้งเวลาและสนับสนุนภาษา python เป็นหลัก

Back pressure

หากคิวเริ่มมีขนาดใหญ่ขึ้นอย่างมาก ขนาดของคิวอาจใหญ่กว่าหน่วยความจำ ส่งผลให้เกิดการพลาดแคช, อ่านข้อมูลจากดิสก์, และประสิทธิภาพที่ช้าลง Back pressure สามารถช่วยโดยการจำกัดขนาดของคิว, ซึ่งจะช่วยรักษาอัตราผ่านงานสูงและเวลาในการตอบสนองที่ดีสำหรับงานที่อยู่ในคิว เมื่อคิวเต็มแล้ว ลูกค้าจะได้รับสถานะเซิร์ฟเวอร์ไม่ว่างหรือ HTTP 503 ให้ลองใหม่ในภายหลัง ลูกค้าสามารถลองส่งคำขอใหม่อีกครั้งในภายหลัง, อาจใช้วิธี exponential backoff

ข้อเสีย: ความไม่ซิงโครนัส (asynchronism)

แหล่งข้อมูลและอ่านเพิ่มเติม

การสื่อสาร (Communication)


ที่มา: โมเดล OSI 7 ชั้น

โปรโตคอลการรับส่งข้อมูลแบบไฮเปอร์เท็กซ์ (HTTP)

HTTP เป็นวิธีสำหรับเข้ารหัสและขนส่งข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ เป็นโปรโตคอลแบบ request/response: ไคลเอนต์จะส่งคำขอและเซิร์ฟเวอร์จะตอบกลับด้วยเนื้อหาที่เกี่ยวข้องและข้อมูลสถานะการดำเนินการของคำขอ HTTP เป็นระบบปิดในตัวเอง ช่วยให้คำขอและการตอบกลับไหลผ่านตัวกลางหลายตัว เช่น ตัวกระจายโหลด, แคช, การเข้ารหัส, และการบีบอัดข้อมูล

คำขอ HTTP พื้นฐานจะประกอบด้วยคำกริยา (method) และทรัพยากร (endpoint) ด้านล่างคือตัวอย่างคำกริยา HTTP ที่ใช้บ่อย:

| Verb | คำอธิบาย | Idempotent* | Safe | Cacheable |

| GET | อ่านทรัพยากร | ใช่ | ใช่ | ใช่ | | POST | สร้างทรัพยากรหรือกระตุ้นกระบวนการที่จัดการข้อมูล | ไม่ | ไม่ | ใช่ถ้าการตอบกลับมีข้อมูลความสดใหม่ | | PUT | สร้างหรือแทนที่ทรัพยากร | ใช่ | ไม่ | ไม่ | | PATCH | อัปเดตทรัพยากรบางส่วน | ไม่ | ไม่ | ใช่ถ้าการตอบกลับมีข้อมูลความสดใหม่ | | DELETE | ลบทรัพยากร | ใช่ | ไม่ | ไม่ |

*สามารถเรียกซ้ำหลายครั้งโดยไม่มีผลลัพธ์ที่ต่างกัน

HTTP เป็นโปรโตคอลชั้นแอปพลิเคชันที่อาศัยโปรโตคอลระดับล่างเช่น TCP และ UDP.

#### แหล่งข้อมูลและอ่านเพิ่มเติม: HTTP

โปรโตคอลควบคุมการส่งข้อมูล (TCP)


ที่มา: วิธีสร้างเกมผู้เล่นหลายคน

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

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

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

TCP เหมาะสำหรับแอปพลิเคชันที่ต้องการความน่าเชื่อถือสูงแต่ไม่เร่งด่วนด้านเวลา ตัวอย่างเช่น เซิร์ฟเวอร์เว็บ ข้อมูลฐานข้อมูล SMTP FTP และ SSH

ใช้ TCP แทน UDP เมื่อ:

โปรโตคอล User datagram (UDP)


ที่มา: วิธีสร้างเกมผู้เล่นหลายคน

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

UDP สามารถกระจายข้อมูล (broadcast) ส่ง datagram ไปยังทุกอุปกรณ์ในเครือข่ายย่อย ซึ่งมีประโยชน์กับ DHCP เพราะไคลเอนต์ยังไม่ได้รับที่อยู่ IP ทำให้ไม่สามารถใช้ TCP สตรีมข้อมูลโดยไม่มี IP address ได้

UDP มีความน่าเชื่อถือน้อยกว่าแต่ทำงานได้ดีในกรณีใช้งานแบบเรียลไทม์ เช่น VoIP, วิดีโอแชท, สตรีมมิ่ง และเกมผู้เล่นหลายคนแบบเรียลไทม์

ใช้ UDP แทน TCP เมื่อ:

#### ที่มาและอ่านเพิ่มเติม: TCP และ UDP

การเรียกใช้ฟังก์ชันระยะไกล (RPC)


ที่มา: Crack the system design interview

ในการเรียกใช้ RPC ไคลเอนต์จะสั่งให้ฟังก์ชันทำงานใน address space อื่น โดยปกติจะเป็นเซิร์ฟเวอร์ระยะไกล ฟังก์ชันจะถูกเขียนเหมือนเป็นการเรียกใช้ฟังก์ชันในเครื่อง โดยซ่อนรายละเอียดการสื่อสารกับเซิร์ฟเวอร์จากโปรแกรมไคลเอนต์ การเรียกใช้ระยะไกลจะช้ากว่าและเชื่อถือน้อยกว่าการเรียกใช้ในเครื่อง จึงควรแยกความแตกต่างระหว่าง RPC กับการเรียกใช้ในเครื่อง Framework RPC ที่นิยม ได้แก่ Protobuf, Thrift, และ Avro

RPC เป็นโปรโตคอลแบบ request-response:

ตัวอย่างการเรียกใช้ RPC:

GET /someoperation?data=anId
POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}
RPC มุ่งเน้นไปที่การเปิดเผยพฤติกรรม RPC มักถูกใช้ด้วยเหตุผลด้านประสิทธิภาพในการสื่อสารภายใน เนื่องจากสามารถสร้าง native calls ที่เหมาะสมกับกรณีการใช้งานของคุณได้

เลือกใช้ native library (หรือ SDK) เมื่อ:

HTTP APIs ที่ใช้ REST มักถูกใช้บ่อยกว่าสำหรับ Public APIs

#### ข้อเสีย: RPC

Representational state transfer (REST)

REST เป็นรูปแบบสถาปัตยกรรมที่บังคับใช้โมเดล client/server โดยที่ client ทำงานกับชุดของ resource ที่ถูกจัดการโดย server server จะให้การแสดงผลของ resource และการกระทำที่สามารถเปลี่ยนแปลงหรือรับการแสดงผลใหม่ของ resource ได้ การสื่อสารทั้งหมดต้องเป็นแบบไร้สถานะและสามารถแคชได้

RESTful interface มีคุณสมบัติ 4 ประการ:

ตัวอย่าง REST calls:

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
REST มุ่งเน้นไปที่การเปิดเผยข้อมูล โดยลดความเชื่อมโยงระหว่าง client/server และมักใช้สำหรับ HTTP API สาธารณะ REST ใช้วิธีที่เป็นกลางและสม่ำเสมอในการเปิดเผย resource ผ่าน URI, การแสดงผลผ่าน header, และการกระทำผ่าน verb เช่น GET, POST, PUT, DELETE และ PATCH ด้วยความเป็น stateless REST จึงเหมาะสำหรับการขยายระบบในแนวนอนและการแบ่งส่วน

#### ข้อเสีย: REST

การเปรียบเทียบ RPC และ REST

| Operation | RPC | REST | |---|---|---| | สมัครสมาชิก | POST /signup | POST /persons | | ลาออก | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | อ่านข้อมูลบุคคล | GET /readPerson?personid=1234 | GET /persons/1234 | | อ่านรายการสิ่งของของบุคคล | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | เพิ่มสิ่งของให้บุคคล | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | อัปเดตสิ่งของ | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | ลบสิ่งของ | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

ที่มา: คุณรู้จริงหรือไม่ว่าทำไมคุณถึงชอบ REST มากกว่า RPC

#### แหล่งข้อมูลและอ่านเพิ่มเติม: REST และ RPC

ความปลอดภัย

ส่วนนี้อาจต้องการการอัปเดต กรุณา ร่วมแก้ไข!

ความปลอดภัยเป็นหัวข้อที่กว้างใหญ่ หากคุณไม่มีประสบการณ์มาก หรือไม่มีพื้นฐานด้านความปลอดภัย หรือไม่ได้สมัครงานที่ต้องการความรู้ด้านความปลอดภัย คุณอาจไม่จำเป็นต้องรู้มากไปกว่าข้อมูลพื้นฐาน:

แหล่งข้อมูลและบทความเพิ่มเติม

ภาคผนวก

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

ตารางกำลังสอง

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

#### แหล่งข้อมูลและอ่านเพิ่มเติม

ตัวเลขค่า Latency ที่โปรแกรมเมอร์ทุกคนควรรู้

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD     30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

ข้อมูลเมตริกที่เป็นประโยชน์จากตัวเลขข้างต้น:

#### ตัวเลขความหน่วงแสดงภาพ

#### แหล่งข้อมูลและอ่านเพิ่มเติม

คำถามสัมภาษณ์ออกแบบระบบเพิ่มเติม

คำถามสัมภาษณ์ออกแบบระบบที่พบบ่อย พร้อมลิงก์แหล่งข้อมูลวิธีแก้แต่ละข้อ

| คำถาม | แหล่งอ้างอิง | |---|---| | ออกแบบบริการซิงค์ไฟล์แบบ Dropbox | youtube.com | | ออกแบบเครื่องมือค้นหาเช่น Google | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | ออกแบบเว็บครอเลอร์ที่ปรับขนาดได้เช่น Google | quora.com | | ออกแบบ Google docs | code.google.com
neil.fraser.name | | ออกแบบระบบ key-value store เช่น Redis | slideshare.net | | ออกแบบระบบแคชเช่น Memcached | slideshare.net | | ออกแบบระบบแนะนำสินค้าแบบ Amazon | hulu.com
ijcai13.org | | ออกแบบระบบ tinyurl เช่น Bitly | n00tc0d3r.blogspot.com | | ออกแบบแอพแชทเช่น WhatsApp | highscalability.com | ออกแบบระบบแชร์รูปภาพเช่น Instagram | highscalability.com
highscalability.com | | ออกแบบฟังก์ชันฟีดข่าว Facebook | quora.com
quora.com
slideshare.net | | ออกแบบฟังก์ชันไทม์ไลน์ Facebook | facebook.com
highscalability.com | | ออกแบบฟังก์ชันแชท Facebook | erlang-factory.com
facebook.com | | ออกแบบฟังก์ชันค้นหาแบบกราฟเหมือน Facebook | facebook.com
facebook.com
facebook.com | | ออกแบบระบบ Content Delivery Network เหมือน CloudFlare | figshare.com | | ออกแบบระบบหัวข้อยอดนิยมเหมือน Twitter | michael-noll.com
snikolov .wordpress.com | | ออกแบบระบบสร้างรหัสสุ่ม | blog.twitter.com
github.com | | ส่งคืนคำขอสูงสุด k ในช่วงเวลาหนึ่ง | cs.ucsb.edu
wpi.edu | | ออกแบบระบบให้บริการข้อมูลจากหลายดาต้าเซ็นเตอร์ | highscalability.com | | ออกแบบเกมไพ่ผู้เล่นหลายคนออนไลน์ | indieflashblog.com
buildnewgames.com | | ออกแบบระบบจัดการขยะ (Garbage Collection) | stuffwithstuff.com
washington.edu | | ออกแบบ API rate limiter | https://stripe.com/blog/ | | ออกแบบตลาดหลักทรัพย์ (เช่น NASDAQ หรือ Binance) | Jane Street
Golang Implementation
Go Implementation | | เพิ่มคำถามออกแบบระบบ | ร่วมสมทบ |

สถาปัตยกรรมในโลกจริง

บทความเกี่ยวกับการออกแบบระบบในโลกจริง


ที่มา: Twitter timelines at scale

ไม่ต้องเน้นรายละเอียดปลีกย่อยสำหรับบทความเหล่านี้ แต่ให้:

|ประเภท | ระบบ | แหล่งข้อมูล | |---|---|---| | ประมวลผลข้อมูล | MapReduce - การประมวลผลข้อมูลแบบกระจายจาก Google | research.google.com | | ประมวลผลข้อมูล | Spark - การประมวลผลข้อมูลแบบกระจายจาก Databricks | slideshare.net | | ประมวลผลข้อมูล | Storm - การประมวลผลข้อมูลแบบกระจายจาก Twitter | slideshare.net | | | | | | ที่เก็บข้อมูล | Bigtable - ฐานข้อมูลแบบ column-oriented กระจายจาก Google | harvard.edu | | ที่เก็บข้อมูล | HBase - การนำ Bigtable มาใช้แบบโอเพนซอร์ส | slideshare.net | | ที่เก็บข้อมูล | Cassandra - ฐานข้อมูลแบบ column-oriented กระจายจาก Facebook | slideshare.net | ที่เก็บข้อมูล | DynamoDB - ฐานข้อมูลแบบ document-oriented จาก Amazon | harvard.edu | | ที่เก็บข้อมูล | MongoDB - ฐานข้อมูลแบบ document-oriented | slideshare.net | | ที่เก็บข้อมูล | Spanner - ฐานข้อมูลกระจายทั่วโลกจาก Google | research.google.com | | ที่เก็บข้อมูล | Memcached - ระบบแคชหน่วยความจำแบบกระจาย | slideshare.net | | ที่เก็บข้อมูล | Redis - ระบบแคชหน่วยความจำแบบกระจายที่มีการคงอยู่และประเภทค่า | slideshare.net | | | | | | ระบบไฟล์ | Google File System (GFS) - ระบบไฟล์แบบกระจาย | research.google.com | | ระบบไฟล์ | Hadoop File System (HDFS) - การนำ GFS มาใช้แบบโอเพนซอร์ส | apache.org | | | | | | เบ็ดเตล็ด | Chubby - บริการล็อกสำหรับระบบกระจายจาก Google | research.google.com | | เบ็ดเตล็ด | Dapper - โครงสร้างพื้นฐานสำหรับติดตามระบบกระจาย | research.google.com | เบ็ดเตล็ด | Kafka - คิวข้อความ pub/sub จาก LinkedIn | slideshare.net | | เบ็ดเตล็ด | Zookeeper - โครงสร้างพื้นฐานแบบศูนย์กลางสำหรับการซิงโครไนซ์ | slideshare.net | | | เพิ่มสถาปัตยกรรม | ร่วมสมทบ |

สถาปัตยกรรมของบริษัท

| บริษัท | แหล่งอ้างอิง | |---|---| | Amazon | สถาปัตยกรรม Amazon | | Cinchcast | การผลิตไฟล์เสียง 1,500 ชั่วโมงต่อวัน | | DataSift | การทำเหมืองข้อมูลแบบเรียลไทม์ที่ 120,000 ทวีตต่อวินาที | | Dropbox | วิธีที่ Dropbox ขยายตัว | | ESPN | การดำเนินงานที่ 100,000 duh nuh nuhs ต่อวินาที | | Google | สถาปัตยกรรม Google | | Instagram | 14 ล้านผู้ใช้, เทราไบต์ของรูปภาพ
สิ่งที่ขับเคลื่อน Instagram | | Justin.tv | สถาปัตยกรรมถ่ายทอดสดของ Justin.tv | | Facebook | การขยาย memcached ที่ Facebook
TAO: ที่เก็บข้อมูลแบบกระจายสำหรับ social graph ของ Facebook
การจัดเก็บรูปภาพของ Facebook
วิธีที่ Facebook ถ่ายทอดสดไปยัง 800,000 ผู้ชมพร้อมกัน | | Flickr | สถาปัตยกรรม Flickr | | Mailbox | จาก 0 ถึงหนึ่งล้านผู้ใช้ใน 6 สัปดาห์ | | Netflix | มุมมอง 360 องศาต่อสแต็กทั้งหมดของ Netflix
Netflix: เกิดอะไรขึ้นเมื่อคุณกดเล่น? | | Pinterest | จาก 0 ถึงหลายสิบพันล้าน page views ต่อเดือน
18 ล้านผู้เข้าชม, เติบโต 10 เท่า, พนักงาน 12 คน | | Playfish | 50 ล้านผู้ใช้ต่อเดือนและยังคงเพิ่มขึ้น | | PlentyOfFish | สถาปัตยกรรม PlentyOfFish | | Salesforce | วิธีจัดการธุรกรรม 1.3 พันล้านรายการต่อวัน | | Stack Overflow | สถาปัตยกรรม Stack Overflow | | TripAdvisor | 40 ล้านผู้เข้าชม, 200 ล้าน page views แบบไดนามิก, ข้อมูล 30TB | | Tumblr | 15 พันล้าน page views ต่อเดือน | | Twitter | ทำให้ Twitter เร็วขึ้น 10000 เปอร์เซ็นต์
การจัดเก็บ 250 ล้านทวีตต่อวันด้วย MySQL
150 ล้านผู้ใช้, 300K QPS, ข้อมูล 22 MB/S
ไทม์ไลน์ที่ขยายได้
ข้อมูลใหญ่และเล็กที่ Twitter
การดำเนินงานที่ Twitter: ขยายเกิน 100 ล้านผู้ใช้
Twitter รับมือกับ 3,000 รูปภาพต่อวินาทีอย่างไร | | Uber | Uber ขยายแพลตฟอร์มตลาดแบบเรียลไทม์อย่างไร
บทเรียนจากการขยาย Uber ไปยัง 2000 วิศวกร, 1000 บริการ, และ 8000 Git repositories | | WhatsApp | สถาปัตยกรรม WhatsApp ที่ Facebook ซื้อไปในราคา 19 พันล้านเหรียญ | | YouTube | การปรับขนาดของ YouTube
สถาปัตยกรรม YouTube |

บล็อกวิศวกรรมของบริษัท

สถาปัตยกรรมสำหรับบริษัทที่คุณกำลังสัมภาษณ์งานด้วย
>
คำถามที่คุณพบอาจมาจากโดเมนเดียวกัน

#### แหล่งข้อมูลและอ่านเพิ่มเติม

กำลังมองหาบล็อกที่จะเพิ่ม? เพื่อหลีกเลี่ยงการทำงานซ้ำ โปรดพิจารณาเพิ่มบล็อกบริษัทของคุณลงใน repo ต่อไปนี้:

กำลังอยู่ระหว่างการพัฒนา

สนใจจะเพิ่มหัวข้อหรือช่วยเติมเต็มส่วนที่กำลังดำเนินการอยู่หรือไม่? ร่วมสมทบ!

เครดิต

เครดิตและแหล่งข้อมูลมีให้ตลอดทั้ง repo นี้

ขอขอบคุณเป็นพิเศษแก่:

ข้อมูลติดต่อ

สามารถติดต่อฉันได้หากต้องการพูดคุยเกี่ยวกับปัญหา คำถาม หรือข้อเสนอแนะใด ๆ

ข้อมูลการติดต่อของฉันสามารถพบได้ที่ GitHub page

ใบอนุญาต

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

Copyright 2017 Donne Martin

ใบอนุญาต Creative Commons Attribution 4.0 International (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

--- Tranlated By Open Ai Tx | Last indexed: 2025-08-09 ---

Original README: View on GitHub

Translated by OpenAiTx | Last updated: 2025-09-16