阿里巴巴平臺(tái)技術(shù)架構(gòu)與布局分析

阿里巴巴平臺(tái)技術(shù)架構(gòu)與布局分析“不論是人工智能還是其他前沿技術(shù)，都離不開高質(zhì)量的數(shù)據(jù)、強(qiáng)大的計(jì)算平臺(tái)和高效的算法平臺(tái)?！卑⒗锇桶图瘓F(tuán)CTO張建鋒在西雅圖表示，“只有這三件事放在一起，才能真正在機(jī)器學(xué)習(xí)和人工智能領(lǐng)域取得突破?！睌?shù)據(jù)特征阿里巴巴之所以將自己定位成大數(shù)據(jù)公司，是因?yàn)閾碛蟹浅６嗟母哔|(zhì)量數(shù)據(jù)?！敖裉齑髷?shù)據(jù)做得最好的，都是平臺(tái)性的企業(yè)，比如Facebook和Google，因?yàn)樗麄冇泻Ａ康母哔|(zhì)量的數(shù)據(jù)。與之相比，阿里的數(shù)據(jù)不但種類豐富，而且含金量特別高。”阿里的數(shù)據(jù)有三個(gè)明顯的特征：首先阿里的數(shù)據(jù)是用戶通過購(gòu)買行為投票產(chǎn)生的，和搜索等場(chǎng)景相比，更加真實(shí)；其次相較于社交等數(shù)據(jù)，阿里的數(shù)據(jù)高度結(jié)構(gòu)化，例如淘寶上的商品描述就高達(dá)一百多個(gè)緯度；第三非常密集而且實(shí)時(shí)，不管在無線還是PC端，阿里日常都有超過1億用戶在訪問。數(shù)據(jù)訓(xùn)練在計(jì)算平臺(tái)的構(gòu)建方面，得益于大規(guī)模數(shù)據(jù)訓(xùn)練的優(yōu)勢(shì)，阿里巴巴做了大量的技術(shù)創(chuàng)新。除了圍繞開源計(jì)算平臺(tái)Hadoop生態(tài)所做的各項(xiàng)工作，如流計(jì)算和批處理，阿里還有兩個(gè)非常高效的自研計(jì)算平臺(tái)：離線計(jì)算平臺(tái)ODPS和實(shí)時(shí)計(jì)算平臺(tái)Galaxy，不但承載阿里日常的海量計(jì)算工作，而且通過阿里云對(duì)外提供服務(wù)。為什么阿里巴巴能夠在7年之前就洞察到云計(jì)算的未來，“阿里一直做平臺(tái)化業(yè)務(wù)，交易平臺(tái)既然可以共享，計(jì)算能力為什么不能？所以我們比大多數(shù)公司更早意識(shí)到，計(jì)算可以變成水電煤一樣的公共服務(wù)?！备咝У乃惴◤埥ㄤh認(rèn)為，算法必須和行業(yè)場(chǎng)景進(jìn)行高度的結(jié)合，在實(shí)驗(yàn)室中并不能研究出真正高效的算法，而阿里巴巴最大的優(yōu)勢(shì)就是能夠提供多樣化的、極其豐富的場(chǎng)景。數(shù)據(jù)、計(jì)算平臺(tái)和算法的結(jié)合，是未來非常重要的趨勢(shì)。強(qiáng)大的計(jì)算平臺(tái)加上高效算法，能夠進(jìn)一步挖掘數(shù)據(jù)價(jià)值，最大化數(shù)據(jù)效率，形成正向循環(huán)。而云計(jì)算則能加速數(shù)據(jù)融合，例如孤立的看氣象數(shù)據(jù)價(jià)值有限，但和農(nóng)業(yè)或商業(yè)結(jié)合，就會(huì)產(chǎn)生巨大化學(xué)反應(yīng)。而傳統(tǒng)制造業(yè)如果能充分利用大數(shù)據(jù)，也將有助于大幅提升良品率。技術(shù)布局目前人工智能的技術(shù)方向很多，爆發(fā)性的出口還沒有明確答案，在張建鋒看來，最有可能獲得成功的，是對(duì)消費(fèi)的趨勢(shì)、對(duì)數(shù)據(jù)和場(chǎng)景規(guī)?；醒芯康娜?，阿里將在這方面投入更多的資源。物聯(lián)網(wǎng)經(jīng)過長(zhǎng)期發(fā)展，目前解決了很多核心的問題。第一，感知能力，目前傳感技術(shù)的發(fā)展非常迅速；第二，聯(lián)網(wǎng)技術(shù)，NB-IoT協(xié)議推動(dòng)廣域網(wǎng)組網(wǎng)，為物聯(lián)網(wǎng)打開了一扇窗。當(dāng)這兩個(gè)問題解決后，互聯(lián)網(wǎng)將迎來新一輪的爆發(fā)。張建鋒強(qiáng)調(diào)，有了感知互聯(lián)之后，才能真正擁有大數(shù)據(jù)，才可能實(shí)現(xiàn)人工智能，從而使得整個(gè)平臺(tái)更加智能化和人性化。據(jù)悉，阿里巴巴6年前開始研發(fā)的YunOS操作系統(tǒng)，目前已成為全球第三大操作系統(tǒng)。阿里將在操作系統(tǒng)、物聯(lián)網(wǎng)、云計(jì)算等方面持續(xù)投入資源。接下來，讓我們看看阿里基于大數(shù)據(jù)的全球電商、阿里數(shù)據(jù)庫(kù)AliSQL的開源，以及基于大數(shù)據(jù)的人工智能，希望能對(duì)阿里巴巴的大局窺一斑而知全貌。基于大數(shù)據(jù)的全球電商系統(tǒng)AliExpress從一開始就是一個(gè)全球性的平臺(tái)。任何一款商品的上架，來自全球200多個(gè)國(guó)家的消費(fèi)者都可以進(jìn)行購(gòu)買，而不同國(guó)家的商家都可以在這個(gè)平臺(tái)的平等競(jìng)爭(zhēng)。因?yàn)檫@個(gè)非常特殊的商業(yè)模型，面臨相當(dāng)多的不同領(lǐng)域，比如說支付、翻譯、物流，訂單和庫(kù)存數(shù)據(jù)在全球跨大洲的多個(gè)機(jī)房間的更改，同步和一致性就是一個(gè)前所未有的巨大挑戰(zhàn)。無論是Google、亞瑪遜、eBay、LinkedIn這類巨型的互聯(lián)網(wǎng)公司，還是獨(dú)角獸級(jí)別的電商，比如說Airbnb，都沒有這種挑戰(zhàn)。接下來首先介紹了AliExpress電商系統(tǒng)的理論基礎(chǔ)，通過頁(yè)面間跳出率的計(jì)算引出了全棧優(yōu)化的思路。然后，介紹了AliExpress平臺(tái)的設(shè)計(jì)思路和性能優(yōu)化過程，以及AliExpress使用過的幾個(gè)有效的優(yōu)化策略。最后，用實(shí)例展示了性能優(yōu)化帶來的結(jié)果，并對(duì)架構(gòu)設(shè)計(jì)的過程提出了幾點(diǎn)思考和總結(jié)。理論基礎(chǔ)這張圖代表流量分布和跳出率的關(guān)系。一個(gè)用戶放棄使用一個(gè)網(wǎng)站或者APP的行為叫做跳出。上圖中，橫軸代表延遲區(qū)間，縱軸代表流量分布。綠色的曲線代表顧客來網(wǎng)站或者APP的流量分布，可以發(fā)現(xiàn)大部分流量分布在幾百到一千毫秒，隨著時(shí)間延遲的增加，跳出率變高。整個(gè)系統(tǒng)計(jì)算時(shí)，使用轉(zhuǎn)化率公式：轉(zhuǎn)化率=1-跳出率。在發(fā)生性能故障的時(shí)候，比如有少部分機(jī)器出現(xiàn)延遲大大增加的情況，我們會(huì)發(fā)現(xiàn)高速性能的流量會(huì)變少，有很長(zhǎng)延時(shí)的流量會(huì)增加，跳去率也很快地爬升上去。這個(gè)過程表明，如果延遲越大，那么延遲跳出率會(huì)變得越來越高，即轉(zhuǎn)化率變得越來越低。我們可以把虛線看作是優(yōu)化前，實(shí)現(xiàn)看作是優(yōu)化后，其中的部分就是優(yōu)化得到的新的轉(zhuǎn)化率。

