對于我們所研發(fā)的網(wǎng)站，若網(wǎng)站的訪問量非常大，那么我們必須考慮相關(guān)的并發(fā)訪問問題，而并發(fā)問題是絕大部分的程序員頭疼的問題。本 Chat 帶你領(lǐng)略一下相關(guān)概念和解決方案：
概念類：
- 什么是 QPS、PV、UV、QPS 不等于并發(fā)連接數(shù)？
- 大中小三種類型網(wǎng)站的 QPS 一般是多少？
- 具體解決方案：數(shù)據(jù)庫層面、Web 負(fù)載層面、IP Hash 策略、Nginx 負(fù)載均衡策略......
第一章 哪些必須掌握的常用概念
1.1 什么是 QPS？
QPS:
每秒查詢率（Query Per Second），每秒的響應(yīng)請求數(shù)，也即是最大吞吐能力。 QPS = req / sec = 請求數(shù) / 秒。 QPS 統(tǒng)計方式 （一般使用 http _ load 進(jìn)行統(tǒng)計）。 QPS = 總請求數(shù) / ( 進(jìn)程總數(shù) * 請求時間 )。 QPS：單個進(jìn)程每秒請求服務(wù)器的成功次數(shù)。
峰值QPS:
原理：每天 80% 的訪問集中在 20 % 的時間里，這 20 % 時間叫做峰值時間。
單臺服務(wù)器每天 PV 計算
公式1：每天總 PV = QPS * 3600 * 6 。 公式2：每天總 PV = QPS * 3600 * 8。
集群服務(wù)器計算
服務(wù)器數(shù)量 = ceil（每天總 PV / 單臺服務(wù)器每天總 PV） 峰值 QPS 和機器計算公式
原理：每天 80 % 的訪問集中在 20 % 的時間里，這 20 % 時間叫做峰值時間 。
公式：( 總 PV 數(shù) * 80 % ) / ( 每天秒數(shù) * 20 % ) = 峰值時間每秒請求數(shù)（QPS）
機器：峰值時間每秒 QPS / 單臺機器的 QPS = 需要的機器
舉例 1： 每天 600 w PV 的在單臺機器上，這臺機器需要多少 QPS？ ( 6000000 * 0.8 ) / (86400 * 0.2 ) = 278 （QPS）
舉例 2： 如果一臺服務(wù)器機器的 QPS 是 58，需要幾臺機器來支持？ 278 / 65 = 4.3 采用進(jìn) 1 算法，需要 5 臺機器支持。
以上 數(shù)據(jù)僅供 chat 講解知識，參考，勿要對應(yīng)自己服務(wù)器，請以自己服務(wù)器的性能為準(zhǔn)。
1.2 什么是 PV？
PV 是 page view 的縮寫，即頁面瀏覽量，或點擊量；通常是衡量一個媒體頻道或網(wǎng)站甚至一條網(wǎng)絡(luò)文章的主要指標(biāo)。
控制 PV 的網(wǎng)站：24 小時算一次 PV 。 例子：點我查看，24 小時只算一次 PV。
普通的 PV 的網(wǎng)站：每訪問一次 PV 增加一次。例子：點我查看，刷新看看人數(shù)，沒刷新增加1人。
Array 老師提醒： 針對大并發(fā)和大流量的網(wǎng)站，一定要做好這個，否則，黑客利用 PV 漏洞，及其容易刷 PV，導(dǎo)致服務(wù)器崩潰。
PV：一個網(wǎng)站的 PV，從某種程度上已成為投資者衡量商業(yè)網(wǎng)站表現(xiàn)的最重要尺度，可以通過專業(yè)的工具查詢和計算。
第三方查詢工具： http://www.alexa.cn/ 這個可以查詢或者搜索 alexa 的工具。
1.3 什么是UV ？
UV:
獨立訪客即 Unique Visitor，訪問您網(wǎng)站的一臺電腦客戶端為一個訪客。00:00 - 24:00 內(nèi)相同的客戶端只被計算一次，指訪問某個站點或點擊某條新聞的不同 IP 地址的人數(shù)。
在同一天內(nèi)，uv 只記錄第一次進(jìn)入網(wǎng)站的具有獨立 IP 的訪問者，在同一天內(nèi)再次訪問該網(wǎng)站則無效。獨立 IP 訪問者提供了一定時間內(nèi)不同觀眾數(shù)量的統(tǒng)計指標(biāo)，而沒有反應(yīng)出網(wǎng)站的全面活動狀況。
分析：PV 和 UV 各有各的用途，但是往往 UV 更為準(zhǔn)確，但是 PV 更能查看活動值。
1.4 什么是 ＰＲ 值
PR 值，即 PageRank，網(wǎng)頁的級別技術(shù)。取自 Google 的創(chuàng)始人 Larry Page，它是 * 運算法則（排名公式）的一部分，用來標(biāo)識網(wǎng)頁的等級 / 重要性。級別從 1 到 10 級，10 級為滿分。PR 值越高說明該網(wǎng)頁越受歡迎（越重要）。
一個 PR 值為 1 的網(wǎng)站表明這個網(wǎng)站不太具有流行度，而 PR 值為 7 到 10 則表明這個網(wǎng)站非常受歡迎。
我們可以這樣說：一個網(wǎng)站的外部鏈接數(shù)越多其 PR 值就越高；外部鏈接站點的級別越高，網(wǎng)站的 PR 值就 越高。
例如：如果 https://edu.csdn.net/course/detail/8566 網(wǎng)站上有一個 www.ugaoxin.com 網(wǎng)站的鏈接，那為 CSDN 網(wǎng)站必須提供一些干貨，搜索引擎認(rèn)為來自 ugaoxin.com 的友情鏈接，從而對 CSDN 的網(wǎng)站增加PR值。
1.5 QPS 不等于并發(fā)連接數(shù)
通過前面的計算公式和各自概念的關(guān)系：我們得出結(jié)論 QPS 不等于并發(fā)連接數(shù)。
QPS 是每秒 HTTP 請求數(shù)量，并發(fā)連接數(shù)是系統(tǒng)同時處理的請求數(shù)量。
（總 PV 數(shù) 80 %）/（6小時秒數(shù) 20 %）= 峰值每秒請求數(shù)（QPS） 80 % 的訪問量集中在 20 % 的時間。
這點謹(jǐn)防在面試中誤入陷阱，面試中該部分是拔高的部分，很多人被面試官帶篇。Array 老師在做面試官期間，問過很多次，如果面試者打不上了你自己做的系統(tǒng)是 QPS 和并發(fā)連接數(shù)，或者誤認(rèn)為是一個的話，在以后的談薪資等容易被動，甚至讓你回家等消息了，因為這是實際項目經(jīng)驗不可或缺的一部分，要不你不上心。
那么如果被面試官問道你做的網(wǎng)站的 QPS 是多了？你該怎么回答？尤其是對這方面缺乏或者沒有實戰(zhàn)經(jīng)驗的同學(xué)，請查看下面的章節(jié)。
第二章 大中小三種類型網(wǎng)站的 QPS 一般是多少？
隨著 QPS 的增長，每個階段需要根據(jù)實際情況來進(jìn)行優(yōu)化，優(yōu)化的方案也與服務(wù)器等硬件、網(wǎng)絡(luò)帶寬等現(xiàn)實的物理條件息息相關(guān)。
2.1網(wǎng)站的大小標(biāo)準(zhǔn)
一個網(wǎng)站的“大小”，所采用的架構(gòu)不同，用到的技術(shù)也大相徑庭，眾多種衡量的方法 。對于并發(fā)業(yè)界的，存在爭議，這里從數(shù)量級層面總結(jié)歸納一下。
網(wǎng)站的熱度：日均 PV，同時在線人數(shù)、注冊用戶數(shù)，活躍用戶等運營數(shù)據(jù)。
互聯(lián)網(wǎng)的“3 秒定律”，大型網(wǎng)站要求 1.5 秒以內(nèi)加載整頁，或者至少可以達(dá)到瀏覽。
2.2 分類
2.2.1 平均值 < 50QPS
小型網(wǎng)站，一般的服務(wù)器就可以應(yīng)付，可以用最簡單的方法快速搭建，短期沒有太多的技術(shù)瓶頸，只要服務(wù)器穩(wěn)定即可，網(wǎng)絡(luò)通暢即可。
2.2.2 50QPS < 平均值 < 100QPS
DB 數(shù)據(jù)庫極限型:常用的關(guān)系型數(shù)據(jù)庫的每次請求大多都能控制在 0.01 秒左右，就算你研發(fā)的 Web 網(wǎng)站每頁面只有一次數(shù)據(jù)庫請求，那么頁面請求無法保證在 1 秒鐘內(nèi)完成 100 個請求，這個階段要考慮做 Cache 或者多 DB 負(fù)載。
2.2.3 300QPS<平均值<800QPS
帶寬極限型
服務(wù)器常用 IDC 提供的“百兆帶寬”，這意味著網(wǎng)站出口的實際帶寬是 8 M Byte左右。假定每個頁面只有 10 K Byte，在這個并發(fā)條件下，百兆帶寬已經(jīng)快速的占用資源完畢。
這要就可能考慮優(yōu)化的技術(shù)如同：CDN 加速 & 異地緩存，集群負(fù)載等技術(shù)。
2.2.4 500QPS < 平均值 < 1000QPS
內(nèi)網(wǎng)帶寬極限＋緩存極限型
由于 Key/value 的特性，每個頁面對緩存技術(shù)的請求遠(yuǎn)大于直接對 DB 的請求。
例：Memcache 的悲觀并發(fā)數(shù)在 2w 左右，現(xiàn)在的實際項目，可能在大并發(fā)之前內(nèi)網(wǎng)的帶寬就已經(jīng)吃光。
Array 老師當(dāng)初做電商項目的時候，用的也是 memcached，但是壓力測試的時候，在 7991QPS 的時候，memcached 已經(jīng)不穩(wěn)定，存在各種無法預(yù)知的程序問題，這是壓力迅速到到 mysql 的數(shù)據(jù)庫上了，整個系統(tǒng)性能迅速下降，這樣就會出現(xiàn)網(wǎng)站訪問變慢，甚至無法訪問的 404 等情況，我們當(dāng)時做的是 wait.xxxxx.com，跳轉(zhuǎn)到等待界面，這樣提示更加的友好。
2.2.5 1000QPS < 平均值 < 2000QPS
FORK / SELECT，鎖模式極限型
線程模型決定吞吐量。不管你系統(tǒng)中最常見的鎖是什么鎖，這個級別下，文件系統(tǒng)訪問鎖都成為了災(zāi)難。這就要求系統(tǒng)中不能存在中央節(jié)點，所有的數(shù)據(jù)都必須分布存儲，數(shù)據(jù)需要分布處理?？傊?分布
Array 老師提醒：這個是常說的是否需要做分布式的標(biāo)準(zhǔn)，如果達(dá)到了這個標(biāo)準(zhǔn)，必須做分布式。
2.2.6 2000 QPS < 平均值
C10K 極限 現(xiàn)在阿里的技術(shù)以及實現(xiàn)了 C25K，但熟悉 java 的短板理論，木桶原理很明顯我們能得出， 網(wǎng)站整體并發(fā)的永遠(yuǎn)是最慢的那個。在阿里巴巴的雙 11 的晚上 24 點的時候，肯定超過這個值。
第三章 具體的解決方案
以下內(nèi)容都是在實際項目中遇到的各種瓶頸或者問題，經(jīng)過了團隊討論，前輩的請教，閉關(guān)的修煉，查閱大量技術(shù)官網(wǎng)或者文檔，最后的總結(jié)，結(jié)合市面上的各種成熟方案，聯(lián)系當(dāng)下硬件，寬帶等多方面的局限，經(jīng)過了研發(fā)團隊的打磨和面試中，面試高工或者架構(gòu)師的門檻，總結(jié)如下：供大家在日常業(yè)務(wù)中參考和面試中升職加薪。
3.1 數(shù)據(jù)庫層面
數(shù)據(jù)庫緩存層的優(yōu)化：數(shù)據(jù)庫集群、庫表散列 自從去 IOE 之后，大批量的軟件研發(fā)團隊和企業(yè)都開始研究使用 Mysql，緩存等作為存儲設(shè)備。本 chat 以 mysql 的數(shù)據(jù)庫層面去探索優(yōu)化的意義。
下面具體給大家說一說
數(shù)據(jù)庫存儲引擎是數(shù)據(jù)庫底層軟件組織，數(shù)據(jù)庫管理系統(tǒng)使用數(shù)據(jù)引擎進(jìn)行創(chuàng)建、查詢、更新和刪除數(shù)據(jù)。不同的存儲引擎提供不同的存儲機制、索引技巧、鎖定水平等功能，使用不同的存儲引擎，還可以 獲得特定的功能?，F(xiàn)在許多不同的數(shù)據(jù)庫管理系統(tǒng)都支持多種不同的數(shù)據(jù)引擎。
MySql 的核心就是存儲引擎。
3.1.1 InnoDB 存儲引擎
InnoDB 是事務(wù)型數(shù)據(jù)庫的首選引擎，支持事務(wù)安全表（ACID），支持行鎖定和外鍵，上圖也看到了，InnoDB 是默認(rèn)的 MySQL 引擎。InnoDB 主要特性有：
1、InnoDB 給 MySQL 提供了具有提交、回滾和崩潰恢復(fù)能力的事物安全（ACID 兼容）存儲引擎。InnoDB 鎖定在行級并且也在 SELECT 語句中提供一個類似 Oracle 的非鎖定讀。這些功能增加了多用戶部署和性能。在 SQL 查詢中，可以自由地將 InnoDB 類型的表和其他 MySQL 的表類型混合起來，甚至在同一個查詢中也可以混合。
2、InnoDB 是為處理巨大數(shù)據(jù)量的最大性能設(shè)計。它的 CPU 效率可能是任何其他基于磁盤的關(guān)系型數(shù)據(jù)庫引擎鎖不能匹敵的。
3、InnoDB 存儲引擎完全與 MySQL 服務(wù)器整合，InnoDB 存儲引擎為在主內(nèi)存中緩存數(shù)據(jù)和索引而維持它自己的緩沖池。InnoDB 將它的表和索引在一個邏輯表空間中，表空間可以包含數(shù)個文件（或原始磁盤文件）。這與 MyISAM 表不同，比如在 MyISAM 表中每個表被存放在分離的文件中。InnoDB 表可以是任何尺寸，即使在文件尺寸被限制為 2 GB 的操作系統(tǒng)上。
4、InnoDB 支持外鍵完整性約束，存儲表中的數(shù)據(jù)時，每張表的存儲都按主鍵順序存放，如果沒有顯示在表定義時指定主鍵，InnoDB 會為每一行生成一個 6 字節(jié)的 ROWID，并以此作為主鍵。
5、InnoDB 被用在眾多需要高性能的大型數(shù)據(jù)庫站點上。
InnoDB 不創(chuàng)建目錄，使用 InnoDB 時，MySQL 將在 MySQL 數(shù)據(jù)目錄下創(chuàng)建一個名為 ibdata1 的 10 MB 大小的自動擴展數(shù)據(jù)文件，以及兩個名為 ib _ logfile0 和 ib _ logfile1 的 5 MB 大小的日志文件。
3.1.2 MyISAM 存儲引擎
MyISAM 基于 ISAM 存儲引擎，并對其進(jìn)行擴展。它是在 Web、數(shù)據(jù)倉儲和其他應(yīng)用環(huán)境下最常使用的存儲引擎之一。MyISAM 擁有較高的插入、查詢速度，但不支持事物。
MyISAM 主要特性有：
1、大文件（達(dá)到 63 位文件長度）在支持大文件的文件系統(tǒng)和操作系統(tǒng)上被支持。
2、當(dāng)把刪除和更新及插入操作混合使用的時候，動態(tài)尺寸的行產(chǎn)生更少碎片。這要通過合并相鄰被刪除的塊，以及若下一個塊被刪除，就擴展到下一塊自動完成。
3、每個 MyISAM 表最大索引數(shù)是 64，這可以通過重新編譯來改變。每個索引最大的列數(shù)是 16。
4、最大的鍵長度是 1000 字節(jié)，這也可以通過編譯來改變，對于鍵長度超過 250 字節(jié)的情況，一個超過 1024 字節(jié)的鍵將被用上。
5、BLOB 和 TEXT 列可以被索引。
6、NULL 被允許在索引的列中，這個值占每個鍵的 0 ~ 1 個字節(jié)。
7、所有數(shù)字鍵值以高字節(jié)優(yōu)先被存儲以允許一個更高的索引壓縮。
8、每個 MyISAM 類型的表都有一個 AUTO _ INCREMENT 的內(nèi)部列，當(dāng) INSERT 和 UPDATE 操作的時候該列被更新，同時 AUTO _ INCREMENT 列將被刷新。所以說，MyISAM 類型表的 AUTO _ INCREMENT 列更新比 InnoDB 類型的 AUTO _ INCREMENT 更快。
9、可以把數(shù)據(jù)文件和索引文件放在不同目錄。
10、每個字符列可以有不同的字符集。
11、有 VARCHAR 的表可以固定或動態(tài)記錄長度。
12、VARCHAR 和 CHAR 列可以多達(dá) 64KB。
使用 MyISAM 引擎創(chuàng)建數(shù)據(jù)庫，將產(chǎn)生 3 個文件。文件的名字以表名字開始，擴展名之處文件類型：frm 文件存儲表定義、數(shù)據(jù)文件的擴展名為 .MYD（MYData）、索引文件的擴展名時 .MYI（MYIndex）。
3.1.3 MEMORY 存儲引擎（也叫 HEAP）堆內(nèi)存
MEMORY 存儲引擎將表中的數(shù)據(jù)存儲到內(nèi)存中，未查詢和引用其他表數(shù)據(jù)提供快速訪問。
MEMORY主要特性有：
1、MEMORY 表的每個表可以有多達(dá) 32 個索引，每個索引 16 列，以及 500 字節(jié)的最大鍵長度。
2、MEMORY 存儲引擎執(zhí)行 HASH 和 BTREE 縮影。
3、可以在一個 MEMORY 表中有非唯一鍵值。
4、MEMORY 表使用一個固定的記錄長度格式。
5、MEMORY 不支持 BLOB 或 TEXT 列。
6、MEMORY 支持 AUTO _ INCREMENT 列和對可包含 NULL 值的列的索引。
7、MEMORY 表在所由客戶端之間共享（就像其他任何非 TEMPORARY 表）。
8、MEMORY 表內(nèi)存被存儲在內(nèi)存中，內(nèi)存是 MEMORY 表和服務(wù)器在查詢處理時的空閑中，創(chuàng)建的內(nèi)部表共享。
9、當(dāng)不再需要 MEMORY 表的內(nèi)容時，要釋放被 MEMORY 表使用的內(nèi)存，應(yīng)該執(zhí)行 DELETE FROM或TRUNCATE TABLE，或者刪除整個表（使用 DROP TABLE）。
3.1.4 EXAMPLE 存儲引擎
是一個 “ 存根 ” 引擎，它不做什么。你可以用這個引擎創(chuàng)建表，但沒有數(shù)據(jù)被存儲于其中或從其中檢索。這個引擎的目的是服務(wù)，在 MySQL 源代碼中的一個例子，它演示說明如何開始編寫新存儲引擎。同樣，它的主要興趣是對開發(fā)者。
3.1.5 NDB Cluster
是被 MySQL Cluster 用來實現(xiàn)分割到多臺計算機上的表的存儲引擎。
它在 MySQL - Max 5.1 二進(jìn)制分發(fā)版里提供。這個存儲引擎當(dāng)前只被 Linux，Solaris，和 Mac OS X 支持。在未來的 MySQL 分發(fā)版中，我們想要添加其它平臺對這個引擎的支持，包括 Windows。
3.1.6 ARCHIVE 存儲引擎 被用來無索引地，非常小地覆蓋存儲的大量數(shù)據(jù)。
3.1.7 CSV 存儲引擎 把數(shù)據(jù)以逗號分隔的格式存儲在文本文件中。
3.1.8 BLACKHOLE 存儲引擎 接受但不存儲數(shù)據(jù)，并且檢索總是返回一個空集。
3.1.9 FEDERATED 存儲引擎
把數(shù)據(jù)存在遠(yuǎn)程數(shù)據(jù)庫中，在 MySQL 5.1 中，它只和 MySQL 一起工作，使用 MySQL C Client API。在未來的分發(fā)版中，我們想要讓它使用其它驅(qū)動器或客戶端連接方法連接到另外的數(shù)據(jù)源。
在實際高并發(fā)項目中：
MySQL 等一些常見的關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)都存儲在磁盤中，在高并發(fā)場景下，業(yè)務(wù)應(yīng)用對 MySQL 產(chǎn)生的增、刪、改、查的操作造成巨大的 I/O 開銷和查詢壓力， 數(shù)據(jù)庫和服務(wù)器都是一種巨大的壓力，為了解決此類問題，緩存數(shù)據(jù)的概念應(yīng)運而生。
緩存數(shù)據(jù)是為了讓客戶端很少甚至不訪問數(shù)據(jù)庫服務(wù)器進(jìn)行數(shù)據(jù)的查詢，高并發(fā)下，能最大程度的降低對數(shù)據(jù)庫服務(wù)器的訪問壓力極大地解決數(shù)據(jù)庫服務(wù)器的壓力。
提高應(yīng)用數(shù)據(jù)的響應(yīng)速度
用戶請求 --> 數(shù)據(jù)查詢 --> 連接數(shù)據(jù)庫服務(wù)器并查詢數(shù)據(jù)-->將數(shù)據(jù)緩存起來（HTML、內(nèi)存、JSON、序列化數(shù)據(jù)）--> 顯示給客戶端 用戶再次請求或者新用戶訪問 --> 數(shù)據(jù)查詢 --> 直接從緩存中獲取數(shù)據(jù) --> 顯示給客戶端
3.2 聯(lián)姻的數(shù)據(jù)庫
引入緩存可以提高性能，但是數(shù)據(jù)會存在兩份，一份在數(shù)據(jù)庫中，一份在緩存中，如果更新其中任何一份會引起數(shù)據(jù)的不一致，數(shù)據(jù)的完整性被破壞了，因此，同步數(shù)據(jù)庫和緩存的這兩份數(shù)據(jù)就非常重要。本文介紹常見的緩存更新的同步策略。
1.預(yù)留緩存 Cache-aside
應(yīng)用代碼能夠手工管理數(shù)據(jù)庫和緩存中數(shù)據(jù)，應(yīng)用邏輯會在訪問數(shù)據(jù)庫之前檢查緩存，在數(shù)據(jù)庫更新以后再更新緩存。
通過手工編碼分別對數(shù)據(jù)庫 save() 和緩存 (put(key,entity)) 做更新，將這種瑣碎的緩存管理和更新夾雜在應(yīng)用邏輯中并不是一種好方式，可以采取 AOP 面向方面攔截器等方式實現(xiàn)緩存操作，減輕緩存操作泄漏到應(yīng)用代碼中，同時確保數(shù)據(jù)庫和緩存都能正確同步。
2.Read-through（同步讀?。?/p>
如果緩存中不存在某個項目，則對 DataCache.Get 的調(diào)用將會返回 null。
在緩存端編程模型中，調(diào)用方負(fù)責(zé)隨后從后端存儲中加載數(shù)據(jù)，然后將該數(shù)據(jù)放置于緩存中。緩存使用 read - through（同步讀?。┨峁┏绦驒z測丟失的項目，并調(diào)用提供程序執(zhí)行數(shù)據(jù)加載。項目隨后將無縫返回到緩存客戶端中。
相比上面同時管理數(shù)據(jù)庫和緩存，我們可以簡單委托數(shù)據(jù)庫同步給一個緩存提供者，所有數(shù)據(jù)交互通過這個緩存抽象層完成。確認(rèn)緩存中是否有該數(shù)據(jù)，如果沒有，從數(shù)據(jù)庫加載，然后放入緩存，下次以后再訪問就可以直接從緩存中獲得。
3.Write - through
類似于 Read - through 的數(shù)據(jù)抓取策略，緩存能夠在其中數(shù)據(jù)變化時自動更新底層數(shù)據(jù)庫。
盡管數(shù)據(jù)庫和緩存同步更新了，但是我們也可以按照我們自己的業(yè)務(wù)要求選擇事務(wù)的邊界，如果需要強一致性，并且緩存提供者提供了 XAResource，這樣我們可以在一個全局事務(wù)中完成緩存和數(shù)據(jù)庫的更新，這樣數(shù)據(jù)庫和緩存更新是在一個原子單元：single atomic unit-of-work。 如果只需要弱一致性，我們可以先后更新緩存和數(shù)據(jù)庫，不必使用全局事務(wù)，這會讓我們提升快速響應(yīng)性與性能，通常緩存首先被更新，如果數(shù)據(jù)庫更新失敗，緩存可以通過補償動作實現(xiàn)回滾當(dāng)前事務(wù)所做的改變。
4.Write - behind（事后寫入）
如果強一致性不是必須的，我們可以簡單將緩存的更新放在隊列中，然后定期批量地去更新數(shù)據(jù)庫。打破了事務(wù)保證，但是性能要遠(yuǎn)遠(yuǎn)超過 write - through，因為數(shù)據(jù)庫能夠快速批量更新，事務(wù)機制不再需要。在 write - behind 緩存中，數(shù)據(jù)的讀取和更新通過緩存進(jìn)行，與 write - through 緩存不同，更新的數(shù)據(jù)并不會立即傳到數(shù)據(jù)庫。相反，在緩存中一旦進(jìn)行更新操作，緩存就會跟蹤臟記錄列表，并定期將當(dāng)前的臟記錄集刷新到數(shù)據(jù)庫中。
作為額外的性能改善，緩存會合并這些臟記錄。合并意味著如果相同的記錄被更新，或者在緩沖區(qū)內(nèi)被多次標(biāo)記為臟數(shù)據(jù)，則只保證最后一次更新。對于那些值更新非常頻繁，例如金融市場中的股票價格等場景，這種方式能夠很大程度上改善性能。如果股票價格每秒鐘變化 100 次，則意味著在 30 秒內(nèi)會發(fā)生 30 x 100 次更新。合并將其減少至只有一次。
3.2 Web 負(fù)載層面，IP Hash 策略，Nginx 負(fù)載均衡策略三者互相關(guān)聯(lián)
涉及高并發(fā)的時候，我們的 Nginx 這個是不可或缺的工具,那么我們來看看這個軟件是什么，他能幫助我們實際生產(chǎn)中解決什么問題。
#3.2.1 Web 負(fù)載層面，Nginx 負(fù)載均衡策略
HTTP基礎(chǔ)功能：
處理靜態(tài)文件，索引文件以及自動索引； 反向代理加速(無緩存)，簡單的負(fù)載均衡和容錯； FastCGI，簡單的負(fù)載均衡和容錯；
模塊化的結(jié)構(gòu):
過濾器包括：gzipping，byte ranges，chunked responses，以及 SSI - filter ; 在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求并發(fā)處理； SSL 和 TLS SNI 支持。
IMAP/POP3 代理服務(wù)功能：
- 使用外部 HTTP 認(rèn)證服務(wù)器重定向用戶到 IMAP/POP3 后端；
- 使用外部 HTTP 認(rèn)證服務(wù)器認(rèn)證用戶后連接重定向到內(nèi)部的 SMTP 后端。
認(rèn)證方法：
POP3：POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5； IMAP：IMAP LOGIN； SMTP：AUTH LOGIN PLAIN CRAM-MD5； SSL 支持； 在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持。
支持的操作系統(tǒng)：
FreeBSD 3.x，4.x，5.x，6.x i386； FreeBSD 5.x，6.x amd64； Linux 2.2，2.4，2.6 i386； Linux 2.6 amd64； Solaris 8 i386； Solaris 9 i386 and sun4u； Solaris 10 i386； MacOS X (10.4) PPC。
結(jié)構(gòu)與擴展：
一個主進(jìn)程和多個工作進(jìn)程。工作進(jìn)程是單線程的，且不需要特殊授權(quán)即可運行；
kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；
kqueue 支持的不同功能包括EV_CLEAR, EV_DISABLE（臨時禁止事件），NOTE_LOWAT, EV_EOF，有效數(shù)據(jù)的數(shù)目，錯誤代碼；
sendfile (FreeBSD 3.1+)，sendfile (Linux 2.2+)，sendfile64 (Linux 2.4.21+)，和 sendfilev (Solaris 8 7/01+) 支持；
輸入過濾（FreeBSD 4.1 +） 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；
10000 非活動的 HTTP keep-alive 連接僅需要 2.5 M 內(nèi)存。 最小化的數(shù)據(jù)拷貝操作；
其他HTTP功能：
基于IP 和名稱的虛擬主機服務(wù)； Memcached 的 GET 接口； 支持 keep-alive 和管道連接； 靈活簡單的配置； 重新配置和在線升級而無須中斷客戶的工作進(jìn)程； 可定制的訪問日志，日志寫入緩存，以及快捷的日志回卷； 4xx - 5xx 錯誤代碼重定向； 基于 PCRE 的 rewrite 重寫模塊； 基于客戶端 IP 地址和 HTTP 基本認(rèn)證的訪問控制； PUT，DELETE，和 MKCOL 方法； 支持 FLV （Flash 視頻）； 帶寬限制；
3.2.2 高性能的服務(wù)器
Nginx 是一個高性能的 Web 和反向代理服務(wù)器, 它具有有很多非常優(yōu)越的特性:
作為 Web 服務(wù)器：相比 Apache，Nginx 使用更少的資源，支持更多的并發(fā)連接，體現(xiàn)更高的效率，這點使 Nginx 尤其受到虛擬主機提供商的歡迎。能夠支持高達(dá) 50000 個并發(fā)連接數(shù)的響應(yīng)，感謝 Nginx 為我們選擇了 epoll and kqueue 作為開發(fā)模型。
作為負(fù)載均衡服務(wù)器：Nginx 既可以在內(nèi)部直接支持 Rails 和 PHP，也可以支持作為 HTTP代理服務(wù)器 對外進(jìn)行服務(wù)。Nginx 用 C 編寫, 不論是系統(tǒng)資源開銷還是 CPU 使用效率都比 Perlbal 要好的多。
作為郵件代理服務(wù)器：Nginx 同時也是一個非常優(yōu)秀的郵件代理服務(wù)器（最早開發(fā)這個產(chǎn)品的目的之一也是作為郵件代理服務(wù)器），Last.fm 描述了成功并且美妙的使用經(jīng)驗。
Nginx 安裝非常的簡單，配置文件 非常簡潔（還能夠支持 perl 語法），Bugs 非常少的服務(wù)器：Nginx 啟動特別容易，并且?guī)缀蹩梢宰龅?7 * 24 不間斷運行，即使運行數(shù)個月也不需要重新啟動。你還能夠在 不間斷服務(wù)的情況下進(jìn)行軟件版本的升級。
總結(jié)：七層負(fù)載均衡的實現(xiàn)基于 Web 層面的 URL 等應(yīng)用信息的負(fù)載均衡，Nginx 的 proxy 是它一個很強大的功能，實現(xiàn)了 7 層負(fù)載均衡。
3.2.3 nginx 負(fù)載均衡中 RR 和 IP Hash 策略分析
1、RR（默認(rèn)）
每個請求按時間順序逐一分配到不同的后端服務(wù)器，如果后端服務(wù)器 down 掉，能自動剔除。
例如：
upstream tomcats {
server 172.19.1.182:8888 max_fails=3 fail_timeout=3s weight=9;
server 172.19.1.152:8080 max_fails=3 fail_timeout=3s weight=9;
}
2、IP Hash 策略
每個請求按訪問 ip 的 hash 結(jié)果分配，這樣每個訪客固定訪問一個后端服務(wù)器，可以解決 session 的問題。
例如：
upstream tomcats {
ip_hash;
server 172.19.1.182:8888;
server 1172.19.1.152:8080 ;
}
3、fair（第三方）
按后端服務(wù)器的響應(yīng)時間來分配請求，響應(yīng)時間短的優(yōu)先分配。
4、url_hash（第三方）
按訪問 url 的 hash 結(jié)果來分配請求，使每個 url 定向到同一個后端服務(wù)器，后端服務(wù)器為緩存時比較有效。
總結(jié)：Nginx 內(nèi)置的另一個負(fù)載均衡的策略，流程和輪詢很類似，只是七種的算法和具體的策略有些變化 IP Hash 算法是一種變相的輪詢算法
3.3 頁面靜態(tài)化
現(xiàn)在提倡前后端分離，前端界面基本都是 HTML 網(wǎng)頁代碼，通過 Angular JS 或者 NodeJS 提供的路由向后端服務(wù)器發(fā)出請求獲取數(shù)據(jù)，然后在游覽器對數(shù)據(jù)進(jìn)行渲染，這樣在很大程度上降低了后端服務(wù)器的壓力。
還可以將這些靜態(tài)的 HTML、CSS、JS、圖片資源等放置在緩存服務(wù)器上或者 CDN 服務(wù)器上，一般使用最多的應(yīng)該是 CDN 服務(wù)器或者 Nginx 服務(wù)器提供的靜態(tài)資源功能。
總結(jié)的規(guī)則如下：
無論是 JSP，ASP，PHP 等等效率最高、消耗最小的就是純靜態(tài)化的 html 頁面，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實現(xiàn)，這個最簡單的方法其實也是最有效的方法。因為這樣可以減少了和后臺等交互的步驟，尤其大量內(nèi)容并且頻繁更新的網(wǎng)站，我們無法全部手動逐個實現(xiàn)。
所以就誕生了 CMS 的內(nèi)容發(fā)布系統(tǒng)，生成 HTML，Array 老師在電商系統(tǒng)的實戰(zhàn)項目，講到這這個 CTX 技術(shù)，像我們常訪問的各個門戶站點，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實現(xiàn)的，信息發(fā)布系統(tǒng)可以實現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面，還能權(quán)限和爬蟲自動抓取等功能，對于一個大型門戶網(wǎng)站來說，擁有一套高效、可管理的 CMS 必須的。
哪些網(wǎng)站需要這些技術(shù)？
除了門戶和信息發(fā)布類型的網(wǎng)站，對于交互性要求很高的社區(qū)類型網(wǎng)站來說，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進(jìn)行實時的靜態(tài)化、有更新的時候再重新靜態(tài)化也是大量使用的策略，像電商類使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。
第四章 實戰(zhàn)分享
無論是淘寶的雙 11，還是京東的 618 都是高并發(fā)和大流量的王者，那么我們通過網(wǎng)絡(luò)中的例子和電商的官方解析來看看他們?nèi)绾螌⒓夹g(shù)落地的。
4.1關(guān)系數(shù)據(jù)庫仍然不可或缺
當(dāng)前主流的關(guān)系型數(shù)據(jù)庫有 Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL 等。
非關(guān)系型數(shù)據(jù)庫有 NoSql、Cloudant。
nosql和關(guān)系型數(shù)據(jù)庫的比較
優(yōu)點： 1）成本：nosql數(shù)據(jù)庫簡單易部署，基本都是開源軟件，不需要像使用oracle那樣花費大量成本購買使用，相比關(guān)系型數(shù)據(jù)庫價格便宜。 2）查詢速度：nosql數(shù)據(jù)庫將數(shù)據(jù)存儲于緩存之中，關(guān)系型數(shù)據(jù)庫將數(shù)據(jù)存儲在硬盤中，自然查詢速度遠(yuǎn)不及nosql數(shù)據(jù)庫。 3）存儲數(shù)據(jù)的格式：nosql的存儲格式是key,value形式、文檔形式、圖片形式等等，所以可以存儲基礎(chǔ)類型以及對象或者是集合等各種格式，而數(shù)據(jù)庫則只支持基礎(chǔ)類型。 4）擴展性：關(guān)系型數(shù)據(jù)庫有類似join這樣的多表查詢機制的限制導(dǎo)致擴展很艱難。
缺點：
1）維護的工具和資料有限，因為 nosql 是屬于新的技術(shù)，不能和關(guān)系型數(shù)據(jù)庫 10 幾年的技術(shù)同日而語。
2）不提供對 sql 的支持，如果不支持 sql 這樣的工業(yè)標(biāo)準(zhǔn)，將產(chǎn)生一定用戶的學(xué)習(xí)和使用成本。
3）不提供關(guān)系型數(shù)據(jù)庫對事物的處理。
非關(guān)系型數(shù)據(jù)庫的優(yōu)勢：
性能 NOSQL 是基于鍵值對的，可以想象成表中的主鍵和值的對應(yīng)關(guān)系，而且不需要經(jīng)過 SQL 層的解析，所以性能非常高。
可擴展性同樣也是因為基于鍵值對，數(shù)據(jù)之間沒有耦合性，所以非常容易水平擴展。
關(guān)系型數(shù)據(jù)庫的優(yōu)勢：
復(fù)雜查詢可以用 SQL 語句方便的在一個表以及多個表之間做非常復(fù)雜的數(shù)據(jù)查詢。
事務(wù)支持使得對于安全性能很高的數(shù)據(jù)訪問要求得以實現(xiàn)。對于這兩類數(shù)據(jù)庫，對方的優(yōu)勢就是自己的弱勢，反之亦然。
關(guān)系型數(shù)據(jù)庫的優(yōu)勢：
保持?jǐn)?shù)據(jù)的一致性（事務(wù)處理）。
由于以標(biāo)準(zhǔn)化為前提，數(shù)據(jù)更新的開銷很?。ㄏ嗤淖侄位旧隙贾挥幸惶帲?。
可以進(jìn)行 Join 等復(fù)雜查詢。
其中能夠保持?jǐn)?shù)據(jù)的一致性是關(guān)系型數(shù)據(jù)庫的最大優(yōu)勢。
關(guān)系型數(shù)據(jù)庫的不足
不擅長的處理：
大量數(shù)據(jù)的寫入處理。
為有數(shù)據(jù)更新的表做索引或表結(jié)構(gòu)（schema）變更。
字段不固定時應(yīng)用。
對簡單查詢需要快速返回結(jié)果的處理。
大量數(shù)據(jù)的寫入處理
讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負(fù)，大部分網(wǎng)站已使用主從復(fù)制技術(shù)實現(xiàn)讀寫分離，以提高讀寫性能和讀庫的可擴展性。
所以在進(jìn)行大量數(shù)據(jù)操作時，會使用數(shù)據(jù)庫主從模式。數(shù)據(jù)的寫入由主數(shù)據(jù)庫負(fù)責(zé)，數(shù)據(jù)的讀入由從數(shù)據(jù)庫負(fù)責(zé)，可以比較簡單地通過增加從數(shù)據(jù)庫來實現(xiàn)規(guī)?；菙?shù)據(jù)的寫入?yún)s完全沒有簡單的方法來解決規(guī)?；瘑栴}。
4.2 非關(guān)系型數(shù)據(jù)庫錦上添花
臨時性鍵值存儲（memcached、Redis）、永久性鍵值存儲（ROMA、Redis）、面向文檔的數(shù)據(jù)庫（MongoDB、CouchDB）、面向列的數(shù)據(jù)庫（Cassandra、HBase）
4.2.1 鍵值存儲
它的數(shù)據(jù)是以鍵值的形式存儲的，雖然它的速度非?？?，但基本上只能通過鍵的完全一致查詢獲取數(shù)據(jù)，根據(jù)數(shù)據(jù)的保存方式可以分為臨時性、永久性和兩者兼具 三種。
（1）臨時性
所謂臨時性就是數(shù)據(jù)有可能丟失，memcached 把所有數(shù)據(jù)都保存在內(nèi)存中，這樣保存和讀取的速度非常快，但是當(dāng) memcached 停止時，數(shù)據(jù)就不存在了。由于數(shù)據(jù)保存在內(nèi)存中，所以無法操作超出內(nèi)存容量的數(shù)據(jù)，舊數(shù)據(jù)會丟失。
總結(jié)來說：
- 在內(nèi)存中保存數(shù)據(jù)。
- 可以進(jìn)行非?？焖俚谋４婧妥x取處理。
- 數(shù)據(jù)有可能丟失。
（2）永久性
所謂永久性就是數(shù)據(jù)不會丟失，這里的鍵值存儲是把數(shù)據(jù)保存在硬盤上，與臨時性比起來，由于必然要發(fā)生對硬盤的 IO 操作，所以性能上還是有差距的，但數(shù)據(jù)不會丟失是它最大的優(yōu)勢。
總結(jié)來說：
- 在硬盤上保存數(shù)據(jù)。
- 可以進(jìn)行非?？焖俚谋４婧妥x取處理（但無法與 memcached 相比）。
- 數(shù)據(jù)不會丟失。
（3） 兩者兼?zhèn)?/p>
Redis 屬于這種類型。Redis 有些特殊，臨時性和永久性兼具。Redis 首先把數(shù)據(jù)保存在內(nèi)存中，在滿足特定條件（默認(rèn)是 15 分鐘一次以上，5 分鐘內(nèi) 10 個以上，1 分鐘內(nèi) 10000 個以上的鍵發(fā)生變更）的時候?qū)?shù)據(jù)寫入到硬盤中，這樣既確保了內(nèi)存中數(shù)據(jù)的處理速度，又可以通過寫入硬盤來保證數(shù)據(jù)的永久性，這種類型的數(shù)據(jù)庫特別適合處理數(shù)組類型的數(shù)據(jù)。
總結(jié)來說：
- 同時在內(nèi)存和硬盤上保存數(shù)據(jù)。
- 可以進(jìn)行非?？焖俚谋４婧妥x取處理。
- 保存在硬盤上的數(shù)據(jù)不會消失（可以恢復(fù)）。
- 適合于處理數(shù)組類型的數(shù)據(jù)。
4.2.2 面向文檔的數(shù)據(jù)庫
MongoDB、CouchDB 屬于這種類型，它們屬于 NoSQL 數(shù)據(jù)庫，但與鍵值存儲相異。
（1）不定義表結(jié)構(gòu)
即使不定義表結(jié)構(gòu)，也可以像定義了表結(jié)構(gòu)一樣使用，還省去了變更表結(jié)構(gòu)的麻煩。
（2）可以使用復(fù)雜的查詢條件
跟鍵值存儲不同的是，面向文檔的數(shù)據(jù)庫可以通過復(fù)雜的查詢條件來獲取數(shù)據(jù)，雖然不具備事務(wù)處理和 Join 這些關(guān)系型數(shù)據(jù)庫所具有的處理能力，但初次以外的其他處理基本上都能實現(xiàn)。
4.2.3 面向列的數(shù)據(jù)庫
Cassandra、HBae、HyperTable 屬于這種類型，由于近年來數(shù)據(jù)量出現(xiàn)爆發(fā)性增長，這種類型的 NoSQL 數(shù)據(jù)庫尤其引入注目。
普通的關(guān)系型數(shù)據(jù)庫都是以行為單位來存儲數(shù)據(jù)的，擅長以行為單位的讀入處理，比如特定條件數(shù)據(jù)的獲取。因此，關(guān)系型數(shù)據(jù)庫也被成為面向行的數(shù)據(jù)庫。相反，面向列的數(shù)據(jù)庫是以列為單位來存儲數(shù)據(jù)的，擅長以列為單位讀入數(shù)據(jù)。
面向列的數(shù)據(jù)庫具有搞擴展性，即使數(shù)據(jù)增加也不會降低相應(yīng)的處理速度（特別是寫入速度），所以它主要應(yīng)用于需要處理大量數(shù)據(jù)的情況。另外，把它作為批處理程序的存儲器來對大量數(shù)據(jù)進(jìn)行更新也是非常有用的。
但由于面向列的數(shù)據(jù)庫跟現(xiàn)行數(shù)據(jù)庫存儲的思維方式有很大不同，故應(yīng)用起來十分困難。
總結(jié)：關(guān)系型數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫并非對立而是互補的關(guān)系，即通常情況下使用關(guān)系型數(shù)據(jù)庫，在適合使用NoSQL的時候使用NoSQL數(shù)據(jù)庫，讓NoSQL數(shù)據(jù)庫對關(guān)系型數(shù)據(jù)庫的不足進(jìn)行彌補。
4.3 淘寶雙 11
2017 年雙 11 又創(chuàng)造了新紀(jì)錄，全天交易額 1682 億，交易峰值 32.5 萬筆/秒，支付峰值 25.6 W 筆/秒，狂歡的背后是極其復(fù)雜龐大的技術(shù)系統(tǒng)。那么，這些技術(shù)在雙 11 的狂歡中又起了什么作用呢？對大家的購物有什么影響呢？
阿里云網(wǎng)絡(luò)產(chǎn)品團隊的剖析
VPC - 安全的網(wǎng)絡(luò)容器
專有網(wǎng)絡(luò) VPC（Virtual Private Cloud）是用戶在云上的一個隔離，安全的網(wǎng)絡(luò)環(huán)境，就像是用戶在云上的一個私有的網(wǎng)絡(luò)容器，這個容器和其它用戶邏輯上是徹底隔離的，有了這個網(wǎng)絡(luò)容器后，就可以在這個容器中“放置”需要的云產(chǎn)品和資源，比如負(fù)載均衡 SLB，RDS 等等。
VPC 是用戶在云上具備網(wǎng)絡(luò)管理能力的基礎(chǔ)，如選擇 IP 地址范圍、劃分子網(wǎng)、配置網(wǎng)關(guān)、實現(xiàn)多低于私網(wǎng)互通以及和云下 IDC 的互通等，都需要依賴 VPC。
有了 VPC 后，用戶就能掌控自己的網(wǎng)絡(luò)。
公共云平臺是很多用戶共享的平臺，雙 11 電商核心的交易、訂單、物流等都是在公共云平臺上，為了保證雙 11 交易的安全，使用了專有網(wǎng)絡(luò) VPC 進(jìn)行租戶隔離。
如下圖所示，雙 11 使用了公共云平臺上的一個 VPC，這個 VPC 和其它 VPC 都是隔離的，禁止通信的。
專有網(wǎng)絡(luò) VPC 使用隧道技術(shù)進(jìn)行邏輯隔離，比經(jīng)典網(wǎng)絡(luò)更安全。這么說可能有點抽象，打個比方，VPC 使用的隧道技術(shù)就好比是在同一條公路上開辟不同的隧道，每個用戶有自己獨有的隧道，和其它用戶的隧道是完全隔離的，而經(jīng)典網(wǎng)絡(luò)的安全隔離技術(shù)就好比是在同一條公路上有不同的車道，車道之間用隔離帶進(jìn)行隔離，相比而言，沒有隧道隔離那么安全。
如下圖所示，隧道 ID 100 和隧道 ID 200 就對用兩個不同用戶的 VPC，兩個 VPC 中分別有 VM1，VM3和VM2，VM4，這 2 個 VPC 的 VM 在各自的隧道上通信，和其它隧道的 VM 是隔離的。
負(fù)載均衡 SLB - 流量洪峰的調(diào)度器
負(fù)載均衡 SLB 產(chǎn)品支持對多臺 ECS 進(jìn)行流量分發(fā)，以提升應(yīng)用系統(tǒng)的服務(wù)能力，長期以來都是關(guān)鍵業(yè)務(wù)系統(tǒng)的入口。
雙 11 億萬用戶訪問的流量洪峰需要大量的 ECS 服務(wù)器進(jìn)行處理，而這些 ECS 的調(diào)度都需要依賴負(fù)載均衡 SLB，負(fù)載均衡 SLB 接收到用戶的請求，智能調(diào)度到后端的 ECS 進(jìn)行處理，并將處理后的結(jié)果返回給用戶。如下圖所示：
可以說，雙 11 的流量洪峰能不能扛住，用戶溝通體驗是不是流暢，負(fù)載均衡 SLB 是關(guān)鍵因素。對于負(fù)載均衡來說，網(wǎng)站大流量的指標(biāo)通過本文前面章節(jié)的逐步解析：
雙 11 中負(fù)載均衡 SLB 使用了很多實例，其中我們拿出單獨的一個實例來賞析：
| 每秒峰值流量 | 10G |
| 連接數(shù)CPS | 10萬 |
| 最大并發(fā) | 300萬 |
ECS數(shù) 1000+
4.4 訂單層面
NAT 網(wǎng)關(guān)
NAT 網(wǎng)關(guān)產(chǎn)品支持 SNAT 和 DNAT 功能。SNAT 功能即為 VPC 內(nèi)無公網(wǎng) ECS 提供訪問 Internet 的能力，也支持通過 DNAT 將公網(wǎng) IP 地址映射給 VPC ECS，使得 VPC ECS 可以面向 Internet 提供服務(wù)。
雙11中NAT網(wǎng)關(guān)主要提供的是 SNAT 服務(wù)，為什么說 NAT 網(wǎng)關(guān)是雙 11 中支付成功的關(guān)鍵呢？ 如下圖，當(dāng)用戶選擇了自己看中的寶貝后，點擊 “ 提交訂單 ”：
我們在提交訂單的時候其實后臺做了復(fù)雜的出力。
4.5 支付寶進(jìn)行付款
NAT 網(wǎng)關(guān)去調(diào)用支付寶的
雙 11 支付寶交易峰值達(dá)到 25.6 W 筆/秒，其中每一筆的支付都需要 NAT 網(wǎng)關(guān)，這就需要NAT網(wǎng)關(guān)具備超大規(guī)模的帶寬和超大并發(fā)連接，當(dāng)然還需要具備超強的容災(zāi)能力。整個雙 11 期間，其中一個 NAT 網(wǎng)關(guān)的最大連接數(shù)就高達(dá) 300 W。
4.6 高速的在線云
全球最大混合云的網(wǎng)絡(luò)通道
混合云將公共云和云下數(shù)據(jù)中心通過專線互通，云上云下連成一體，這就是混合云?；旌显萍瓤梢员Ｗo原有線下 IDC 的投資，又可以充分利用云的彈性，尤其適合雙 11 這樣的促銷場景。
可以說，雙 11 發(fā)展到第九年，其意義早已超越消費和零售領(lǐng)域，更是史無前例的社會化大協(xié)同，成為商業(yè)、經(jīng)濟、科技變革的最大實驗場，因此，雙 11 也是全球最大規(guī)?；旌显萍軜?gòu)的極好實踐，在這朵云上，商品瀏覽，訂單支付，客戶服務(wù)，物流查詢等等，很多系統(tǒng)調(diào)用頻繁在公共云和云下數(shù)據(jù)中心之間進(jìn)行，已經(jīng)成為一個緊密的整體，這些云上云下系統(tǒng)調(diào)用的背后都依賴混合云網(wǎng)絡(luò)通道，這就是高速通道。
如下圖所示，高速通道有兩個重要的功能，一是專線，即將線下 IDC 和云上 VPC 連接起來，二是 VPC 互聯(lián)，即將不同的 VPC［跨地域］連接起來。
4.7 底層的網(wǎng)絡(luò)技術(shù)（我們在后面的 chat 專題講解） 例如：晚會直播
雙 11 晚會的視頻直播，再如說彈性計算 ECS 的網(wǎng)絡(luò)性能，更依賴存在于宿主機上的無名英雄－虛擬交換機。
網(wǎng)絡(luò)是雙11背后千百個系統(tǒng)的基礎(chǔ)，是基礎(chǔ)的基礎(chǔ)，核心的核心。網(wǎng)絡(luò)無處不在，但網(wǎng)絡(luò)之于雙 11 的最高境界是購物狂歡中感知不到網(wǎng)絡(luò)的存在，平穩(wěn)，絲滑的購物體驗就是網(wǎng)絡(luò)的最大意義。
4.8 官方的技術(shù)架構(gòu)（來自阿里的云棲社區(qū)）
2017 天貓雙 11 的交易額定格在 1682 億。但對技術(shù)的追求，卻從未定格。11 秒交易額破億，28 秒破 10 億，3 分 01 秒破百億，40 分 12 秒破 500 億，9 小時破 1000 億 …… 2017 年 11 月 11 日的數(shù)據(jù)一定會銘記在歷史中。交易峰值 32.5 萬/秒，支付峰值 25.6 萬/秒，比去年增長超 1.1 倍，再次刷新全球紀(jì)錄。同時誕生的還有數(shù)據(jù)庫處理峰值，4200 萬次／秒。
要想詳細(xì) 高清 chat 后臺上傳該圖片都上傳了 2 分鐘。
不知道前臺能否展示高清，請查看或者點擊。
后記
還有同步的解決策略，圖片服務(wù)器分離，CDN 加速技術(shù)等技術(shù)。
更多優(yōu)秀的方案，伴隨著時代的高速步伐，在后廠村的道路上讓我們共同見證......
網(wǎng)絡(luò)中很多技術(shù)，善于整理歸納，學(xué)習(xí)到知道才是最終目的，技術(shù)知識手段，運用技術(shù)才是最終效果。
參考資料：
