日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

公告:魔扣目錄網(wǎng)為廣大站長提供免費(fèi)收錄網(wǎng)站服務(wù),提交前請做好本站友鏈:【 網(wǎng)站目錄:http://www.ylptlb.cn 】, 免友鏈快審服務(wù)(50元/站),

點(diǎn)擊這里在線咨詢客服
新站提交
  • 網(wǎng)站:51998
  • 待審:31
  • 小程序:12
  • 文章:1030137
  • 會員:747

一些數(shù)據(jù)

大家還記得2013年的小米秒殺嗎?三款小米手機(jī)各11萬臺開賣,走的都是大秒系統(tǒng),3分鐘后成為雙十一第一家也是最快破億的旗艦店。經(jīng)過日志統(tǒng)計(jì),前端系統(tǒng)雙11峰值有效請求約60w以上的QPS ,而后端cache的集群峰值近2000w/s、單機(jī)也近30w/s,但到真正的寫時(shí)流量要小很多了,當(dāng)時(shí)最高下單減庫存tps是紅米創(chuàng)造,達(dá)到1500/s。

熱點(diǎn)隔離

秒殺系統(tǒng)設(shè)計(jì)的第一個(gè)原則就是將這種熱點(diǎn)數(shù)據(jù)隔離出來,不要讓1%的請求影響到另外的99%,隔離出來后也更方便對這1%的請求做針對性優(yōu)化。針對秒殺我們做了多個(gè)層次的隔離:

  • 業(yè)務(wù)隔離。把秒殺做成一種營銷活動,賣家要參加秒殺這種營銷活動需要單獨(dú)報(bào)名,從技術(shù)上來說,賣家報(bào)名后對我們來說就是已知熱點(diǎn),當(dāng)真正開始時(shí)我們可以提前做好預(yù)熱。
  • 系統(tǒng)隔離。系統(tǒng)隔離更多是運(yùn)行時(shí)的隔離,可以通過分組部署的方式和另外99%分開。秒殺還申請了單獨(dú)的域名,目的也是讓請求落到不同的集群中。
  • 數(shù)據(jù)隔離。秒殺所調(diào)用的數(shù)據(jù)大部分都是熱數(shù)據(jù),比如會啟用單獨(dú)cache集群或MySQL數(shù)據(jù)庫來放熱點(diǎn)數(shù)據(jù),目前也是不想0.01%的數(shù)據(jù)影響另外99.99%。

當(dāng)然實(shí)現(xiàn)隔離很有多辦法,如可以按照用戶來區(qū)分,給不同用戶分配不同cookie,在接入層路由到不同服務(wù)接口中;還有在接入層可以對URL的不同Path來設(shè)置限流策略等。服務(wù)層通過調(diào)用不同的服務(wù)接口;數(shù)據(jù)層可以給數(shù)據(jù)打上特殊的標(biāo)來區(qū)分。目的都是把已經(jīng)識別出來的熱點(diǎn)和普通請求區(qū)分開來。

動靜分離

前面介紹在系統(tǒng)層面上的原則是要做隔離,接下去就是要把熱點(diǎn)數(shù)據(jù)進(jìn)行動靜分離,這也是解決大流量系統(tǒng)的一個(gè)重要原則。如何給系統(tǒng)做動靜分離的靜態(tài)化改造我以前寫過一篇《高訪問量系統(tǒng)的靜態(tài)化架構(gòu)設(shè)計(jì)》詳細(xì)介紹了淘寶商品系統(tǒng)的靜態(tài)化設(shè)計(jì)思路,感興趣的可以在《程序員》雜志上找一下。我們的大秒系統(tǒng)是從商品詳情系統(tǒng)發(fā)展而來,所以本身已經(jīng)實(shí)現(xiàn)了動靜分離,如圖1。

淘寶大秒系統(tǒng)設(shè)計(jì)詳解

 

圖1 大秒系統(tǒng)動靜分離

