「真®全棧之路」Web前端開發的後端指南

前言

在若干次前的一場面試，面試官看我做過python爬蟲/後端 的工作，順帶問了我些後端相關的問題：你覺得什麼是後端？

送命題。當時腦瓦特了，答曰：邏輯處理和資料增刪改查。。。

當場被懟得體無完膚，羞愧難當。事後再反思這問題，結合資料總結了一下。發現自己學過的Redis、Elasticsearch和DNS等其實都屬於後端知識體系範疇。

在本文中，我將嘗試總結前端須知的後端體系入門。

無論你的動機是什麼，這個體系裡都有你想要了解或學習的東西：

• 儲存和服務如何結合在一起？
• 什麼時候（或為什麼）我需要用到這個？
• 全棧之路該怎麼走？
• 各技術的主流框架選擇

本文目錄：

1. Web / Application Servers
2. 負載均衡器: Load Balancer
3. 域名解析系統，DNS
4. HTTPS / SSL證照
5. 資料庫，Database
6. Blob / 檔案儲存
7. 內容分發網路（CDN）
8. 快取服務：Caching Service
9. 訊息佇列：Message queue

1. Web / Application Servers

• Web Servers伺服器：Web伺服器，使用http協議向Web提供內容。
• Application Servers：應用程式伺服器，託管並公開業務邏輯和程式。

1.1 伺服器端語言

可以使用不同的伺服器端語言編寫程式碼：

• 例如Node.js，Python，PHP，Java，C＃或Ruby。
• 每種語言都有自己的“Web框架”（例如基於 Java 的 Spring，基於 Ruby 的 Rails，基於C＃的ASP.NET MVC或基於Node.js的Express）。
• 這些框架使開發人員能夠編寫更少的程式碼來處理資料請求。

1.2 後端語言選擇

而事實上，每個後端語言都有不一樣的特性，也都有各自的擁護者。哪一個語言最適合做為後端語言的入門一直都是沒有定論的問題。但為了讓我們可以對各語言有一個很簡單的概念，以下整理了各語言較常被提及的特色、在開發上比較被人詬病的點，以及有什麼樣的網站是透過該語言開發的：

PHP：

• 使用者多，算是最普及的後端語言。
• 簡單易學，但因一些古老的設計飽受批評。
• 網站範例：Facebook、Wordpress、新浪微博。

Java：

• 老牌語言，開發統治者。國內外工作需求穩定，應用層面廣。
• 開發相較起來較慢，沒那麼適合新手。
• 網站範例：Linkedin、Amazon、淘寶。

Ruby：

• 開發快速，國內外很多 bootcamp 都以此語言教後端。
• 適不適合新手學飽受爭議。
• 網站範例：Airbnb、Twitter。

Python:

• 語法簡單易學，資料分析與資料探勘相關應用多。
• 單獨使用 Python 相較起來執行效能較差。
• 網站範例：Instagram、Reddit、知乎。

JavaScript (Node.js):

• 前端後端都可用 JS，高併發的情況執行效率極高
• 不適合 CPU 密集的應用
• 初創型企業首選
• 網站範例：Yahoo、Walmart

Go:

• Google力推，有很完善的標準庫，效能強大堪比C系列。
• 目前學習資源較少（感謝偉大B站的付出，真香）
• 網站範例：Google、Youtube、嗶哩嗶哩、頭條、騰訊雲

1.2 Web伺服器

即Web Server，除了託管自定義應用程式程式碼之外，一些Web應用程式體系結構還使用“Web伺服器程式”，例如Apache HTTP Server或Nginx。這些伺服器程式將在訪問後端程式碼之前攔截客戶端請求。使用它們有以下幾個原因：

• 快速重定向某些請求而不必通過後端程式碼執行此操作（狀態碼404頁面）。
• 儲存在Web伺服器的檔案系統上的靜態內容（例如影像，CSS，JS）比通過後端程式碼訪問更快。
• 某些伺服器端語言（例如PHP）沒有內建的生產級Web伺服器，因此需要通過專用的Web伺服器程式啟動。

