Web Analytics

system-design-primer

⭐ 318813 stars Vietnamese by donnemartin

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

Hãy dịch hướng dẫn này!

Hướng Dẫn Thiết Kế Hệ Thống


Động lực

Học cách thiết kế các hệ thống quy mô lớn.
>
Chuẩn bị cho phỏng vấn thiết kế hệ thống.

Học cách thiết kế hệ thống quy mô lớn

Học cách thiết kế các hệ thống có khả năng mở rộng sẽ giúp bạn trở thành một kỹ sư giỏi hơn.

Thiết kế hệ thống là một chủ đề rộng. Có rất nhiều tài nguyên phân tán trên web về các nguyên tắc thiết kế hệ thống.

Kho lưu trữ này là một bộ sưu tập tổ chức các tài nguyên để giúp bạn học cách xây dựng hệ thống ở quy mô lớn.

Học hỏi từ cộng đồng mã nguồn mở

Đây là một dự án mã nguồn mở, được cập nhật liên tục.

Đóng góp luôn được hoan nghênh!

Chuẩn bị cho phỏng vấn thiết kế hệ thống

Bên cạnh các cuộc phỏng vấn lập trình, thiết kế hệ thống là một thành phần bắt buộc trong quy trình phỏng vấn kỹ thuật tại nhiều công ty công nghệ.

Thực hành các câu hỏi phỏng vấn thiết kế hệ thống phổ biến và so sánh kết quả của bạn với các giải pháp mẫu: thảo luận, mã nguồn và sơ đồ.

Các chủ đề bổ sung để chuẩn bị phỏng vấn:

Thẻ ghi nhớ Anki


Bộ thẻ ghi nhớ Anki được cung cấp sử dụng phương pháp lặp lại ngắt quãng giúp bạn ghi nhớ các khái niệm thiết kế hệ thống quan trọng.

Rất tiện lợi khi sử dụng lúc di chuyển.

Tài nguyên lập trình: Thử thách Lập trình Tương tác

Bạn đang tìm kiếm tài nguyên để luyện tập cho Phỏng vấn Lập trình?


Hãy xem kho lưu trữ chị em Thử thách Lập trình Tương tác, trong đó có thêm một bộ thẻ Anki:

Đóng góp

Học hỏi từ cộng đồng.

Bạn hoàn toàn có thể gửi pull request để giúp:

Nội dung cần hoàn thiện thêm được đặt đang phát triển.

Xem lại Hướng dẫn đóng góp.

Mục lục các chủ đề thiết kế hệ thống

Tóm tắt các chủ đề thiết kế hệ thống khác nhau, bao gồm ưu và nhược điểm. Mọi thứ đều là sự đánh đổi.
>
Mỗi mục đều có liên kết đến các tài liệu chuyên sâu hơn.


Hướng dẫn học tập

Các chủ đề gợi ý để ôn tập dựa trên thời gian phỏng vấn của bạn (ngắn, trung bình, dài).

Imgur

Q: Để phỏng vấn, tôi có cần biết tất cả mọi thứ ở đây không?

A: Không, bạn không cần phải biết tất cả mọi thứ ở đây để chuẩn bị cho buổi phỏng vấn.

Những gì bạn được hỏi trong buổi phỏng vấn phụ thuộc vào các biến số như:

Các ứng viên có kinh nghiệm thường được kỳ vọng biết nhiều hơn về thiết kế hệ thống. Kiến trúc sư hoặc trưởng nhóm có thể được yêu cầu biết nhiều hơn các thành viên cá nhân. Các công ty công nghệ hàng đầu thường có một hoặc nhiều vòng phỏng vấn về thiết kế.

Bắt đầu từ tổng quan và đi sâu vào một vài lĩnh vực nhất định. Việc biết một chút về các chủ đề thiết kế hệ thống quan trọng sẽ rất hữu ích. Điều chỉnh hướng dẫn dưới đây dựa trên thời gian, kinh nghiệm, vị trí bạn đang phỏng vấn và công ty bạn ứng tuyển.

| | Ngắn | Trung bình | Dài | |---|---|---|---| | Đọc qua Các chủ đề thiết kế hệ thống để hiểu tổng quan về cách hệ thống hoạt động | :+1: | :+1: | :+1: | | Đọc một vài bài viết trong Blog kỹ thuật của công ty tại các công ty bạn đang ứng tuyển | :+1: | :+1: | :+1: | | Đọc qua một số Kiến trúc thực tế | :+1: | :+1: | :+1: | | Xem lại Cách tiếp cận câu hỏi phỏng vấn thiết kế hệ thống | :+1: | :+1: | :+1: | | Giải Câu hỏi phỏng vấn thiết kế hệ thống có đáp án | Một số | Nhiều | Hầu hết | | Giải Câu hỏi phỏng vấn thiết kế hướng đối tượng có đáp án | Một số | Nhiều | Hầu hết | | Xem lại Câu hỏi phỏng vấn thiết kế hệ thống bổ sung | Một số | Nhiều | Hầu hết |

Cách tiếp cận câu hỏi phỏng vấn thiết kế hệ thống

Cách giải quyết một câu hỏi phỏng vấn thiết kế hệ thống.

Phỏng vấn thiết kế hệ thống là một cuộc trò chuyện mở. Bạn được mong đợi sẽ dẫn dắt buổi phỏng vấn.

Bạn có thể sử dụng các bước sau để định hướng cuộc thảo luận. Để củng cố quy trình này, hãy luyện tập với Câu hỏi phỏng vấn thiết kế hệ thống có đáp án sử dụng các bước sau.

Bước 1: Phác thảo các trường hợp sử dụng, ràng buộc, và giả định

Thu thập yêu cầu và xác định phạm vi vấn đề. Đặt câu hỏi để làm rõ trường hợp sử dụng và các ràng buộc. Thảo luận về các giả định.

Bước 2: Tạo thiết kế cấp cao

Phác thảo thiết kế tổng quan với tất cả các thành phần quan trọng.

Bước 3: Thiết kế các thành phần cốt lõi

Đi sâu vào chi tiết cho từng thành phần cốt lõi. Ví dụ, nếu bạn được yêu cầu thiết kế dịch vụ rút gọn url, hãy thảo luận:

Bước 4: Mở rộng thiết kế

Xác định và giải quyết các điểm nghẽn, dựa trên các ràng buộc. Ví dụ, bạn có cần các yếu tố sau để xử lý vấn đề mở rộng?

Thảo luận về các giải pháp tiềm năng và các đánh đổi. Mọi thứ đều là sự đánh đổi. Giải quyết điểm nghẽn dựa trên nguyên tắc thiết kế hệ thống mở rộng.

Tính toán sơ bộ

Bạn có thể được yêu cầu thực hiện một số ước tính bằng tay. Tham khảo Phụ lục cho các nguồn sau:

Nguồn và tài liệu đọc thêm

Xem các liên kết sau để có ý tưởng rõ hơn về những gì sẽ gặp phải:

Các câu hỏi phỏng vấn thiết kế hệ thống kèm giải pháp

Các câu hỏi phỏng vấn thiết kế hệ thống phổ biến kèm thảo luận mẫu, mã nguồn, và sơ đồ.
>
Các giải pháp liên kết đến nội dung trong thư mục solutions/.

| Câu hỏi | | |---|---| | Thiết kế Pastebin.com (hoặc Bit.ly) | Giải pháp | | Thiết kế dòng thời gian và tìm kiếm của Twitter (hoặc bảng tin và tìm kiếm của Facebook) | Giải pháp | | Thiết kế trình thu thập dữ liệu web | Giải pháp | | Thiết kế Mint.com | Giải pháp | | Thiết kế cấu trúc dữ liệu cho mạng xã hội | Giải pháp | | Thiết kế khoá-giá trị cho công cụ tìm kiếm | Giải pháp | | Thiết kế tính năng xếp hạng bán hàng theo danh mục của Amazon | Giải pháp | | Thiết kế hệ thống mở rộng cho hàng triệu người dùng trên AWS | Giải pháp | | Thêm câu hỏi thiết kế hệ thống | Đóng góp |

Thiết kế Pastebin.com (hoặc Bit.ly)

Xem bài tập và giải pháp

