Hadoop 是目前大數(shù)據(jù)領(lǐng)域最主流的一套技術(shù)體系，包含了多種技術(shù)，例如 HDFS(分布式文件系統(tǒng))，YARN(分布式資源調(diào)度系統(tǒng))，MapReduce(分布式計(jì)算系統(tǒng))等等。

 

 

有些朋友可能聽說過 Hadoop，但是卻不太清楚它到底是個(gè)什么東西，這篇文章就用大白話給各位闡述一下。

假如你現(xiàn)在公司里的數(shù)據(jù)都是放在 MySQL 里的，那么就全部放在一臺(tái)數(shù)據(jù)庫服務(wù)器上，我們就假設(shè)這臺(tái)服務(wù)器的磁盤空間有 2T 吧，大家先看下面這張圖。

 

 

現(xiàn)在問題來了，你不停的往這臺(tái)服務(wù)器的 MySQL 里放數(shù)據(jù)，結(jié)果數(shù)據(jù)量越來越大了，超過了 2T 的大小了，現(xiàn)在咋辦?

你說，我可以搞多臺(tái) MySQL 數(shù)據(jù)庫服務(wù)器，分庫分表啊!每臺(tái)服務(wù)器放一部分?jǐn)?shù)據(jù)不就得了。如上圖所示!

好，沒問題，那咱們搞 3 臺(tái)數(shù)據(jù)庫服務(wù)器，3 個(gè) MySQL 實(shí)例，然后每臺(tái)服務(wù)器都可以 2T 的數(shù)據(jù)。

現(xiàn)在我問你一個(gè)問題，所謂的大數(shù)據(jù)是在干什么?我們來說一下大數(shù)據(jù)最初級(jí)的一個(gè)使用場(chǎng)景。

假設(shè)你有一個(gè)電商網(wǎng)站，要把這個(gè)電商網(wǎng)站里所有的用戶在頁面和 App 上的點(diǎn)擊、購買、瀏覽的行為日志都存放起來分析。

你現(xiàn)在把這些數(shù)據(jù)全都放在了 3 臺(tái) MySQL 服務(wù)器上，數(shù)據(jù)量很大，但還是勉強(qiáng)可以放的下。

某天早上，你的 Boss 來了。要看一張報(bào)表，比如要看每天網(wǎng)站的 X 指標(biāo)、Y 指標(biāo)、Z 指標(biāo)，等等，二三十個(gè)數(shù)據(jù)指標(biāo)。

好了，兄弟，現(xiàn)在你嘗試去從那些點(diǎn)擊、購買、瀏覽的日志里，通過寫一個(gè) SQL 來分析出那二三十個(gè)指標(biāo)試試看?

我跟你打賭，你絕對(duì)會(huì)寫出來一個(gè)幾百行起步，甚至上千行的超級(jí)復(fù)雜大 SQL。這個(gè) SQL，你覺得他能運(yùn)行在分庫分表后的 3 臺(tái) MySQL 服務(wù)器上么?

如果你覺得可以的話，那你一定是不太了解 MySQL 分庫分表后有多坑，幾百行的大 SQL 跨庫 Join，各種復(fù)雜的計(jì)算，根本不現(xiàn)實(shí)。

所以說，大數(shù)據(jù)的存儲(chǔ)和計(jì)算壓根兒不是靠 MySQL 來搞的，因此 Hadoop、Spark 等大數(shù)據(jù)技術(shù)體系才應(yīng)運(yùn)而生。

本質(zhì)上，Hadoop、Spark 等大數(shù)據(jù)技術(shù)，其實(shí)就是一系列的分布式系統(tǒng)。比如 Hadoop 中的 HDFS，就是大數(shù)據(jù)技術(shù)體系中的核心基石，負(fù)責(zé)分布式存儲(chǔ)數(shù)據(jù)，這是啥意思?別急，繼續(xù)往下看。

HDFS 全稱是 Hadoop Distributed File System，是 Hadoop 的分布式文件系統(tǒng)。

它由很多機(jī)器組成，每臺(tái)機(jī)器上運(yùn)行一個(gè) DataNode 進(jìn)程，負(fù)責(zé)管理一部分?jǐn)?shù)據(jù)。

然后有一臺(tái)機(jī)器上運(yùn)行了 NameNode 進(jìn)程，NameNode 大致可以認(rèn)為是負(fù)責(zé)管理整個(gè) HDFS 集群的這么一個(gè)進(jìn)程，它里面存儲(chǔ)了 HDFS 集群的所有元數(shù)據(jù)。