我們做更深一步的討論。上圖中，紅色代表轉(zhuǎn)化率，藍(lán)色代表性能區(qū)間的分布。假設(shè)我們把性能從a秒壓縮到3秒時(shí)，轉(zhuǎn)化率的回報(bào)是圖中綠色的部分。這些回報(bào)是怎么得到的？隨著延遲越大，轉(zhuǎn)化率越低，由于回報(bào)是單調(diào)減的函數(shù)，所以壓縮之后得到的回報(bào)就是圖中綠色的部分。如果我們知道壓縮的時(shí)間，我們就可以預(yù)測(cè)出單個(gè)頁(yè)面上得到的回報(bào)，這個(gè)回報(bào)稱為性能損耗（PerformanceLoss）。

接下來，我們進(jìn)行從A頁(yè)面到B頁(yè)面的理論跳出率的計(jì)算。如上圖所示，A是一個(gè)頁(yè)面，0、1、2、3是它的前序頁(yè)面，end代表跳出頁(yè)面。我們發(fā)現(xiàn)，出口的跳出率=經(jīng)過補(bǔ)償后的所有跳出率-自然跳出率。其中，自然跳出率是指自己因?yàn)閷?duì)商品內(nèi)容不滿意、評(píng)價(jià)不滿意而產(chǎn)生的自然跳出。