Imgur

Thiết kế dòng thời gian và tìm kiếm của Twitter (hoặc bảng tin và tìm kiếm của Facebook)

Xem bài tập và giải pháp

Imgur

Thiết kế trình thu thập dữ liệu web

Xem bài tập và giải pháp

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 | | |---|---| | Thiết kế một bảng băm | Giải pháp | | Thiết kế bộ nhớ đệm truy xuất gần nhất (LRU cache) | Giải pháp | | Thiết kế tổng đài điện thoại | Giải pháp | | Thiết kế bộ bài | Giải pháp | | Thiết kế bãi đậu xe | Giải pháp | | Thiết kế máy chủ chat | Giải pháp | | Thiết kế mảng vòng tròn | Đóng góp | | Thêm một câu hỏi thiết kế hướng đối tượng | Đóng góp |

Chủ đề thiết kế hệ thống: bắt đầu từ đây

Bạn mới làm quen với thiết kế hệ thống?

Trước tiên, bạn cần hiểu cơ bản về các nguyên tắc phổ biến, tìm hiểu chúng là gì, cách sử dụng, và điểm mạnh/yếu của chúng.

Bước 1: Xem bài giảng video về khả năng mở rộng

Bài giảng về khả năng mở rộng tại Harvard

Bước 2: Đọc bài viết về khả năng mở rộng

Khả năng mở rộng

Các bước tiếp theo

Tiếp theo, chúng ta sẽ xem xét các sự đánh đổi ở cấp độ cao:

Hãy nhớ rằng mọi thứ đều là sự đánh đổi.

Sau đó, chúng ta sẽ đi sâu vào các chủ đề cụ thể hơn như DNS, CDN, và bộ cân bằng tải.

Hiệu năng vs khả năng mở rộng

Một dịch vụ được gọi là có khả năng mở rộng nếu nó có thể tăng hiệu năng theo tỷ lệ với tài nguyên được thêm vào. Thông thường, tăng hiệu năng nghĩa là phục vụ được nhiều đơn vị công việc hơn, nhưng nó cũng có thể là xử lý các đơn vị công việc lớn hơn, ví dụ như khi bộ dữ liệu tăng lên.1

Một cách khác để nhìn nhận về hiệu năng và khả năng mở rộng:

Nguồn và đọc thêm

Độ trễ vs thông lượng

Độ trễ là thời gian để thực hiện một hành động hoặc tạo ra một kết quả.

Thông lượng là số lượng các hành động hoặc kết quả đó trên mỗi đơn vị thời gian.

Thông thường, bạn nên hướng tới thông lượng tối đa với độ trễ chấp nhận được.

Nguồn và đọc thêm

Khả dụng vs tính nhất quán

Định lý CAP


Nguồn: CAP theorem revisited

Trong một hệ thống máy tính phân tán, bạn chỉ có thể đảm bảo hai trong ba yếu tố sau:

Mạng lưới không đáng tin cậy, do đó bạn cần hỗ trợ khả năng chịu phân vùng. Bạn sẽ cần phải đánh đổi phần mềm giữa tính nhất quán và tính sẵn sàng.

#### CP - nhất quán và chịu phân vùng

Chờ phản hồi từ nút bị phân vùng có thể dẫn đến lỗi quá thời gian. CP là lựa chọn tốt nếu yêu cầu kinh doanh của bạn đòi hỏi đọc và ghi nguyên tử.

#### AP - sẵn sàng và chịu phân vùng

Phản hồi trả về phiên bản dữ liệu có sẵn nhất trên bất kỳ nút nào, có thể không phải là phiên bản mới nhất. Các thao tác ghi có thể mất thời gian để lan truyền khi phân vùng được giải quyết.

AP là lựa chọn phù hợp nếu nhu cầu kinh doanh cho phép tính nhất quán cuối cùng hoặc khi hệ thống cần tiếp tục hoạt động dù xảy ra lỗi bên ngoài.

Nguồn và tài liệu tham khảo

Các mẫu nhất quán

Khi có nhiều bản sao của cùng một dữ liệu, chúng ta phải lựa chọn cách đồng bộ để khách hàng có cái nhìn nhất quán về dữ liệu. Hãy nhớ lại định nghĩa về tính nhất quán từ định lý CAP - Mỗi lần đọc nhận được lần ghi mới nhất hoặc báo lỗi.

Nhất quán yếu

Sau một lần ghi, các lần đọc có thể thấy hoặc không thấy kết quả đó. Một cách tiếp cận nỗ lực tốt nhất được áp dụng.

Cách tiếp cận này thường thấy ở các hệ thống như memcached. Tính nhất quán yếu hoạt động tốt trong các trường hợp thời gian thực như VoIP, video chat và trò chơi nhiều người chơi trực tuyến. Ví dụ, nếu bạn đang gọi điện thoại và mất sóng trong vài giây, khi kết nối lại bạn sẽ không nghe được những gì đã nói trong lúc mất kết nối.

Tính nhất quán cuối cùng

Sau một lần ghi, các lần đọc cuối cùng sẽ thấy nó (thường trong vòng mili giây). Dữ liệu được sao chép bất đồng bộ.

Cách tiếp cận này được sử dụng trong các hệ thống như DNS và email. Tính nhất quán cuối cùng hoạt động tốt trong các hệ thống có độ khả dụng cao.

Tính nhất quán mạnh

Sau một lần ghi, các lần đọc sẽ thấy nó. Dữ liệu được sao chép đồng bộ.

Cách tiếp cận này được sử dụng trong hệ thống tệp và các hệ quản trị cơ sở dữ liệu quan hệ (RDBMS). Tính nhất quán mạnh phù hợp với các hệ thống cần giao dịch.

Nguồn và tài liệu đọc thêm

Mô hình khả dụng

Có hai mô hình bổ trợ để hỗ trợ khả dụng cao: chuyển đổi dự phòng và sao chép dữ liệu.

Chuyển đổi dự phòng

#### Chủ động - bị động

Với chuyển đổi dự phòng chủ động - bị động, các tín hiệu nhịp tim được gửi giữa máy chủ chủ động và máy chủ bị động ở chế độ chờ. Nếu tín hiệu nhịp tim bị gián đoạn, máy chủ bị động sẽ tiếp nhận địa chỉ IP của máy chủ chủ động và tiếp tục dịch vụ.

Thời gian ngừng hoạt động phụ thuộc vào việc máy chủ bị động đã chạy ở chế độ chờ 'nóng' hay cần khởi động từ chế độ chờ 'lạnh'. Chỉ máy chủ chủ động xử lý lưu lượng.

Chuyển đổi dự phòng chủ động - bị động còn được gọi là chuyển đổi dự phòng chủ - tớ.

#### Chủ động - chủ động

Trong chuyển đổi dự phòng chủ động - chủ động, cả hai máy chủ đều xử lý lưu lượng, phân chia tải giữa chúng.

Nếu các máy chủ hướng ra công chúng, DNS cần biết về các địa chỉ IP công khai của cả hai máy chủ. Nếu các máy chủ hướng nội bộ, logic ứng dụng cần biết về cả hai máy chủ.

Chuyển đổi dự phòng chủ động - chủ động còn được gọi là chuyển đổi dự phòng chủ - chủ.

Nhược điểm: chuyển đổi dự phòng

Sao chép dữ liệu (Replication)

#### Mô hình chủ-tớ và chủ-chủ

Chủ đề này được thảo luận thêm trong phần Cơ sở dữ liệu:

Tỷ lệ sẵn sàng dưới dạng số liệu

Tỷ lệ sẵn sàng thường được định lượng bằng thời gian hoạt động (hoặc thời gian ngừng hoạt động) dưới dạng phần trăm thời gian dịch vụ có thể truy cập. Tỷ lệ sẵn sàng thường được đo bằng số lượng số 9--một dịch vụ có tỷ lệ sẵn sàng 99,99% được mô tả là có bốn số 9.

#### Tỷ lệ sẵn sàng 99,9% - ba số 9

| Thời lượng | Thời gian ngừng hoạt động chấp nhận được| |------------------------|-----------------------------------------| | Ngừng hoạt động mỗi năm| 8 giờ 45 phút 57 giây | | Ngừng hoạt động mỗi tháng| 43 phút 49,7 giây | | Ngừng hoạt động mỗi tuần| 10 phút 4,8 giây | | Ngừng hoạt động mỗi ngày| 1 phút 26,4 giây |