然后有很多臺(tái)機(jī)器，每臺(tái)機(jī)器存儲(chǔ)一部分?jǐn)?shù)據(jù)!好，HDFS 現(xiàn)在可以很好的存儲(chǔ)和管理大量的數(shù)據(jù)了。

這時(shí)候你肯定會(huì)有疑問：MySQL 服務(wù)器不也是這樣的嗎?你要是這樣想，那就大錯(cuò)特錯(cuò)了。

這個(gè)事情不是你想的那么簡單的，HDFS 天然就是分布式的技術(shù)，所以你上傳大量數(shù)據(jù)，存儲(chǔ)數(shù)據(jù)，管理數(shù)據(jù)，天然就可以用 HDFS 來做。

如果你硬要基于 MySQL 分庫分表這個(gè)事兒，會(huì)痛苦很多倍，因?yàn)?MySQL 并不是設(shè)計(jì)為分布式系統(tǒng)架構(gòu)的，它在分布式數(shù)據(jù)存儲(chǔ)這塊缺乏很多數(shù)據(jù)保障的機(jī)制。

好，你現(xiàn)在用 HDFS 分布式存儲(chǔ)了數(shù)據(jù)，接著不就是要分布式來計(jì)算這些數(shù)據(jù)了嗎?

對(duì)于分布式計(jì)算：

很多公司用 Hive 寫幾百行的大 SQL(底層基于 MapReduce)。

也有很多公司開始慢慢的用 Spark 寫幾百行的大 SQL(底層是 Spark Core 引擎)。

總之就是寫一個(gè)大 SQL，然后拆分為很多的計(jì)算任務(wù)，放到各個(gè)機(jī)器上去，每個(gè)計(jì)算任務(wù)就負(fù)責(zé)計(jì)算一小部分?jǐn)?shù)據(jù)，這就是所謂的分布式計(jì)算。

這個(gè)，絕對(duì)比你針對(duì)分庫分表的 MySQL 來跑幾百行大 SQL 要靠譜的多。

 

 

對(duì)于上述所說的分布式存儲(chǔ)與分布式計(jì)算，老規(guī)矩，同樣給大家來一張圖，大伙兒跟著圖來仔細(xì)捋一下整個(gè)過程。

HDFS 的 NameNode 架構(gòu)原理

好了，前奏鋪墊完之后，進(jìn)入正題。本文主要就是討論一下 HDFS 集群中的 NameNode 的核心架構(gòu)原理。

NameNode 有一個(gè)很核心的功能：管理整個(gè) HDFS 集群的元數(shù)據(jù)，比如說文件目錄樹、權(quán)限的設(shè)置、副本數(shù)的設(shè)置，等等。

下面就用最典型的文件目錄樹的維護(hù)，來給大家舉例說明，我們看看下面的圖�，F(xiàn)在有一個(gè)客戶端系統(tǒng)要上傳一個(gè) 1TB 的大文件到 HDFS 集群里

 

 

此時(shí)它會(huì)先跟 NameNode 通信，說：大哥，我想創(chuàng)建一個(gè)新的文件，它的名字叫“/usr/hive/warehouse/access_20180101.log”，大小是 1TB，你看行不?

然后 NameNode 就會(huì)在自己內(nèi)存的文件目錄樹里，在指定的目錄下搞一個(gè)新的文件對(duì)象，名字就是“access_20180101.log”。

這個(gè)文件目錄樹不就是 HDFS 非常核心的一塊元數(shù)據(jù)，維護(hù)了 HDFS 這個(gè)分布式文件系統(tǒng)中，有哪些目錄，有哪些文件，對(duì)不對(duì)?

但是有個(gè)問題，這個(gè)文件目錄樹是在 NameNode 的內(nèi)存里的啊!這可坑爹了，你把重要的元數(shù)據(jù)都放在內(nèi)存里，萬一 NameNode 不小心宕機(jī)了可咋整?元數(shù)據(jù)不就全部丟失了?

可你要是每次都頻繁的修改磁盤文件里的元數(shù)據(jù)，性能肯定是極低的啊!畢竟這是大量的磁盤隨機(jī)讀寫!

