此文是開濤在【三體高可用架構(gòu)群】之分享內(nèi)容,，“三體”是為了紀(jì)念三體一書對(duì)技術(shù)人的偉大影響而冠名,。

張開濤：2014年加入京東，主要負(fù)責(zé)商品詳情頁,、詳情頁統(tǒng)一服務(wù)架構(gòu)與開發(fā)工作,，設(shè)計(jì)并開發(fā)了多個(gè)億級(jí)訪問量系統(tǒng)。工作之余喜歡寫技術(shù)博客,，有《跟我學(xué)Spring》,、《跟我學(xué)Spring MVC》、《跟我學(xué)Shiro》,、《跟我學(xué)Nginx Lua開發(fā)》等系列教程,，博客 http://jinnianshilongnian./ 的訪問量超過500W。

京東618的硝煙雖已散去,，可開發(fā)和備戰(zhàn)618期間總結(jié)過的一些設(shè)計(jì)原則和遇到的一些坑還歷歷在目,。伴隨著網(wǎng)站業(yè)務(wù)發(fā)展，需求日趨復(fù)雜多樣并隨時(shí)變化,；傳統(tǒng)靜態(tài)化方案會(huì)遇到業(yè)務(wù)瓶頸,，不能滿足瞬變的需求。因此,，需要一種能高性能實(shí)時(shí)渲染的動(dòng)態(tài)化模板技術(shù)來解決這些問題,。

今夜（編者：指8/27），我們將進(jìn)行服裝品類的垂直詳情頁的AB測(cè)試和切新庫存服務(wù)的1/n流量,。就此機(jī)會(huì),，和大家分享一下最近一年做的京東商品詳情頁的架構(gòu)升級(jí)的心路歷程。

商品詳情頁是什么

商品詳情頁是展示商品詳細(xì)信息的一個(gè)頁面,，承載在網(wǎng)站的大部分流量和訂單的入口,。京東商城目前有通用版、全球購,、閃購,、易車、惠買車,、服裝,、拼購,、今日抄底等許多套詳情頁模板，通過一些特殊屬性,、商家類型和打標(biāo)來區(qū)分,，每套模板數(shù)據(jù)是一樣的，核心邏輯基本一樣,，但是一些前端邏輯是有差別的,。

目前商品詳情頁個(gè)性化需求非常多，數(shù)據(jù)來源也是非常多的（目前統(tǒng)計(jì)后端有差不多數(shù)十個(gè)依賴服務(wù)）,，而且許多基礎(chǔ)服務(wù)做不了的不想做的或者說需要緊急處理的都放我們這處理,，比如一些屏蔽商品需求等。因此我們需要一種架構(gòu)能快速響應(yīng)和優(yōu)雅的解決這些需求問題,，來了問題能在5~10分鐘內(nèi)搞定,。我們這邊經(jīng)還常收到一些緊急需求，比如工商的一些投訴等需要及時(shí)響應(yīng),。之前架構(gòu)是靜態(tài)化的,，肯定無法滿足這種日趨復(fù)雜和未知的需求。靜態(tài)化時(shí)做屏蔽都是通過js,，所以我們重新設(shè)計(jì)了商品詳情頁的架構(gòu),。

它主要包括以下三部分：

商品詳情頁系統(tǒng)
負(fù)責(zé)靜的部分（整個(gè)頁面）

商品詳情頁動(dòng)態(tài)服務(wù)系統(tǒng)和商品詳情頁統(tǒng)一服務(wù)系統(tǒng)
統(tǒng)一服務(wù)系統(tǒng) 負(fù)責(zé)動(dòng)的部分，比如實(shí)時(shí)庫存,。目前已經(jīng)上線了幾個(gè)核心服務(wù),，今晚計(jì)劃切新庫存服務(wù)的1/n流量。
動(dòng)態(tài)服務(wù)系統(tǒng) 負(fù)責(zé)給內(nèi)網(wǎng)其他系統(tǒng)提供一些數(shù)據(jù)服務(wù)（比如大客戶系統(tǒng)需要商品數(shù)據(jù)）,，目前商品詳情頁系統(tǒng)已經(jīng)穩(wěn)定運(yùn)行半年了,，目前主要給列表頁提供一些數(shù)據(jù)。

鍵值結(jié)構(gòu)的異構(gòu)數(shù)據(jù)集群

商品主數(shù)據(jù)因?yàn)槭谴鎯?chǔ)在DB中,，對(duì)于一些聚合數(shù)據(jù)需要聯(lián)合查詢非常多,，會(huì)導(dǎo)致查詢性能差的問題，因此對(duì)于鍵值類型的查詢,，我們這套異構(gòu)數(shù)據(jù)非常有用,。我們這次架構(gòu)的調(diào)整的主要目的是滿足日趨復(fù)雜的業(yè)務(wù)需求，能及時(shí)開發(fā)業(yè)務(wù)方的需求,。我們的系統(tǒng)主要處理鍵值數(shù)據(jù)的邏輯,，關(guān)系查詢我們有另一套異構(gòu)系統(tǒng)。

下圖是我們的模板頁,，核心數(shù)據(jù)都是一樣的,，只是展示方式和一些前端邏輯不太一樣。

我們?cè)斍轫摰那岸苏故局饕譃檫@么幾個(gè)維度：

• 商品維度(標(biāo)題、圖片,、屬性等)

• 主商品維度（商品介紹,、規(guī)格參數(shù)）

• 分類維度

• 商家維度

• 店鋪維度

另外還有一些實(shí)時(shí)性要求比較高的如實(shí)時(shí)價(jià)格、實(shí)時(shí)促銷,、廣告詞,、配送至、預(yù)售等是通過異步加載,。

我們目前把數(shù)據(jù)按維度化存儲(chǔ),，比如一些維度直接redis存，性能好,。

京東商城還有一些特殊維度數(shù)據(jù)：比如套裝,、手機(jī)合約機(jī)等，這些數(shù)據(jù)是主商品數(shù)據(jù)外掛的,，通過異步加載來實(shí)現(xiàn)的邏輯。還有一些與第三方合作的,，如易車,，很多數(shù)據(jù)都是無法異構(gòu)的，都是直接異步加載的,。目前有易車,、途牛等一些公司有這種合作。

我們618當(dāng)天PV數(shù)億,，服務(wù)器端TOP99響應(yīng)時(shí)間低于38ms（此處是第1000次中第99次排名的時(shí)間,，PV具體數(shù)據(jù)不便公開，但TOP99基本在40ms之內(nèi)）,。

上圖是我們的一個(gè)監(jiān)控圖,。我們?cè)斍轫摿髁刻攸c(diǎn)是離散數(shù)據(jù)，熱點(diǎn)少,，各種爬蟲,、比價(jià)軟件抓取,；所以如果直接查庫,，防刷沒做好，很容易被刷掛,。

商品詳情頁發(fā)展史

這是我們的一個(gè)架構(gòu)歷史,。

架構(gòu)1.0