#### Tỷ lệ sẵn sàng 99,99% - bốn số 9

| Thời lượng | Thời gian ngừng hoạt động chấp nhận được| |------------------------|-----------------------------------------| | Ngừng hoạt động mỗi năm| 52 phút 35,7 giây | | Ngừng hoạt động mỗi tháng| 4 phút 23 giây | | Ngừng hoạt động mỗi tuần| 1 phút 5 giây | | Ngừng hoạt động mỗi ngày| 8,6 giây |

#### Tỷ lệ sẵn sàng song song so với tuần tự

Nếu một dịch vụ bao gồm nhiều thành phần có khả năng gặp sự cố, tỷ lệ sẵn sàng tổng thể của dịch vụ phụ thuộc vào việc các thành phần này được sắp xếp theo tuần tự hay song song.

###### Theo tuần tự

Tổng độ sẵn sàng giảm khi hai thành phần có độ sẵn sàng < 100% được kết nối nối tiếp:

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

Nếu cả Foo và Bar đều có độ sẵn sàng 99,9%, tổng độ sẵn sàng của chúng khi nối tiếp sẽ là 99,8%.

###### Song song

Độ sẵn sàng tổng thể tăng lên khi hai thành phần có độ sẵn sàng < 100% được kết nối song song:

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
Nếu cả Foo và Bar đều có mức độ sẵn sàng 99,9%, tổng mức độ sẵn sàng khi chạy song song của chúng sẽ là 99,9999%.

Hệ thống tên miền (Domain name system)


Nguồn: Bài thuyết trình về bảo mật DNS

Hệ thống tên miền (DNS) chuyển đổi một tên miền như www.example.com thành một địa chỉ IP.

DNS có cấu trúc phân cấp, với một vài máy chủ có thẩm quyền ở cấp cao nhất. Bộ định tuyến hoặc nhà cung cấp dịch vụ internet (ISP) của bạn cung cấp thông tin về máy chủ DNS cần liên hệ khi thực hiện truy vấn. Các máy chủ DNS cấp thấp hơn lưu bộ nhớ đệm các ánh xạ, có thể bị lỗi thời do độ trễ truyền bá DNS. Kết quả DNS cũng có thể được trình duyệt hoặc hệ điều hành của bạn lưu vào bộ đệm trong một khoảng thời gian nhất định, được xác định bởi thời gian tồn tại (TTL).

Các dịch vụ như CloudFlare và Route 53 cung cấp dịch vụ DNS được quản lý. Một số dịch vụ DNS có thể định tuyến lưu lượng thông qua các phương pháp khác nhau:

Nhược điểm: DNS

Nguồn và tài liệu đọc thêm

Mạng phân phối nội dung


Nguồn: Tại sao sử dụng CDN

Mạng phân phối nội dung (CDN) là một mạng lưới các máy chủ proxy được phân phối toàn cầu, cung cấp nội dung từ các vị trí gần người dùng hơn. Thông thường, các tệp tĩnh như HTML/CSS/JS, ảnh và video được phục vụ từ CDN, mặc dù một số CDN như CloudFront của Amazon hỗ trợ cả nội dung động. Quá trình phân giải DNS của trang web sẽ cho khách truy cập biết nên liên hệ với máy chủ nào.

Việc cung cấp nội dung từ CDN có thể cải thiện hiệu suất đáng kể theo hai cách:

Push CDN

Push CDN nhận nội dung mới mỗi khi có thay đổi trên máy chủ của bạn. Bạn hoàn toàn chịu trách nhiệm cung cấp nội dung, tải trực tiếp lên CDN và viết lại URL để trỏ tới CDN. Bạn có thể cấu hình thời điểm nội dung hết hạn và được cập nhật. Nội dung chỉ được tải lên khi có mới hoặc thay đổi, giảm thiểu lưu lượng nhưng tối đa hóa lưu trữ.

Các trang web có lưu lượng nhỏ hoặc nội dung không thường xuyên thay đổi rất phù hợp với Push CDN. Nội dung được đặt lên CDN một lần, thay vì bị lấy lại định kỳ.

Pull CDN

Pull CDN lấy nội dung mới từ máy chủ của bạn khi người dùng đầu tiên yêu cầu nội dung đó. Bạn để nội dung trên máy chủ và viết lại URL để trỏ đến CDN. Điều này dẫn đến lần truy cập đầu tiên chậm hơn cho đến khi nội dung được cache trên CDN.

Thời gian sống (TTL) xác định thời gian nội dung được cache. Pull CDN giảm thiểu không gian lưu trữ trên CDN, nhưng có thể tạo ra lưu lượng dư thừa nếu các tệp hết hạn và bị lấy lại trước khi chúng thực sự thay đổi.

Các trang web có lưu lượng lớn hoạt động hiệu quả với Pull CDN, vì lưu lượng được phân tán đều hơn và chỉ những nội dung vừa được yêu cầu mới ở lại trên CDN.

Nhược điểm: CDN

Nguồn và đọc thêm

Bộ cân bằng tải


Nguồn: Các mẫu thiết kế hệ thống có khả năng mở rộng

Bộ cân bằng tải phân phối các yêu cầu từ khách hàng đến các tài nguyên tính toán như máy chủ ứng dụng và cơ sở dữ liệu. Trong mỗi trường hợp, bộ cân bằng tải trả về phản hồi từ tài nguyên tính toán đến đúng khách hàng. Bộ cân bằng tải hiệu quả trong việc:

Bộ cân bằng tải có thể được triển khai bằng phần cứng (đắt tiền) hoặc phần mềm như HAProxy.

Các lợi ích bổ sung bao gồm:

Để bảo vệ chống lại sự cố, thông thường sẽ thiết lập nhiều bộ cân bằng tải, ở chế độ active-passive hoặc active-active.

Bộ cân bằng tải có thể định tuyến lưu lượng dựa trên nhiều chỉ số khác nhau, bao gồm:

Cân bằng tải tầng 4

Bộ cân bằng tải tầng 4 xem xét thông tin tại tầng vận chuyển để quyết định cách phân phối yêu cầu. Thông thường, điều này liên quan đến địa chỉ IP nguồn, đích và các cổng trong phần đầu, nhưng không phải nội dung của gói tin. Bộ cân bằng tải tầng 4 chuyển tiếp các gói mạng đến và từ máy chủ upstream, thực hiện Chuyển đổi địa chỉ mạng (NAT).

Cân bằng tải tầng 7

Bộ cân bằng tải tầng 7 kiểm tra tầng ứng dụng để quyết định cách phân phối các yêu cầu. Điều này có thể liên quan đến nội dung của tiêu đề, thông điệp và cookie. Bộ cân bằng tải tầng 7 sẽ chấm dứt lưu lượng mạng, đọc thông điệp, đưa ra quyết định cân bằng tải, sau đó mở kết nối đến máy chủ đã được chọn. Ví dụ, bộ cân bằng tải tầng 7 có thể chuyển hướng lưu lượng video đến các máy chủ lưu trữ video trong khi chuyển hướng lưu lượng thanh toán người dùng nhạy cảm đến các máy chủ đã được tăng cường bảo mật.

Đổi lại cho sự linh hoạt, cân bằng tải tầng 4 yêu cầu ít thời gian và tài nguyên tính toán hơn tầng 7, mặc dù tác động đến hiệu suất có thể không đáng kể trên phần cứng phổ thông hiện đại.

Mở rộng theo chiều ngang

Bộ cân bằng tải cũng giúp mở rộng theo chiều ngang, cải thiện hiệu suất và độ sẵn sàng. Mở rộng bằng các máy phổ thông tiết kiệm chi phí hơn và mang lại độ sẵn sàng cao hơn so với mở rộng một máy chủ duy nhất trên phần cứng đắt tiền, gọi là Mở rộng theo chiều dọc. Việc tuyển dụng nhân sự làm việc với phần cứng phổ thông cũng dễ dàng hơn so với các hệ thống doanh nghiệp chuyên biệt.