在此基礎(chǔ)上，我們可以將其推廣到所有頁(yè)面。一個(gè)大的網(wǎng)站可能有數(shù)百個(gè)頁(yè)面，比如上圖中的兩條鏈路：搜索—詳情—訂單；商鋪—商鋪詳情—訂單。在這種關(guān)系下，如果我們把每條鏈路的跳出率算出來，其實(shí)我們就得到了每條鏈路的理論最大流量，這樣我們就知道了最終頁(yè)面的最大流量。這其實(shí)就是一個(gè)全棧性能損耗的過程，我們可以知道每個(gè)細(xì)小的過程對(duì)全局的貢獻(xiàn)。這對(duì)于優(yōu)化方案的制定非常重要。在做優(yōu)化方案的時(shí)候，我們可以選擇一個(gè)頁(yè)面做嘗試，準(zhǔn)確度量一個(gè)頁(yè)面的回報(bào)，這樣就可以明確知道一種優(yōu)化方案對(duì)整個(gè)系統(tǒng)的貢獻(xiàn)，即本次優(yōu)化對(duì)電商系統(tǒng)的訂單回報(bào)量。平臺(tái)設(shè)計(jì)

平臺(tái)是獨(dú)立于業(yè)務(wù)領(lǐng)域的。針對(duì)不同的業(yè)務(wù)領(lǐng)域，有不同的優(yōu)化方案，顯示在圖中左下部分。平臺(tái)的功能是：把當(dāng)前的性能變得可視化；實(shí)時(shí)度量目前的性能水平；對(duì)全鏈路做一個(gè)性能的監(jiān)控；所有的領(lǐng)域都可以接到這個(gè)平臺(tái)上；做一個(gè)全量的度量。平臺(tái)其實(shí)就是將性能優(yōu)化的回報(bào)變成一個(gè)可度量的、非常容易看到的結(jié)果。在整個(gè)試驗(yàn)的過程中，數(shù)據(jù)是不斷積累的，數(shù)據(jù)會(huì)帶來準(zhǔn)確的度量結(jié)果，度量結(jié)果則決定是否將優(yōu)化在全棧進(jìn)行推廣。性能優(yōu)化

首先，應(yīng)該有很多業(yè)務(wù)模塊來收集用戶的行為數(shù)據(jù)（請(qǐng)求時(shí)間、建聯(lián)時(shí)間等），然后數(shù)據(jù)經(jīng)過采集系統(tǒng)進(jìn)行處理。處理完的數(shù)據(jù)有兩種分析方式：離線分析、實(shí)時(shí)分析，區(qū)別在于離線的處理量比較大一些。分析的結(jié)果都會(huì)存在一個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)中，最終會(huì)送到cachelayer中做追溯和同比。后端會(huì)支持很多不同的應(yīng)用場(chǎng)景，比如報(bào)警、監(jiān)控、報(bào)表。優(yōu)化方案

其實(shí)，在DNS層、網(wǎng)絡(luò)層、CDN層、業(yè)內(nèi)沉淀有很多優(yōu)化方案。這些優(yōu)化方案哪些最有效呢？下面列舉幾個(gè)使用過的有效的優(yōu)化方案。動(dòng)態(tài)加速