除此之外還有如下特點(diǎn):

  • 把整個(gè)頁面Cache在用戶瀏覽器
  • 如果強(qiáng)制刷新整個(gè)頁面,也會請求到CDN
  • 實(shí)際有效請求只是“刷新?lián)寣?rdquo;按鈕

 

這樣把90%的靜態(tài)數(shù)據(jù)緩存在用戶端或者CDN上,當(dāng)真正秒殺時(shí)用戶只需要點(diǎn)擊特殊的按鈕“刷新?lián)寣?rdquo;即可,而不需要刷新整個(gè)頁面,這樣只向服務(wù)端請求很少的有效數(shù)據(jù),而不需要重復(fù)請求大量靜態(tài)數(shù)據(jù)。秒殺的動態(tài)數(shù)據(jù)和普通的詳情頁面的動態(tài)數(shù)據(jù)相比更少,性能也比普通的詳情提升3倍以上。所以“刷新?lián)寣?rdquo;這種設(shè)計(jì)思路很好地解決了不刷新頁面就能請求到服務(wù)端最新的動態(tài)數(shù)據(jù)。

基于時(shí)間分片削峰

熟悉淘寶秒殺的都知道,第一版的秒殺系統(tǒng)本身并沒有答題功能,后面才增加了秒殺答題,當(dāng)然秒殺答題一個(gè)很重要的目的是為了防止秒殺器,2011年秒殺非常火的時(shí)候,秒殺器也比較猖獗,而沒有達(dá)到全民參與和營銷的目的,所以增加的答題來限制秒殺器。增加答題后,下單的時(shí)間基本控制在2s后,秒殺器的下單比例也下降到5%以下。新的答題頁面如圖2。

淘寶大秒系統(tǒng)設(shè)計(jì)詳解

 

圖2 秒答題頁面

其實(shí)增加答題還有一個(gè)重要的功能,就是把峰值的下單請求給拉長了,從以前的1s之內(nèi)延長到2~10s左右,請求峰值基于時(shí)間分片了,這個(gè)時(shí)間的分片對服務(wù)端處理并發(fā)非常重要,會減輕很大壓力,另外由于請求的先后,靠后的請求自然也沒有庫存了,也根本到不了最后的下單步驟,所以真正的并發(fā)寫就非常有限了。其實(shí)這種設(shè)計(jì)思路目前也非常普遍,如支付寶的“咻一咻”已及微信的搖一搖。

除了在前端通過答題在用戶端進(jìn)行流量削峰外,在服務(wù)端一般通過鎖或者隊(duì)列來控制瞬間請求。

數(shù)據(jù)分層校驗(yàn)

淘寶大秒系統(tǒng)設(shè)計(jì)詳解

 

圖3 分層校驗(yàn)

對大流量系統(tǒng)的數(shù)據(jù)做分層校驗(yàn)也是最重要的設(shè)計(jì)原則,所謂分層校驗(yàn)就是對大量的請求做成“漏斗”式設(shè)計(jì),如圖3所示:在不同層次盡可能把無效的請求過濾,“漏斗”的最末端才是有效的請求,要達(dá)到這個(gè)效果必須對數(shù)據(jù)做分層的校驗(yàn),下面是一些原則:

  • 先做數(shù)據(jù)的動靜分離
  • 將90%的數(shù)據(jù)緩存在客戶端瀏覽器
  • 將動態(tài)請求的讀數(shù)據(jù)Cache在Web端
  • 對讀數(shù)據(jù)不做強(qiáng)一致性校驗(yàn)
  • 對寫數(shù)據(jù)進(jìn)行基于時(shí)間的合理分片
  • 對寫請求做限流保護(hù)
  • 對寫數(shù)據(jù)進(jìn)行強(qiáng)一致性校驗(yàn)

 

秒殺系統(tǒng)正是按照這個(gè)原則設(shè)計(jì)的系統(tǒng)架構(gòu),如圖4所示。

淘寶大秒系統(tǒng)設(shè)計(jì)詳解

 

圖4 秒殺系統(tǒng)分層架構(gòu)