IIS C# Sql Server，最原始的架構(gòu),，直接調(diào)用商品庫獲取相應(yīng)的數(shù)據(jù),，扛不住時(shí)加了一層memcached來緩存數(shù)據(jù)。

這種方式經(jīng)常受到依賴的服務(wù)不穩(wěn)定而導(dǎo)致的性能抖動(dòng)?；景l(fā)展初期都是這個(gè)樣子的,，扛不住加層緩存。因此我們?cè)O(shè)計(jì)了架構(gòu)2.0,。

架構(gòu)2.0

該方案使用了靜態(tài)化技術(shù),，按照商品維度生成靜態(tài)化HTML，這就是一個(gè)靜態(tài)化方案,。

主要思路：

1. 通過MQ得到變更通知,；

2. 通過Java Worker調(diào)用多個(gè)依賴系統(tǒng)生成詳情頁HTML；

3. 通過rsync同步到其他機(jī)器,；

4. 通過Nginx直接輸出靜態(tài)頁,；

5. 接入層負(fù)責(zé)負(fù)載均衡。

   
   

主要缺點(diǎn)：

1. 假設(shè)只有分類,、面包屑變更了,，那么所有相關(guān)的商品都要重刷；

2. 隨著商品數(shù)量的增加,，rsync會(huì)成為瓶頸,；

3. 無法迅速響應(yīng)一些頁面需求變更，大部分都是通過JavaScript動(dòng)態(tài)改頁面元素,。

之前需求沒那么多,，因此頁面變更不是很頻繁，基本沒什么問題,。但是隨著商品數(shù)量的增加這種架構(gòu)的存儲(chǔ)容量到達(dá)了瓶頸,，而且按照商品維度生成整個(gè)頁面會(huì)存在如分類維度變更就要全部刷一遍這個(gè)分類下所有信息的問題，因此我們又改造了一版按照尾號(hào)路由到多臺(tái)機(jī)器,。這種生成整個(gè)頁面的方案會(huì)存在比如只有分類信息變了,，也需要把這個(gè)分類下的商品重新刷一遍。

架構(gòu)2.1

主要思路：

1. 容量問題通過按照商品尾號(hào)做路由分散到多臺(tái)機(jī)器,，按照自營商品單獨(dú)一臺(tái),，第三方商品按照尾號(hào)分散到11臺(tái)；

2. 按維度生成HTML片段（框架,、商品介紹,、規(guī)格參數(shù)、面包屑,、相關(guān)分類,、店鋪信息），而不是一個(gè)大HTML,；

3. 通過Nginx SSI合并片段輸出,；

4. 接入層負(fù)責(zé)負(fù)載均衡；

5. 多機(jī)房部署也無法通過rsync同步，而是使用部署多套相同的架構(gòu)來實(shí)現(xiàn),。

這種方式通過尾號(hào)路由的方式分散到多臺(tái)機(jī)器擴(kuò)容,，然后生成HTML片段，按需靜態(tài)化,；當(dāng)時(shí)我們做閃購的時(shí)候,，需要加頁頭，都是通過js搞定的,。但對(duì)于大的頁面結(jié)構(gòu)變更,，需要全量生成。尤其像面包屑不一樣的話會(huì)很麻煩,，需要生成多個(gè)版本,。

主要缺點(diǎn)：

1. 碎片文件太多，導(dǎo)致如無法rsync,；

2. 機(jī)械盤做SSI合并時(shí),，高并發(fā)時(shí)性能差，此時(shí)我們還沒有嘗試使用SSD,；

3. 模板如果要變更,，數(shù)億商品需要數(shù)天才能刷完；

4. 到達(dá)容量瓶頸時(shí),，我們會(huì)刪除一部分靜態(tài)化商品,，然后通過動(dòng)態(tài)渲染輸出,，動(dòng)態(tài)渲染系統(tǒng)在高峰時(shí)會(huì)導(dǎo)致依賴系統(tǒng)壓力大,，抗不住,；

5. 還是無法迅速響應(yīng)一些業(yè)務(wù)需求,。

當(dāng)時(shí)我記得印象最深的就是碎片文件太多，我們的inode不夠了,，經(jīng)常要半夜去公司刪文件,。因?yàn)榇嬖趧h除問題，每臺(tái)服務(wù)器并不是全量,，所以我們需要一個(gè)動(dòng)態(tài)生成的服務(wù),，當(dāng)靜態(tài)化不存在的時(shí)候還原到動(dòng)態(tài)服務(wù)；但這樣雙十一時(shí)壓力非常大,，我們依賴的系統(tǒng)隨時(shí)都給我們降級(jí),。

架構(gòu)3.0

我們的痛點(diǎn)：

1. 之前架構(gòu)的問題存在容量問題，很快就會(huì)出現(xiàn)無法全量靜態(tài)化,，還是需要?jiǎng)討B(tài)渲染,；（對(duì)于全量靜態(tài)化可以通過分布式文件系統(tǒng)解決該問題，這種方案沒有嘗試）

2. 最主要的問題是隨著業(yè)務(wù)的發(fā)展，無法滿足迅速變化,、還有一些變態(tài)的需求,。

其實(shí)最痛快的是業(yè)務(wù)來說我們要搞垂直，我們要模塊化,，我們要個(gè)性化,；這些統(tǒng)統(tǒng)不好搞，因此我們就考慮做一版全動(dòng)態(tài)的,。其實(shí)思路和靜態(tài)化差不多,， 數(shù)據(jù)靜態(tài)化聚合、頁面模板化,。

我們要考慮和要解決的問題：

1. 能迅速響瞬變的需求,，各種變態(tài)需求；

2. 支持各種垂直化頁面改版,；

3. 頁面模塊化,；

4. AB測(cè)試；

5. 高性能,、水平擴(kuò)容,；

6. 多機(jī)房多活、異地多活,。

這是我們新的系統(tǒng)：三個(gè)子系統(tǒng),。

主要思路：

1. 數(shù)據(jù)變更還是通過MQ通知；

2. 數(shù)據(jù)異構(gòu)Worker得到通知,，然后按照一些維度進(jìn)行數(shù)據(jù)存儲(chǔ),，存儲(chǔ)到數(shù)據(jù)異構(gòu)JIMDB集群（JIMDB：Redis 持久化引擎，是基于Redis改造的一個(gè)加了持久化引擎的KV存儲(chǔ)）,，存儲(chǔ)的數(shù)據(jù)都是未加工的原子化數(shù)據(jù),，如商品基本信息、商品擴(kuò)展屬性,、商品其他一些相關(guān)信息,、商品規(guī)格參數(shù)、分類,、商家信息等,；

3. 數(shù)據(jù)異構(gòu)Worker存儲(chǔ)成功后，會(huì)發(fā)送一個(gè)MQ給數(shù)據(jù)同步 Worker,，數(shù)據(jù)同步Worker也可以叫做數(shù)據(jù)聚合Worker,，按照相應(yīng)的維度聚合數(shù)據(jù)存儲(chǔ)到相應(yīng)的JIMDB集群；三個(gè)維度：基本信息（基本信息 擴(kuò)展屬性等的一個(gè)聚合）,、商品介紹（PC版,、移動(dòng)版）,、其他信息（分類、商家等維度,，數(shù)據(jù)量小,，直接Redis存儲(chǔ)）；