優(yōu)化前，用戶的動(dòng)態(tài)請(qǐng)求都在源站，請(qǐng)求鏈路是：用戶—運(yùn)營(yíng)商—源站。全世界都要去源站拿數(shù)據(jù)，這樣的請(qǐng)求鏈路會(huì)非常長(zhǎng)，過程相當(dāng)耗時(shí)。

優(yōu)化后，盡量把動(dòng)態(tài)數(shù)據(jù)推到邊緣節(jié)點(diǎn)，這些邊緣節(jié)點(diǎn)不需要去源站進(jìn)行請(qǐng)求，只需直接在邊緣節(jié)點(diǎn)做請(qǐng)求。另外一個(gè)優(yōu)化：請(qǐng)求既可以是同步的，也可以是異步的，可以同時(shí)并行請(qǐng)求多個(gè)頁(yè)面內(nèi)的元素。整體的動(dòng)態(tài)回源的過程是對(duì)內(nèi)容的動(dòng)態(tài)加速。另外一個(gè)動(dòng)態(tài)加速的做法是，如果需要回源的話，把這個(gè)回源網(wǎng)絡(luò)的最優(yōu)化路徑交給CDN來決定，CDN會(huì)幫助找到目前一條最優(yōu)的鏈路來回源。動(dòng)態(tài)加速其實(shí)是一系列的優(yōu)化方案，比如包括內(nèi)容壓縮等。整個(gè)過程中也有不少的技術(shù)挑戰(zhàn)：電商需要知道用戶的真實(shí)IP；源站防止攻擊要做請(qǐng)求攔截等等。靜態(tài)化+ESI

用戶把內(nèi)容放到邊緣節(jié)點(diǎn)上，到了機(jī)房?jī)?nèi)其實(shí)也是做一個(gè)緩存：如果是動(dòng)態(tài)內(nèi)容則直接回源到數(shù)據(jù)庫(kù)，如果是靜態(tài)的不命中的內(nèi)容則通過業(yè)務(wù)邏輯回源到數(shù)據(jù)庫(kù)。請(qǐng)求鏈路一般是“讀鏈路”，“寫鏈路”會(huì)變更db，db被變更消息的消費(fèi)者消費(fèi)之后通過業(yè)務(wù)邏輯更新存入緩存，是緩存內(nèi)的信息總是最新的。這樣的過程相當(dāng)于用戶如果能直接hit到邊緣節(jié)點(diǎn)就返回（大多數(shù)最優(yōu)的情況），不是最優(yōu)的情況會(huì)hit到緩存層再返回。元素請(qǐng)求合并

一個(gè)頁(yè)面中會(huì)有很多的子元素，如果單獨(dú)去請(qǐng)求，則每個(gè)請(qǐng)求都是回源的調(diào)用，那么每個(gè)請(qǐng)求都會(huì)占用很多時(shí)間（包括TCP建聯(lián)時(shí)間等）。元素請(qǐng)求合并就是指把所有的請(qǐng)求合并成一個(gè)，統(tǒng)一提供到服務(wù)方，然后服務(wù)端再將這些請(qǐng)求分發(fā)，然后再統(tǒng)一合并再返回。CDN調(diào)度優(yōu)化

AliExpress在全球的各個(gè)國(guó)家都有相當(dāng)多的用戶，在巴西是第二大的電商網(wǎng)站，巴西用戶可以請(qǐng)求美國(guó)的邊緣節(jié)點(diǎn)，也可以請(qǐng)求巴西的邊緣節(jié)點(diǎn)。經(jīng)過測(cè)試，巴西用戶請(qǐng)求巴西的邊緣節(jié)點(diǎn)的相對(duì)耗時(shí)要少一些，可以認(rèn)為是4個(gè)單位，請(qǐng)求美國(guó)節(jié)點(diǎn)耗時(shí)5個(gè)單位，但是請(qǐng)求地理位置離巴西近的阿根廷節(jié)點(diǎn)需要耗時(shí)7個(gè)節(jié)點(diǎn)。所以得出結(jié)論：不能單純從地理位置來估計(jì)請(qǐng)求節(jié)點(diǎn)的耗時(shí)，以此為基礎(chǔ)可以優(yōu)化CDN調(diào)度。業(yè)務(wù)結(jié)果上述理論的分析，平臺(tái)的搭建，業(yè)務(wù)的優(yōu)化，帶來了：整套系統(tǒng)的分析能力提升；過去的優(yōu)化直接為整個(gè)網(wǎng)站帶來5.07%的訂單；性能損耗明顯下降；購(gòu)買力增強(qiáng)。思考總結(jié)