把大量靜態(tài)不需要檢驗(yàn)的數(shù)據(jù)放在離用戶最近的地方;在前端讀系統(tǒng)中檢驗(yàn)一些基本信息,如用戶是否具有秒殺資格、商品狀態(tài)是否正常、用戶答題是否正確、秒殺是否已經(jīng)結(jié)束等;在寫數(shù)據(jù)系統(tǒng)中再校驗(yàn)一些如是否是非法請求,營銷等價(jià)物是否充足(淘金幣等),寫的數(shù)據(jù)一致性如檢查庫存是否還有等;最后在數(shù)據(jù)庫層保證數(shù)據(jù)最終準(zhǔn)確性,如庫存不能減為負(fù)數(shù)。

實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)

其實(shí)秒殺系統(tǒng)本質(zhì)是還是一個(gè)數(shù)據(jù)讀的熱點(diǎn)問題,而且是最簡單一種,因?yàn)樵谖奶岬酵ㄟ^業(yè)務(wù)隔離,我們已能提前識別出這些熱點(diǎn)數(shù)據(jù),我們可以提前做一些保護(hù),提前識別的熱點(diǎn)數(shù)據(jù)處理起來還相對簡單,比如分析歷史成交記錄發(fā)現(xiàn)哪些商品比較熱門,分析用戶的購物車記錄也可以發(fā)現(xiàn)那些商品可能會比較好賣,這些都是可以提前分析出來的熱點(diǎn)。比較困難的是那種我們提前發(fā)現(xiàn)不了突然成為熱點(diǎn)的商品成為熱點(diǎn),這種就要通過實(shí)時(shí)熱點(diǎn)數(shù)據(jù)分析了,目前我們設(shè)計(jì)可以在3s內(nèi)發(fā)現(xiàn)交易鏈路上的實(shí)時(shí)熱點(diǎn)數(shù)據(jù),然后根據(jù)實(shí)時(shí)發(fā)現(xiàn)的熱點(diǎn)數(shù)據(jù)每個(gè)系統(tǒng)做實(shí)時(shí)保護(hù)。 具體實(shí)現(xiàn)如下:

  • 構(gòu)建一個(gè)異步的可以收集交易鏈路上各個(gè)中間件產(chǎn)品如Tengine、Tair緩存、HSF等本身的統(tǒng)計(jì)的熱點(diǎn)key(Tengine和Tair緩存等中間件產(chǎn)品本身已經(jīng)有熱點(diǎn)統(tǒng)計(jì)模塊)。
  • 建立一個(gè)熱點(diǎn)上報(bào)和可以按照需求訂閱的熱點(diǎn)服務(wù)的下發(fā)規(guī)范,主要目的是通過交易鏈路上各個(gè)系統(tǒng)(詳情、購物車、交易、優(yōu)惠、庫存、物流)訪問的時(shí)間差,把上游已經(jīng)發(fā)現(xiàn)的熱點(diǎn)能夠透傳給下游系統(tǒng),提前做好保護(hù)。比如大促高峰期詳情系統(tǒng)是最早知道的,在統(tǒng)計(jì)接入層上Tengine模塊統(tǒng)計(jì)的熱點(diǎn)URL。
  • 將上游的系統(tǒng)收集到熱點(diǎn)數(shù)據(jù)發(fā)送到熱點(diǎn)服務(wù)臺上,然后下游系統(tǒng)如交易系統(tǒng)就會知道哪些商品被頻繁調(diào)用,然后做熱點(diǎn)保護(hù)。如圖5所示。

 

淘寶大秒系統(tǒng)設(shè)計(jì)詳解

 

圖5 實(shí)時(shí)熱點(diǎn)數(shù)據(jù)后臺