沒關(guān)系，我們來看看 HDFS 優(yōu)雅的解決方案。每次內(nèi)存里改完了，寫一條 edits log，元數(shù)據(jù)修改的操作日志存到磁盤文件里，不修改磁盤文件內(nèi)容，就是順序追加，這個(gè)性能就高多了。

每次 NameNode 重啟的時(shí)候，把 edits log 里的操作日志讀到內(nèi)存里回放一下，不就可以恢復(fù)元數(shù)據(jù)了?

大家順著上面的文字，把整個(gè)過程，用下面這張圖跟著走一遍：

 

 

但是問題又來了，那 edits log 如果越來越大的話，豈不是每次重啟都會(huì)很慢?因?yàn)橐�讀取大量的 edits log 回放恢復(fù)元數(shù)據(jù)!

所以 HDFS 說，我可以這樣子啊，我引入一個(gè)新的磁盤文件叫做 fsimage，然后呢，再引入一個(gè) JournalNodes 集群，以及一個(gè) Standby NameNode(備節(jié)點(diǎn))。

每次 Active NameNode(主節(jié)點(diǎn))修改一次元數(shù)據(jù)都會(huì)生成一條 edits log，除了寫入本地磁盤文件，還會(huì)寫入 JournalNodes 集群。

然后 Standby NameNode 就可以從 JournalNodes 集群拉取 edits log，應(yīng)用到自己內(nèi)存的文件目錄樹里，跟 Active NameNode 保持一致。

然后每隔一段時(shí)間，Standby NameNode 都把自己內(nèi)存里的文件目錄樹寫一份到磁盤上的 fsimage，這可不是日志，這是完整的一份元數(shù)據(jù)。這個(gè)操作就是所謂的 checkpoint 檢查點(diǎn)操作。

然后把這個(gè) fsimage 上傳到 Active NameNode，接著清空掉 Active NameNode 的舊的 edits log 文件，這里可能都有 100 萬行修改日志了!

然后 Active NameNode 繼續(xù)接收修改元數(shù)據(jù)的請(qǐng)求，再寫入 edits log，寫了一小會(huì)兒，這里可能就幾十行修改日志而已!

如果說此時(shí)，Active NameNode 重啟了，Bingo!沒關(guān)系，只要把 Standby NameNode 傳過來的 fsimage 直接讀到內(nèi)存里，這個(gè) fsimage 直接就是元數(shù)據(jù)，不需要做任何額外操作，純讀取，效率很高!

然后把新的 edits log 里少量的幾十行的修改日志回放到內(nèi)存里就 OK 了!

這個(gè)過程的啟動(dòng)速度就快的多了!因?yàn)椴恍枰�回放大量上百萬行的 edits log 來恢復(fù)元數(shù)據(jù)了!如下圖所示。

 

 

此外，大家看看上面這張圖，現(xiàn)在咱們有倆 NameNode：

一個(gè)是主節(jié)點(diǎn)對(duì)外提供服務(wù)接收請(qǐng)求。

另外一個(gè)純就是接收和同步主節(jié)點(diǎn)的 edits log 以及執(zhí)行定期 checkpoint 的備節(jié)點(diǎn)。

大家有沒有發(fā)現(xiàn)!他們倆內(nèi)存里的元數(shù)據(jù)幾乎是一模一樣的啊!所以呢，如果 Active NameNode 掛了，是不是可以立馬切換成 Standby NameNode 對(duì)外提供服務(wù)?

這不就是所謂的 NameNode 主備高可用故障轉(zhuǎn)移機(jī)制么!接下來大家再想想，HDFS 客戶端在 NameNode 內(nèi)存里的文件目錄樹，新加了一個(gè)文件。

但是這個(gè)時(shí)候，人家要把數(shù)據(jù)上傳到多臺(tái) DataNode 機(jī)器上去啊，這可是一個(gè) 1TB 的大文件!咋傳呢?

很簡單，把 1TB 的大文件拆成 N 個(gè) block，每個(gè) block 是 128MB。1TB = 1024GB = 1048576MB，一個(gè) block 是 128MB，那么就是對(duì)應(yīng)著 8192 個(gè) block。

這些 block 會(huì)分布在不同的機(jī)器上管理著，比如說一共有 100 臺(tái)機(jī)器組成的集群，那么每臺(tái)機(jī)器上放 80 個(gè)左右的 block 就 OK 了。

但是問題又來了，那如果這個(gè)時(shí)候 1 臺(tái)機(jī)器宕機(jī)了，不就導(dǎo)致 80 個(gè) block 丟失了?