至此，會引出一個疑問：Apache、Nginx、Tomcat和Node.js四者的區別是什麼？

引用：apache、node.js、nginx、tomcat誰能幫我捋一捋關係？

是一類東西，又不是一類東西。

首先它們都能建立 Web伺服器，但是他們關注的點不一樣。

• Tomcat 只能跟 Java配合，Node.js只能跟JavaScript。
• Apache 能和其他語言配合（通常跟 PHP 配合居多），但需要藉助不同的模組。
• Nginx則是通過埠轉發，所以Apache和Nginx可以和各種程式語言一起使用
• Nginx和Apache是純web伺服器，不具備解析動態語言（比如php檔案和js檔案）的能力.
• Tomcat和Node.js 能夠解析這些指令碼語言，提供應用服務，Web Server算是附加的功能。

1.3 web伺服器的形式（載體）

安裝這些工具和後端專案的Web伺服器計算機，本身可以採用以下幾種形式：

• 一臺物理機器
• 虛擬專用伺服器，即我們通常所說的VPS（例如華為雲，阿里雲等）

VPS實際上是被劃分為幾個部分的獨立伺服器，每個部分作為單獨的VPS伺服器進行銷售和使用。也就是說，它是一臺可執行多個Web應用程式(網站、軟體等)的相對獨立的機器，每個使用者擁有部分資源。

• 託管虛擬機器例項（例如AWS EC2，Google Compute Engine）
• 平臺即服務（PaaS）主機，雲服務提供商（例如Heroku，AWS Elastic Beanstalk）

VPS是基於軟體層的虛擬化技術,具體來說就是作業系統的虛擬化,VM是基於硬體層的虛擬化技術,VM主機使用vmware server搭建。

1.4 Dokcer，虛擬機器與物理機

docker容器與虛擬機器有什麼區別？

用個類比來極簡說明一下：

1. 物理機是這樣的：

2. 虛擬機器是這樣的：

3. Dokcer是這樣的：

2. 負載均衡器: Load Balancer

負載均衡是高可用網路基礎架構的的一個關鍵組成部分，有了負載均衡，我們通常可以將我們的應用伺服器部署多臺，然後通過負載均衡將使用者的請求分發到不同的伺服器用來提高網站、應用、資料庫或其他服務的效能以及可靠性。

負載平衡器模型通常分為兩類：第4層（傳輸層）和第7層（應用層）。

第4層（傳輸層）：：

• 根據網路和傳輸層協議（IP，TCP，FTP，UDP）中的資料進行操作。
• 不認識http協議，對應其他TCP應用，例如基於C/S開發的ERP等系統。

第7層（應用層）：：

• 根據應用層協議（如HTTP）中的資料分發請求。
• 認識http協議，所以其應用範圍主要是眾多的網站或者內部資訊平臺等基於B/S開發的系統。

負載均衡器主要分為硬體負載均衡和軟體負載均衡兩大類。

• 硬體負載均衡： 對應第四層，如F5負載均衡器
• 軟體負載均衡： 對應第七層，如LVS、Nginx和HAproxy

兩種型別的負載平衡器都會收到請求，並根據配置的演算法將這些請求分發到特定的伺服器。一些行業標準演算法是：

• 輪詢排程，Round robin，RR
• 加權輪詢，Weighted round robin，WRB
• 最少連線數，Least connections
• 最短的響應時間，Least response time

在Web應用程式中使用負載均衡器有兩個主要好處：

• 它通過確保單個Web伺服器不會被所有請求淹沒，來幫助維持一致的響應時間，因此處理每個請求的速度會相對慢些。
• 它保持高可用性。如果伺服器崩潰，所有後續客戶端請求仍將成功，因為它們將路由到健康的伺服器，並且使用者不會發現任何問題。

3. 域名解析系統，DNS

