【 👨🏻‍💻YouTube 】

系統設計101

使用視覺和簡單的術語解釋複雜的系統。

無論您是在準備系統設計面試，還是只是想了解系統底層的工作原理，我們都希望這個儲存庫能夠幫助您實現這一目標。

目錄

• 通訊協定

*   [REST API vs. GraphQL](#rest-api-vs-graphql)

*   [How does gRPC work?](#how-does-grpc-work)

*   [What is a webhook?](#what-is-a-webhook)

*   [How to improve API performance?](#how-to-improve-api-performance)

*   [HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)](#http-10---http-11---http-20---http-30-quic)

*   [SOAP vs REST vs GraphQL vs RPC](#soap-vs-rest-vs-graphql-vs-rpc)

*   [Code First vs. API First](#code-first-vs-api-first)

*   [HTTP status codes](#http-status-codes)

*   [What does API gateway do?](#what-does-api-gateway-do)

*   [How do we design effective and safe APIs?](#how-do-we-design-effective-and-safe-apis)

*   [TCP/IP encapsulation](#tcpip-encapsulation)

*   [Why is Nginx called a “reverse” proxy?](#why-is-nginx-called-a-reverse-proxy)

*   [What are the common load-balancing algorithms?](#what-are-the-common-load-balancing-algorithms)

*   [URL, URI, URN - Do you know the differences?](#url-uri-urn---do-you-know-the-differences)

• 持續整合/持續交付

*   [CI/CD Pipeline Explained in Simple Terms](#cicd-pipeline-explained-in-simple-terms)

*   [Netflix Tech Stack (CI/CD Pipeline)](#netflix-tech-stack-cicd-pipeline)

• 架構模式

*   [MVC, MVP, MVVM, MVVM-C, and VIPER](#mvc-mvp-mvvm-mvvm-c-and-viper)

*   [18 Key Design Patterns Every Developer Should Know](#18-key-design-patterns-every-developer-should-know)

• 資料庫

*   [A nice cheat sheet of different databases in cloud services](#a-nice-cheat-sheet-of-different-databases-in-cloud-services)

*   [8 Data Structures That Power Your Databases](#8-data-structures-that-power-your-databases)

*   [How is an SQL statement executed in the database?](#how-is-an-sql-statement-executed-in-the-database)

*   [CAP theorem](#cap-theorem)

*   [Types of Memory and Storage](#types-of-memory-and-storage)

*   [Visualizing a SQL query](#visualizing-a-sql-query)

*   [SQL language](#sql-language)

• 快取

*   [Data is cached everywhere](#data-is-cached-everywhere)

*   [Why is Redis so fast?](#why-is-redis-so-fast)

*   [How can Redis be used?](#how-can-redis-be-used)

*   [Top caching strategies](#top-caching-strategies)

• 微服務架構

*   [What does a typical microservice architecture look like?](#what-does-a-typical-microservice-architecture-look-like)

*   [Microservice Best Practices](#microservice-best-practices)

*   [What tech stack is commonly used for microservices?](#what-tech-stack-is-commonly-used-for-microservices)

*   [Why is Kafka fast](#why-is-kafka-fast)

• 支付系統

*   [How to learn payment systems?](#how-to-learn-payment-systems)

*   [Why is the credit card called “the most profitable product in banks”? How does VISA/Mastercard make money?](#why-is-the-credit-card-called-the-most-profitable-product-in-banks-how-does-visamastercard-make-money)

*   [How does VISA work when we swipe a credit card at a merchant’s shop?](#how-does-visa-work-when-we-swipe-a-credit-card-at-a-merchants-shop)

*   [Payment Systems Around The World Series (Part 1): Unified Payments Interface (UPI) in India](#payment-systems-around-the-world-series-part-1-unified-payments-interface-upi-in-india)

• DevOps

*   [DevOps vs. SRE vs. Platform Engineering. What is the difference?](#devops-vs-sre-vs-platform-engineering-what-is-the-difference)

*   [What is k8s (Kubernetes)?](#what-is-k8s-kubernetes)

*   [Docker vs. Kubernetes. Which one should we use?](#docker-vs-kubernetes-which-one-should-we-use)

*   [How does Docker work?](#how-does-docker-work)

• 胃腸道疾病

*   [How Git Commands work](#how-git-commands-work)

*   [How does Git Work?](#how-does-git-work)

*   [Git merge vs. Git rebase](#git-merge-vs-git-rebase)

• 雲端服務

*   [A nice cheat sheet of different cloud services (2023 edition)](#a-nice-cheat-sheet-of-different-cloud-services-2023-edition)

*   [What is cloud native?](#what-is-cloud-native)

• 開發人員生產力工具

*   [Visualize JSON files](#visualize-json-files)

*   [Automatically turn code into architecture diagrams](#automatically-turn-code-into-architecture-diagrams)

• Linux

*   [Linux file system explained](#linux-file-system-explained)

*   [18 Most-used Linux Commands You Should Know](#18-most-used-linux-commands-you-should-know)

• 安全

*   [How does HTTPS work?](#how-does-https-work)

*   [Oauth 2.0 Explained With Simple Terms.](#oauth-20-explained-with-simple-terms)

*   [Top 4 Forms of Authentication Mechanisms](#top-4-forms-of-authentication-mechanisms)

*   [Session, cookie, JWT, token, SSO, and OAuth 2.0 - what are they?](#session-cookie-jwt-token-sso-and-oauth-20---what-are-they)

*   [How to store passwords safely in the database and how to validate a password?](#how-to-store-passwords-safely-in-the-database-and-how-to-validate-a-password)

*   [Explaining JSON Web Token (JWT) to a 10 year old Kid](#explaining-json-web-token-jwt-to-a-10-year-old-kid)

*   [How does Google Authenticator (or other types of 2-factor authenticators) work?](#how-does-google-authenticator-or-other-types-of-2-factor-authenticators-work)

• 真實案例研究

*   [Netflix's Tech Stack](#netflixs-tech-stack)

*   [Twitter Architecture 2022](#twitter-architecture-2022)

*   [Evolution of Airbnb’s microservice architecture over the past 15 years](#evolution-of-airbnbs-microservice-architecture-over-the-past-15-years)

*   [Monorepo vs. Microrepo.](#monorepo-vs-microrepo)

*   [How will you design the Stack Overflow website?](#how-will-you-design-the-stack-overflow-website)

*   [Why did Amazon Prime Video monitoring move from serverless to monolithic? How can it save 90% cost?](#why-did-amazon-prime-video-monitoring-move-from-serverless-to-monolithic-how-can-it-save-90-cost)

*   [How does Disney Hotstar capture 5 Billion Emojis during a tournament?](#how-does-disney-hotstar-capture-5-billion-emojis-during-a-tournament)

*   [How Discord Stores Trillions Of Messages](#how-discord-stores-trillions-of-messages)

*   [How do video live streamings work on YouTube, TikTok live, or Twitch?](#how-do-video-live-streamings-work-on-youtube-tiktok-live-or-twitch)

通訊協定

架構風格定義了應用程式介面 (API) 的不同元件如何相互作用。因此，它們透過提供設計和建構 API 的標準方法來確保效率、可靠性以及與其他系統的易於整合。以下是最常用的樣式：

• 肥皂：

Mature, comprehensive, XML-based

Best for enterprise applications 

• REST 風格的：

Popular, easy-to-implement, HTTP methods 

Ideal for web services 

• GraphQL：

Query language, request specific data 

Reduces network overhead, faster responses 

• gRPC：

Modern, high-performance, Protocol Buffers 

Suitable for microservices architectures 

• WebSocket 介面：

Real-time, bidirectional, persistent connections 

Perfect for low-latency data exchange 

• Webhook：

Event-driven, HTTP callbacks, asynchronous 

Notifies systems when events occur

REST API 與 GraphQL

在 API 設計方面，REST 和 GraphQL 各有優缺點。

下圖顯示了 REST 和 GraphQL 之間的快速比較。

休息

• 使用標準 HTTP 方法（如 GET、POST、PUT、DELETE）進行 CRUD 操作。

• 當您需要單獨的服務/應用程式之間簡單、統一的介面時，它可以很好地發揮作用。

• 快取策略很容易實現。

• 缺點是可能需要多次往返才能從不同的端點收集相關資料。

GraphQL

• 為客戶提供單一端點，以便其精確查詢所需的資料。

• 客戶端指定嵌套查詢中所需的精確字段，伺服器傳回僅包含這些字段的最佳化負載。

• 支援修改資料的變異和即時通知的訂閱。

• 非常適合聚合來自多個來源的資料，並且可以很好地滿足快速發展的前端需求。

• 然而，它將複雜性轉移到了客戶端，如果沒有適當的保護，可能會允許濫用查詢

• 快取策略可能比 REST 更複雜。

REST 和 GraphQL 之間的最佳選擇取決於應用程式和開發團隊的特定要求。 GraphQL 非常適合複雜或頻繁變化的前端需求，而 REST 適合需要簡單且一致的契約的應用程式。

這兩種 API 方法都不是靈丹妙藥。仔細評估需求和權衡對於選擇正確的風格非常重要。 REST 和 GraphQL 都是公開資料和支援現代應用程式的有效選擇。

gRPC 如何運作？

RPC（Remote Procedure Call）之所以被稱為“遠端”，是因為它能夠在微服務架構下，當服務部署到不同的伺服器時，實現遠端服務之間的通訊。從使用者的角度來看，它就像一個本地函數呼叫。

下圖說明了gRPC的整體資料流。

步驟 1：從客戶端發出 REST 呼叫。請求主體通常為JSON格式。

步驟2-4：訂單服務（gRPC客戶端）接收REST呼叫，進行轉換，並向支付服務發出RPC呼叫。 gRPC 將客戶端存根編碼為二進位格式並將其傳送至低階傳輸層。

步驟5：gRPC透過HTTP2透過網路傳送封包。由於二進位編碼和網路優化，據說 gRPC 比 JSON 快 5 倍。

步驟 6 - 8：支付服務（gRPC 伺服器）從網路接收資料包、對其進行解碼並呼叫伺服器應用程式。

步驟 9 - 11：結果從伺服器應用程式返回，並進行編碼並發送到傳輸層。

步驟 12 - 14：訂單服務接收資料包、解碼並將結果傳送給客戶端應用程式。

什麼是 webhook？

下圖顯示了輪詢和 Webhook 之間的比較。

假設我們經營一個電子商務網站。用戶端透過API網關將訂單傳送至訂單服務，訂單服務到支付服務進行支付交易。然後，支付服務與外部支付服務提供者 (PSP) 對話以完成交易。

有兩種方法可以處理與外部 PSP 的通訊。

1. 簡短輪詢

支付服務向PSP發送付款請求後，不斷向PSP詢問付款狀態。經過幾輪之後，PSP終於回到狀態。

短輪詢有兩個缺點：

• 不斷輪詢狀態需要支付服務的資源。

• 外部服務直接與支付服務通信，產生安全漏洞。

2. Webhook

我們可以向外部服務註冊一個 webhook。意思是：當請求有更新時，透過某個 URL 給我回電。當PSP完成處理後，它將呼叫HTTP請求來更新付款狀態。

這樣，程式設計範式就發生了改變，支付服務不再需要浪費資源去輪詢付款狀態。

如果 PSP 不再回電會怎麼樣？我們可以設定一項管理工作來每小時檢查一次付款狀態。

Webhook 通常被稱為反向 API 或推送 API，因為伺服器會向客戶端發送 HTTP 請求。使用 webhook 時我們需要注意 3 件事：

1. 我們需要設計一個合適的API供外部服務呼叫。

2. 出於安全原因，我們需要在 API 閘道中設定適當的規則。

3. 我們需要在外部服務上註冊正確的URL。

如何提高API效能？

下圖展示了 5 個提升 API 效能的常見技巧。

分頁

當結果規模很大時，這是一種常見的最佳化。結果將傳回客戶端以提高服務回應能力。

非同步日誌記錄

同步日誌記錄會處理每次呼叫的磁碟，並可能降低系統速度。非同步日誌記錄首先將日誌傳送到無鎖緩衝區並立即傳回。日誌將定期刷新到磁碟。這顯著減少了 I/O 開銷。

快取

我們可以將經常存取的資料儲存到快取中。客戶端可以先查詢緩存，而不是直接存取資料庫。如果發生快取未命中，用戶端可以從資料庫查詢。像Redis這樣的快取將資料儲存在記憶體中，因此資料存取比資料庫快得多。

有效載荷壓縮

可以使用 gzip 等壓縮請求和回應，以便傳輸的資料大小更小。這加快了上傳和下載速度。

連接池

在存取資源的時候，我們經常需要從資料庫載入資料。開啟和關閉資料庫連線會增加很大的開銷。因此我們應該透過開放連接池連接到資料庫。連接池負責管理連線生命週期。

HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0（QUIC）

每一代HTTP都解決了什麼問題？

下圖說明了其主要特徵。

• HTTP 1.0 於 1996 年完成並有完整的文件。

• HTTP 1.1 於 1997 年發布。

HOL blocking - when the number of allowed parallel requests in the browser is used up, subsequent requests need to wait for the former ones to complete.

• HTTP 2.0於2015年發布，透過請求多路復用來解決HOL問題，消除了應用層的HOL阻塞，但是傳輸（TCP）層的HOL仍然存在。

As you can see in the diagram, HTTP 2.0 introduced the concept of HTTP “streams”: an abstraction that allows multiplexing different HTTP exchanges onto the same TCP connection. Each stream doesn’t need to be sent in order.

• HTTP 3.0 第一稿於 2020 年發布。它使用 QUIC 而不是 TCP 作為底層傳輸協議，從而消除了傳輸層的 HOL 阻塞。

QUIC是基於UDP。它將流作為傳輸層的一等公民引入。 QUIC 流共享相同的 QUIC 連接，因此不需要額外的握手和慢啟動來建立新的流，但是 QUIC 流是獨立傳送的，因此在大多數情況下影響一個流的資料包丟失不會影響其他流。

SOAP、REST、GraphQL、RPC 的比較

下圖說明了 API 時間軸和 API 樣式比較。

隨著時間的推移，不同的 API 架構風格被發布。他們各自都有自己的標準化資料交換模式。

您可以在圖表中查看每種風格的用例。

[](/ByteByteGoHq/system-design-101/blob/main/RESTges/SOAPr.

程式碼優先與 API 優先

下圖展示了程式碼優先開發和API優先開發之間的差異。為什麼我們要先考慮 API 設計？

• 微服務增加了系統複雜性，我們有單獨的服務來滿足系統的不同功能。雖然這種架構有利於解耦和職責分離，但我們需要處理服務之間的各種通訊。

最好在編寫程式碼之前仔細考慮系統的複雜性並仔細定義服務的邊界。

• 獨立的職能團隊需要使用相同的語言，而專門的職能團隊只負責自己的元件和服務。建議組織透過 API 設計使用相同的語言。

在編寫程式碼之前，我們可以模擬請求和回應來驗證 API 設計。

• 提高軟體品質和開發人員的工作效率由於我們在專案啟動時已經解決了大部分不確定因素，因此整體開發過程更加順暢，軟體品質也得到了很大的提高。

開發人員對這個過程也感到滿意，因為他們可以專注於功能開發，而不是處理突然的變化。

專案生命週期結束時出現意外的可能性減少了。

因為我們先設計了 API，所以可以在開發程式碼時設計測試。從某種程度上來說，我們在使用 API 優先開發時也有 TDD（測試驅動設計）。

HTTP 狀態碼

HTTP 的回應程式碼分為五類：

訊息 (100-199) 成功 (200-299) 重新導向 (300-399) 用戶端錯誤 (400-499) 伺服器錯誤 (500-599)

API 網關有什麼作用？

下圖顯示了詳細資訊。

步驟 1-客戶端向 API 網關發送 HTTP 請求。

步驟 2 - API 網關解析並驗證 HTTP 請求中的屬性。

步驟 3——API 閘道執行允許清單/拒絕清單檢查。

步驟 4-API 網關與身分提供者對話以進行身份驗證和授權。

步驟 5－速率限制規則應用於請求。如果超出限制，請求將被拒絕。

步驟 6 和 7 - 現在請求已經通過了基本檢查，API 網關透過路徑匹配找到要路由到的相關服務。

步驟8-API網關將請求轉換為適當的協定並將其傳送到後端微服務。

步驟9-12：API網關能夠正確處理錯誤，如果錯誤需要較長時間才能恢復（斷路），則處理故障。它還可以利用 ELK（Elastic-Logstash-Kibana）堆疊進行日誌記錄和監控。我們有時會在 API 網關中快取資料。

我們如何設計有效且安全的 API？

下圖以購物車範例展示了典型的 API 設計。

請注意，API 設計不僅僅是 URL 路徑設計。大多數時候，我們需要選擇適當的資源名稱、辨識碼和路徑模式。設計適當的 HTTP 標頭欄位或在 API 閘道內設計有效的速率限制規則同樣重要。

TCP/IP 封裝

資料如何透過網路傳送？為什麼需要 OSI 模型中的這麼多層？

下圖顯示了資料在網路傳輸時如何封裝和解封裝。

[](/ByteByteGoHq/system-design-101/blob/main/images/osi 模型.jpeg)

步驟1：當設備A透過HTTP協定透過網路傳送資料到設備B時，首先在應用層新增HTTP標頭。

第 2 步：然後將 TCP 或 UDP 報頭新增至資料。它在傳輸層被封裝成 TCP 段。標頭包含來源連接埠、目標連接埠和序號。

步驟 3：然後在網路層用 IP 標頭封裝這些段。 IP 標頭包含來源/目標 IP 位址。

步驟4：IP資料封包在資料鏈結層新增MAC頭，其中包含來源/目標MAC位址。

步驟5：封裝的訊框被傳送到實體層並以二進位位元的形式透過網路傳送。

步驟6-10：當設備B從網路接收到位時，它將執行解封裝過程，這是封裝過程的逆過程。資料包一層層移除，最終設備B就可以讀取資料了。

我們需要網路模型中的層，因為每一層都專注於自己的職責。每一層都可以依靠頭部來處理指令，而不需要知道上一層資料的意義。

為什麼 Nginx 被稱為「反向」代理？

下圖顯示了 ���𝐨𝐫𝐰𝐚𝐫𝐝 𝐩𝐫𝐨𝐱𝐲 和 𝐫𝐞𝐯𝐞

[\](/ByteByteGoHq/system-design-101/blob/main/images/正向代理與反向代理2x.jpg)

正向代理是位於用戶設備和網際網路之間的伺服器。

正向代理通常用於：

1. 保護客戶

2. 繞過瀏覽限制

3. 阻止存取某些內容

反向代理程式是一種伺服器，它接受來自客戶端的請求，將請求轉發到 Web 伺服器，並將結果傳回給客戶端，就好像代理伺服器已處理該請求一樣。

反向代理適用於：

1. 保護伺服器

2. 負載平衡

3. 快取靜態內容

4. 加密和解密 SSL 通信

常見的負載平衡演算法有哪些？

下圖展示了6種常見的演算法。

• 靜態演算法

1. 循環賽

The client requests are sent to different service instances in sequential order. The services are usually required to be stateless.

2. 黏性循環

This is an improvement of the round-robin algorithm. If Alice’s first request goes to service A, the following requests go to service A as well.

3. 加權循環

The admin can specify the weight for each service. The ones with a higher weight handle more requests than others.

4. 哈希

This algorithm applies a hash function on the incoming requests’ IP or URL. The requests are routed to relevant instances based on the hash function result.

• 動態演算法

5. 最少連接

A new request is sent to the service instance with the least concurrent connections.

6. 最短回應時間

A new request is sent to the service instance with the fastest response time.

URL、URI、URN——您知道它們之間的差異嗎？

下圖顯示了 URL、URI 和 URN 的比較。

• 類型

URI 代表統一資源辨識碼。它標識網路上的邏輯或物理資源。 URL 和 URN 是 URI 的子類型。 URL用於定位資源，URN用於命名資源。

URI 由以下部分組成：scheme:[//authority]path[?query][#fragment]

• 網址

URL 代表統一資源定位器，是 HTTP 的關鍵概念。它是網路上唯一資源的位址。它可以與其他協定（如 FTP 和 JDBC）一起使用。

• 甕

URN 代表統一資源名稱。它採用了 urn 方案。 URN 不能用於定位資源。圖中給出的一個簡單範例由命名空間和特定於命名空間的字串組成。

如果您想了解有關該主題的更多詳細訊息，我建議您查看W3C 的澄清。

持續整合/持續交付

簡單解釋 CI/CD 管道

第 1 部分 - 使用 CI/CD 的 SDLC

軟體開發生命週期 (SDLC) 包括幾個關鍵階段：開發、測試、部署和維護。 CI/CD 自動化並整合這些階段，以實現更快、更可靠的發布。

當程式碼被推送到 git 儲存庫時，它會觸發自動建置和測試過程。執行端對端 (e2e) 測試案例來驗證程式碼。如果測試通過，程式碼可以自動部署到暫存/生產階段。如果發現問題，程式碼將發回開發部門進行錯誤修復。這種自動化可以為開發人員提供快速回饋，並降低生產中出現錯誤的風險。

第 2 節 - CI 和 CD 之間的區別

持續整合 (CI) 自動化了建置、測試和合併流程。每當提交程式碼時它都會執行測試以便儘早發現整合問題。這鼓勵頻繁的程式碼提交和快速的回饋。

持續交付 (CD) 自動化了基礎架構變更和部署等發布流程。它確保軟體可以透過自動化的工作流程隨時可靠地發布。 CD 還可以自動化生產部署前所需的手動測試和批准步驟。

第 3 部分 - CI/CD 管道

典型的 CI/CD 管道有幾個連接的階段：

• 開發人員將程式碼變更提交到原始碼管理

• CI 伺服器偵測到變更並觸發建置

• 程式碼已編譯並測試（單元測試、整合測試）

• 測試結果報告給開發人員

• 成功後，工件將部署到暫存環境

• 發布前可能會進行進一步的測試

• CD 系統將核准的變更部署到生產中

Netflix 技術堆疊（CI/CD 管道）

規劃：Netflix Engineering 使用 JIRA 進行規劃，使用 Confluence 進行文件編制。

編碼：Java 是後端服務的主要程式語言，而其他語言則用於不同的用例。

建置：Gradle 主要用於建置，並且建置了 Gradle 插件來支援各種用例。

打包：將套件和相依性打包到 Amazon Machine Image (AMI) 中以供發布。

測試：測試強調生產文化對建構混沌工具的關注。

部署：Netflix採用自建的Spinnaker進行金絲雀發布部署。

監控：監控指標集中在 Atlas 中，並使用 Kayenta 偵測異常。

事件上報：依照優先等級調度事件，使用PagerDuty進行事件處理。

架構模式

MVC、MVP、MVVM、MVVM-C 與 VIPER

這些架構模式是應用程式開發中最常用的模式，無論是在 iOS 還是 Android 平台上。開發人員引入它們是為了克服早期模式的限制。那麼，它們有何不同？

[](/ByteByteGoHq/system-design-101/blob/main/images/client arch patterns.png)

• MVC 是最古老的模式，已有近 50 年歷史

• 每個模式都有一個「視圖」（V），負責顯示內容和接收使用者輸入

• 大多數模式都包含一個「模型」（M）來管理商業資料

• 「控制器」、「演示者」和「視圖模型」是視圖和模型（VIPER 模式中的「實體」）之間的中介

每個開發人員都應該知道的 18 個關鍵設計模式

模式是常見設計問題的可重複使用的解決方案，可以使開發過程更加順暢、更有效率。它們是建構更好的軟體結構的藍圖。以下是一些最受歡迎的模式：

• 抽象工廠：家庭創造者－將相關物品分組。

• 建造者：樂高大師－一步步建造物體，將創造與外觀分開。

• 原型：克隆製作器－建立已準備好的範例的副本。

• 單例：唯一 - 只有一個實例的特殊類別。

• 適配器：通用插頭－連接具有不同介面的東西。

• 橋樑：功能連接器 - 將物件的工作方式與其功能連結。

• 複合：樹生成器－形成由簡單和複雜部分組成的樹狀結構。

• 裝飾器：定制器－在不改變物件核心的情況下為其加入功能。

• 外觀：一站式服務 - 代表具有單一、簡化介面的整個系統。

• Flyweight：節省空間 - 高效共享小型、可重複使用的物品。

• 代理：替身演員 - 代表另一個物件，控制存取或操作。

• 責任鏈：請求中繼 - 透過物件鏈傳遞請求直至處理為止。

• 指令：任務包裝器 - 將請求轉換為物件，準備採取行動。

• 迭代器：集合資源管理器 - 逐一存取集合中的元素。

• 中介：通訊中心－簡化不同類別之間的互動。

• 紀念品：時間膠囊－捕捉並恢復物體的狀態。

• 觀察者：新聞廣播員－向類別通報其他物件所發生的變化。

• 訪客：熟練的客人 - 在不改變類別的情況下向其加入新的操作。

資料庫

一份關於雲端服務中不同資料庫的詳細清單

為您的專案選擇正確的資料庫是一項複雜的任務。許多資料庫選項都適用於不同的用例，很快就會導致決策疲勞。

我們希望這份備忘錄能夠提供高層的指導，幫助您找到符合您專案需求的正確服務並避免潛在的陷阱。

注意：Google 對其資料庫用例的文件有限。儘管我們盡力查看可用資訊並得出最佳選擇，但某些條目可能需要更加準確。

為資料庫提供動力的 8 種資料結構

答案將根據你的使用情況而有所不同。資料可以在記憶體或磁碟中被索引。同樣，資料格式也多種多樣，例如數字、字串、地理座標等。所有這些因素都會影響您對資料庫索引格式的選擇。

以下是用於索引資料的一些最受歡迎的資料結構：

• Skiplist：一種常見的記憶體索引類型。在 Redis 中使用

• 哈希索引：“Map”資料結構（或“Collection”）的一種非常常見的實現

• SSTable：不可變的磁碟「Map」實現

• LSM 樹：Skiplist + SSTable。高寫入吞吐量

• B 樹：基於磁碟的解決方案。一致的讀/寫效能

• 倒排索引：用於文件索引。用於 Lucene

• 後綴樹：用於字串模式搜尋

• R樹：多維搜尋，例如查找最近鄰居

SQL語句在資料庫中是如何執行的？

下圖顯示了該過程。請注意，不同資料庫的架構不同，該圖演示了一些常見的設計。

[](/ByteByteGoHq/system-design-101/blob/main/images/dbdb 中的 ges 執行順序。

步驟 1-透過傳輸層協定（例如TCP）將SQL語句傳送到資料庫。

步驟 2 - SQL 語句被傳送到命令解析器，在那裡它經過句法和語義分析，然後產生查詢樹。

步驟 3－查詢樹被傳送給優化器。優化器建立一個執行計劃。

步驟4-執行計劃發送給執行者。執行器從執行中檢索資料。

步驟 5-存取方法提供執行所需的資料擷取邏輯，從儲存引擎檢索資料。

步驟 6-存取方法決定 SQL 語句是否是唯讀的。如果查詢是唯讀的（SELECT 語句），則會將其傳遞給緩衝區管理器進行進一步處理。緩衝區管理器在快取或資料檔案中尋找資料。

步驟 7 - 如果該語句是 UPDATE 或 INSERT，則將其傳遞給事務管理器進行進一步處理。

步驟8－在交易期間，資料處於鎖定模式。這是由鎖管理器保證的。它還確保了交易的 ACID 特性。

CAP 定理

CAP 定理是計算機科學中最著名的術語之一，但我相信不同的開發人員有不同的理解。讓我們分析一下它是什麼以及為什麼它會造成混淆。

[](/ByteByteGoHq/system-design-101/blob/main/images/cap theorem.jpeg)

CAP 定理指出分散式系統不能同時提供這三個保證中的兩個以上。

一致性：一致性意味著無論所有客戶端連接到哪個節點，它們都會同時看到相同的資料。

可用性：可用性意味著即使某些節點發生故障，任何請求資料的客戶端都會得到回應。

分區容忍度：分區表示兩個節點之間的通訊中斷。分區容忍度意味著即使出現網路分區，系統仍能繼續運作。

“2 之 3” 公式可能有用，但這種簡化可能會產生誤導。

1. 選擇資料庫並不容易。僅僅基於 CAP 定理來證明我們的選擇是不夠的。例如，公司不會僅僅因為 Cassandra 是一個 AP 系統就選擇它用於聊天應用程式。 Cassandra 具有一系列優良特性，是儲存聊天訊息的理想選擇。我們需要深入挖掘。

2. 「CAP 僅禁止設計空間的一小部分：在存在分區的情況下實現完美的可用性和一致性，但這種情況很少見」。摘自論文：CAP十二年後：「規則」如何改變。

3. 該定理是關於 100% 的可用性和一致性。更現實的討論是當沒有網路分區時延遲和一致性之間的權衡。有關更多詳細訊息，請參閱 PACELC 定理。

CAP 定理真的有用嗎？

我認為它仍然是有用的，因為它開闊了我們的視野，讓我們能夠進行一系列權衡討論，但這只是故事的一部分。在選擇正確的資料庫時，我們需要深入挖掘。

記憶體和儲存的類型

視覺化 SQL 查詢

資料庫系統分幾個步驟執行SQL語句，包括：

• 解析 SQL 語句並檢查其有效性

• 將 SQL 轉換為內部表示，例如關係代數

• 優化內部表示並建立利用索引資訊的執行計劃

• 執行計劃並傳回結果

SQL的執行非常複雜，涉及許多注意事項，例如：

• 索引和快取的使用

• 表連接的順序

• 並發控制

• 交易管理

SQL 語言

1986年，SQL（結構化查詢語言）成為標準。在接下來的 40 年裡，它成為關聯式資料庫管理系統的主導語言。閱讀最新標準（ANSI SQL 2016）可能很耗時。我怎樣才能學會它？

SQL 語言有 5 個組成部分：

• DDL：資料定義語言，例如 CREATE、ALTER、DROP

• DQL：資料查詢語言，例如 SELECT

• DML：資料操作語言，例如 INSERT、UPDATE、DELETE

• DCL：資料控制語言，例如GRANT、REVOKE

• TCL：事務控制語言，例如COMMIT、ROLLBACK

對於後端工程師來說，你可能需要了解其中的大部分內容。作為資料分析師，您可能需要對 DQL 有充分的了解。選擇與您最相關的主題。

快取

資料緩存在各處

該圖說明了我們在典型架構中快取資料的位置。

[\](/ByteByteGoHq/system-design-101/blob/main/images/我們在哪裡快取資料.jpeg)

沿著流動方向有多個層。

1. 客戶端應用程式：HTTP 回應可以被瀏覽器快取。我們第一次透過 HTTP 請求資料，並在 HTTP 標頭中返回過期策略；我們再次請求資料，客戶端應用程式首先嘗試從瀏覽器快取中檢索資料。

2. CDN：CDN 快取靜態網路資源。客戶端可以從附近的 CDN 節點檢索資料。

3. 負載平衡器：負載平衡器也可以快取資源。

4. 訊息傳遞基礎設施：訊息代理首先將訊息儲存在磁碟上，然後消費者以自己的速度檢索它們。根據保留策略，資料會在 Kafka 叢集中快取一段時間。

5. 服務：服務中有多層快取。如果資料未快取在 CPU 快取中，服務將嘗試從記憶體中檢索資料。有時服務具有二級快取來將資料儲存在磁碟上。

6. 分散式快取：像 Redis 這樣的分散式快取在記憶體中保存多個服務的鍵值對。它提供了比資料庫更好的讀/寫效能。

7. 全文搜尋：我們有時需要使用全文搜尋，例如 Elastic Search 進行文件搜尋或日誌搜尋。資料的副本也被編入搜尋引擎索引。

8. 資料庫：即使在資料庫中，我們也有不同層級的快取：

• WAL(Write-ahead Log)：在建立B樹索引之前，先將資料寫入WAL

• 緩衝池：分配用於快取查詢結果的記憶體區域

• 物化視圖：預先計算查詢結果並將其儲存在資料庫表中，以獲得更好的查詢效能

• 交易日誌：記錄所有交易和資料庫更新

• 複製日誌：用於記錄資料庫叢集中的複製狀態

Redis 為何這麼快？

如下圖所示，主要有 3 個原因。

1. Redis 是一個基於 RAM 的資料儲存。 RAM 存取比隨機磁碟存取快至少 1000 倍。

2. Redis 利用 IO 多路復用和單執行緒執行迴圈來提高執行效率。

3. Redis 利用了幾種高效的低階資料結構。

問題：另一個流行的記憶體儲存是 Memcached。你知道 Redis 和 Memcached 之間的差異嗎？

您可能已經注意到該圖表的風格與我之前的帖子不同。請告訴我您比較喜歡哪一個。

Redis 如何使用？

Redis 不僅僅只是快取。

Redis 可用於多種場景，如圖所示。

• 會議

We can use Redis to share user session data among different services.

• 快取

We can use Redis to cache objects or pages, especially for hotspot data.

• 分散式鎖

We can use a Redis string to acquire locks among distributed services.

• 櫃檯

We can count how many likes or how many reads for articles.

• 速率限制器

We can apply a rate limiter for certain user IPs.

• 全域 ID 產生器

We can use Redis Int for global ID.

• 購物車

We can use Redis Hash to represent key-value pairs in a shopping cart.

• 計算用戶留存率

We can use Bitmap to represent the user login daily and calculate user retention.

• 訊息佇列

We can use List for a message queue.

• 排行

We can use ZSet to sort the articles.

頂級快取策略

設計大型系統通常需要仔細考慮快取。以下是五種經常使用的快取策略。

微服務架構

典型的微服務架構是什麼樣的呢？

下圖展示了典型的微服務架構。

• 負載平衡器：它將傳入的流量分配到多個後端服務之間。

• CDN（內容分發網路）：CDN 是一組地理分佈的伺服器，用於保存靜態內容以便更快分發。客戶端首先在 CDN 中尋找內容，然後再進入後端服務。

• API 閘道：處理傳入的請求並將其路由至相關服務。它與身分提供者和服務發現進行對話。

• 身分提供者：負責處理使用者的身分驗證和授權。

• 服務註冊與發現：微服務註冊和發現發生在此元件中，API 閘道在此元件中尋找相關服務進行通訊。

• 管理：此元件負責監控服務。

• 微服務：微服務在不同的領域進行設計和部署。每個網域都有自己的資料庫。 API閘道透過REST API或其他協定與微服務通信，同一域內的微服務使用RPC（遠端過程呼叫）相互通訊。

微服務的好處：

• 它們可以快速設計、部署和水平擴展。

• 每個域可以由專門的團隊獨立維護。

• 因此，可以在每個領域自訂業務需求並獲得更好的支援。

微服務最佳實踐

一圖勝千言：開發微服務的 9 個最佳實踐。

在開發微服務時，我們需要遵循以下最佳實務：

1. 為每個微服務使用單獨的資料存儲

2. 保持程式碼的成熟度相似

3. 為每個微服務單獨建置

4. 為每個微服務分配單一職責

5. 部署到容器中

6. 設計無狀態服務

7. 採用領域驅動設計

8. 設計微前端

9. 編排微服務

微服務通常使用什麼技術棧？

下面您將看到一個顯示微服務技術堆疊的圖表，包括開發階段和生產階段。

▶️ 基礎護理

• 定義 API－這在前端和後端之間建立了契約。我們可以為此使用 Postman 或 OpenAPI。

• 開發 - Node.js 或 react 適用於前端開發，而 java/python/go 適用於後端開發。另外，我們需要根據API定義來更改API網關中的設定。

• 持續整合－JUnit 和 Jenkins 用於自動化測試。將程式碼打包成Docker映像並部署為微服務。

▶️ 基礎訊息

• NGinx 是負載平衡器的常見選擇。 Cloudflare 提供 CDN（內容傳遞網路）。

• API 網關 - 我們可以使用 spring boot 作為網關，並使用 Eureka/Zookeeper 進行服務發現。

• 微服務部署在雲端。我們可以在 AWS、Microsoft Azure 或 Google GCP 中進行選擇。快取和全文搜尋 - Redis 是快取鍵值對的常見選擇。 Elasticsearch 用於全文搜尋。

• 通信 - 為了使服務相互通信，我們可以使用訊息傳遞基礎設施 Kafka 或 RPC。

• 持久性 - 我們可以使用 MySQL 或 PostgreSQL 作為關聯式資料庫，使用 Amazon S3 作為物件儲存。如果有必要，我們也可以使用 Cassandra 進行寬列儲存。

• 管理和監控—為了管理如此多的微服務，常見的 Ops 工具包括 Prometheus、Elastic Stack 和 Kubernetes。

為什麼Kafka速度很快

許多設計決策影響了 Kafka 的性能。在這篇文章中，我們將重點放在兩點。我們認為這兩項最有影響力。

1. 第一個是 Kafka 對順序 I/O 的依賴。

2. 使Kafka具有性能優勢的第二個設計選擇是其對效率的關注：零拷貝原則。

該圖說明了資料在生產者和消費者之間是如何傳輸的，以及零拷貝的含義。

• 步驟1.1 - 1.3：生產者將資料寫入磁碟

• 步驟2：消費者不使用零拷貝讀取資料

2.1 資料從磁碟載入到OS快取

2.2 資料從OS快取複製到Kafka應用程式

2.3 Kafka應用程式將資料複製到套接字緩衝區

2.4 資料從socket緩衝區複製到網路卡

2.5 網路卡向消費者發送資料

• 步驟3：消費者使用零拷貝讀取資料

3.1：資料從磁碟載入到OS快取中 3.2 OS快取透過sendfile()指令直接將資料複製到網路卡 3.3 網路卡將資料傳送給消費者

零拷貝是節省應用程式上下文和核心上下文之間多次資料拷貝的一條捷徑。

支付系統

如何學習支付系統？

信用卡為何被稱為「銀行最賺錢的產品」？ VISA/Mastercard 如何賺錢？

下圖顯示了信用卡支付流程的經濟原理。

[](/ByteByteGoHq/system-design-101/blob/main/images/visa 如何賺錢.jpg)

1. 持卡人向商家支付 100 美元購買產品。

2.商家受惠於使用銷售量較高的信用卡，需要支付發卡機構和卡片網路提供支付服務的報酬。收單銀行向商家收取一項費用，稱為「商家折扣費」。

3 - 4. 收單銀行保留 0.25 美元作為收單加價，並向發卡銀行支付 1.75 美元作為交換費。商家折扣費應該涵蓋交換費。

交換費由卡片網路設定，因為每家發卡銀行與每個商家協商費用效率較低。

5. 卡網路與各家銀行約定網路評估及費用，各銀行每月向卡片網路支付服務費。例如，VISA 對每次刷卡收取 0.11% 的評估費，外加 0.0195 美元的使用費。

6.持卡人向發卡銀行支付服務費用。

開證行為什麼要得到賠償？

• 即使持卡人未能向發卡機構付款，發卡機構也會向商家付款。

• 發卡機構先向商家付款，然後持卡人再向發卡機構付款。

• 發行人還有其他營運成本，包括管理客戶帳戶、提供報表、詐欺偵測、風險管理、清算和結算等。

當我們在商家店鋪刷信用卡時 VISA 如何運作？

VISA、萬事達卡和美國運通卡作為資金清算和結算的卡片網路。信用卡收單銀行和信用卡發卡銀行可能 (而且通常是) 不同。如果銀行在沒有中介的情況下逐一結算交易，則每家銀行都必須與所有其他銀行結算交易。這是非常低效的。

下圖顯示了VISA在信用卡支付過程中所扮演的角色。其中涉及兩個流程。當客戶刷信用卡時，授權流程發生。當商家想要在一天結束時獲得金錢時，就會發生捕獲和結算流程。

• 授權流程

步驟0：發卡銀行向客戶發行信用卡。

步驟1：持卡人想要購買產品，並在商家的銷售點（POS）終端機上刷信用卡。

步驟 2：POS 終端將交易傳送給提供 POS 終端機的收單銀行。

步驟 3 和 4：收單銀行將交易傳送到卡片網路（也稱為卡片計畫）。卡網路將交易發送給發卡銀行進行批准。

步驟 4.1、4.2 和 4.3：如果交易獲得批准，發卡銀行將凍結資金。批准或拒絕的資訊將發送回收單機構以及 POS 終端。

• 捕獲和結算流程

步驟 1 和 2：商家想要在一天結束時收取錢款，因此他們在 POS 終端機上點擊「捕獲」。交易被大量發送給收單機構。收單機構將包含交易的批次文件傳送至卡片網路。

步驟3：卡片網路對從不同收單機構收集的交易進行清算，並將清算文件發送給不同的發卡銀行。

步驟4：發卡銀行確認清算文件的正確性，並將款項轉入相關收單銀行。

第 5 步：收單銀行隨後將資金轉入商家銀行。

步驟4：卡片網路清算來自不同收單銀行的交易。清算是將相互抵銷的交易進行淨額結算的過程，因此總交易數量會減少。

在此過程中，信用卡網路承擔與各家銀行溝通的負擔，並收取服務費。

全球支付系統系列（第 1 部分）：印度的統一支付介面 (UPI)

什麼是 UPI？ UPI 是由印度國家支付公司開發的即時即時支付系統。

它佔目前印度數位零售交易的60%。

UPI = 支付標記語言 + 可互通支付標準

DevOps

DevOps 與 SRE 與平台工程。有什麼區別？

DevOps、SRE 和平台工程的概念出現在不同的時期，並由不同的個人和組織開發。

DevOps 這個概念由 Patrick Debois 和 Andrew Shafer 於 2009 年在敏捷會議上提出。他們試圖透過促進協作文化和整個軟體開發生命週期的共擔責任來彌合軟體開發與營運之間的差距。

SRE，即站點可靠性工程，由 Google 於 21 世紀初率先推出，用於解決管理大規模複雜系統時遇到的營運挑戰。 Google 開發了 SRE 實踐和工具，例如 Borg 叢集管理系統和 Monarch 監控系統，以提高其服務的可靠性和效率。

平台工程是一個較新的概念，建立在 SRE 工程的基礎上。平台工程的確切起源尚不清楚，但通常將其理解為 DevOps 和 SRE 實踐的延伸，專注於提供支援整個業務視角的綜合產品開發平台。

值得注意的是，雖然這些概念出現的時間不同。它們都與提高軟體開發和營運的協作、自動化和效率的更廣泛趨勢有關。

什麼是 k8s (Kubernetes)？

K8s是一個容器編排系統。用於容器的部署和管理。其設計深受Google內部系統Borg的影響。

k8s 叢集由一組執行容器化應用程式的工作機器（稱為節點）組成。每個叢集至少有一個工作節點。

工作節點託管作為應用程式工作負載元件的 Pod。控制平面管理叢集中的工作節點和 Pod。在生產環境中，控制平面通常會跨多台電腦執行，叢集通常執行多個節點，提供容錯和高可用性。

• 控制平面元件

1. API 伺服器

The API server talks to all the components in the k8s cluster. All the operations on pods are executed by talking to the API server.

2. 調度器

The scheduler watches pod workloads and assigns loads on newly created pods.

3. 控制器管理器

The controller manager runs the controllers, including Node Controller, Job Controller, EndpointSlice Controller, and ServiceAccount Controller.

4. Etcd

etcd is a key-value store used as Kubernetes' backing store for all cluster data.

• 節點

1. Pod

A pod is a group of containers and is the smallest unit that k8s administers. Pods have a single IP address applied to every container within the pod.

2. 庫貝萊特

An agent that runs on each node in the cluster. It ensures containers are running in a Pod.

3. 成為代理人

Kube-proxy is a network proxy that runs on each node in your cluster. It routes traffic coming into a node from the service. It forwards requests for work to the correct containers.

Docker 與 Kubernetes。我們應該使用哪一個？

什麼是 Docker？

Docker 是一個開源平台，可讓您在隔離的容器中打包、分發和執行應用程式。它專注於容器化，提供封裝應用程式及其相依性的輕量級環境。

什麼是 Kubernetes？

Kubernetes，通常稱為K8s，是一個開源容器編排平台。它提供了一個框架，用於自動在節點叢集中部署、擴展和管理容器化應用程式。

兩者有何不同？

Docker：Docker 在單一作業系統主機上的單一容器層級運作。

您必須手動管理每個主機，並且為多個相關容器設定網路、安全性原則和儲存可能會很複雜。

Kubernetes：Kubernetes 在叢集層級運作。它管理跨多個主機的多個容器化應用程式，為負載平衡、擴展和確保應用程式所需狀態等任務提供自動化。

簡而言之，Docker 專注於容器化和在單一主機上執行容器，而 Kubernetes 則專注於在主機叢集中大規模管理和編排容器。

Docker 如何運作？

下圖展示了 Docker 的架構以及我們在執行「docker build」、「docker pull」和「docker run」時它的工作原理。

Docker 架構中有 3 個元件：

• Docker 用戶端

The docker client talks to the Docker daemon.

• Docker 主機

The Docker daemon listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes.

• Docker 註冊表

A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use.

我們以「docker run」指令為例。

1. Docker 從登錄中提取映像。

2. Docker 建立一個新容器。

3. Docker 為容器指派一個讀寫檔案系統。

4. Docker 建立一個網路介面以將容器連接到預設網路。

5. Docker 啟動容器。

胃腸道疾病

Git 指令如何運作

首先，必須確定我們的程式碼儲存在哪裡。常見的假設是只有兩個位置 - 一個在像 Github 這樣的遠端伺服器上，另一個在我們的本地機器上。但這並不完全準確。 Git 在我們的機器上維護三個本地存儲，這意味著我們的程式碼可以在四個地方找到：

• 工作目錄：我們編輯檔案的地方

• 暫存區：儲存文件以供下次提交的臨時位置

• 本機儲存庫：包含已提交的程式碼

• 遠端儲存庫：儲存程式碼的遠端伺服器

大多數 Git 指令主要在這四個位置之間移動檔案。

Git 如何運作？

下圖展示了 Git 工作流程。

Git 是分散式版本控制系統。

每個開發人員都會維護主儲存庫的本機副本，並編輯和提交本機副本。

提交非常快，因為操作不與遠端儲存庫互動。

如果遠端儲存庫崩潰，則可以從本機儲存庫復原檔案。

Git 對比Git 變基

有什麼區別？

當我們將變更從一個 Git 分支合併到另一個 Git 分支時，我們可以使用「git merge」或「git rebase」。下圖顯示了這兩個命令的工作原理。

Git 合併

這會在主分支中建立一個新的提交 G'。 G' 將主分支和功能分支的歷史記錄連結起來。

Git 合併是非破壞性的。主分支和功能分支均未改變。

Git 變基

Git rebase 將功能分支歷史記錄移至主分支的頭部。它為功能分支中的每個提交建立新的提交 E'、F' 和 G'。

rebase 的好處是它具有線性的提交歷史。

如果不遵循“git rebase 的黃金法則”，Rebase 可能會很危險。

Git Rebase 的黃金法則

切勿在公共分支上使用它！

雲端服務

不同雲端服務的實用小抄（2023 年版）

什麼是雲端原生？

下面的圖表展示了 20 世紀 80 年代以來架構和流程的演變。

組織可以使用雲端原生技術在公有雲、私有雲和混合雲上建置和執行可擴展的應用程式。

這意味著這些應用程式旨在利用雲端功能，因此它們具有負載彈性且易於擴展。

雲端原生包括4個面向：

1. 開發流程

This has progressed from waterfall to agile to DevOps.

2. 應用程式架構

The architecture has gone from monolithic to microservices. Each service is designed to be small, adaptive to the limited resources in cloud containers.

3. 部署和打包

The applications used to be deployed on physical servers. Then around 2000, the applications that were not sensitive to latency were usually deployed on virtual servers. With cloud native applications, they are packaged into docker images and deployed in containers.

4. 應用程式基礎設施

The applications are massively deployed on cloud infrastructure instead of self-hosted servers.

開發人員生產力工具

可視化 JSON 文件

嵌套的 JSON 檔案難以閱讀。

JsonCrack從 JSON 檔案生成圖表並使其易於閱讀。

此外，產生的圖表可以作為圖像下載。

自動將程式碼轉換為架構圖

它起什麼作用？

• 用Python程式碼繪製雲端系統架構。

• 圖表也可以直接在 Jupyter Notebook 中呈現。

• 不需要任何設計工具。

• 支援以下提供者：AWS、Azure、GCP、Kubernetes、阿里雲、Oracle Cloud 等。

Github 倉庫

Linux

Linux 檔案系統詳解

Linux 檔案系統曾經類似於一個無組織的城鎮，人們可以在任何他們喜歡的地點建造房屋。然而，1994 年，檔案系統層次標準 (FHS) 的引入，為 Linux 檔案系統帶來了秩序。

透過實施像 FHS 這樣的標準，軟體可以確保在各個 Linux 發行版中的佈局一致。儘管如此，並非所有 Linux 發行版都嚴格遵守此標準。它們常常融入自己獨特的元素或滿足特定的要求。為了熟練掌握這個標準，您可以從探索開始。使用“cd”等指令進行導航和使用“ls”列出目錄內容。想像一下檔案系統是一棵樹，從根（/）開始。隨著時間的推移，它將成為你的第二天性，讓你成為一個熟練的 Linux 管理員。

你應該知道的 18 個最常用的 Linux 指令

Linux 指令是與作業系統互動的指令。它們可協助管理系統的檔案、目錄、系統流程和系統的許多其他方面。您需要熟悉這些命令才能有效瀏覽和維護基於 Linux 的系統。

下圖顯示了流行的 Linux 命令：

[](/ByteByteGoHq/system-design-101/blob/main/18 個你應該知道的最常用的指令.

• ls－列出檔案和目錄

• cd－更改目前目錄

• mkdir－建立新目錄

• rm——刪除檔案或目錄

• cp——複製檔案或目錄

• mv——移動或重新命名檔案或目錄

• chmod－更改檔案或目錄的權限

• grep－在檔案中搜尋模式

• find－搜尋檔案和目錄

• tar——操作 tarball 存檔文件

• vi－使用文字編輯器編輯文件

• cat—顯示文件內容

• top - 顯示進程和資源使用情況

• ps—顯示進程資訊

• kill－透過發送訊號終止進程

• du - 估計檔案空間使用情況

• ifconfig－設定網路介面

• ping - 測試主機之間的網路連接

安全

HTTPS 如何運作？

超文本傳輸協定安全性 (HTTPS) 是超文本傳輸協定 (HTTP) 的擴展。

資料如何加密和解密？

步驟 1-客戶端（瀏覽器）和伺服器建立 TCP 連線。

步驟 2 - 用戶端向伺服器發送「客戶端 hello」。該訊息包含一組必要的加密演算法（密碼套件）和它可以支援的最新 TLS 版本。伺服器以「server hello」回應，以便瀏覽器知道它是否可以支援演算法和 TLS 版本。

然後，伺服器將 SSL 憑證傳送給客戶端。憑證包含公鑰、主機名稱、有效期限等。

步驟 3 - 驗證 SSL 憑證後，用戶端產生會話金鑰並使用公鑰對其進行加密。伺服器收到加密的會話金鑰並使用私鑰進行解密。

步驟 4 - 現在用戶端和伺服器都持有相同的會話金鑰（對稱加密），加密資料在安全的雙向通道中傳輸。

HTTPS在傳輸資料時為什麼要轉為對稱加密？主要有兩個原因：

1. 安全性：非對稱加密僅是單向的。這意味著如果伺服器嘗試將加密資料傳送回客戶端，任何人都可以使用公鑰解密資料。

2. 伺服器資源：非對稱加密增加了相當多的數學開銷。它不適合長時間的資料傳輸。

用簡單的術語解釋 Oauth 2.0。

OAuth 2.0 是一個強大且安全的框架，允許不同的應用程式代表使用者安全地相互交互，而無需共享敏感憑證。

OAuth 涉及的實體包括使用者、伺服器和身分提供者 (IDP)。

OAuth 令牌能做什麼？

當您使用 OAuth 時，您會獲得一個代表您的身分和權限的 OAuth 令牌。這個令牌可以做一些重要的事情：

單一登入 (SSO)：使用 OAuth 令牌，您只需一次登入即可登入多個服務或應用程式，讓生活更輕鬆、更安全。

跨系統授權：OAuth 令牌可讓您在各個系統之間共用您的授權或存取權限，因此您不必在各個地方單獨登入。

存取使用者設定檔：具有 OAuth 令牌的應用程式可以存取您允許的使用者設