也就是說上傳上去的 1TB 的大文件，會(huì)丟失一小部分?jǐn)?shù)據(jù)啊。沒關(guān)系!HDFS 都考慮好了!

它會(huì)默認(rèn)給每個(gè) block 搞 3 個(gè)副本，一模一樣的副本，分放在不同的機(jī)器上，如果一臺(tái)機(jī)器宕機(jī)了，同一個(gè) block 還有另外兩個(gè)副本在其他機(jī)器上呢!

大伙兒看看下面這張圖。每個(gè) block 都在不同的機(jī)器上有 3 個(gè)副本，任何一臺(tái)機(jī)器宕機(jī)都沒事!還可以從其他的機(jī)器上拿到那個(gè) block。

這下子，你往 HDFS 上傳一個(gè) 1TB 的大文件，可以高枕無憂了吧!

 

 

OK，上面就是大白話加上一系列手繪圖，給大家先聊聊小白都能聽懂的 Hadoop 的基本架構(gòu)原理。

大規(guī)模集群下 Hadoop NameNode 如何承載每秒上千次的高并發(fā)訪問

上面我們已經(jīng)初步給大家解釋了 Hadoop HDFS 的整體架構(gòu)原理，相信大家都有了一定的認(rèn)識(shí)和了解。

下面我們來看看，如果大量客戶端對(duì) NameNode 發(fā)起高并發(fā)(比如每秒上千次)訪問來修改元數(shù)據(jù)，此時(shí) NameNode 該如何抗住?

問題源起

我們先來分析一下，高并發(fā)請(qǐng)求 NameNode 會(huì)遇到什么樣的問題。

大家現(xiàn)在都知道了，每次請(qǐng)求 NameNode 修改一條元數(shù)據(jù)(比如說申請(qǐng)上傳一個(gè)文件，那么就需要在內(nèi)存目錄樹中加入一個(gè)文件)，都要寫一條 edits log。

包括如下兩個(gè)步驟：

寫入本地磁盤。
通過網(wǎng)絡(luò)傳輸給 JournalNodes 集群。

但是如果對(duì) Java 有一定了解的同學(xué)都該知道多線程并發(fā)安全問題吧?

NameNode 在寫 edits log 時(shí)的第一條原則：必須保證每條 edits log 都有一個(gè)全局順序遞增的 transactionId(簡稱為 txid)，這樣才可以標(biāo)識(shí)出來一條一條的 edits log 的先后順序。

那么如果要保證每條 edits log 的 txid 都是遞增的，就必須得加鎖。

每個(gè)線程修改了元數(shù)據(jù)，要寫一條 edits log 的時(shí)候，都必須按順序排隊(duì)獲取鎖后，才能生成一個(gè)遞增的 txid，代表這次要寫的 edits log 的序號(hào)。

好了，那么問題來了，大家看看下面的圖。如果每次都是在一個(gè)加鎖的代碼塊里，生成 txid，然后寫磁盤文件 edits log，網(wǎng)絡(luò)請(qǐng)求寫入 JournalNodes 一條 edits log，會(huì)咋樣?

 

 

不用說，這個(gè)絕對(duì)完蛋了!NameNode 本身用多線程接收多個(gè)客戶端發(fā)送過來的并發(fā)的請(qǐng)求，結(jié)果多個(gè)線程居然修改完內(nèi)存中的元數(shù)據(jù)之后，排著隊(duì)寫 edits log!

而且你要知道，寫本地磁盤 + 網(wǎng)絡(luò)傳輸給 JournalNodes，都是很耗時(shí)的啊!性能兩大殺手：磁盤寫 + 網(wǎng)絡(luò)寫!

如果 HDFS 的架構(gòu)真要是這么設(shè)計(jì)的話，基本上 NameNode 能承載的每秒的并發(fā)數(shù)量就很少了，可能就每秒處理幾十個(gè)并發(fā)請(qǐng)求處理撐死了!

HDFS 優(yōu)雅的解決方案

所以說，針對(duì)這個(gè)問題，人家 HDFS 是做了不少的優(yōu)化的!

首先大家想一下，既然咱們不希望每個(gè)線程寫 edits log 的時(shí)候，串行化排隊(duì)生成 txid + 寫磁盤 + 寫 JournalNode，那么是不是可以搞一個(gè)內(nèi)存緩沖?