#### Nhược điểm: mở rộng theo chiều ngang

Nhược điểm: bộ cân bằng tải

Nguồn và đọc thêm

Reverse proxy (máy chủ web)


Nguồn: Wikipedia

Reverse proxy là một máy chủ web tập trung các dịch vụ nội bộ và cung cấp giao diện thống nhất cho công chúng. Các yêu cầu từ khách hàng sẽ được chuyển tiếp đến máy chủ có thể xử lý trước khi reverse proxy trả về phản hồi của máy chủ cho khách hàng.

Các lợi ích bổ sung bao gồm:

Bộ cân bằng tải vs reverse proxy

Bất lợi: reverse proxy

Nguồn và đọc thêm

Tầng ứng dụng


Nguồn: Giới thiệu về kiến trúc hệ thống cho khả năng mở rộng

Tách biệt tầng web khỏi tầng ứng dụng (còn gọi là tầng nền tảng) cho phép bạn mở rộng và cấu hình cả hai tầng một cách độc lập. Việc thêm một API mới dẫn đến việc bổ sung máy chủ ứng dụng mà không nhất thiết phải thêm máy chủ web bổ sung. Nguyên tắc single responsibility khuyến khích các dịch vụ nhỏ và tự động làm việc cùng nhau. Các nhóm nhỏ với các dịch vụ nhỏ có thể lập kế hoạch phát triển nhanh chóng một cách tích cực hơn.

Các worker ở tầng ứng dụng cũng giúp kích hoạt tính bất đồng bộ.

Microservices

Liên quan đến chủ đề này là microservices, có thể được mô tả là một bộ các dịch vụ nhỏ, mô-đun, có thể triển khai độc lập. Mỗi dịch vụ chạy một tiến trình riêng biệt và giao tiếp qua một cơ chế nhẹ, được xác định rõ nhằm phục vụ mục tiêu kinh doanh. 1

Pinterest, ví dụ, có thể có các microservice như: hồ sơ người dùng, theo dõi, nguồn cấp, tìm kiếm, tải ảnh lên, v.v.

Khám phá dịch vụ

Các hệ thống như Consul, Etcd, và Zookeeper có thể giúp các dịch vụ tìm nhau bằng cách theo dõi tên, địa chỉ và cổng đã đăng ký. Kiểm tra sức khỏe giúp xác minh tính toàn vẹn của dịch vụ và thường được thực hiện thông qua một endpoint HTTP. Cả Consul và Etcd đều có kho lưu trữ key-value tích hợp sẵn, hữu ích để lưu giá trị cấu hình và dữ liệu chia sẻ khác.

Nhược điểm: tầng ứng dụng

Nguồn và tài liệu đọc thêm

Cơ sở dữ liệu


Nguồn: Mở rộng lên 10 triệu người dùng đầu tiên

Hệ quản trị cơ sở dữ liệu quan hệ (RDBMS)

Một cơ sở dữ liệu quan hệ như SQL là một tập hợp các mục dữ liệu được tổ chức trong các bảng.

ACID là một tập hợp các thuộc tính của giao dịch trong cơ sở dữ liệu quan hệ.

Có nhiều kỹ thuật để mở rộng quy mô cơ sở dữ liệu quan hệ: nhân bản chủ-tớ, nhân bản chủ-chủ, liên kết, phân mảnh, phi chuẩn hóa, và tối ưu hóa SQL.

#### Nhân bản chủ-tớ

Chủ phục vụ cả đọc và ghi, nhân bản các thao tác ghi đến một hoặc nhiều tớ, các tớ chỉ phục vụ đọc. Các tớ cũng có thể nhân bản đến các tớ bổ sung theo dạng cây. Nếu chủ bị ngắt kết nối, hệ thống có thể tiếp tục hoạt động ở chế độ chỉ đọc cho đến khi một tớ được nâng cấp thành chủ hoặc một chủ mới được cung cấp.


Nguồn: Scalability, availability, stability, patterns

##### Nhược điểm: nhân bản chủ-tớ

#### Nhân bản chủ-chủ

Cả hai chủ đều phục vụ đọc và ghi và phối hợp với nhau về các thao tác ghi. Nếu một trong hai chủ gặp sự cố, hệ thống vẫn có thể tiếp tục hoạt động với cả đọc và ghi.


Nguồn: Scalability, availability, stability, patterns

##### Nhược điểm: nhân bản chủ-chủ

##### Nhược điểm: nhân bản

##### Nguồn và tài liệu tham khảo thêm: nhân bản

#### Federation


Nguồn: Scaling up to your first 10 million users

Federation (hoặc phân vùng chức năng) chia nhỏ cơ sở dữ liệu theo chức năng. Ví dụ, thay vì một cơ sở dữ liệu đơn lẻ, nguyên khối, bạn có thể có ba cơ sở dữ liệu: forums, users, và products, dẫn đến ít lưu lượng đọc và ghi đến mỗi cơ sở dữ liệu hơn và do đó ít độ trễ nhân bản hơn. Các cơ sở dữ liệu nhỏ hơn giúp nhiều dữ liệu có thể nằm trong bộ nhớ hơn, từ đó tăng số lần truy cập cache nhờ cải thiện tính cục bộ của cache. Không có master trung tâm duy nhất để tuần tự hóa ghi, bạn có thể ghi song song, tăng thông lượng.

##### Nhược điểm: federation

##### Nguồn và tài liệu tham khảo thêm: federation

#### Sharding


Nguồn: Scalability, availability, stability, patterns

Sharding phân phối dữ liệu qua các cơ sở dữ liệu khác nhau sao cho mỗi cơ sở dữ liệu chỉ quản lý một phần của dữ liệu. Lấy ví dụ với cơ sở dữ liệu người dùng, khi số lượng người dùng tăng lên, nhiều shard hơn sẽ được thêm vào cụm.

Tương tự như lợi ích của federation, sharding giúp giảm lưu lượng đọc và ghi, giảm việc nhân bản dữ liệu, và tăng tỷ lệ cache hit. Kích thước chỉ mục cũng được giảm, thường cải thiện hiệu năng với các truy vấn nhanh hơn. Nếu một shard gặp sự cố, các shard khác vẫn hoạt động, tuy nhiên bạn sẽ muốn thêm một số hình thức nhân bản để tránh mất dữ liệu. Giống như federation, không có một master trung tâm duy nhất serial hóa việc ghi, cho phép bạn ghi song song với thông lượng cao hơn.

Các cách phổ biến để shard bảng người dùng là dựa vào ký tự đầu của họ người dùng hoặc vị trí địa lý của người dùng.

##### Nhược điểm: sharding

##### Nguồn và đọc thêm: sharding

#### Denormalization

Denormalization cố gắng cải thiện hiệu năng đọc bằng cách hy sinh một phần hiệu năng ghi. Các bản sao dư thừa của dữ liệu được ghi vào nhiều bảng để tránh các phép nối đắt đỏ. Một số RDBMS như PostgreSQL và Oracle hỗ trợ materialized views giúp lưu trữ thông tin dư thừa và giữ các bản sao dư thừa nhất quán.

Khi dữ liệu được phân phối bằng các kỹ thuật như federation và sharding, việc quản lý các phép nối qua các trung tâm dữ liệu càng làm tăng độ phức tạp. Denormalization có thể giúp tránh được nhu cầu thực hiện các phép nối phức tạp như vậy.

Trong hầu hết các hệ thống, số lần đọc có thể vượt xa số lần ghi với tỷ lệ 100:1 hoặc thậm chí 1000:1. Một lần đọc dẫn đến phép nối dữ liệu phức tạp có thể rất tốn kém, tiêu tốn nhiều thời gian cho các thao tác ổ đĩa.

##### Nhược điểm: denormalization

###### Nguồn và đọc thêm: denormalization

#### Tinh chỉnh SQL

Tinh chỉnh SQL là một chủ đề rộng lớn và nhiều sách đã được viết làm tài liệu tham khảo.

Điều quan trọng là phải kiểm thử hiệu năng và phân tích hồ sơ để mô phỏng và phát hiện các nút thắt cổ chai.

Kiểm thử hiệu năng và phân tích hồ sơ có thể giúp bạn xác định các tối ưu hóa sau.