4. 前端展示分為兩個(gè)：商品詳情頁和商品介紹,，使用Nginx Lua技術(shù)獲取數(shù)據(jù)并渲染模板輸出,。

思路差不多： MQ得到變更通知，Worker刷元數(shù)據(jù)到JIMDB,，前端展示系統(tǒng)取數(shù)據(jù)渲染模板,。另外我們當(dāng)時(shí)架構(gòu)的目標(biāo)是詳情頁上有的數(shù)據(jù)，我們都可以提供服務(wù)出去,，主要提供單個(gè)商品的查詢服務(wù),，所以我們把這個(gè)系統(tǒng)叫做動(dòng)態(tài)服務(wù)系統(tǒng)。

該動(dòng)態(tài)服務(wù)分為前端和后端,，即公網(wǎng)還是內(nèi)網(wǎng),，如目前該動(dòng)態(tài)服務(wù)為列表頁、商品對(duì)比,、微信單品頁,、總代等提供相應(yīng)的數(shù)據(jù)來滿足和支持其業(yè)務(wù)。

目前每天為列表頁提供增量數(shù)據(jù)服務(wù),。微信上京東入口看到的詳情頁 也是我們這個(gè)服務(wù)提供的數(shù)據(jù),。APP的數(shù)據(jù)暫時(shí)沒走我們的系統(tǒng)，不過我們目前系統(tǒng)實(shí)現(xiàn)的是平常流量的50倍左右,，性能和流量基本不是問題,。我們?cè)斍轫摷軜?gòu)設(shè)計(jì)的一些原則：

1. 數(shù)據(jù)閉環(huán)

2. 數(shù)據(jù)維度化

3. 拆分系統(tǒng)

4. Worker無狀態(tài)化 任務(wù)化

5. 異步化 并發(fā)化

6. 多級(jí)緩存化

7. 動(dòng)態(tài)化

8. 彈性化

9. 降級(jí)開關(guān)

10. 多機(jī)房多活

11. 多種壓測(cè)方案

因?yàn)槲覀冞@邊主要是讀服務(wù)，因此我們架構(gòu)可能偏讀為主的設(shè)計(jì),；目前我設(shè)計(jì)的幾個(gè)系統(tǒng)都遵循這些原則去設(shè)計(jì)：

數(shù)據(jù)閉環(huán)：

數(shù)據(jù)閉環(huán),，即數(shù)據(jù)的自我管理,，或者說是數(shù)據(jù)都在自己系統(tǒng)里維護(hù),，不依賴于任何其他系統(tǒng)，去依賴化,，這樣得到的好處就是別人抖動(dòng)跟我沒關(guān)系,。因此我們要先數(shù)據(jù)異構(gòu)。

數(shù)據(jù)異構(gòu),，是數(shù)據(jù)閉環(huán)的第一步,，將各個(gè)依賴系統(tǒng)的數(shù)據(jù)拿過來，按照自己的要求存儲(chǔ)起來,；我們把很多數(shù)據(jù)劃分為三個(gè)主要維度進(jìn)行異構(gòu)：商品信息,、商品介紹和其他信息（分類,、商家、店鋪等）,。

數(shù)據(jù)原子化處理,，數(shù)據(jù)異構(gòu)的數(shù)據(jù)是原子化數(shù)據(jù)，這樣未來我們可以對(duì)這些數(shù)據(jù)再加工再處理而響應(yīng)變化的需求,。我們有了一份原子化異構(gòu)數(shù)據(jù)雖然方便處理新需求,，但恰恰因?yàn)榈谝环輸?shù)據(jù)是原子化的，那么它會(huì)很分散,，前端讀取時(shí)mget的話 性能不是很好,，因此我們又做了數(shù)據(jù)聚合。

數(shù)據(jù)聚合,，是將多個(gè)原子數(shù)據(jù)聚合為一個(gè)大JSON數(shù)據(jù),，這樣前端展示只需要一次get，當(dāng)然要考慮系統(tǒng)架構(gòu),，比如我們使用的Redis改造,，Redis又是單線程系統(tǒng)，我們需要部署更多的Redis來支持更高的并發(fā),，另外存儲(chǔ)的值要盡可能的小,。

數(shù)據(jù)存儲(chǔ),，我們使用JIMDB,，Redis加持久化存儲(chǔ)引擎,，可以存儲(chǔ)超過內(nèi)存N倍的數(shù)據(jù)量,，我們目前一些系統(tǒng)是Redis LMDB引擎的存儲(chǔ),，目前是配合SSD進(jìn)行存儲(chǔ),；另外我們使用Hash Tag機(jī)制把相關(guān)的數(shù)據(jù)哈希到同一個(gè)分片,，這樣mget時(shí)不需要跨分片合并,。分片邏輯使用的是Twemproxy,，和應(yīng)用端混合部署在一起,；減少了一層中間層，也節(jié)約一部分機(jī)器,。

我們目前的異構(gòu)數(shù)據(jù)是鍵值結(jié)構(gòu)的,，用于按照商品維度查詢，還有一套異構(gòu)時(shí)關(guān)系結(jié)構(gòu)的用于關(guān)系查詢使用,。

數(shù)據(jù)維度化
對(duì)于數(shù)據(jù)應(yīng)該按照維度和作用進(jìn)行維度化,，這樣可以分離存儲(chǔ)，進(jìn)行更有效的存儲(chǔ)和使用,。我們數(shù)據(jù)的維度比較簡(jiǎn)單：

1. 商品基本信息,，標(biāo)題、擴(kuò)展屬性,、特殊屬性,、圖片,、顏色尺碼、規(guī)格參數(shù)等,；
   這些信息都是商品維度的,。

2. 商品介紹信息，商品維度商家模板,、商品介紹等,；
   京東的商品比較特殊：自營和第三方。
   自營的商品可以任意組合,，選擇其中一個(gè)作為主商品,，因此他的商品介紹是商品維度。
   第三方的組合是固定的,，有一個(gè)固定的主商品,，商品介紹是主商品維度。

3. 非商品維度其他信息,，分類信息,、商家信息、店鋪信息,、店鋪頭,、品牌信息等；
   這些數(shù)據(jù)量不是很大,，一個(gè)redis實(shí)例就能存儲(chǔ),。

4. 商品維度其他信息（異步加載），價(jià)格,、促銷,、配送至、廣告詞,、推薦配件,、最佳組合等。

這些數(shù)據(jù)很多部門在維護(hù),，只能異步加載,；目前這些服務(wù)比較穩(wěn)定，性能也不錯(cuò),，我們?cè)诎堰@些服務(wù)在服務(wù)端聚合,，然后一次性吐出去?，F(xiàn)在已經(jīng)這么做了幾個(gè),，比如下面這個(gè)就是在服務(wù)端聚合吐出去的情況。