也就是說，多個(gè)線程可以快速的獲取鎖，生成 txid，然后快速的將 edits log 寫入內(nèi)存緩沖。

接著就快速的釋放鎖，讓下一個(gè)線程繼續(xù)獲取鎖后，生成 id + 寫 edits log 進(jìn)入內(nèi)存緩沖。

然后接下來有一個(gè)線程可以將內(nèi)存中的 edits log 刷入磁盤，但是在這個(gè)過程中，還是繼續(xù)允許其他線程將 edits log 寫入內(nèi)存緩沖中。

但是這里又有一個(gè)問題了，如果針對(duì)同一塊內(nèi)存緩沖，同時(shí)有人寫入，還同時(shí)有人讀取后寫磁盤，那也有問題，因?yàn)椴荒懿�發(fā)讀寫一塊共享內(nèi)存數(shù)據(jù)!

所以 HDFS 在這里采取了 double-buffer 雙緩沖機(jī)制來處理!將一塊內(nèi)存緩沖分成兩個(gè)部分：

其中一個(gè)部分可以寫入。

另外一個(gè)部分用于讀取后寫入磁盤和 JournalNodes。

大家可能感覺文字?jǐn)⑹霾惶�直觀，老規(guī)矩，咱們來一張圖，按順序給大家闡述一下。

 

 

①分段加鎖機(jī)制 + 內(nèi)存雙緩沖機(jī)制

首先各個(gè)線程依次第一次獲取鎖，生成順序遞增的 txid，然后將 edits log 寫入內(nèi)存雙緩沖的區(qū)域 1，接著就立馬第一次釋放鎖了。

趁著這個(gè)空隙，后面的線程就可以再次立馬第一次獲取鎖，然后立即寫自己的 edits log 到內(nèi)存緩沖。

寫內(nèi)存那么快，可能才耗時(shí)幾十微妙，接著就立馬第一次釋放鎖了。所以這個(gè)并發(fā)優(yōu)化絕對(duì)是有效果的，大家有沒有感受到?

接著各個(gè)線程競(jìng)爭第二次獲取鎖，有線程獲取到鎖之后，就看看，有沒有誰在寫磁盤和網(wǎng)絡(luò)?

如果沒有，好，那么這個(gè)線程是個(gè)幸運(yùn)兒!直接交換雙緩沖的區(qū)域 1 和區(qū)域 2，接著第二次釋放鎖。這個(gè)過程相當(dāng)快速，內(nèi)存里判斷幾個(gè)條件，耗時(shí)不了幾微秒。

好，到這一步為止，內(nèi)存緩沖已經(jīng)被交換了，后面的線程可以立馬快速的依次獲取鎖，然后將 edits log 寫入內(nèi)存緩沖的區(qū)域 2，區(qū)域 1 中的數(shù)據(jù)被鎖定了，不能寫。

怎么樣，是不是又感受到了一點(diǎn)點(diǎn)多線程并發(fā)的優(yōu)化?

②多線程并發(fā)吞吐量的百倍優(yōu)化

接著，之前那個(gè)幸運(yùn)兒線程，將內(nèi)存緩沖的區(qū)域 1 中的數(shù)據(jù)讀取出來(此時(shí)沒人寫區(qū)域 1 了，都在寫區(qū)域 2)，將里面的 edtis log 都寫入磁盤文件，以及通過網(wǎng)絡(luò)寫入 JournalNodes 集群。

這個(gè)過程可是很耗時(shí)的!但是沒關(guān)系啊，人家做過優(yōu)化了，在寫磁盤和網(wǎng)絡(luò)的過程中，是不持有鎖的!

因此后面的線程可以噼里啪啦的快速的第一次獲取鎖后，立馬寫入內(nèi)存緩沖的區(qū)域 2，然后釋放鎖。

這個(gè)時(shí)候大量的線程都可以快速的寫入內(nèi)存，沒有阻塞和卡頓!怎么樣?并發(fā)優(yōu)化的感覺感受到了沒有!

③緩沖數(shù)據(jù)批量刷磁盤 + 網(wǎng)絡(luò)的優(yōu)化

那么在幸運(yùn)兒線程吭哧吭哧把數(shù)據(jù)寫磁盤和網(wǎng)絡(luò)的過程中，排在后面的大量線程，快速的第一次獲取鎖，寫內(nèi)存緩沖區(qū)域 2，釋放鎖，之后，這些線程第二次獲取到鎖后會(huì)干嘛?