重要的幾個(gè):其中關(guān)鍵部分包括:

  • 這個(gè)熱點(diǎn)服務(wù)后臺抓取熱點(diǎn)數(shù)據(jù)日志最好是異步的,一方面便于做到通用性,另一方面不影響業(yè)務(wù)系統(tǒng)和中間件產(chǎn)品的主流程。
  • 熱點(diǎn)服務(wù)后臺、現(xiàn)有各個(gè)中間件和應(yīng)用在做的沒有取代關(guān)系,每個(gè)中間件和應(yīng)用還需要保護(hù)自己,熱點(diǎn)服務(wù)后臺提供一個(gè)收集熱點(diǎn)數(shù)據(jù)提供熱點(diǎn)訂閱服務(wù)的統(tǒng)一規(guī)范和工具,便于把各個(gè)系統(tǒng)熱點(diǎn)數(shù)據(jù)透明出來。
  • 熱點(diǎn)發(fā)現(xiàn)要做到實(shí)時(shí)(3s內(nèi))。

 

關(guān)鍵技術(shù)優(yōu)化點(diǎn)

前面介紹了一些如何設(shè)計(jì)大流量讀系統(tǒng)中用到的原則,但是當(dāng)這些手段都用了,還是有大流量涌入該如何處理呢?秒殺系統(tǒng)要解決幾個(gè)關(guān)鍵問題。

JAVA處理大并發(fā)動態(tài)請求優(yōu)化

其實(shí)Java和通用的Web服務(wù)器相比(Nginx或Apache)在處理大并發(fā)HTTP請求時(shí)要弱一點(diǎn),所以一般我們都會對大流量的Web系統(tǒng)做靜態(tài)化改造,讓大部分請求和數(shù)據(jù)直接在Nginx服務(wù)器或者Web代理服務(wù)器(Varnish、Squid等)上直接返回(可以減少數(shù)據(jù)的序列化與反序列化),不要將請求落到Java層上,讓Java層只處理很少數(shù)據(jù)量的動態(tài)請求,當(dāng)然針對這些請求也有一些優(yōu)化手段可以使用:

  • 直接使用Servlet處理請求。避免使用傳統(tǒng)的MVC框架也許能繞過一大堆復(fù)雜且用處不大的處理邏輯,節(jié)省個(gè)1ms時(shí)間,當(dāng)然這個(gè)取決于你對MVC框架的依賴程度。
  • 直接輸出流數(shù)據(jù)。使用resp.getOutputStream()而不是resp.getWriter()可以省掉一些不變字符數(shù)據(jù)編碼,也能提升性能;還有數(shù)據(jù)輸出時(shí)也推薦使用JSON而不是模板引擎(一般都是解釋執(zhí)行)輸出頁面。

 

同一商品大并發(fā)讀問題

你會說這個(gè)問題很容易解決,無非放到Tair緩存里面就行,集中式Tair緩存為了保證命中率,一般都會采用一致性Hash,所以同一個(gè)key會落到一臺機(jī)器上,雖然我們的Tair緩存機(jī)器單臺也能支撐30w/s的請求,但是像大秒這種級別的熱點(diǎn)商品還遠(yuǎn)不夠,那如何徹底解決這種單點(diǎn)瓶頸?答案是采用應(yīng)用層的Localcache,即在秒殺系統(tǒng)的單機(jī)上緩存商品相關(guān)的數(shù)據(jù),如何cache數(shù)據(jù)?也分動態(tài)和靜態(tài):

  • 像商品中的標(biāo)題和描述這些本身不變的會在秒殺開始之前全量推送到秒殺機(jī)器上并一直緩存直到秒殺結(jié)束。
  • 像庫存這種動態(tài)數(shù)據(jù)會采用被動失效的方式緩存一定時(shí)間(一般是數(shù)秒),失效后再去Tair緩存拉取最新的數(shù)據(jù)。

 

你可能會有疑問,像庫存這種頻繁更新數(shù)據(jù)一旦數(shù)據(jù)不一致會不會導(dǎo)致超賣?其實(shí)這就要用到我們前面介紹的讀數(shù)據(jù)分層校驗(yàn)原則了,讀的場景可以允許一定的臟數(shù)據(jù),因?yàn)檫@里的誤判只會導(dǎo)致少量一些原本已經(jīng)沒有庫存的下單請求誤認(rèn)為還有庫存而已,等到真正寫數(shù)據(jù)時(shí)再保證最終的一致性。這樣在數(shù)據(jù)的高可用性和一致性做平衡來解決這種高并發(fā)的數(shù)據(jù)讀取問題。