http://c./recommend?callback=jQuery4132621&methods=accessories%2Csuit&p=103003&sku=1217499&cat=9987%2C653%2C655&lid=1&uuid=1156941855&pin=zhangkaitao1987&ck=pin%2CipLocation%2Catw%2Caview&lim=6&cuuid=1156941855&csid=122270672.4.1156941855%7C91.1440679162&c1=9987&c2=653&c3=655&_=1440679196326

這是我們url的一些規(guī)則,，methods指定聚合的服務(wù),。我們還對(duì)系統(tǒng)按照其作用做了拆分,。

拆分系統(tǒng)

將系統(tǒng)拆分為多個(gè)子系統(tǒng)雖然增加了復(fù)雜性，但是可以得到更多的好處,。比如,，數(shù)據(jù)異構(gòu)系統(tǒng)存儲(chǔ)的數(shù)據(jù)是原子化數(shù)據(jù)，這樣可以按照一些維度對(duì)外提供服務(wù),；而數(shù)據(jù)同步系統(tǒng)存儲(chǔ)的是聚合數(shù)據(jù),，可以為前端展示提供高性能的讀取。而前端展示系統(tǒng)分離為商品詳情頁和商品介紹,，可以減少相互影響,；目前商品介紹系統(tǒng)還提供其他的一些服務(wù)，比如全站異步頁腳服務(wù),。我們后端還是一個(gè)任務(wù)系統(tǒng),。

Worker無狀態(tài)化 任務(wù)化

1. 數(shù)據(jù)異構(gòu)和數(shù)據(jù)同步Worker無狀態(tài)化設(shè)計(jì)，這樣可以水平擴(kuò)展,；

2. 應(yīng)用雖然是無狀態(tài)化的,，但是配置文件還是有狀態(tài)的，每個(gè)機(jī)房一套配置,，這樣每個(gè)機(jī)房只讀取當(dāng)前機(jī)房數(shù)據(jù),；

3. 任務(wù)多隊(duì)列化，等待隊(duì)列,、排重隊(duì)列,、本地執(zhí)行隊(duì)列、失敗隊(duì)列,；

4. 隊(duì)列優(yōu)先級(jí)化,，分為：普通隊(duì)列、刷數(shù)據(jù)隊(duì)列,、高優(yōu)先級(jí)隊(duì)列,；
   例如，一些秒殺商品會(huì)走高優(yōu)先級(jí)隊(duì)列保證快速執(zhí)行,。

5. 副本隊(duì)列,，當(dāng)上線后業(yè)務(wù)出現(xiàn)問題時(shí)，修正邏輯可以回放,，從而修復(fù)數(shù)據(jù),；可以按照比如固定大小隊(duì)列或者小時(shí)隊(duì)列設(shè)計(jì)；

6. 在設(shè)計(jì)消息時(shí),，按照維度更新,，比如商品信息變更和商品上下架分離，減少每次變更接口的調(diào)用量,，通過聚合Worker去做聚合,。

異步化 并發(fā)化

我們系統(tǒng)大量使用異步化,，通過異步化機(jī)制提升并發(fā)能力。首先我們使用了消息異步化進(jìn)行系統(tǒng)解耦合,，通過消息通知我變更,，然后我再調(diào)用相應(yīng)接口獲取相關(guān)數(shù)據(jù)；之前老系統(tǒng)使用同步推送機(jī)制,，這種方式系統(tǒng)是緊耦合的,，出問題需要聯(lián)系各個(gè)負(fù)責(zé)人重新推送還要考慮失敗重試機(jī)制。數(shù)據(jù)更新異步化,，更新緩存時(shí),，同步調(diào)用服務(wù)，然后異步更新緩存,。

可并行任務(wù)并發(fā)化,，商品數(shù)據(jù)系統(tǒng)來源有多處，但是可以并發(fā)調(diào)用聚合,，這樣本來串行需要1s的經(jīng)過這種方式我們提升到300ms之內(nèi),。異步請(qǐng)求合并，異步請(qǐng)求做合并,，然后一次請(qǐng)求調(diào)用就能拿到所有數(shù)據(jù),。前端服務(wù)異步化/聚合，實(shí)時(shí)價(jià)格,、實(shí)時(shí)庫存異步化,，使用如線程或協(xié)程機(jī)制將多個(gè)可并發(fā)的服務(wù)聚合。異步化還一個(gè)好處就是可以對(duì)異步請(qǐng)求做合并,，原來N次調(diào)用可以合并為一次,，還可以做請(qǐng)求的排重。

多級(jí)緩存化
因之前的消息粒度較粗,，我們目前在按照一些維度拆分消息,，因此讀服務(wù)肯定需要大量緩存設(shè)計(jì),所以我們是一個(gè)多級(jí)緩存的系統(tǒng)。

瀏覽器緩存,，當(dāng)頁面之間來回跳轉(zhuǎn)時(shí)走local cache,，或者打開頁面時(shí)拿著Last-Modified去CDN驗(yàn)證是否過期，減少來回傳輸?shù)臄?shù)據(jù)量,；

CDN緩存,，用戶去離自己最近的CDN節(jié)點(diǎn)拿數(shù)據(jù)，而不是都回源到北京機(jī)房獲取數(shù)據(jù),，提升訪問性能,；

服務(wù)端應(yīng)用本地緩存，我們使用Nginx Lua架構(gòu)，使用HttpLuaModule模塊的shared dict做本地緩存（ reload不丟失）或內(nèi)存級(jí)Proxy Cache,，從而減少帶寬,。

我們的應(yīng)用就是通過Nginx Lua寫的,，每次重啟共享緩存不丟,，這點(diǎn)我們受益頗多，重啟沒有抖動(dòng),，另外我們還使用使用一致性哈希（如商品編號(hào)/分類）做負(fù)載均衡內(nèi)部對(duì)URL重寫提升命中率,；我們對(duì)mget做了優(yōu)化，如去商品其他維度數(shù)據(jù),，分類,、面包屑、商家等差不多8個(gè)維度數(shù)據(jù),，如果每次mget獲取性能差而且數(shù)據(jù)量很大,，30KB以上；而這些數(shù)據(jù)緩存半小時(shí)也是沒有問題的,，因此我們?cè)O(shè)計(jì)為先讀local cache,，然后把不命中的再回源到remote cache獲取，這個(gè)優(yōu)化減少了一半以上的remote cache流量,；這個(gè)優(yōu)化減少了這個(gè)數(shù)據(jù)獲取的一半流量,；

服務(wù)端分布式緩存，我們使用內(nèi)存 SSD JIMDB持久化存儲(chǔ),。

動(dòng)態(tài)化
我們整個(gè)頁面是動(dòng)態(tài)化渲染,，輸出的數(shù)據(jù)獲取動(dòng)態(tài)化，商品詳情頁：按維度獲取數(shù)據(jù),，商品基本數(shù)據(jù),、其他數(shù)據(jù)（分類、商家信息等）,；而且可以根據(jù)數(shù)據(jù)屬性,，按需做邏輯，比如虛擬商品需要自己定制的詳情頁,，那么我們就可以跳轉(zhuǎn)走,，比如全球購的需要走jd.hk域名，那么也是沒有問題的,；未來比如醫(yī)藥的也要走單獨(dú)域名,。