這套系統(tǒng)給大家?guī)淼淖畲髢r(jià)值是：在做這套架構(gòu)設(shè)計(jì)的過程中是不是能有新的創(chuàng)新？通過這個(gè)創(chuàng)新能否帶來業(yè)務(wù)價(jià)值？把技術(shù)變民主，每個(gè)有想法的人都可以去嘗試優(yōu)化，每個(gè)人都可以做貢獻(xiàn)。所有做的事情能不能量化？能不能做比較？不同的人對(duì)性能優(yōu)化的貢獻(xiàn)都應(yīng)該能準(zhǔn)確度量，這樣可以把一個(gè)人的力量放大到整個(gè)團(tuán)隊(duì)的力量。怎么一步一步贏得這個(gè)團(tuán)隊(duì)的信任？阿里云數(shù)據(jù)庫(kù)AliSQLAliSQL是基于MySQL官方版本的一個(gè)分支，由阿里云數(shù)據(jù)庫(kù)團(tuán)隊(duì)維護(hù)，目前也應(yīng)用于阿里巴巴集團(tuán)業(yè)務(wù)以及阿里云數(shù)據(jù)庫(kù)服務(wù)。該版本在MySQL社區(qū)版的基礎(chǔ)上做了大量的性能與功能的優(yōu)化改進(jìn)，尤其適合電商、云計(jì)算以及金融等行業(yè)環(huán)境。最新的AliSQL版本不僅從其他開源分支，比如Percona，MariaDB，WebScaleSQL等社區(qū)汲取精華，也沉淀了阿里巴巴多年在MySQL領(lǐng)域的經(jīng)驗(yàn)和解決方案。AliSQL增加更多監(jiān)控指標(biāo)，并針對(duì)電商秒殺、物聯(lián)網(wǎng)大數(shù)據(jù)壓縮、金融數(shù)據(jù)安全等場(chǎng)景提供個(gè)性化的解決方案。在通用基準(zhǔn)測(cè)試場(chǎng)景下，AliSQL版本比MySQL官方版本有著70%的性能提升。在秒殺場(chǎng)景下，性能提升100倍。性能優(yōu)化

功能、穩(wěn)定性增強(qiáng)

接下來主要講解一個(gè)很小的功能——在線執(zhí)行計(jì)劃優(yōu)化。在MySQL內(nèi)部，每一個(gè)SQL執(zhí)行都會(huì)解析，在解析的過程中可能會(huì)解析出一個(gè)錯(cuò)誤的執(zhí)行計(jì)劃，致使執(zhí)行效率大大降低，甚至?xí)颜麄€(gè)系統(tǒng)打爆。針對(duì)這個(gè)問題，其實(shí)Oracle是有解法的，即所謂的執(zhí)行計(jì)劃綁定。在在線執(zhí)行計(jì)劃優(yōu)化技術(shù)出現(xiàn)之前，我們能做的是告訴應(yīng)用我們現(xiàn)在有SQL走錯(cuò)了執(zhí)行計(jì)劃，讓應(yīng)用加hint把執(zhí)行計(jì)劃固定下來，這種做法耗時(shí)非常長(zhǎng)，并且需要應(yīng)用介入，對(duì)可持續(xù)服務(wù)是一個(gè)很大的挑戰(zhàn)。所以，我們可以做這么一件事，在線把一個(gè)應(yīng)用的執(zhí)行計(jì)劃綁定好。具體做法是：我們識(shí)別在線的SQL，對(duì)SQL進(jìn)行模式識(shí)別，對(duì)于錯(cuò)誤的SQL，我們?cè)赟QL發(fā)到MySQL之后再對(duì)它識(shí)別之后做一個(gè)hint來把執(zhí)行計(jì)劃固定下來。這樣一個(gè)功能能夠很快把整個(gè)系統(tǒng)的響應(yīng)時(shí)間降下來，使業(yè)務(wù)馬上恢復(fù)服務(wù)。大連接、高并發(fā)下的數(shù)據(jù)庫(kù)穩(wěn)定性保障大連接、高并發(fā)下的數(shù)據(jù)庫(kù)會(huì)出現(xiàn)什么問題呢？