同一數(shù)據(jù)大并發(fā)更新問題

解決大并發(fā)讀問題采用Localcache和數(shù)據(jù)的分層校驗(yàn)的方式,但是無論如何像減庫存這種大并發(fā)寫還是避免不了,這也是秒殺這個(gè)場景下最核心的技術(shù)難題。

同一數(shù)據(jù)在數(shù)據(jù)庫里肯定是一行存儲(MySQL),所以會有大量的線程來競爭InnoDB行鎖,當(dāng)并發(fā)度越高時(shí)等待的線程也會越多,TPS會下降RT會上升,數(shù)據(jù)庫的吞吐量會嚴(yán)重受到影響。說到這里會出現(xiàn)一個(gè)問題,就是單個(gè)熱點(diǎn)商品會影響整個(gè)數(shù)據(jù)庫的性能,就會出現(xiàn)我們不愿意看到的0.01%商品影響99.99%的商品,所以一個(gè)思路也是要遵循前面介紹第一個(gè)原則進(jìn)行隔離,把熱點(diǎn)商品放到單獨(dú)的熱點(diǎn)庫中。但是無疑也會帶來維護(hù)的麻煩(要做熱點(diǎn)數(shù)據(jù)的動態(tài)遷移以及單獨(dú)的數(shù)據(jù)庫等)。

分離熱點(diǎn)商品到單獨(dú)的數(shù)據(jù)庫還是沒有解決并發(fā)鎖的問題,要解決并發(fā)鎖有兩層辦法。

  • 應(yīng)用層做排隊(duì)。按照商品維度設(shè)置隊(duì)列順序執(zhí)行,這樣能減少同一臺機(jī)器對數(shù)據(jù)庫同一行記錄操作的并發(fā)度,同時(shí)也能控制單個(gè)商品占用數(shù)據(jù)庫連接的數(shù)量,防止熱點(diǎn)商品占用太多數(shù)據(jù)庫連接。
  • 數(shù)據(jù)庫層做排隊(duì)。應(yīng)用層只能做到單機(jī)排隊(duì),但應(yīng)用機(jī)器數(shù)本身很多,這種排隊(duì)方式控制并發(fā)仍然有限,所以如果能在數(shù)據(jù)庫層做全局排隊(duì)是最理想的,淘寶的數(shù)據(jù)庫團(tuán)隊(duì)開發(fā)了針對這種MySQL的InnoDB層上的patch,可以做到數(shù)據(jù)庫層上對單行記錄做到并發(fā)排隊(duì),如圖6所示。

 

淘寶大秒系統(tǒng)設(shè)計(jì)詳解

 

圖6 數(shù)據(jù)庫層對單行記錄并發(fā)排隊(duì)

你可能會問排隊(duì)和鎖競爭不要等待嗎?有啥區(qū)別?如果熟悉MySQL會知道,InnoDB內(nèi)部的死鎖檢測以及MySQL Server和InnoDB的切換會比較耗性能,淘寶的MySQL核心團(tuán)隊(duì)還做了很多其他方面的優(yōu)化,如COMMIT_ON_SUCCESS和ROLLBACK_ON_FAIL的patch,配合在SQL里面加hint,在事務(wù)里不需要等待應(yīng)用層提交COMMIT而在數(shù)據(jù)執(zhí)行完最后一條SQL后直接根據(jù)TARGET_AFFECT_ROW結(jié)果提交或回滾,可以減少網(wǎng)絡(luò)的等待時(shí)間(平均約0.7ms)。據(jù)我所知,目前阿里MySQL團(tuán)隊(duì)已將這些patch及提交給MySQL官方評審。

大促熱點(diǎn)問題思考