##### Siết chặt lược đồ

##### Sử dụng chỉ mục tốt

##### Tránh các phép nối tốn kém

##### Phân vùng bảng

##### Tinh chỉnh bộ nhớ đệm truy vấn

##### Nguồn và tài liệu đọc thêm: Tinh chỉnh SQL

NoSQL

NoSQL là tập hợp các mục dữ liệu được thể hiện bằng key-value store, document store, wide column store, hoặc graph database. Dữ liệu được phi chuẩn hóa và các phép nối thường được thực hiện trong mã ứng dụng. Hầu hết các kho NoSQL không có giao dịch ACID thực sự và ưu tiên tính nhất quán cuối cùng.

BASE thường được dùng để mô tả các đặc tính của cơ sở dữ liệu NoSQL. So với Định lý CAP, BASE chọn tính sẵn sàng thay vì tính nhất quán.

Ngoài việc lựa chọn giữa SQL hoặc NoSQL, việc hiểu loại cơ sở dữ liệu NoSQL nào phù hợp nhất với trường hợp sử dụng của bạn cũng rất hữu ích. Chúng ta sẽ xem xét key-value store, document store, wide column store, và graph database ở phần tiếp theo.

#### Key-value store

Trừu tượng: bảng băm

Một key-value store thường cho phép đọc và ghi với độ phức tạp O(1), thường được hỗ trợ bởi bộ nhớ hoặc SSD. Các kho dữ liệu có thể duy trì khóa theo thứ tự từ điển, cho phép truy xuất phạm vi khóa hiệu quả. Key-value store có thể lưu trữ siêu dữ liệu cùng với giá trị.

Key-value store cung cấp hiệu năng cao và thường được dùng cho các mô hình dữ liệu đơn giản hoặc dữ liệu thay đổi nhanh, như lớp bộ nhớ đệm trong RAM. Vì chúng chỉ cung cấp một tập hợp thao tác hạn chế, độ phức tạp sẽ chuyển sang tầng ứng dụng nếu cần thêm thao tác.

Key-value store là nền tảng cho các hệ thống phức tạp hơn như document store, và trong một số trường hợp, graph database.

##### Nguồn và tài liệu đọc thêm: key-value store

#### Kho lưu trữ tài liệu

Trừu tượng: kho lưu trữ key-value với tài liệu được lưu trữ dưới dạng giá trị

Kho lưu trữ tài liệu tập trung vào các tài liệu (XML, JSON, nhị phân, v.v.), trong đó một tài liệu lưu trữ toàn bộ thông tin cho một đối tượng nhất định. Kho lưu trữ tài liệu cung cấp API hoặc ngôn ngữ truy vấn để truy vấn dựa trên cấu trúc nội bộ của chính tài liệu đó. Lưu ý, nhiều kho key-value cũng bao gồm các chức năng làm việc với siêu dữ liệu của giá trị, làm mờ ranh giới giữa hai loại lưu trữ này.

Tùy thuộc vào cách triển khai bên dưới, tài liệu được tổ chức theo bộ sưu tập, thẻ, siêu dữ liệu hoặc thư mục. Mặc dù tài liệu có thể được tổ chức hoặc nhóm lại, các trường của tài liệu có thể hoàn toàn khác nhau giữa các tài liệu.

Một số kho lưu trữ tài liệu như MongoDB và CouchDB còn cung cấp ngôn ngữ giống SQL để thực hiện các truy vấn phức tạp. DynamoDB hỗ trợ cả key-value và tài liệu.

Kho lưu trữ tài liệu mang lại tính linh hoạt cao và thường được sử dụng cho dữ liệu thay đổi không thường xuyên.

##### Nguồn và đọc thêm: kho lưu trữ tài liệu

#### Kho lưu trữ cột rộng


Nguồn: SQL & NoSQL, lịch sử ngắn gọn

Trừu tượng: bản đồ lồng nhau ColumnFamily>

Đơn vị dữ liệu cơ bản của kho lưu trữ cột rộng là một cột (cặp tên/giá trị). Một cột có thể được nhóm thành các họ cột (tương tự như bảng trong SQL). Họ siêu cột tiếp tục nhóm các họ cột. Bạn có thể truy cập từng cột độc lập bằng khóa dòng, và các cột có cùng khóa dòng tạo thành một dòng. Mỗi giá trị chứa một dấu thời gian để phân phiên bản và giải quyết xung đột.

Google đã giới thiệu Bigtable là kho lưu trữ cột rộng đầu tiên, ảnh hưởng đến HBase mã nguồn mở thường dùng trong hệ sinh thái Hadoop, và Cassandra của Facebook. Các kho như BigTable, HBase, và Cassandra duy trì các khóa theo thứ tự từ điển, cho phép truy xuất hiệu quả các dải khóa lựa chọn.

Kho lưu trữ cột rộng cung cấp tính sẵn sàng cao và khả năng mở rộng lớn. Chúng thường được sử dụng cho bộ dữ liệu rất lớn.

##### Nguồn và đọc thêm: kho lưu trữ cột rộng

#### Cơ sở dữ liệu đồ thị


Nguồn: Cơ sở dữ liệu đồ thị

Trừu tượng: đồ thị

Trong cơ sở dữ liệu đồ thị, mỗi nút là một bản ghi và mỗi cung là một mối quan hệ giữa hai nút. Cơ sở dữ liệu đồ thị được tối ưu hóa để biểu diễn các mối quan hệ phức tạp với nhiều khóa ngoại hoặc các quan hệ nhiều-nhiều.

Cơ sở dữ liệu đồ thị cung cấp hiệu năng cao cho các mô hình dữ liệu có mối quan hệ phức tạp, ví dụ như mạng xã hội. Chúng còn khá mới và chưa được sử dụng rộng rãi; có thể sẽ khó tìm công cụ và tài nguyên phát triển. Nhiều cơ sở dữ liệu đồ thị chỉ có thể truy cập qua REST APIs.

##### Nguồn và tài liệu đọc thêm: đồ thị

#### Nguồn và tài liệu đọc thêm: NoSQL

SQL hay NoSQL


Nguồn: Chuyển đổi từ RDBMS sang NoSQL

Lý do chọn SQL:

Lý do chọn NoSQL:

Dữ liệu mẫu phù hợp với NoSQL:

##### Nguồn và đọc thêm: SQL hay NoSQL

Bộ nhớ đệm (Cache)


Nguồn: Các mẫu thiết kế hệ thống có khả năng mở rộng

Bộ nhớ đệm giúp cải thiện thời gian tải trang và có thể giảm tải cho máy chủ và cơ sở dữ liệu của bạn. Trong mô hình này, bộ phân phối sẽ kiểm tra xem yêu cầu đã được thực hiện trước đó chưa và cố gắng tìm kết quả trước đó để trả về, nhằm tiết kiệm việc thực thi thực tế.

Cơ sở dữ liệu thường hưởng lợi từ việc phân phối đều các thao tác đọc và ghi trên các phân vùng của nó. Những mục phổ biến có thể làm lệch phân phối, gây ra điểm nghẽn. Đặt bộ nhớ đệm phía trước cơ sở dữ liệu có thể giúp hấp thụ tải không đều và các đợt tăng đột biến lưu lượng truy cập.

Bộ nhớ đệm phía khách

Bộ nhớ đệm có thể được đặt ở phía khách (hệ điều hành hoặc trình duyệt), phía máy chủ, hoặc trong một tầng bộ nhớ đệm riêng biệt.

Bộ nhớ đệm CDN

CDN được xem là một loại bộ nhớ đệm.

Bộ nhớ đệm máy chủ web

Reverse proxy và các bộ nhớ đệm như Varnish có thể phục vụ nội dung tĩnh và động trực tiếp. Máy chủ web cũng có thể lưu bộ nhớ đệm các yêu cầu, trả về phản hồi mà không cần liên hệ với máy chủ ứng dụng.

Bộ nhớ đệm cơ sở dữ liệu

Cơ sở dữ liệu của bạn thường bao gồm một mức bộ nhớ đệm nào đó trong cấu hình mặc định, được tối ưu cho trường hợp sử dụng tổng quát. Tinh chỉnh các thiết lập này cho các mẫu sử dụng cụ thể có thể tăng hiệu suất hơn nữa.