他們會(huì)發(fā)現(xiàn)有人在寫磁盤啊，兄弟們!所以會(huì)立即休眠 1 秒，釋放鎖。

此時(shí)大量的線程并發(fā)過來的話，都會(huì)在這里快速的第二次獲取鎖，然后發(fā)現(xiàn)有人在寫磁盤和網(wǎng)絡(luò)，快速的釋放鎖，休眠。

怎么樣，這個(gè)過程沒有人長時(shí)間的阻塞其他人吧!因?yàn)槎紩?huì)快速的釋放鎖，所以后面的線程還是可以迅速的第一次獲取鎖后寫內(nèi)存緩沖!

Again!并發(fā)優(yōu)化的感覺感受到了沒有?

而且這時(shí)，一定會(huì)有很多線程發(fā)現(xiàn)，好像之前那個(gè)幸運(yùn)兒線程的 txid 是排在自己之后的，那么肯定就把自己的 edits log 從緩沖里寫入磁盤和網(wǎng)絡(luò)了。

這些線程甚至都不會(huì)休眠等待，直接就會(huì)返回后去干別的事情了，壓根兒不會(huì)卡在這里。這里又感受到并發(fā)的優(yōu)化沒有?

然后那個(gè)幸運(yùn)兒線程寫完磁盤和網(wǎng)絡(luò)之后，就會(huì)喚醒之前休眠的那些線程。

那些線程會(huì)依次排隊(duì)再第二次獲取鎖后進(jìn)入判斷，咦!發(fā)現(xiàn)沒有人在寫磁盤和網(wǎng)絡(luò)了!

然后就會(huì)再判斷，有沒有排在自己之后的線程已經(jīng)將自己的 edtis log 寫入磁盤和網(wǎng)絡(luò)了：

如果有的話，就直接返回了。

沒有的話，那么就成為第二個(gè)幸運(yùn)兒線程，交換兩塊緩沖區(qū)，區(qū)域 1 和區(qū)域 2 交換一下。

然后釋放鎖，自己開始吭哧吭哧的將區(qū)域 2 的數(shù)據(jù)寫入磁盤和網(wǎng)絡(luò)。

但是這個(gè)時(shí)候沒有關(guān)系啊，后面的線程如果要寫 edits log 的，還是可以第一次獲取鎖后立馬寫內(nèi)存緩沖再釋放鎖。以此類推。

總結(jié)

這套機(jī)制還是挺復(fù)雜的，涉及到了分段加鎖以及內(nèi)存雙緩沖兩個(gè)機(jī)制。

通過這套機(jī)制，NameNode 保證了多個(gè)線程在高并發(fā)的修改元數(shù)據(jù)之后寫 edits log 的時(shí)候，不會(huì)說一個(gè)線程一個(gè)線程的寫磁盤和網(wǎng)絡(luò)，那樣性能實(shí)在太差，并發(fā)能力太弱了!

所以通過上述那套復(fù)雜的機(jī)制，盡最大的努力保證，一個(gè)線程可以批量的將一個(gè)緩沖中的多條 edits log 刷入磁盤和網(wǎng)絡(luò)。

在這個(gè)漫長的吭哧吭哧的過程中，其他的線程可以快速的高并發(fā)寫入 edits log 到內(nèi)存緩沖里，不會(huì)阻塞其他的線程寫 edits log。

所以，正是依靠以上機(jī)制，最大限度優(yōu)化了 NameNode 處理高并發(fā)訪問修改元數(shù)據(jù)的能力!

 

 

中華石杉：十余年 BAT 架構(gòu)經(jīng)驗(yàn)，一線互聯(lián)網(wǎng)公司技術(shù)總監(jiān)。帶領(lǐng)上百人團(tuán)隊(duì)開發(fā)過多個(gè)億級(jí)流量高并發(fā)系統(tǒng)。現(xiàn)將多年工作中積累下的研究手稿、經(jīng)驗(yàn)總結(jié)整理成文，傾囊相授。微信公眾號(hào)：石杉的架構(gòu)筆記(ID：shishan100)。

標(biāo)簽： Mysql 安全 大數(shù)據(jù) 大數(shù)據(jù)技術(shù) 代碼 電商 電商網(wǎng) 電商網(wǎng)站 服務(wù)器 互聯(lián)網(wǎng) 互聯(lián)網(wǎng)公司 權(quán)限 數(shù)據(jù)庫 通信 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。