模板渲染實(shí)時(shí)化，支持隨時(shí)變更模板需求,；我們目前模板變更非常頻繁,，需求非常多，一個(gè)頁面8個(gè)開發(fā)。

重啟應(yīng)用秒級(jí)化,， 使用Nginx Lua架構(gòu),，重啟速度快，重啟不丟共享字典緩存數(shù)據(jù),；其實(shí)我們有一些是Tomcat應(yīng)用,，我們也在考慮使用如Tomcat Local Redis 或 Tomcat Nginx Local Shared Dict 做一些本地緩存，防止重啟堆緩存失效的問題,。

需求上線速度化,，因?yàn)槲覀兪褂昧薔ginx Lua架構(gòu)，可以快速上線和重啟應(yīng)用,，不會(huì)產(chǎn)生抖動(dòng),；另外Lua本身是一種腳本語言，我們也在嘗試把代碼如何版本化存儲(chǔ),，直接內(nèi)部驅(qū)動(dòng)Lua代碼更新上線而不需要重啟Nginx,。

彈性化
我們所有應(yīng)用業(yè)務(wù)都接入了Docker容器，存儲(chǔ)還是物理機(jī),；我們會(huì)制作一些基礎(chǔ)鏡像,，把需要的軟件打成鏡像，這樣不用每次去運(yùn)維那安裝部署軟件了,；未來可以支持自動(dòng)擴(kuò)容,，比如按照CPU或帶寬自動(dòng)擴(kuò)容機(jī)器，目前京東一些業(yè)務(wù)支持一分鐘自動(dòng)擴(kuò)容,，下個(gè)月會(huì)進(jìn)行彈性調(diào)度嘗試,。

降級(jí)開關(guān)
一個(gè)前端提供服務(wù)的系統(tǒng)必須考慮降級(jí)，推送服務(wù)器推送降級(jí)開關(guān),，開關(guān)集中化維護(hù),，然后通過推送機(jī)制推送到各個(gè)服務(wù)器；

可降級(jí)的多級(jí)讀服務(wù),，前端數(shù)據(jù)集群—->數(shù)據(jù)異構(gòu)集群—->動(dòng)態(tài)服務(wù)(調(diào)用依賴系統(tǒng)),；這樣可以保證服務(wù)質(zhì)量，假設(shè)前端數(shù)據(jù)集群壞了一個(gè)磁盤,，還可以回源到數(shù)據(jù)異構(gòu)集群獲取數(shù)據(jù),；基本不怕磁盤壞或一些機(jī)器故障、或者機(jī)架故障,。

開關(guān)前置化,，如Nginx代替Tomcat，在Nginx上做開關(guān),，請(qǐng)求就到不了后端,，減少后端壓力,；我們目前很多開關(guān)都是在Nginx上。

可降級(jí)的業(yè)務(wù)線程池隔離,，從Servlet3開始支持異步模型,，Tomcat7/Jetty8開始支持，相同的概念是Jetty6的Continuations,。我們可以把處理過程分解為一個(gè)個(gè)的事件,。

通過這種將請(qǐng)求劃分為事件方式我們可以進(jìn)行更多的控制。如,，我們可以為不同的業(yè)務(wù)再建立不同的線程池進(jìn)行控制：即我們只依賴tomcat線程池進(jìn)行請(qǐng)求的解析,，對(duì)于請(qǐng)求的處理我們交給我們自己的線程池去完成,；這樣tomcat線程池就不是我們的瓶頸,，造成現(xiàn)在無法優(yōu)化的狀況。通過使用這種異步化事件模型,，我們可以提高整體的吞吐量,，不讓慢速的A業(yè)務(wù)處理影響到其他業(yè)務(wù)處理。慢的還是慢,，但是不影響其他的業(yè)務(wù),。我們通過這種機(jī)制還可以把tomcat線程池的監(jiān)控拿出來，出問題時(shí)可以直接清空業(yè)務(wù)線程池,，另外還可以自定義任務(wù)隊(duì)列來支持一些特殊的業(yè)務(wù),。

去年使用的是JDK7 Tomcat7 最近一個(gè)月我們升級(jí)到了JDK8 Tomcat8 G1。

多機(jī)房多活
對(duì)于我們這種核心系統(tǒng),，我們需要考慮多機(jī)房多活的問題,。目前是應(yīng)用無狀態(tài)，通過在配置文件中配置各自機(jī)房的數(shù)據(jù)集群來完成數(shù)據(jù)讀取,。

其實(shí)我們系統(tǒng)只要存儲(chǔ)多機(jī)房就多活了,，因?yàn)橄到y(tǒng)天然就是。數(shù)據(jù)集群采用一主三從結(jié)構(gòu),，防止當(dāng)一個(gè)機(jī)房掛了,，另一個(gè)機(jī)房壓力大產(chǎn)生抖動(dòng)。

各個(gè)機(jī)房都是讀本機(jī)房的從另外每個(gè)機(jī)房都是倆份數(shù)據(jù),，不怕因?yàn)闄C(jī)房突然中斷恢復(fù)后的影響,。

多種壓測(cè)方案
我們?cè)隍?yàn)證系統(tǒng)時(shí)需要進(jìn)行壓測(cè)。
線下壓測(cè),，Apache ab,，Apache Jmeter，這種方式是固定url壓測(cè),，一般通過訪問日志收集一些url進(jìn)行壓測(cè),，可以簡(jiǎn)單壓測(cè)單機(jī)峰值吞吐量,，但是不能作為最終的壓測(cè)結(jié)果，因?yàn)檫@種壓測(cè)會(huì)存在熱點(diǎn)問題,；

線上壓測(cè),，可以使用Tcpcopy直接把線上流量導(dǎo)入到壓測(cè)服務(wù)器，這種方式可以壓測(cè)出機(jī)器的性能,，而且可以把流量放大,，也可以使用Nginx Lua協(xié)程機(jī)制把流量分發(fā)到多臺(tái)壓測(cè)服務(wù)器，或者直接在頁面埋點(diǎn),，讓用戶壓測(cè),，此種壓測(cè)方式可以不給用戶返回內(nèi)容。服務(wù)剛開始的時(shí)候大量使用tcpcopy做驗(yàn)證,，對(duì)于一些 新服務(wù),，如果無法使用tcpcopy我們就在頁面埋url讓用戶來壓。

另外壓測(cè)時(shí),，要考慮讀,、寫、讀或?qū)懲瑫r(shí)壓,。只壓某一種場(chǎng)景可能都會(huì)不真實(shí),。

遇到的一些問題和解決方案

SSD性能差

使用SSD做KV存儲(chǔ)時(shí)發(fā)現(xiàn)磁盤IO非常低。配置成RAID10的性能只有3_{6MB/s,；配置成RAID0的性能有}130MB/s,，系統(tǒng)中沒有發(fā)現(xiàn)CPU，MEM,，中斷等瓶頸,。一臺(tái)服務(wù)器從RAID1改成RAID0后，性能只有~60MB/s,。這說明我們用的SSD盤性能不穩(wěn)定,。