Bộ nhớ đệm ứng dụng

Các bộ nhớ đệm trong RAM như Memcached và Redis là các kho lưu trữ key-value nằm giữa ứng dụng của bạn và bộ lưu trữ dữ liệu. Vì dữ liệu được giữ trong RAM, nó nhanh hơn nhiều so với các cơ sở dữ liệu thông thường nơi dữ liệu được lưu trên ổ đĩa. RAM bị giới hạn hơn so với ổ đĩa, vì vậy các thuật toán hủy bộ nhớ đệm như ít được sử dụng gần đây nhất (LRU)) có thể giúp loại bỏ các mục 'lạnh' và giữ dữ liệu 'nóng' trong RAM.

Redis có các tính năng bổ sung sau:

Có nhiều cấp độ bạn có thể lưu bộ nhớ đệm, chia thành hai loại chính: truy vấn cơ sở dữ liệu và đối tượng:

Thông thường, bạn nên tránh sử dụng bộ nhớ đệm dựa trên tệp, vì nó làm cho việc nhân bản và tự động mở rộng trở nên khó khăn hơn.

Bộ nhớ đệm ở cấp độ truy vấn cơ sở dữ liệu

Bất cứ khi nào bạn truy vấn cơ sở dữ liệu, hãy băm truy vấn thành một khóa và lưu kết quả vào bộ nhớ đệm. Cách tiếp cận này gặp phải các vấn đề về hết hạn:

Bộ nhớ đệm ở cấp độ đối tượng

Xem dữ liệu của bạn như một đối tượng, giống như cách bạn làm với mã ứng dụng của mình. Hãy để ứng dụng của bạn tập hợp bộ dữ liệu từ cơ sở dữ liệu thành một thể hiện lớp hoặc một cấu trúc dữ liệu:

Các đề xuất về những gì nên lưu trong bộ nhớ đệm:

Khi nào cập nhật bộ nhớ đệm

Vì bạn chỉ có thể lưu một lượng dữ liệu giới hạn trong bộ nhớ đệm, bạn sẽ cần xác định chiến lược cập nhật bộ nhớ đệm nào phù hợp nhất với trường hợp sử dụng của mình.

#### Cache-aside


Nguồn: From cache to in-memory data grid

Ứng dụng chịu trách nhiệm đọc và ghi từ bộ lưu trữ. Bộ nhớ đệm không tương tác trực tiếp với bộ lưu trữ. Ứng dụng sẽ thực hiện các bước sau:

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 thường được sử dụng theo cách này.

Các lần đọc dữ liệu tiếp theo được thêm vào bộ nhớ đệm sẽ rất nhanh. Cache-aside còn được gọi là lazy loading. Chỉ dữ liệu được yêu cầu mới được lưu vào cache, tránh làm đầy bộ nhớ đệm với dữ liệu không được yêu cầu.

##### Nhược điểm: cache-aside

#### Write-through


Nguồn: Scalability, availability, stability, patterns

Ứng dụng sử dụng bộ nhớ đệm như kho lưu trữ dữ liệu chính, đọc và ghi dữ liệu vào đó, trong khi bộ nhớ đệm chịu trách nhiệm đọc và ghi vào cơ sở dữ liệu:

Mã ứng dụng:

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

Mã bộ nhớ đệm: 

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)
Ghi trực tiếp là một thao tác tổng thể chậm do thao tác ghi, nhưng các lần đọc sau đó đối với dữ liệu vừa được ghi thì nhanh. Người dùng thường dễ chấp nhận độ trễ khi cập nhật dữ liệu hơn là khi đọc dữ liệu. Dữ liệu trong bộ nhớ đệm không bị lỗi thời.

##### Bất lợi: ghi trực tiếp

#### Ghi phía sau (ghi lại)


Nguồn: Scalability, availability, stability, patterns

Trong ghi phía sau, ứng dụng thực hiện các bước sau:

##### Bất lợi: ghi phía sau

#### Làm mới trước (refresh-ahead)


Nguồn: From cache to in-memory data grid

Bạn có thể cấu hình bộ nhớ đệm để tự động làm mới bất kỳ mục bộ nhớ đệm nào vừa được truy cập trước khi nó hết hạn.

Làm mới trước có thể giảm độ trễ so với đọc thông qua nếu bộ nhớ đệm dự đoán chính xác các mục sẽ cần trong tương lai.

##### Bất lợi: làm mới trước

Nhược điểm: bộ nhớ đệm

Nguồn và tài liệu đọc thêm

Bất đồng bộ


Nguồn: Giới thiệu về kiến trúc hệ thống để mở rộng

Luồng công việc bất đồng bộ giúp giảm thời gian yêu cầu cho các thao tác tốn kém mà bình thường sẽ được thực hiện ngay lập tức. Chúng cũng có thể giúp thực hiện các công việc tốn nhiều thời gian trước, như tổng hợp dữ liệu định kỳ.

Hàng đợi tin nhắn

Hàng đợi tin nhắn nhận, giữ và chuyển phát tin nhắn. Nếu một thao tác quá chậm để thực hiện ngay, bạn có thể sử dụng hàng đợi tin nhắn với quy trình sau:

Người dùng không bị chặn và công việc được xử lý ở chế độ nền. Trong thời gian này, client có thể tùy ý thực hiện một số xử lý nhỏ để khiến tác vụ có vẻ như đã hoàn thành. Ví dụ, khi đăng tweet, tweet có thể được đăng ngay lập tức lên timeline của bạn, nhưng có thể mất một thời gian trước khi tweet của bạn thực sự được gửi đến tất cả người theo dõi.

Redis hữu ích như một message broker đơn giản nhưng có thể bị mất tin nhắn.

RabbitMQ phổ biến nhưng yêu cầu bạn phải thích nghi với giao thức 'AMQP' và tự quản lý các node.

Amazon SQS là dịch vụ được lưu trữ nhưng có thể có độ trễ cao và có khả năng tin nhắn được gửi hai lần.

Hàng đợi tác vụ

Hàng đợi tác vụ nhận các tác vụ và dữ liệu liên quan, thực hiện chúng, sau đó trả về kết quả. Chúng có thể hỗ trợ lập lịch và được sử dụng để chạy các công việc tính toán nặng ở chế độ nền.

Celery hỗ trợ lập lịch và chủ yếu hỗ trợ python.

Áp lực ngược (Back pressure)

Nếu các hàng đợi bắt đầu tăng lên đáng kể, kích thước hàng đợi có thể lớn hơn bộ nhớ, dẫn đến lỗi bộ nhớ cache, đọc từ đĩa và hiệu suất chậm hơn. Áp lực ngược có thể giúp bằng cách giới hạn kích thước hàng đợi, giữ tốc độ thông lượng cao và thời gian phản hồi tốt cho các công việc đã có trong hàng đợi. Khi hàng đợi đầy, khách hàng sẽ nhận được thông báo máy chủ bận hoặc mã trạng thái HTTP 503 để thử lại sau. Khách hàng có thể thử lại yêu cầu vào thời điểm sau, có thể với phương pháp lùi theo cấp số nhân.

Bất lợi: tính bất đồng bộ

Nguồn và đọc thêm

Giao tiếp


Nguồn: Mô hình 7 lớp OSI

Giao thức truyền siêu văn bản (HTTP)

HTTP là một phương thức để mã hóa và truyền dữ liệu giữa máy khách và máy chủ. Đây là giao thức yêu cầu/đáp ứng: máy khách gửi yêu cầu và máy chủ phản hồi với nội dung liên quan và thông tin trạng thái hoàn thành về yêu cầu. HTTP là tự chứa, cho phép yêu cầu và phản hồi đi qua nhiều bộ định tuyến và máy chủ trung gian thực hiện cân bằng tải, bộ nhớ đệm, mã hóa và nén.

Một yêu cầu HTTP cơ bản gồm một động từ (phương thức) và một tài nguyên (điểm cuối). Dưới đây là các động từ HTTP phổ biến:

| Động từ | Mô tả | Idempotent* | An toàn | Có thể lưu vào bộ đệm | |---|---|---|---|---| | GET | Đọc một tài nguyên | Có | Có | Có | | POST | Tạo một tài nguyên hoặc kích hoạt một tiến trình xử lý dữ liệu | Không | Không | Có nếu phản hồi chứa thông tin độ tươi mới | | PUT | Tạo hoặc thay thế một tài nguyên | Có | Không | Không | | PATCH | Cập nhật một phần tài nguyên | Không | Không | Có nếu phản hồi chứa thông tin độ tươi mới | | DELETE | Xóa một tài nguyên | Có | Không | Không |

*Có thể gọi nhiều lần mà không có kết quả khác biệt.

HTTP là một giao thức tầng ứng dụng dựa vào các giao thức tầng thấp hơn như TCP và UDP.

#### Nguồn và đọc thêm: HTTP

Giao thức điều khiển truyền tải (TCP)


Nguồn: Cách làm game nhiều người chơi

TCP là một giao thức hướng kết nối hoạt động trên mạng IP. Kết nối được thiết lập và kết thúc bằng cách sử dụng bắt tay. Tất cả các gói gửi đi đều được đảm bảo đến đích theo đúng thứ tự ban đầu và không bị lỗi thông qua:

Nếu người gửi không nhận được phản hồi đúng, nó sẽ gửi lại các gói. Nếu có nhiều lần hết thời gian chờ, kết nối sẽ bị ngắt. TCP cũng thực hiện kiểm soát luồng) và kiểm soát tắc nghẽn. Những đảm bảo này gây ra độ trễ và thường dẫn đến việc truyền dữ liệu kém hiệu quả hơn UDP.

Để đảm bảo thông lượng cao, các máy chủ web có thể giữ một số lượng lớn kết nối TCP mở, dẫn đến sử dụng bộ nhớ cao. Việc có nhiều kết nối mở giữa các luồng máy chủ web và ví dụ, một máy chủ memcached có thể tốn kém. Pooling kết nối có thể giúp ngoài việc chuyển sang UDP khi phù hợp.

TCP hữu ích cho các ứng dụng đòi hỏi độ tin cậy cao nhưng không quá nhạy về thời gian. Một số ví dụ bao gồm máy chủ web, dữ liệu cơ sở dữ liệu, SMTP, FTP và SSH.

Sử dụng TCP thay vì UDP khi:

Giao thức datagram người dùng (UDP)


Nguồn: Cách tạo một trò chơi nhiều người chơi

UDP là giao thức không kết nối. Datagram (tương tự như gói tin) chỉ được đảm bảo ở cấp độ datagram. Datagram có thể đến đích không theo thứ tự hoặc có thể không đến được. UDP không hỗ trợ kiểm soát tắc nghẽn. Không có các đảm bảo như TCP, UDP thường hiệu quả hơn.

UDP có thể phát sóng, gửi datagram đến tất cả các thiết bị trong mạng con. Điều này hữu ích với DHCP vì máy khách chưa nhận được địa chỉ IP, do đó ngăn chặn việc TCP truyền dữ liệu mà không có địa chỉ IP.

UDP kém tin cậy hơn nhưng hoạt động tốt trong các trường hợp sử dụng thời gian thực như VoIP, trò chuyện video, streaming và trò chơi nhiều người chơi thời gian thực.

Sử dụng UDP thay cho TCP khi:

#### Nguồn và đọc thêm: TCP và UDP

Gọi thủ tục từ xa (RPC)


Nguồn: Crack the system design interview

Trong RPC, một máy khách gây ra việc thực thi một thủ tục ở không gian địa chỉ khác, thường là máy chủ từ xa. Thủ tục này được mã hóa như một lời gọi thủ tục cục bộ, trừu tượng hóa chi tiết về cách giao tiếp với máy chủ khỏi chương trình máy khách. Các lời gọi từ xa thường chậm hơn và kém tin cậy hơn các lời gọi cục bộ, vì vậy nên phân biệt các lời gọi RPC với lời gọi cục bộ. Các framework RPC phổ biến bao gồm Protobuf, Thrift, và Avro.

RPC là giao thức yêu cầu-phản hồi:

Ví dụ các lời gọi RPC:

GET /someoperation?data=anId
POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}
RPC tập trung vào việc phơi bày các hành vi. RPC thường được sử dụng vì lý do hiệu năng trong giao tiếp nội bộ, vì bạn có thể tự tay xây dựng các lệnh gọi gốc phù hợp hơn với trường hợp sử dụng của mình.

Chọn thư viện gốc (hay còn gọi là SDK) khi:

HTTP API tuân theo REST thường được sử dụng nhiều hơn cho các API công khai.

#### Nhược điểm: RPC

Representational state transfer (REST)

REST là một kiểu kiến trúc áp đặt mô hình client/server, trong đó client thao tác trên tập hợp các tài nguyên do server quản lý. Server cung cấp đại diện của tài nguyên và các hành động có thể thao tác hoặc lấy đại diện mới của tài nguyên đó. Mọi giao tiếp đều phải không trạng thái và có thể lưu vào bộ nhớ đệm.

Có bốn đặc tính của một giao diện RESTful:

Ví dụ các lệnh gọi REST:

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
REST tập trung vào việc cung cấp dữ liệu. Nó giảm thiểu sự kết nối chặt chẽ giữa client/server và thường được sử dụng cho các HTTP API công khai. REST sử dụng phương pháp cung cấp tài nguyên thông qua URI một cách tổng quát và đồng nhất, biểu diễn qua các header, và hành động qua các động từ như GET, POST, PUT, DELETE và PATCH. Là stateless, REST rất phù hợp cho mở rộng ngang và phân vùng.

#### Nhược điểm: REST

So sánh các gọi RPC và REST

| Hoạt động | RPC | REST | |---|---|---| | Đăng ký | POST /signup | POST /persons | | Nghỉ việc | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | Đọc thông tin một người | GET /readPerson?personid=1234 | GET /persons/1234 | | Đọc danh sách vật phẩm của một người | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | Thêm vật phẩm vào danh sách của một người | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | Cập nhật vật phẩm | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | Xóa vật phẩm | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

Nguồn: Bạn có thật sự biết vì sao bạn thích REST hơn RPC không

#### Nguồn và tài liệu đọc thêm: REST và RPC

Bảo mật

Phần này có thể cần cập nhật. Hãy cân nhắc đóng góp!

Bảo mật là một chủ đề rộng. Trừ khi bạn có kinh nghiệm đáng kể, có nền tảng về bảo mật, hoặc đang ứng tuyển vào vị trí yêu cầu kiến thức về bảo mật, bạn có lẽ chỉ cần biết những điều cơ bản sau:

Nguồn và tài liệu đọc thêm

Phụ lục

Đôi khi bạn sẽ được yêu cầu ước lượng nhanh. Ví dụ, bạn có thể cần xác định mất bao lâu để tạo 100 ảnh thumbnail từ đĩa hoặc một cấu trúc dữ liệu sẽ tiêu tốn bao nhiêu bộ nhớ. Bảng số mũ của hai và Các con số độ trễ mà lập trình viên nên biết là những tài liệu tham khảo hữu ích.

Bảng số mũ của hai

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

#### Nguồn và tài liệu đọc thêm

Những con số độ trễ mà mọi lập trình viên nên biết

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
Các chỉ số hữu ích dựa trên các con số ở trên:

#### Hình minh họa các con số độ trễ

#### Nguồn và tài liệu đọc thêm

Các câu hỏi phỏng vấn thiết kế hệ thống bổ sung

Các câu hỏi phỏng vấn thiết kế hệ thống phổ biến, kèm liên kết đến tài liệu hướng dẫn cách giải.

| Câu hỏi | Tài liệu tham khảo | |---|---| | Thiết kế dịch vụ đồng bộ tập tin như Dropbox | youtube.com | | Thiết kế công cụ tìm kiếm như Google | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Thiết kế trình thu thập dữ liệu web có khả năng mở rộng như Google | quora.com | | Thiết kế Google Docs | code.google.com
neil.fraser.name | | Thiết kế kho key-value như Redis | slideshare.net | | Thiết kế hệ thống cache như Memcached | slideshare.net | | Thiết kế hệ thống đề xuất như Amazon | hulu.com
ijcai13.org | | Thiết kế hệ thống tinyurl như Bitly | n00tc0d3r.blogspot.com | | Thiết kế ứng dụng chat như WhatsApp | highscalability.com | Thiết kế hệ thống chia sẻ ảnh như Instagram | highscalability.com
highscalability.com | | Thiết kế chức năng news feed của Facebook | quora.com
quora.com
slideshare.net | | Thiết kế chức năng timeline của Facebook | facebook.com
highscalability.com | | Thiết kế chức năng chat của Facebook | erlang-factory.com
facebook.com |