這是一個(gè)商品庫(kù)的監(jiān)控圖。上邊是threadsrunning，用于在MySQL內(nèi)部監(jiān)控活躍線程數(shù)，下面是responsetime（響應(yīng)時(shí)間），這兩個(gè)是MySQL里面兩個(gè)重要的指標(biāo)。一般情況下，這兩個(gè)數(shù)值都是非常低的，但是偶爾會(huì)出現(xiàn)圖中的高峰，高峰的持續(xù)時(shí)間也很短，但是峰值特別高。

在壓力很低的情況下，數(shù)據(jù)庫(kù)為什么會(huì)時(shí)不時(shí)的停止服務(wù)？如上圖所示，下面是數(shù)據(jù)庫(kù)，上面是APPServers，每一個(gè)應(yīng)用服務(wù)器到達(dá)數(shù)據(jù)庫(kù)的時(shí)間是不固定的。如果很多用戶恰巧在同一時(shí)間訪問相同商品的話，從系統(tǒng)看來就是幾萬個(gè)連接同時(shí)活躍，就會(huì)出現(xiàn)之前所說的問題。這個(gè)問題并不是阿里特有的問題，它其實(shí)是一個(gè)排隊(duì)論的問題。解決方案1：高低水位限流高水位限流方法：當(dāng)發(fā)現(xiàn)數(shù)據(jù)庫(kù)的threadsrunning超過一個(gè)閾值時(shí)，直接將超過閾值的連接數(shù)拋棄掉。這種方式雖然保證了部分請(qǐng)求能夠順利的執(zhí)行并且有很好的響應(yīng)時(shí)間，但是卻拋棄了很大一部分的并發(fā)用戶請(qǐng)求。

考慮到拋棄的不可行性，想到了排隊(duì)，即低水位限流：在數(shù)據(jù)庫(kù)內(nèi)部做了一個(gè)隊(duì)列，所有的用戶請(qǐng)求到達(dá)的時(shí)候，先hash到隊(duì)列上。當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)并發(fā)的請(qǐng)求數(shù)激增時(shí)，可以先服務(wù)一批，服務(wù)完成之后再服務(wù)下一批，這樣就可以在不拋棄的基礎(chǔ)上保證數(shù)據(jù)庫(kù)的穩(wěn)定。低水位限流有了一些線程池的思想在里面，是一個(gè)比較粗的線程池。解決方案2：線程池

處理并發(fā)請(qǐng)求，線程池是一個(gè)很好的解決思路，上圖就是線程池的簡(jiǎn)單架構(gòu)圖。在MySQL中，一個(gè)用戶請(qǐng)求對(duì)應(yīng)到MySQL的一個(gè)工作線程。線程池是把用戶請(qǐng)求線程和工作線程進(jìn)行解耦，用戶請(qǐng)求線程可以非常多，比如用戶請(qǐng)求線程可以有成千上萬，而工作線程只有固定的幾十個(gè)上百個(gè)。把這些工作線程進(jìn)行聚合，每一個(gè)Group里面有多個(gè)工作線程。用戶線程通過哈希算法映射到Group中。如果Group中所有的工作線程都正在服務(wù)，那么就進(jìn)行排隊(duì)等待。為什么所有工作線程不放到一起，而是分開成一個(gè)個(gè)的Group？因?yàn)镚roup是可以與CPU的核進(jìn)行綁定的，可以減少很多CPU的調(diào)度開銷，這樣又進(jìn)一步提高了整個(gè)線程池的效率。使用線程池時(shí)應(yīng)該注意哪些問題？慢SQL是線程池的大敵！如果慢SQL比較多的話，所有的工作線程就會(huì)被占滿，這樣導(dǎo)致非常快的SQL也不能去搶占工作單元，相當(dāng)于慢SQL把整個(gè)系統(tǒng)完全堵住了。所以，使用線程池時(shí)要對(duì)整個(gè)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行一個(gè)很大的優(yōu)化，把數(shù)據(jù)庫(kù)的SQL性能進(jìn)行比較好的調(diào)優(yōu)，頻繁執(zhí)行的SQL不能是慢SQL。慢SQL的來源包括：正常業(yè)務(wù)SQL、定時(shí)任務(wù)、系統(tǒng)后臺(tái)操作（例如：binlogdump）。無論任何原因?qū)е戮€程池堵塞，確保管理命令不受影響！管理命令不應(yīng)該走正常的業(yè)務(wù)線程池，而應(yīng)該走一個(gè)單獨(dú)的接口。當(dāng)線程池堵塞時(shí)，管理命令可以通過Extraport將慢SQL處理掉。線程池和用戶的登錄請(qǐng)求也是有關(guān)的。登錄到數(shù)據(jù)庫(kù)的那些請(qǐng)求其實(shí)走的也是線程池。使用線程池之后，處理連接風(fēng)暴的能力也會(huì)變?nèi)酢?kù)存熱點(diǎn)更新