當使用者在其位址列中輸入URL時，瀏覽器將獲取URL的域部分（例如www.google.com）並呼叫DNS 。DNS解析發回該網站伺服器的IP地址位置（例如172.217.23.4）。一旦它具有IP地址，它就可以傳送對網頁的實際請求。

• 如果你的Web應用程式使用負載均衡器，則應將域名配置為指向負載均衡器的域名或IP地址。
• 如果您沒有使用負載均衡器，那麼您可以將域名直接指向應用程式伺服器的域名/ IP地址。

大多數網際網路域名註冊服務（例如GoDaddy，萬網等）都提供DNS管理控制檯。這些允許你配置域名（和子域）以指向應用程式的位置。

如果你願意，還可以將您的域名伺服器轉移到阿里雲、騰訊雲等雲提供商，並從那裡進行管理。這樣做的好處是可以將所有應用程式環境配置儲存在一個位置，並使其更易於自動化。

4. HTTPS / SSL證照

如果你正在構建Web應用程式（或靜態網站），則需要通過HTTPS提供服務，以確保使用者與伺服器之間的安全通訊。現在使用HTTPS 也有SEO的好處，所以沒有理由不使用它。

這意味著需要在後端安裝SSL證照。具體來說，需要在任何伺服器上安裝它們，這是客戶端請求的第一個聯絡點。這通常意味著負載均衡器和CDN伺服器，但如果你沒有使用負載均衡器，也可能是應用程式伺服器。

• 你可以使用LetsEncrypt免費生成證照。
• 如果你使用的是雲基礎架構，則可以使用託管服務，例如AWS Certificate Manager。這允許你建立並自動續訂SSL證照並將其分發到應用程式伺服器，負載平衡器和CDN伺服器。
• 只有中大型的HTTPS證照授權中心才會被瀏覽器承認，否則會顯示為不安全，需要手動信任。

目前SSL證照根據驗證級別分為三種型別

• 域名型SSL證照，簡稱DV SSL
• 企業型SSL證照，簡稱OV SSL
• 增強型SSL證照，簡稱EV SSL。
• 它們之間都有一定的區別，認證級別也都不同，各自適合不同規模型別的網站安裝。

一般情況下，企業類網站使用的OV SSL證照比較多，而且價格也適中，在大眾使用者可接受範圍內。

5. 資料庫，Database

幾乎所有Web應用程式都需要在某處保留資料。在大多數情況下，某處即某種形式的資料庫。 資料庫的主要工作是將資料可靠地儲存到永久儲存器中，並允許通過查詢檢索資料。它還可以圍繞它儲存的資料結構強制執行一些規則約束。

5.1 資料庫的種類

早期比較流行的資料庫模型有三種，分別為層次式資料庫、網路式資料庫和關係型資料庫。

而在當今的網際網路中，最常用的資料庫模型主要是兩種，即關係型（SQL）資料庫和非關係型（NoSQL）資料庫。

• 關聯式資料庫（例如MySql，Postgres，SQLServer，Oracle，SQLite）已經存在了40多年，並且一直是大多數Web應用程式的支柱。
• 而在過去十年左右的時間裡，NoSQL資料庫（例如MongoDB，Cassandra，CouchDB，DynamoDB）在Web應用程式中變得越來越普遍，主要是因為它們具有可擴充套件性優勢和資料結構靈活性。

5.2 資料庫部署

你可以在一臺伺服器上託管資料庫，但在生產方案中更常見的是將其託管在某種形式的叢集2臺或更多伺服器上。這可確保資料庫具有高可用性並降低資料丟失的風險，例如，如果一臺伺服器的儲存損壞。

近年來，少數雲託管的“無伺服器資料庫”已經可用。這些是可以通過API呼叫的資料庫，但你無需設定伺服器來託管它們。除了處理諸如自動備份之類的事情之外，雲供應商還為您無形地執行此操作。這些示例包括DynamoDB（NoSQL），Firebase實時資料庫（NoSQL）和Aurora無伺服器（關係）。