| Thiết kế một chức năng tìm kiếm đồ thị giống Facebook | facebook.com
facebook.com
facebook.com | | Thiết kế một mạng phân phối nội dung giống CloudFlare | figshare.com | | Thiết kế hệ thống chủ đề thịnh hành giống Twitter | michael-noll.com
snikolov .wordpress.com | | Thiết kế hệ thống sinh ID ngẫu nhiên | blog.twitter.com
github.com | | Trả về k yêu cầu hàng đầu trong một khoảng thời gian | cs.ucsb.edu
wpi.edu | | Thiết kế hệ thống phục vụ dữ liệu từ nhiều trung tâm dữ liệu | highscalability.com | | Thiết kế trò chơi bài đa người chơi trực tuyến | indieflashblog.com
buildnewgames.com | | Thiết kế hệ thống thu gom rác | stuffwithstuff.com
washington.edu | | Thiết kế bộ giới hạn tần suất gọi API | https://stripe.com/blog/ | | Thiết kế một Sàn giao dịch chứng khoán (như NASDAQ hoặc Binance) | Jane Street
Golang Implementation
Go Implementation | | Thêm một câu hỏi thiết kế hệ thống | Đóng góp |

Kiến trúc thực tế

Các bài viết về cách hệ thống thực tế được thiết kế.


Nguồn: Twitter timelines at scale

Đừng tập trung vào chi tiết vụn vặt trong các bài viết sau, thay vào đó:

|Loại | Hệ thống | Tài liệu tham khảo | |---|---|---| | Xử lý dữ liệu | MapReduce - Xử lý dữ liệu phân tán từ Google | research.google.com | | Xử lý dữ liệu | Spark - Xử lý dữ liệu phân tán từ Databricks | slideshare.net | | Xử lý dữ liệu | Storm - Xử lý dữ liệu phân tán từ Twitter | slideshare.net | | | | | | Kho dữ liệu | Bigtable - Cơ sở dữ liệu cột phân tán từ Google | harvard.edu | | Kho dữ liệu | HBase - Triển khai mã nguồn mở của Bigtable | slideshare.net | | Kho dữ liệu | Cassandra - Cơ sở dữ liệu cột phân tán từ Facebook | slideshare.net | Kho dữ liệu | DynamoDB - Cơ sở dữ liệu hướng tài liệu từ Amazon | harvard.edu | | Kho dữ liệu | MongoDB - Cơ sở dữ liệu hướng tài liệu | slideshare.net | | Kho dữ liệu | Spanner - Cơ sở dữ liệu phân tán toàn cầu từ Google | research.google.com | | Kho dữ liệu | Memcached - Hệ thống bộ nhớ đệm phân tán | slideshare.net | | Kho dữ liệu | Redis - Hệ thống bộ nhớ đệm phân tán có khả năng lưu trữ lâu dài và kiểu giá trị | slideshare.net | | | | | | Hệ thống tập tin | Google File System (GFS) - Hệ thống tập tin phân tán | research.google.com | | Hệ thống tập tin | Hadoop File System (HDFS) - Phiên bản mã nguồn mở của GFS | apache.org | | | | | | Khác | Chubby - Dịch vụ khóa cho các hệ thống phân tán liên kết lỏng của Google | research.google.com | | Khác | Dapper - Hạ tầng truy vết hệ thống phân tán | research.google.com | Khác | Kafka - Hàng đợi thông điệp pub/sub từ LinkedIn | slideshare.net | | Khác | Zookeeper - Hạ tầng và dịch vụ tập trung hỗ trợ đồng bộ hóa | slideshare.net | | | Thêm kiến trúc | Đóng góp |

Kiến trúc của các công ty

| Công ty | Tham khảo | |---|---| | Amazon | Kiến trúc Amazon | | Cinchcast | Sản xuất 1.500 giờ âm thanh mỗi ngày | | DataSift | Khai thác dữ liệu thời gian thực với 120.000 tweet mỗi giây | | Dropbox | Cách Dropbox mở rộng quy mô | | ESPN | Vận hành với 100.000 duh nuh nuhs mỗi giây | | Google | Kiến trúc Google | | Instagram | 14 triệu người dùng, hàng terabyte ảnh
Công nghệ phía sau Instagram | | Justin.tv | Kiến trúc phát video trực tuyến của Justin.tv | | Facebook | Mở rộng memcached tại Facebook
TAO: Kho dữ liệu phân tán cho social graph của Facebook
Lưu trữ ảnh của Facebook
Cách Facebook Live phát trực tiếp đến 800.000 người xem đồng thời | | Flickr | Kiến trúc Flickr | | Mailbox | Từ 0 đến một triệu người dùng trong 6 tuần | | Netflix | Toàn cảnh hệ thống Netflix
Netflix: Chuyện gì xảy ra khi bạn nhấn Play? | | Pinterest | Từ 0 đến hàng chục tỷ lượt xem trang mỗi tháng
18 triệu khách truy cập, tăng trưởng 10 lần, 12 nhân viên | | Playfish | 50 triệu người dùng hàng tháng và tiếp tục tăng trưởng | | PlentyOfFish | Kiến trúc PlentyOfFish | | Salesforce | Cách họ xử lý 1,3 tỷ giao dịch mỗi ngày | | Stack Overflow | Kiến trúc Stack Overflow | | TripAdvisor | 40 triệu khách truy cập, 200 triệu lượt xem trang động, 30TB dữ liệu | | Tumblr | 15 tỷ lượt xem trang mỗi tháng | | Twitter | Làm Twitter nhanh hơn 10.000 lần
Lưu trữ 250 triệu tweet mỗi ngày bằng MySQL
150 triệu người dùng hoạt động, 300K QPS, 22 MB/S dữ liệu lớn
Timeline ở quy mô lớn
Dữ liệu lớn và nhỏ tại Twitter
Vận hành tại Twitter: mở rộng vượt quá 100 triệu người dùng
Cách Twitter xử lý 3.000 ảnh mỗi giây | | Uber | Cách Uber mở rộng nền tảng thị trường thời gian thực
Bài học từ việc mở rộng Uber lên 2000 kỹ sư, 1000 dịch vụ, và 8000 kho Git | | WhatsApp | Kiến trúc WhatsApp mà Facebook mua với giá 19 tỷ USD | | YouTube | Khả năng mở rộng của YouTube
Kiến trúc YouTube |

Blog kỹ thuật của các công ty

Kiến trúc của các công ty mà bạn đang phỏng vấn.
>
Những câu hỏi bạn gặp phải có thể đến từ cùng một lĩnh vực.

#### Nguồn và đọc thêm

Muốn thêm blog? Để tránh trùng lặp công việc, hãy cân nhắc thêm blog công ty của bạn vào kho lưu trữ sau:

Đang phát triển

Quan tâm đến việc thêm một mục hoặc giúp hoàn thành một mục đang tiến hành? Đóng góp!

Ghi công

Ghi công và nguồn được cung cấp xuyên suốt kho lưu trữ này.

Đặc biệt cảm ơn:

Thông tin liên hệ

Hãy liên hệ với tôi để thảo luận về bất kỳ vấn đề, câu hỏi hoặc ý kiến nào.

Thông tin liên hệ của tôi có thể được tìm thấy trên trang GitHub của tôi.

Giấy phép

Tôi cung cấp mã nguồn và tài nguyên trong kho lưu trữ này cho bạn theo giấy phép nguồn mở. Vì đây là kho lưu trữ cá nhân của tôi, giấy phép bạn nhận được đối với mã nguồn và tài nguyên là từ tôi chứ không phải từ công ty tôi (Facebook).

Bản quyền 2017 Donne Martin

Giấy phép Creative Commons Attribution 4.0 International License (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