據(jù)以上現(xiàn)象，初步懷疑以下幾點(diǎn)：SSD盤,，線上系統(tǒng)用的三星840Pro是消費(fèi)級(jí)硬盤,；RAID卡設(shè)置，Write back和Write through策略（后來測(cè)試驗(yàn)證,，有影響,，但不是關(guān)鍵）；RAID卡類型,，線上系統(tǒng)用的是LSI 2008,，比較陳舊。

下面是使用dd做的簡(jiǎn)單測(cè)試,。

我們現(xiàn)實(shí)竟然使用的是民用級(jí)盤,， 一個(gè)月壞幾塊很正常,。后來我們?nèi)可暾?qǐng)換成了INTEL企業(yè)級(jí)盤，線上用3500型號(hào),。

鍵值存儲(chǔ)選型壓測(cè)

在系統(tǒng)設(shè)計(jì)初期最頭痛的就是存儲(chǔ)選型,，我們對(duì)于存儲(chǔ)選型時(shí)嘗試過LevelDB、RocksDB,、BeansDB,、LMDB、Riak等,，最終根據(jù)我們的需求選擇了LMDB,。

機(jī)器：2臺(tái)
配置：32核CPU、32GB內(nèi)存,、SSD（(512GB)三星840Pro—> (600GB)Intel 3500 /Intel S3610）
數(shù)據(jù)：1.7億數(shù)據(jù)（800多G數(shù)據(jù)）,、大小5~30KB左右
KV存儲(chǔ)引擎：LevelDB、RocksDB,、LMDB,，每臺(tái)啟動(dòng)2個(gè)實(shí)例
壓測(cè)工具：tcpcopy直接線上導(dǎo)流
壓測(cè)用例：隨機(jī)寫 隨機(jī)讀

LevelDB壓測(cè)時(shí),，隨機(jī)讀 隨機(jī)寫會(huì)產(chǎn)生抖動(dòng)（我們的數(shù)據(jù)出自自己的監(jiān)控平臺(tái),，分鐘級(jí)采樣）。

我們線上一些順序?qū)懙姆?wù)在使用leveldb,，RocksDB是改造自LevelDB,，對(duì)SSD做了優(yōu)化，我們壓測(cè)時(shí)單獨(dú)寫或讀,，性能非常好,，但是讀寫混合時(shí)就會(huì)因?yàn)闅w并產(chǎn)生抖動(dòng)。

在歸并時(shí)基本達(dá)到了我們磁盤的瓶頸,，LMDB引擎沒有大的抖動(dòng),，基本滿足我們的需求。

我們目前一些線上服務(wù)器使用的是LMDB,，新機(jī)房正在嘗試公司自主研發(fā)的CycleDB引擎,。目前我看到的應(yīng)該很少使用LMDB引擎的。

數(shù)據(jù)量大時(shí)Jimdb同步不動(dòng)

Jimdb數(shù)據(jù)同步時(shí)要dump數(shù)據(jù),，SSD盤容量用了50%以上,，dump到同一塊磁盤容量不足。
解決方案：

1. 一臺(tái)物理機(jī)掛2塊SSD(512GB),，單掛raid0,；啟動(dòng)8個(gè)jimdb實(shí)例；這樣每實(shí)例差不多125GB左右,；目前是掛4塊,，raid0,；新機(jī)房計(jì)劃8塊raid10；

2. 目前是千兆網(wǎng)卡同步,，同步峰值在100MB/s左右,；

3. dump和sync數(shù)據(jù)時(shí)是順序讀寫，因此掛一塊SAS盤專門來同步數(shù)據(jù),；

4. 使用文件鎖保證一臺(tái)物理機(jī)多個(gè)實(shí)例同時(shí)只有一個(gè)dump,；

5. 后續(xù)計(jì)劃改造為直接內(nèi)存轉(zhuǎn)發(fā)而不做dump。

切換主從

因?yàn)槭腔赗edis的,，目前是先做數(shù)據(jù)RDB dump然后同步,。后續(xù)計(jì)劃改造為直接內(nèi)存復(fù)制，之前存儲(chǔ)架構(gòu)是一主二從（主機(jī)房一主一從,，備機(jī)房一從）切換到備機(jī)房時(shí),，只有一個(gè)主服務(wù)，讀寫壓力大時(shí)有抖動(dòng),，因此我們改造為之前架構(gòu)圖中的一主三從,。

分片配置

之前的架構(gòu)是存儲(chǔ)集群的分片邏輯分散到多個(gè)子系統(tǒng)的配置文件中，切換時(shí)需要操作很多系統(tǒng),。

解決方案：

1. 引入Twemproxy中間件,，我們使用本地部署的Twemproxy來維護(hù)分片邏輯；

2. 使用自動(dòng)部署系統(tǒng)推送配置和重啟應(yīng)用,，重啟之前暫停mq消費(fèi)保證數(shù)據(jù)一致性,；

3. 用unix domain socket減少連接數(shù)和端口占用不釋放啟動(dòng)不了服務(wù)的問題。

我們都是在應(yīng)用本地部署的Twemproxy,，然后通過中間系統(tǒng)對(duì)外提供數(shù)據(jù),。

模板元數(shù)據(jù)存儲(chǔ)HTML

我們前端應(yīng)用使用的是Nginx Lua，起初不確定Lua做邏輯和渲染模板性能如何,，就盡量減少for,、if/else之類的邏輯；通過java worker組裝html片段存儲(chǔ)到j(luò)imdb,，html片段會(huì)存儲(chǔ)諸多問題,，假設(shè)未來變了也是需要全量刷出的，因此存儲(chǔ)的內(nèi)容最好就是元數(shù)據(jù),。

因此通過線上不斷壓測(cè),，最終jimdb只存儲(chǔ)元數(shù)據(jù)，lua做邏輯和渲染,；邏輯代碼在3000行以上,；模板代碼1500行以上，其中大量for,、if/else,，目前渲染性可以接受,。

線上真實(shí)流量，整體性能從TOP99 53ms降到32ms,。

綁定8 CPU測(cè)試的,，渲染模板的性能可以接受。

庫存接口訪問量600W/分鐘

商品詳情頁庫存接口2014年被惡意刷,，每分鐘超過600w訪問量,，tomcat機(jī)器只能定時(shí)重啟；因?yàn)槭窃斍轫撜故镜臄?shù)據(jù),，緩存幾秒鐘是可以接受的,，因此開啟nginx proxy cache來解決該問題，開啟后降到正常水平,；我們目前正在使用Nginx Lua架構(gòu)改造服務(wù),，數(shù)據(jù)過濾、URL重寫等在Nginx層完成,，通過URL重寫 一致性哈希負(fù)載均衡,，不怕隨機(jī)URL，一些服務(wù)提升了10% 的緩存命中率,。