5.3 資料庫基礎方案

來源：架構設計之「資料庫從主備到主主的高可用方案」

無論底層是關係型資料庫，還是NoSQL資料庫，無論是 Mysql 還是 Redis、MongoDB，在架構設計上都是相通的。

資料庫伺服器的基礎方案分為三種：

• 一主一備的架構（主備式）
• 一主一從的架構（主從式）
• 互為主從的架構（主主式）

1. 一主一備的架構(主備式)

主備式架構是雙機部署中最簡單的一種架構，幾乎市面上所有的資料庫系統都會自帶這個主備功能。

其思路也特別的簡單：

• 將資料庫部署到兩臺機器，其中一臺機器(代號A)作為日常提供資料讀寫服務的機器，稱為「主機」。
• 另外一臺機器(代號B)並不提供線上服務，但會實時的將「主機」的資料同步過來，稱為「備機」。
• 一旦「主機」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。

這個架構的優缺點都很明顯，優點就是幾乎不需要做什麼開發改造，各類資料庫就支援這種模式，部署維護起來也簡單，並沒有引入額外的系統複雜度和瓶頸。

但是缺點呢，就是當「主機」出現故障的時候，需要人工去幹預啊，運維同學很辛苦的，而且處理還不一定及時。再還有一個缺點就是，主備架構會造成嚴重浪費資源，畢竟需要一臺與「主機」同等配置的「備機」長期備著，但又不作為線上服務來使用，你說浪費不浪費。

為了解決這個資源浪費問題，我們就得想一個把「備機」也用起來的方案：主從式架構。

2. 一主一從的架構(主從式)

主從式架構大體上與上述的主備式架構差不多。區別就是主備式的「備機」平時是不幹活的的，主要起到備份的作用。而主從式的「備機」改為了「從機」，平時也要提供服務，跟「主機」一樣隨時隨刻的在幹活的。

1. 主從式架構中的「從機」雖然也在隨時隨刻提供服務，但是它只提供「讀」服務，並不提供「寫」服務。
2. 「主機」會實時的將線上資料同步到「從機」，以保證「從機」能夠正常的提供讀操作。
3. 這種架構相比較主備式，對資源是一種節約，畢竟「從機」也在提供服務，沒有白白的浪費。並且在「主機」出現故障時，在人工介入之前，好歹「從機」也是能夠提供資料的「讀」操作的，畢竟大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。
4. 缺點就是架構稍微複雜了一點，畢竟「主機」和「從機」都有「讀」服務，那麼前端業務系統就需要用一定策略去判斷該路由到哪一臺去讀取資料。還有就是，延遲問題，「主機」的資料同步到「從機」難免會有一定程度的延遲，這個延遲可能會對資料實時性要求較高的業務有一定影響。

3. 互為主從的架構(主主式)

互為主從的架構是指兩臺機器自己都是主機，並且也都是作為對方的從機。兩臺機器都提供完整的讀寫服務，因此無需切換，客戶機在呼叫的時候隨機挑選一臺即可，當其中一臺當機了，另外一臺還可以繼續服務。

• 採用 互為主從架構 有個複雜點就是，因為兩臺主機都接受寫資料，那就需要將寫的最新資料實時的同步給對方，需要將資料進行兩臺主機的雙向複製。
• 而雙向複製不可避免的會在一定程度上帶來資料延遲、極端情況下甚至有資料丟失等問題。
• 在實際業務中，有些業務資料對一致性要求是非常高的，並不能接受資料的延遲、丟失，因此這類業務也不適合互為主從的模式，比如金融業務。
• 但是我們網際網路業務中大多數場景還是沒有這麼高要求的，所以這種模式對於一般場景還是用的蠻多。

至於資料庫叢集方案，我暫時沒看懂，就不寫了。。。

6. Blob / 檔案儲存