“雙十一”時(shí)，有很多商品是大家都想去搶購(gòu)的，庫(kù)存在數(shù)據(jù)庫(kù)內(nèi)部只是一行標(biāo)識(shí)商品剩余件數(shù)的記錄，買商品的行為其實(shí)是大家在并發(fā)的扣減商品記錄。當(dāng)我們并發(fā)的去扣減記錄的時(shí)候，為了保證正確性，一定要對(duì)這條記錄加鎖，由于鎖的存在，就把商品扣減變成了一個(gè)串行的過程。這個(gè)問題與之前問題的不同之處是，這個(gè)問題是很多用戶去搶一個(gè)熱點(diǎn)商品所帶來的問題。先把它做成一個(gè)簡(jiǎn)化的模型，先開始一個(gè)事務(wù)，對(duì)它做一個(gè)插入，更新熱點(diǎn)行，讀出熱點(diǎn)行的后項(xiàng)，最后進(jìn)行提交。其中，更新熱點(diǎn)行需要加鎖，提交的時(shí)候放鎖。MySQL會(huì)出現(xiàn)排隊(duì)等鎖的過程，并且每次排隊(duì)都會(huì)進(jìn)行死鎖檢測(cè)，這樣逐漸使得死鎖檢測(cè)時(shí)間越來越長(zhǎng)。

第一版做了一個(gè)很簡(jiǎn)單的優(yōu)化，由于很多線程進(jìn)入到數(shù)據(jù)庫(kù)，但是又無事可做，所以控制進(jìn)入數(shù)據(jù)庫(kù)的線程數(shù)，保證InnoDB中有固定數(shù)目的線程，這樣會(huì)使死鎖檢測(cè)、線程切換時(shí)間等都急劇下降。

繼續(xù)分析該模型，持有鎖的時(shí)間是從第三步開始，第五步結(jié)束，這個(gè)過程中有兩個(gè)網(wǎng)絡(luò)交互時(shí)間?？紤]到降低網(wǎng)絡(luò)交互時(shí)間，把第三步和第四步合并，先對(duì)熱點(diǎn)行進(jìn)行更新，更新完之后順便把熱點(diǎn)行返回給應(yīng)用服務(wù)器。在此基礎(chǔ)上，再考慮繼續(xù)減少網(wǎng)絡(luò)交互時(shí)間，把三四五步都合并。更新庫(kù)存時(shí)，如果更新到了一行，并且更新后項(xiàng)也滿足，就直接把這個(gè)事務(wù)提交；如果說這里面的邏輯不滿足，則自動(dòng)把事務(wù)回滾掉。這樣一來，所有持有鎖的SQL都在數(shù)據(jù)庫(kù)內(nèi)部，沒有任何網(wǎng)絡(luò)交互。

既然串行已經(jīng)優(yōu)化到了一定的極致，能不能把所有穿行的用戶請(qǐng)求做一個(gè)batch合并？怎么演進(jìn)？用戶發(fā)SQL過來后，對(duì)熱點(diǎn)記錄做哈希，其中每一個(gè)桶是一個(gè)熱點(diǎn)行，對(duì)每個(gè)桶做收集，然后由桶里面的第一個(gè)事務(wù)一批次的把當(dāng)前桶里收集的所有扣減請(qǐng)求全部一次性提交掉，這樣雖然仍舊是串行化，但是用批處理去做了。為了提升整體性能，當(dāng)?shù)谝慌峤坏臅r(shí)候第二批開始收集，這樣就將單線程的串行變成了批處理的線程。完整生態(tài)體系

數(shù)據(jù)庫(kù)追求的是一個(gè)體系，而不僅僅是一個(gè)數(shù)據(jù)庫(kù)。想要用好數(shù)據(jù)庫(kù)，需要為數(shù)據(jù)庫(kù)構(gòu)建完整的生態(tài)體系。其中，第二層是運(yùn)維組件層，第三層是運(yùn)維服務(wù)