目前我們大量使用內(nèi)存級(jí)nginx proxy cache和nginx共享字典做數(shù)據(jù)緩存,。
http://c./recommend?callback=jQuery4132621&methods=accessories%2Csuit&p=103003&sku=1217499&cat=9987%2C653%2C655&lid=1&uuid=1156941855&pin=zhangkaitao1987&ck=pin%2CipLocation%2Catw%2Caview&lim=6&cuuid=1156941855&csid=122270672.4.1156941855%7C91.1440679162&c1=9987&c2=653&c3=655&_=1440679196326

還有我們會(huì)對(duì)這些前端的url進(jìn)行重寫，所以不管怎么加隨機(jī)數(shù),，都不會(huì)影響我們服務(wù)端的命中率,，我們服務(wù)端做了參數(shù)的重新拼裝和驗(yàn)證。

微信接口調(diào)用量暴增

14年的一段時(shí)間微信接口調(diào)用量暴增,，通過訪問日志發(fā)現(xiàn)某IP頻繁抓取,；而且按照商品編號(hào)遍歷,，但是會(huì)有一些不存在的編號(hào)。

解決方案：

1. 讀取KV存儲(chǔ)的部分不限流,；

2. 回源到服務(wù)接口的進(jìn)行請(qǐng)求限流,，保證服務(wù)質(zhì)量。

3. 回源到DB的或者依賴系統(tǒng)的,，我們也只能通過限流保證服務(wù)質(zhì)量,。

開啟Nginx Proxy Cache性能不升反降

開啟Nginx Proxy Cache后，性能下降,，而且過一段內(nèi)存使用率到達(dá)98%,。

解決方案：

1. 對(duì)于內(nèi)存占用率高的問題是內(nèi)核問題，內(nèi)核使用LRU機(jī)制,，本身不是問題,，不過可以通過修改內(nèi)核參數(shù)
   sysctl -w vm.extra_free_kbytes=6436787
   sysctl -w vm.vfs_cache_pressure=10000

2. 使用Proxy Cache在機(jī)械盤上性能差可以通過tmpfs緩存或nginx共享字典緩存元數(shù)據(jù),，或者使用SSD，我們目前使用內(nèi)存文件系統(tǒng),。

配送至讀服務(wù)因依賴太多,，響應(yīng)時(shí)間偏慢

配送至服務(wù)每天有數(shù)十億調(diào)用量，響應(yīng)時(shí)間偏慢,。
解決方案：

1. 串行獲取變并發(fā)獲取,，這樣一些服務(wù)可以并發(fā)調(diào)用，在我們某個(gè)系統(tǒng)中能提升一倍多的性能,，從原來TP99差不多1s降到500ms以下,；

2. 預(yù)取依賴數(shù)據(jù)回傳，這種機(jī)制還一個(gè)好處,，比如我們依賴三個(gè)下游服務(wù),，而這三個(gè)服務(wù)都需要商品數(shù)據(jù)，那么我們可以在當(dāng)前服務(wù)中取數(shù)據(jù),，然后回傳給他們,，這樣可以減少下游系統(tǒng)的商品服務(wù)調(diào)用量，如果沒有傳,，那么下游服務(wù)再自己查一下,。

假設(shè)一個(gè)讀服務(wù)是需要如下數(shù)據(jù)：

1. 數(shù)據(jù)A 10ms

2. 數(shù)據(jù)B 15ms

3. 數(shù)據(jù)C 20ms

4. 數(shù)據(jù)D 5ms

5. 數(shù)據(jù)E 10ms

那么如果串行獲取那么需要：60ms；而如果數(shù)據(jù)C依賴數(shù)據(jù)A和數(shù)據(jù)B,、數(shù)據(jù)D誰也不依賴,、數(shù)據(jù)E依賴數(shù)據(jù)C；那么我們可以這樣子來獲取數(shù)據(jù)：

那么如果并發(fā)化獲取那么需要：30ms,；能提升一倍的性能,。

假設(shè)數(shù)據(jù)E還依賴數(shù)據(jù)F(5ms)，而數(shù)據(jù)F是在數(shù)據(jù)E服務(wù)中獲取的,，此時(shí)就可以考慮在此服務(wù)中在取數(shù)據(jù)A/B/D時(shí)預(yù)取數(shù)據(jù)F,，那么整體性能就變?yōu)榱耍?5ms。

我們目前大量使用并發(fā)獲取和預(yù)取數(shù)據(jù),，通過這種優(yōu)化我們服務(wù)提升了差不多10ms性能,。 而且能顯著減少一些依賴服務(wù)的重復(fù)調(diào)用，給他們減流,。

如下服務(wù)是在抖動(dòng)時(shí)的性能,，老服務(wù)TOP99 211ms，新服務(wù)118ms,，此處我們主要就是并發(fā)調(diào)用 超時(shí)時(shí)間限制,，超時(shí)直接降級(jí)。

網(wǎng)絡(luò)抖動(dòng)時(shí)，返回502錯(cuò)誤

Twemproxy配置的timeout時(shí)間太長,，之前設(shè)置為5s,，而且沒有分別針對(duì)連接、讀,、寫設(shè)置超時(shí),。后來我們減少超時(shí)時(shí)間，內(nèi)網(wǎng)設(shè)置在150ms以內(nèi),，當(dāng)超時(shí)時(shí)訪問動(dòng)態(tài)服務(wù),。對(duì)于讀服務(wù)的話，應(yīng)該設(shè)置合理的超時(shí)時(shí)間,，比如超時(shí)了直接降級(jí),。

機(jī)器流量太大

2014年雙11期間，服務(wù)器網(wǎng)卡流量到了400Mbps,，CPU30%左右,。原因是我們所有壓縮都在接入層完成，因此接入層不再傳入相關(guān)請(qǐng)求頭到應(yīng)用,，隨著流量的增大,，接入層壓力過大，因此我們把壓縮下方到各個(gè)業(yè)務(wù)應(yīng)用,，添加了相應(yīng)的請(qǐng)求頭,，Nginx GZIP壓縮級(jí)別在2~4吞吐量最高；應(yīng)用服務(wù)器流量降了差不多5倍,；目前正常情況CPU在4%以下,。

因?yàn)橹皦嚎s都是接入層做的，后來因?yàn)榻尤氲姆?wù)太多,，因此我們決定在各應(yīng)用去做,。

一些總結(jié)

• 數(shù)據(jù)閉環(huán)

• 數(shù)據(jù)維度化

• 拆分系統(tǒng)

• Worker無狀態(tài)化 任務(wù)化

• 異步化 并發(fā)化

• 多級(jí)緩存化

• 動(dòng)態(tài)化

• 彈性化

• 降級(jí)開關(guān)

• 多機(jī)房多活

• 多種壓測(cè)方案

• Nginx接入層線上灰度引流

• 接入層轉(zhuǎn)發(fā)時(shí)只保留有用請(qǐng)求頭

• 使用不需要cookie的無狀態(tài)域名（如c.），減少入口帶寬

• Nginx Proxy Cache只緩存有效數(shù)據(jù),，如托底數(shù)據(jù)不緩存