雖然資料庫通常用於儲存動態資料（例如，由終端使用者或API客戶端生成），但是存在某些類別的資料（ 非結構化資料），這些資料不能由使用者改變或者基於檔案而不適合資料庫儲存，例如：

• 前端網站資源，如影像，Javascript，CSS，字型，音訊，視訊檔案。
• 使用者通過表單上傳的各類檔案。

雲服務供應商不是將這些儲存在資料庫中，而是提供專用服務來儲存這些服務，例如AWS Simple Storage Service（S3），Azure，Google Cloud Storage和阿里雲OSS等。

這樣做的好處是雲供應商可以安全地儲存檔案，並可以為其製作冗餘副本，以最大限度地降低資料丟失的風險。

6.1 關於 Blob 儲存:

Blob 儲存用於：

• 直接向瀏覽器提供影像或文件。
• 儲存檔案以供分散式訪問。
• 對視訊和音訊進行流式處理。
• 向日志檔案進行寫入。
• 儲存用於備份和還原、災難恢復及存檔的資料。
• 儲存資料以供本地或 Azure 託管服務執行分析

7. 內容分發網路（CDN）

Blob /檔案儲存服務允許客戶端通過HTTP端點訪問檔案。例如，您的Web應用程式的HTML標記可以簡單地連結到AWS S3中儲存的影像和CSS檔案的URL。 傳統網路訪問：

但是，假設我的使用者位於中國，我的S3儲存位於美國西部 - 資料傳輸距離數千英里，因此我的使用者會看到延遲。

CDN是什麼？使用CDN有什麼優勢？

• CDN是雲供應商提供的服務，它們在全球範圍內分佈有“邊緣伺服器”。
• 這些邊緣伺服器從“原點”（例如，blob /檔案儲存位置）獲取檔案的副本。你的前端Web應用程式將指向 其CDN URL，而不是指向靜態資產的Blob儲存URL。
• 現在，客戶端和“邊緣”之間的距離遠不是幾千英里的往返，而是更少，因此檔案的獲取速度更快。

使用了CDN的網站訪問：

7.1 CDN工作流

通過權威DNS伺服器來實現最優節點的選擇，通過快取來減少源站的壓力。

8. 快取服務：Caching Service

雖然CDN是靜態檔案的一種快取形式，但Web應用程式可能需要臨時快取動態資料。

例如，假設存在一個資料庫查詢，該查詢對昨天的資料執行計算，其結果每天經常被成千上萬的使用者訪問。每次使用者請求此資料時聯絡資料庫就沒有任何意義。

對此的解決方案是使用快取記憶體服務在第一個使用者請求之後將結果儲存一段時間。通過快取將更快地提供對該資料的後續請求。

快取服務本質上是一種特殊型別的資料庫。 快取採用鍵值儲存的形式，其中鍵是應用程式程式碼用於查詢資料的字串（例如DailySiteStats_2018-10-17），值是快取的實際資料。快取的資料通常完全儲存在記憶體中，這使得從快取中檢索資料的速度非常快。

常見的快取服務是Redis和Memcached。AWS通過其Elasticache服務提供這兩者的託管版本。

8.1 Redis和Memcached對比

Redis和Memcached是都是主流的開源記憶體資料儲存。雖然它們既易於使用又提供高效能，但在選擇引擎時需要考慮重要的差異。Memcached是為簡單而設計的，而Redis提供了豐富的功能，使其能夠廣泛用於各種用例。

	Memcached	Redis
亞毫秒級延遲	是	是
開發人員易用性	是	是
資料分割槽	是	是
多語言支援	是	是
高階資料結構	-	是
多執行緒架構	是	-
快照	-	是
複製	-	是
釋出/訂閱	-	是
Lua指令碼	-	是
地理空間支援	-	是

亞毫秒級延遲:

Redis和Memcached都支援亞毫秒的響應時間。通過將資料儲存在記憶體中，它們可以比基於磁碟的資料庫更快地讀取資料。