以秒殺這個(gè)典型系統(tǒng)為代表的熱點(diǎn)問題根據(jù)多年經(jīng)驗(yàn)我總結(jié)了些通用原則:隔離、動態(tài)分離、分層校驗(yàn),必須從整個(gè)全鏈路來考慮和優(yōu)化每個(gè)環(huán)節(jié),除了優(yōu)化系統(tǒng)提升性能,做好限流和保護(hù)也是必備的功課。

除去前面介紹的這些熱點(diǎn)問題外,淘系還有多種其他數(shù)據(jù)熱點(diǎn)問題:

  • 數(shù)據(jù)訪問熱點(diǎn),比如Detail中對某些熱點(diǎn)商品的訪問度非常高,即使是Tair緩存這種Cache本身也有瓶頸問題,一旦請求量達(dá)到單機(jī)極限也會存在熱點(diǎn)保護(hù)問題。有時(shí)看起來好像很容易解決,比如說做好限流就行,但你想想一旦某個(gè)熱點(diǎn)觸發(fā)了一臺機(jī)器的限流閥值,那么這臺機(jī)器Cache的數(shù)據(jù)都將無效,進(jìn)而間接導(dǎo)致Cache被擊穿,請求落地應(yīng)用層數(shù)據(jù)庫出現(xiàn)雪崩現(xiàn)象。這類問題需要與具體Cache產(chǎn)品結(jié)合才能有比較好的解決方案,這里提供一個(gè)通用的解決思路,就是在Cache的client端做本地Localcache,當(dāng)發(fā)現(xiàn)熱點(diǎn)數(shù)據(jù)時(shí)直接Cache在client里,而不要請求到Cache的Server。
  • 數(shù)據(jù)更新熱點(diǎn),更新問題除了前面介紹的熱點(diǎn)隔離和排隊(duì)處理之外,還有些場景,如對商品的lastmodifytime字段更新會非常頻繁,在某些場景下這些多條SQL是可以合并的,一定時(shí)間內(nèi)只執(zhí)行最后一條SQL就行了,可以減少對數(shù)據(jù)庫的update操作。另外熱點(diǎn)商品的自動遷移,理論上也可以在數(shù)據(jù)路由層來完成,利用前面介紹的熱點(diǎn)實(shí)時(shí)發(fā)現(xiàn)自動將熱點(diǎn)從普通庫里遷移出來放到單獨(dú)的熱點(diǎn)庫中。

按照某種維度建的索引產(chǎn)生熱點(diǎn)數(shù)據(jù),比如實(shí)時(shí)搜索中按照商品維度關(guān)聯(lián)評價(jià)數(shù)據(jù),有些熱點(diǎn)商品的評價(jià)非常多,導(dǎo)致搜索系統(tǒng)按照商品ID建評價(jià)數(shù)據(jù)的索引時(shí)內(nèi)存已經(jīng)放不下,交易維度關(guān)聯(lián)訂單信息也同樣有這些問題。這類熱點(diǎn)數(shù)據(jù)需要做數(shù)據(jù)散列,再增加一個(gè)維度,把數(shù)據(jù)重新組織。

分享到:
標(biāo)簽:淘寶 系統(tǒng)
用戶無頭像

網(wǎng)友整理

注冊時(shí)間:

網(wǎng)站:5 個(gè)   小程序:0 個(gè)  文章:12 篇

  • 51998

    網(wǎng)站

  • 12

    小程序

  • 1030137

    文章

  • 747

    會員

趕快注冊賬號,推廣您的網(wǎng)站吧!
最新入駐小程序

數(shù)獨(dú)大挑戰(zhàn)2018-06-03

數(shù)獨(dú)一種數(shù)學(xué)游戲,玩家需要根據(jù)9

答題星2018-06-03

您可以通過答題星輕松地創(chuàng)建試卷

全階人生考試2018-06-03

各種考試題,題庫,初中,高中,大學(xué)四六

運(yùn)動步數(shù)有氧達(dá)人2018-06-03

記錄運(yùn)動步數(shù),積累氧氣值。還可偷

每日養(yǎng)生app2018-06-03

每日養(yǎng)生,天天健康

體育訓(xùn)練成績評定2018-06-03

通用課目體育訓(xùn)練成績評定