• 使用非阻塞鎖應(yīng)對(duì)local cache失效時(shí)突發(fā)請(qǐng)求到后端應(yīng)用(lua-resty-lock/proxy_cache_lock)

• 使用Twemproxy減少Redis連接數(shù)

• 使用unix domain socket套接字減少本機(jī)TCP連接數(shù)

• 設(shè)置合理的超時(shí)時(shí)間（連接,、讀、寫）

• 使用長連接減少內(nèi)部服務(wù)的連接數(shù)

• 去數(shù)據(jù)庫依賴（協(xié)調(diào)部門遷移數(shù)據(jù)庫是很痛苦的,，目前內(nèi)部使用機(jī)房域名而不是ip），服務(wù)化

• 客戶端同域連接限制,，進(jìn)行域名分區(qū)：c0. c1.,，如果未來支持HTTP/2.0的話，就不再適用了,。

  
  

Q&A

Q1：對(duì)于依賴服務(wù)的波動(dòng),，導(dǎo)致我們系統(tǒng)的不穩(wěn)定，我們是怎么設(shè)計(jì)的,？
我們的數(shù)據(jù)源有三套：前端數(shù)據(jù)集群 該數(shù)據(jù)每個(gè)機(jī)房有兩套,，目前兩個(gè)機(jī)房,。數(shù)據(jù)異構(gòu)集群同上動(dòng)態(tài)服務(wù)(調(diào)用依賴系統(tǒng))。

1. 設(shè)置好超時(shí)時(shí)間,，尤其連接超時(shí),，內(nèi)網(wǎng)我們一般100ms左右；

2. 每個(gè)機(jī)房讀從,、如果從掛了降級(jí)讀主,；

3. 如果前端集群掛了，我們會(huì)讀取動(dòng)態(tài)服務(wù)（1,、先mget原子數(shù)據(jù)異構(gòu)集群,；2、失敗了讀依賴系統(tǒng)）,。

Q2：靜態(tài)化屏蔽通過js是怎么做的,？

1. 緊急上線js，做跳轉(zhuǎn),；

2. 上線走流程需要差不多10分鐘,，然后還有清理CDN緩存，用戶端還有本地緩存無法清理,；

3. 我們目前文件都放到我們的自動(dòng)部署上,，出問題直接修改，然后同步上去,，重啟nginx搞定,。

Q3：內(nèi)網(wǎng)的服務(wù)通過什么方式提供？
我偏好使用HTTP,，目前也在學(xué)習(xí)HTTP2.0,，有一些服務(wù)使用我們自己開發(fā)類似于DUBBO的服務(wù)化框架，之前的版本就是DUBBO改造的,。

Q4：對(duì)于mq 的處理如果出現(xiàn)異常是怎么發(fā)現(xiàn)和處理的,？

1. MQ，我們目前是接收下來存Redis,，然后會(huì)寫一份到本地磁盤文件,；

2. 我們會(huì)把消息存一天的；

3. 一般出問題是投訴,，我們會(huì)緊急回滾消息到一天中的某個(gè)時(shí)間點(diǎn),。

Q5：對(duì)于模板這塊，有做預(yù)編譯處理,？或者直接使用Lua寫模板嗎,？

1. luajit，類似于java jit；

2. lua直接寫模板,。

Q6： jimdb能否介紹下,，特性是什么，為什么選用?

1. jimdb就是我們起的一個(gè)名字,，之前版本就是redis lmdb持久化引擎,，做了持久化；

2. 我們根據(jù)當(dāng)時(shí)的壓測(cè)結(jié)果選擇的,，按照對(duì)比結(jié)果選擇的,，我們當(dāng)時(shí)也測(cè)了豆瓣的beansdb，性能非常好,，就是需要定期人工歸并,。

Q7：咨詢下對(duì)于價(jià)格這類敏感數(shù)據(jù)，前端有緩存么,？還是都靠價(jià)格服務(wù)扛,？

1. 價(jià)格前端不緩存；

2. 價(jià)格實(shí)時(shí)同步到Nginx Lua本地的redis集群（大內(nèi)存）,；

3. 不命中的才回源到tomcat查主redis/DB,。

價(jià)格數(shù)據(jù)也是通過MQ得到變更存儲(chǔ)到本地redis的，nginx lua直接讀本機(jī)redis,，性能沒的說,。

Q8：庫存和價(jià)格一樣的模式處理嗎？
前端展示庫存不是,，我們做了幾秒的服務(wù)端緩存,。

Q9：github里有一個(gè)開源的基于lmdb的redis 你們用的這個(gè)嗎?
我們內(nèi)部自己寫的，有一版基于LevelDB的,，我記得github上叫ardb,。

Q10：看測(cè)試條件說測(cè)試的是大小5~30KB左右的數(shù)據(jù)，有沒有測(cè)試過更大文件lmdb的表現(xiàn),？
這個(gè)沒有,，我們的數(shù)據(jù)都是真實(shí)數(shù)據(jù)，最大的有50KB左右的,，但是分布比較均勻,；當(dāng)時(shí)還考慮壓縮，但是發(fā)現(xiàn)沒什么性能問題,，就沒有壓縮做存儲(chǔ)了,。

Q11：關(guān)于redis緩存，是每個(gè)子系統(tǒng)擁有自己的一套緩存,；還是使用統(tǒng)一的緩存服務(wù)？是否有進(jìn)行過對(duì)比測(cè)試？（看到又說使用單機(jī)緩存防止服務(wù)掛掉,，影響整體服務(wù)）

1. 我們公司有統(tǒng)一的緩存服務(wù)接入并提供運(yùn)維,；

2. 我們的服務(wù)自己運(yùn)維，因?yàn)槲覀兪嵌鄼C(jī)房從,，每機(jī)房讀自己的從,，目前不支持這種方式；

3. （看到又說使用單機(jī)緩存防止服務(wù)掛掉,，影響整體服務(wù)）這個(gè)主要是降級(jí) 備份 回源解決,。

Q12： “我們目前一些線上服務(wù)器使用的是LMDB，其他一些正在嘗試公司自主研發(fā)的CycleDB引擎”,。 開始自主研發(fā),，這個(gè)是由于lmdb有坑還是處于別的考慮？

1. 寫放大問題,；

2. 掛主從需要dump整個(gè)文件進(jìn)行同步,。

本文策劃陳剛@北京智識(shí)，內(nèi)容由劉世杰@獵聘網(wǎng)編輯,，四正@大連華信校對(duì)與發(fā)布,，其他多位志愿者對(duì)本文亦有貢獻(xiàn)。更多關(guān)于架構(gòu)方面的內(nèi)容,，讀者可以通過搜索'ArchNotes'或點(diǎn)擊頁首的藍(lán)字,，關(guān)注'高可用架構(gòu)'公眾號(hào)，查看更多架構(gòu)方面內(nèi)容,，獲取通往架構(gòu)師之路的寶貴經(jīng)驗(yàn),。本文來自'高可用架構(gòu) (ArchNotes)'微信公眾號(hào)。