開發人員易用性:

Redis和Memcached在語法上都很容易使用，並且需要最少量的程式碼才能整合到您的應用程式中。

資料分割槽:

Redis和Memcached`都允許您在多個節點之間分發資料。這允許您在需求增長時向外擴充套件以更好地處理更多資料。

支援廣泛的程式語言:

Redis和Memcached都有許多面向開發人員的開源客戶端。支援的語言包括Java，Python，PHP，C，C ++，C＃，JavaScript，Node.js，Ruby，Go等等。

高階資料結構:

除了字串，Redis還支援列表，集合，有序集，雜湊，位陣列等。應用程式可以使用這些更高階的資料結構來支援各種用例。例如，你可以使用Redis排序集輕鬆實現遊戲排行榜，該排行榜保持按其排名排序的玩家列表。

多執行緒架構：

由於Memcached是多執行緒的，因此它可以使用多個處理核心。這意味著您可以通過擴充套件計算容量來處理更多操作。

快照:

使用Redis，您可以使用即時快照將資料儲存在磁碟上，該快照可用於存檔或恢復。

複製:

Redis允許您建立Redis主資料庫的多個副本。這允許您擴充套件資料庫讀取並具有高可用性叢集。

釋出/訂閱:

Redis支援使用模式匹配的Pub /Sub訊息傳遞，您可以將其用於高效能聊天室，實時評論流，社交媒體源和伺服器互通。

Lua指令碼:

Redis允許您執行事務性Lua指令碼。指令碼可以幫助您提高效能並簡化應用程式。

地理空間支援:

Redis具有專門用於大規模處理實時地理空間資料的命令。您可以執行諸如查詢兩個元素（例如人或地點）之間的距離以及查詢點的給定距離內的所有元素之類的操作。

9. 訊息佇列：Message queue

適用於批處理任務和分離應用程式的非同步訊息收發

有時，你程式需要執行的任務與響應使用者請求沒有直接關係。

例如，假設使用者上傳了需要編碼和水印的視訊。但這是一項長期執行的任務，因此讓使用者在完成時等待是沒有意義的。更好的方法是非同步執行此操作。您的網路應用程式程式碼會在佇列中建立一條作業訊息，並通知您的使用者，當水印視訊準備就緒時，他們將收到一封電子郵件（訊息）。

然後，你將擁有一個可以執行以下操作的工作任務流：

1. 從佇列中讀取訊息。
2. 開始處理視訊。
3. 完成後，儲存視訊的編碼副本。
4. 向使用者傳送通知電子郵件（訊息）。
5. 從佇列中刪除訊息。

這裡有2個架構元件：

您可以通過以下幾種方式實現worker任務：

• 排程CRON作業以觸發應用程式伺服器上安裝的指定程式碼，以便按特定計劃從佇列中讀取。
• 將訊息新增到佇列時，使用FaaS平臺呼叫工作器程式碼。

9.1 Message queue 簡介

訊息佇列是一種非同步的服務間通訊方式，適用於無伺服器和微服務架構。訊息在被處理和刪除之前一直儲存在佇列上。每條訊息僅可被一位使用者處理一次。訊息佇列可被用於分離重量級處理、緩衝或批處理工作以及緩解高峰期工作負載。

現在常用的MQ元件有activeMQ、rabbitMQ、rocketMQ、zeroMQ 還有近年來火熱的kafka,從某些場景來說也是MQ，當然kafka的功能更加強大，雖然不同的MQ都有自己的特點和優勢，但是，不管是哪種MQ，都有MQ本身自帶的一些特點。

9.2 MQ主要特性

特性	說明
推送或拉取傳送	拉取是指不斷查詢佇列以獲取新訊息。推送是指系統在有可用訊息時通知使用者 (也稱為釋出/訂閱訊息收發)。您還可以使用長輪詢讓拉取等待指定的時間，以便新訊息在完成之前到達。
定時或延遲傳送	支援為訊息設定特定的傳送時間。如果需要為所有訊息設定相同延遲，可以設定一個延遲佇列。
至少一次傳送	訊息佇列可以儲存多個訊息副本以實現冗餘和高可用性，並在發生通訊故障或錯誤的情況下重新傳送訊息，以確保它們至少經過一次傳送。
確切一次傳送	在不容許重複的情況下，FIFO (先進先出) 訊息佇列會通過自動篩選重複來確保每個訊息均精確地傳輸了一次 (且只有一次)。
FIFO (先進先出) 佇列	在這些佇列中，首先接受處理的是最早的 (或第一個) 條目，有時稱為“隊首”。
訊息優先順序	通常情況下，您可以為訊息分配優先順序，以確定要在佇列中新增該訊息的位置，從而確保優先順序較高的訊息位於佇列前端並得到優先處理。

9.3 MQ應用示例

來源：MQ(訊息佇列)常見的應用場景解析

我們的實際場景大概是一個基於微服務架構的電商系統，分為使用者微服務、商品微服務、訂單微服務、促銷微服務等。

基於微服務模式開發的系統，MQ的使用場景更多。這裡我們就列舉一下常見的應用示例。

1. 註冊後的初始化

註冊後我們可能需要做很多初始化的操作，如：

• 呼叫郵件伺服器傳送郵件、呼叫促銷服務贈送優惠劵、下發使用者資料到客戶關係系統等。
• 那麼這時候我們將這些操作去監聽MQ，當使用者註冊成功過後，通過MQ通知其他業務進行操作。確保註冊使用者的效能。

2. 後臺釋出商品

後臺釋出商品的時候:

• 商品資料需要從資料庫中轉換成搜尋引擎資料（基於elasticsearch）
• 那麼我們應該將商品寫入資料庫後，再寫入到MQ，然後通過監聽MQ來生成elasticsearch對應的資料。

3.支付超時取消

使用者下單後，24小時未支付，需要取消訂單。

• 以前我們可能是定時任務迴圈查詢，然後取消訂單。
• 實際上，我更推薦類似延遲MQ的方式，避免了很多無效的資料庫查詢，將一個MQ設定為24小時後才讓消費者消費掉，這樣很大程度上能減輕伺服器壓力。

4. 支付完成後通知

• 支付完成後，需要及時的通知子系統（進銷存系統發貨，使用者服務積分，傳送簡訊）進行下一步操作。
• 但是，支付回撥我們都是需要保證高效能的，所以，應該直接修改資料庫狀態，存入MQ，讓MQ通知子系統做其他非實時的業務操作。這樣能保證核心業務的高效及時。

免責宣告

逛國外社群看到這篇，覺得挺簡潔明瞭的。

只是覺得好玩，就按其大綱，重寫總結一下，有說錯的地方多擔待。

意思就是寫得略粗糙，別噴我。。。

❤️ 看完三件事

如果你覺得這篇內容對你挺有啟發，我想邀請你幫我三個小忙：

1. 點贊，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓 -_-）
2. 關注公眾號「前端勸退師」，不定期分享原創知識。
3. 也看看其它文章

• 那些你不經意間使用的設計模式(一) - 建立型模式
• 「資料視覺化庫王者」D3.js 極速上手到Vue應用
• 「真®全棧之路」Web前端開發的後端指南
• 「Vue實踐」5分鐘擼一個Vue CLI 外掛
• 「Vue實踐」武裝你的前端專案
• 「中高階前端面試」JavaScript手寫程式碼無敵祕籍
• 「從原始碼中學習」面試官都不知道的Vue題目答案
• 「從原始碼中學習」Vue原始碼中的JS騷操作
• 「Vue實踐」專案升級vue-cli3的正確姿勢
• 為何你始終理解不了JavaScript作用域鏈？

也可以來我的GitHub部落格裡拿所有文章的原始檔：

前端勸退指南：github.com/roger-hiro/…