java 商城系統(tǒng)架構(gòu)之*四篇：構(gòu)建高并發(fā)高可用的電商平臺架構(gòu)實踐

時間：2020-01-05作者：無錫紅豬網(wǎng)絡(luò)科技有限公司瀏覽：260

一、設(shè)計理念
注：這里只講概念，盡量不講技術(shù)！但是會推薦一些。本博客雖然是基于java語言，但是適用于任何其他大型架構(gòu)系統(tǒng)。
1、空間換時間
1)多級緩存、靜態(tài)化
關(guān)于緩存方面，可以做：客戶端頁面緩存、反向代理緩存、應(yīng)用端的緩存、內(nèi)存數(shù)據(jù)庫以及做**靜態(tài)化
對于頁面緩存，比如京東較狠，圖片*存儲在客戶端，改圖片、css、js等的話，必須要改名字，要不然會hit到舊文件。
對于**靜態(tài)化，web的話可以做靜態(tài)頁面，對于app、cs架構(gòu)等同樣適用
2) 索引
一般對于關(guān)系型數(shù)據(jù)庫查詢，需要用到索引。
2、并行與分布式計算
1)任務(wù)切分、分而治之(MR)
在大規(guī)模的數(shù)據(jù)中，數(shù)據(jù)存在一定的局部性的特征，利用局部性的原理將海量數(shù)據(jù)計算的問題分而治之。
MR模型是無共享的架構(gòu)，數(shù)據(jù)集分布至各個節(jié)點(diǎn)。處理時，每個節(jié)點(diǎn)就近讀取本地存儲的數(shù)據(jù)處理(map)，將處理后的數(shù)據(jù)進(jìn)行合并(combine)、排序(shuffle and sort)后再分發(fā)(至reduce節(jié)點(diǎn))，避免了大量數(shù)據(jù)的傳輸，提高了處理效率。
 
2)多進(jìn)程、多線程并行執(zhí)行(MPP)
并行計算（Parallel Computing）是指同時使用多種計算資源解決計算問題的過程，是提高計算機(jī)系統(tǒng)計算速度和處理能力的一種有效手段。它的基本思想是用多個處理器/進(jìn)程/線程來協(xié)同求解同一問題，即將被求解的問題分解成若干個部分，各部分均由一個獨(dú)立的處理機(jī)來并行計算。
和MR的區(qū)別在于，它是基于問題分解的，而不是基于數(shù)據(jù)分解。
3、多維度的高可用
1)負(fù)載均衡、容災(zāi)、備份
隨著平臺并發(fā)量的增大，需要擴(kuò)容節(jié)點(diǎn)進(jìn)行集群，利用負(fù)載均衡設(shè)備進(jìn)行請求的分發(fā)；負(fù)載均衡設(shè)備通常在提供負(fù)載均衡的同時，也提供失效檢測功能；同時為了提高可用性，需要有容災(zāi)備份，以防止節(jié)點(diǎn)宕機(jī)失效帶來的不可用問題；備份有在線的和離線備份，可以根據(jù)失效性要求的不同，進(jìn)行選擇不同的備份策略。
2)讀寫分離、分庫分表
讀寫分離是對數(shù)據(jù)庫來講的，隨著系統(tǒng)并發(fā)量的增大，提高數(shù)據(jù)訪問可用性的一個重要手段就是寫數(shù)據(jù)和讀數(shù)據(jù)進(jìn)行分離；當(dāng)然在讀寫分離的同時，需要關(guān)注數(shù)據(jù)的一致性問題；對于一致性的問題，在分布式的系統(tǒng)CAP定量中，更多的關(guān)注于可用性。
根據(jù)本博主經(jīng)驗，對于單表數(shù)據(jù)量**過300萬，就可以做分庫分表，不推薦使用第三方，推薦大家自己寫一套，其實就是改造下ORM端，自己改造有幾個優(yōu)勢，1、學(xué)習(xí)成本低，2、后期維護(hù)不依賴于第三方，3、橫向擴(kuò)展容易。博主的公司分庫分表是自己寫的，是**過300萬就會自動建庫、切分。
首先需要做垂直切分，也就是字段非常多，改成字段在20個以內(nèi)的表。當(dāng)然這個并不是必須，為的是分庫分表操作起來較簡單，很多人對這個有誤解，垂直并不是必須要做的。我們公司還有表是100來個字段，數(shù)據(jù)量在5千萬以上，并沒有拆分。
3)依賴關(guān)系
平臺中各個模塊之間的關(guān)系盡量是低耦合的，可以通過相關(guān)的消息組件進(jìn)行交互，能異步則異步，分清楚數(shù)據(jù)流轉(zhuǎn)的主流程和副流程，主副是異步的，比如記錄日志、郵件、短信、公告等可以是異步操作的，增加整個系統(tǒng)的可用性。
當(dāng)然在異步處理中，為了確保數(shù)據(jù)得到接收或者處理，往往需要確認(rèn)機(jī)制(confirm、ack)。
但是有些場景中，雖然請求已經(jīng)得到處理，但是因其他原因(比如網(wǎng)絡(luò)不穩(wěn)定)，確認(rèn)消息沒有返回，那么這種情況下需要進(jìn)行請求的重發(fā)，對請求的處理設(shè)計因重發(fā)因素需要考慮冪等性。
4) 監(jiān)控
監(jiān)控也是提高整個平臺可用性的一個重要手段，多平臺進(jìn)行多個維度的監(jiān)控；模塊在運(yùn)行時候是透明的，以達(dá)到運(yùn)行期白盒化。
4、伸縮
1) 拆分
拆分包括對業(yè)務(wù)的拆分和對數(shù)據(jù)庫的拆分。
系統(tǒng)的資源總是有限的，一段比較長的業(yè)務(wù)執(zhí)行如果是一竿子執(zhí)行的方式，在大量并發(fā)的操作下，這種阻塞的方式，無法有效的及時釋放資源給其他進(jìn)程執(zhí)行，這樣系統(tǒng)的吞吐量不高。
需要把業(yè)務(wù)進(jìn)行邏輯的分段，采用異步非阻塞的方式，提高系統(tǒng)的吞吐量。
隨著數(shù)據(jù)量和并發(fā)量的增加，讀寫分離不能滿足系統(tǒng)并發(fā)性能的要求，需要對數(shù)據(jù)進(jìn)行切分，包括對數(shù)據(jù)進(jìn)行分庫和分表。這種分庫分表的方式，需要增加對數(shù)據(jù)的路由邏輯支持。
2)無狀態(tài)
對于系統(tǒng)的伸縮性而言，模塊較好是無狀態(tài)的，通過增加節(jié)點(diǎn)就可以提高整個的吞吐量。
注：無狀態(tài)其實就是一些邏輯上不需要用戶登錄狀態(tài)的。。。比如查看web系統(tǒng)首頁、新聞頁面、以及模塊的局部，比如訪問京東的詳情頁，Top部分需要用戶登錄狀態(tài)、價格優(yōu)惠部分需要用戶信息才能做出優(yōu)惠，這幾個模塊就是有狀態(tài)。
有狀態(tài)也可以做橫向擴(kuò)展。。。。
5、優(yōu)化資源利用
1)系統(tǒng)容量有限
系統(tǒng)的容量是有限的，承受的并發(fā)量也是有限的，在架構(gòu)設(shè)計時，一定需要考慮流量的控制，防止因意外攻擊或者瞬時并發(fā)量的沖擊導(dǎo)致系統(tǒng)崩潰。在設(shè)計時增加流控的措施，可考慮對請求進(jìn)行排隊，**出預(yù)期的范圍，可以進(jìn)行告警或者丟棄。
2)原子操作與并發(fā)控制
對于共享資源的訪問，為了防止沖突，需要進(jìn)行并發(fā)的控制，同時有些交易需要有事務(wù)性來保證交易的一致性，所以在交易系統(tǒng)的設(shè)計時，需考慮原子操作和并發(fā)控制。
保證并發(fā)控制一些常用高性能手段有，樂觀鎖、Latch、mutex、寫時復(fù)制、CAS等；多版本的并發(fā)控制MVCC通常是保證一致性的重要手段，這個在數(shù)據(jù)庫的設(shè)計中經(jīng)常會用到。
3)基于邏輯的不同，采取不一樣的策略
平臺中業(yè)務(wù)邏輯存在不同的類型，有計算復(fù)雜型的，有消耗IO型的，同時就同一種類型而言，不同的業(yè)務(wù)邏輯消耗的資源數(shù)量也是不一樣的，這就需要針對不同的邏輯采取不同的策略。
針對IO型的，可以采取基于事件驅(qū)動的異步非阻塞的方式，單線程方式可以減少線程的切換引起的開銷，或者在多線程的情況下采取自旋spin的方式，減少對線程的切換(比如oracle latch設(shè)計)；對于計算型的，充分利用多線程進(jìn)行操作。
同一類型的調(diào)用方式，不同的業(yè)務(wù)進(jìn)行合適的資源分配，設(shè)置不同的計算節(jié)點(diǎn)數(shù)量或者線程數(shù)量，對業(yè)務(wù)進(jìn)行分流，**執(zhí)行**級別高的業(yè)務(wù)。
4)容錯隔離
系統(tǒng)的有些業(yè)務(wù)模塊在出現(xiàn)錯誤時，為了減少并發(fā)下對正常請求的處理的影響，有時候需要考慮對這些異常狀態(tài)的請求進(jìn)行單獨(dú)渠道的處理，甚至?xí)簳r自動禁止這些異常的業(yè)務(wù)模塊。
有些請求的失敗可能是偶然的暫時的失敗(比如網(wǎng)絡(luò)不穩(wěn)定)，需要進(jìn)行請求重試或者請求轉(zhuǎn)移到其他機(jī)器的考慮。
 
5)資源釋放
系統(tǒng)的資源是有限的，在使用資源時，一定要在最后釋放資源，無論是請求走的是正常路徑還是異常的路徑，以便于資源的及時回收，供其他請求使用。
在設(shè)計通信的架構(gòu)時，往往需要考慮**時的控制。
 
二、 靜態(tài)架構(gòu)藍(lán)圖
 
整個架構(gòu)是分層的分布式的架構(gòu)，縱向包括CDN，負(fù)載均衡/反向代理，web應(yīng)用，業(yè)務(wù)層，基礎(chǔ)服務(wù)層，數(shù)據(jù)存儲層。水平方向包括對整個平臺的配置管理部署和監(jiān)控。
 
三、 剖析架構(gòu)
1、CDN
CDN系統(tǒng)能夠?qū)崟r地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連接、負(fù)載狀況以及到用戶的距離和響應(yīng)時間等綜合信息將用戶的請求重新導(dǎo)向離用戶較近的服務(wù)節(jié)點(diǎn)上。其目的是使用戶可就近**所需內(nèi)容，解決 Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。
對于大規(guī)模電子商務(wù)平臺一般需要建CDN做網(wǎng)絡(luò)加速，大型平臺如淘寶、京東都采用自建CDN，中小型的企業(yè)可以采用第三方CDN廠商合作，如藍(lán)汛、網(wǎng)宿、快網(wǎng)等。
當(dāng)然在選擇CDN廠商時，需要考慮經(jīng)營時間長短，是否有可擴(kuò)充的帶寬資源、靈活的流量和帶寬選擇、穩(wěn)定的節(jié)點(diǎn)、性價比。
2、負(fù)載均衡、反向代理
一個大型的平臺包括很多個業(yè)務(wù)域，不同的業(yè)務(wù)域有不同的集群，可以用DNS做域名解析的分發(fā)或輪詢，DNS方式實現(xiàn)簡單，但是因存在cache而缺乏靈活性；一般基于商用的硬件F5、NetScaler或者開源的軟負(fù)載lvs在4層做分發(fā)，當(dāng)然會采用做冗余(比如lvs+keepalived)的考慮，采取主備方式。
4層分發(fā)到業(yè)務(wù)集群上后，會經(jīng)過web服務(wù)器如nginx或者HAProxy在7層做負(fù)載均衡或者反向代理分發(fā)到集群中的應(yīng)用節(jié)點(diǎn)。
選擇哪種負(fù)載，需要綜合考慮各種因素（是否滿足高并發(fā)高性能，Session保持如何解決，負(fù)載均衡的算法如何，支持壓縮，緩存的內(nèi)存消耗）；下面基于幾種常用的負(fù)載均衡軟件做個介紹。
LVS，工作在4層，Linux實現(xiàn)的高性能高并發(fā)、可伸縮性、可靠的的負(fù)載均衡器，支持多種轉(zhuǎn)發(fā)方式(NAT、DR、IP Tunneling)，其中DR模式支持通過廣域網(wǎng)進(jìn)行負(fù)載均衡。支持雙機(jī)熱備(Keepalived或者Heartbeat)。對網(wǎng)絡(luò)環(huán)境的依賴性比較高。
Nginx工作在7層，事件驅(qū)動的、異步非阻塞的架構(gòu)、支持多進(jìn)程的高并發(fā)的負(fù)載均衡器/反向代理軟件?？梢葬槍τ蛎?、目錄結(jié)構(gòu)、正則規(guī)則針對http做一些分流。通過端口檢測到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁返回的狀態(tài)碼、**時等等，并且會把返回錯誤的請求重新提交到另一個節(jié)點(diǎn)，不過其中缺點(diǎn)就是不支持url來檢測。對于session sticky，可以基于ip hash的算法來實現(xiàn)，通過基于cookie的擴(kuò)展nginx-sticky-module支持session sticky。
HAProxy支持4層和7層做負(fù)載均衡，支持session的會話保持，cookie的引導(dǎo)；支持后端url方式的檢測；負(fù)載均衡的算法比較豐富，有RR、權(quán)重等。
對于圖片，需要有單獨(dú)的域名，獨(dú)立或者分布式的圖片服務(wù)器或者如mogileFS，可以圖片服務(wù)器之上加varnish做圖片緩存。
3、App接入
應(yīng)用層運(yùn)行在jboss或者tomcat容器中，代表獨(dú)立的系統(tǒng)，比如**購物、用戶自主服務(wù)、后端系統(tǒng)等
協(xié)議接口，HTTP、JSON
可以采用servlet3.0,異步化servlet,提高整個系統(tǒng)的吞吐量
http請求經(jīng)過Nginx，通過負(fù)載均衡算法分到到App的某一節(jié)點(diǎn)，這一層層擴(kuò)容起來比較簡單。
除了利用cookie保存少量用戶部分信息外(cookie一般不能**過4K的大小)，對于App接入層，保存有用戶相關(guān)的session數(shù)據(jù)，但是有些反向代理或者負(fù)載均衡不支持對session sticky支持不是很好或者對接入的可用性要求比較高(app接入節(jié)點(diǎn)宕機(jī)，session隨之丟失)，這就需要考慮session的集中式存儲，使得App接入層無狀態(tài)化，同時系統(tǒng)用戶變多的時候，就可以通過增加更多的應(yīng)用節(jié)點(diǎn)來達(dá)到水平擴(kuò)展的目的。
Session的集中式存儲，需要滿足以下幾點(diǎn)要求：
a、高效的通訊協(xié)議
b、session的分布式緩存，支持節(jié)點(diǎn)的伸縮，數(shù)據(jù)的冗余備份以及數(shù)據(jù)的遷移
c、session過期的管理
 
4、業(yè)務(wù)服務(wù)
代表某一領(lǐng)域的業(yè)務(wù)提供的服務(wù)，對于電商而言，領(lǐng)域有用戶、商品、訂單、紅包、支付業(yè)務(wù)等等，不同的領(lǐng)域提供不同的服務(wù)，
這些不同的領(lǐng)域構(gòu)成一個個模塊，良好的模塊劃分和接口設(shè)計非常重要，一般是參考高內(nèi)聚、接口收斂的原則，
這樣可以提高整個系統(tǒng)的可用性。當(dāng)然可以根據(jù)應(yīng)用規(guī)模的大小，模塊可以部署在一起，對于大規(guī)模的應(yīng)用，一般是獨(dú)立部署的。
高并發(fā)：
業(yè)務(wù)層對外協(xié)議以NIO的RPC方式暴露，可以采用比較成熟的NIO通訊框架，如netty、mina
可用性：
為了提高模塊服務(wù)的可用性，一個模塊部署在多個節(jié)點(diǎn)做冗余，并自動進(jìn)行負(fù)載轉(zhuǎn)發(fā)和失效轉(zhuǎn)移;
較初可以利用VIP+heartbeat方式，目前系統(tǒng)有一個單獨(dú)的組件HA,利用zookeeper實現(xiàn)(比原來方案的優(yōu)點(diǎn))
一致性、事務(wù)：
對于分布式系統(tǒng)的一致性，盡量滿足可用性，一致性可以通過校對來達(dá)到較終一致的狀態(tài)。
5、基礎(chǔ)服務(wù)中間件
1) 通信組件
通信組件用于業(yè)務(wù)系統(tǒng)內(nèi)部服務(wù)之間的調(diào)用，在大并發(fā)的電商平臺中，需要滿足高并發(fā)高吞吐量的要求。
整個通信組件包括客戶端和服務(wù)端兩部分。
客戶端和服務(wù)器端維護(hù)的是長連接，可以減少每次請求建立連接的開銷，在客戶端對于每個服務(wù)器定義一個連接池，初始化連接后，可以并發(fā)連接服務(wù)端進(jìn)行rpc操作，連接池中的長連接需要心跳維護(hù)，設(shè)置請求**時時間。
對于長連接的維護(hù)過程可以分兩個階段，一個是發(fā)送請求過程，另外一個是接收響應(yīng)過程。在發(fā)送請求過程中，若發(fā)生IOException，則把該連接標(biāo)記失效。接收響應(yīng)時，服務(wù)端返回SocketTimeoutException，如果設(shè)置了**時時間，那么就直接返回異常，清除當(dāng)前連接中那些**時的請求。否則繼續(xù)發(fā)送心跳包(因為可能是丟包，**過pingInterval間隔時間就發(fā)送ping操作)，若ping不通(發(fā)送IOException)，則說明當(dāng)前連接是有問題的，那么就把當(dāng)前連接標(biāo)記成已經(jīng)失效；若ping通，則說明當(dāng)前連接是可靠的，繼續(xù)進(jìn)行讀操作。失效的連接會從連接池中清除掉。
每個連接對于接收響應(yīng)來說都以單獨(dú)的線程運(yùn)行，客戶端可以通過同步(wait,notify)方式或者異步進(jìn)行rpc調(diào)用，
序列化采用較高效的hession序列化方式。
服務(wù)端采用事件驅(qū)動的NIO的MINA框架，支撐高并發(fā)高吞吐量的請求。
 
2) 路由Router
在大多數(shù)的數(shù)據(jù)庫切分解決方案中，為了提高數(shù)據(jù)庫的吞吐量，首先是對不同的表進(jìn)行垂直切分到不同的數(shù)據(jù)庫中，
然后當(dāng)數(shù)據(jù)庫中一個表**過一定大小時，需要對該表進(jìn)行水平切分，這里也是一樣，這里以用戶表為例；
對于訪問數(shù)據(jù)庫客戶端來講，需要根據(jù)用戶的ID，定位到需要訪問的數(shù)據(jù)；
數(shù)據(jù)切分算法，
根據(jù)用戶的ID做hash操作，一致性Hash，這種方式存在失效數(shù)據(jù)的遷移問題，遷移時間內(nèi)服務(wù)不可用
維護(hù)路由表，路由表中存儲用戶和sharding的映射關(guān)系,sharding分為leader和replica，分別負(fù)責(zé)寫和讀
這樣每個biz客戶端都需要保持所有sharding的連接池，這樣有個缺點(diǎn)是會產(chǎn)生全連接的問題；
一種解決方法是sharding的切分提到業(yè)務(wù)服務(wù)層進(jìn)行，每個業(yè)務(wù)節(jié)點(diǎn)只維護(hù)一個shard的連接即可。
  
路由組件的實現(xiàn)是這樣的（可用性、高性能、高并發(fā)）
基于性能方面的考慮，采用mongodb中維護(hù)用戶id和shard的關(guān)系，為了保證可用性，搭建replicatset集群。
biz的sharding和數(shù)據(jù)庫的sharding是一一對應(yīng)的，只訪問一個數(shù)據(jù)庫sharding.
biz業(yè)務(wù)注冊節(jié)點(diǎn)到zookeeper上/bizs/shard/下。
router監(jiān)聽zookeeper上/bizs/下節(jié)點(diǎn)狀態(tài)，緩存在線biz在router中。
client請求router獲取biz時，router首先從mongodb中獲取用戶對應(yīng)的shard,router根據(jù)緩存的內(nèi)容通過RR算法獲取biz節(jié)點(diǎn)。
為了解決router的可用性和并發(fā)吞吐量問題，對router進(jìn)行冗余，同時client監(jiān)聽zookeeper的/routers節(jié)點(diǎn)并緩存在線router節(jié)點(diǎn)列表。
 
3) HA
傳統(tǒng)實現(xiàn)HA的做法一般是采用虛擬IP漂移，結(jié)合Heartbeat、keepalived等實現(xiàn)HA，
Keepalived使用vrrp方式進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)，提供4層的負(fù)載均衡，通過檢測vrrp數(shù)據(jù)包來切換，做冗余熱備較加適合與LVS搭配。Linux Heartbeat是基于網(wǎng)絡(luò)或者主機(jī)的服務(wù)的高可用，HAProxy或者Nginx可以基于7層進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)，因此Heatbeat較加適合做HAProxy、Nginx，包括業(yè)務(wù)的高可用。
在分布式的集群中，可以用zookeeper做分布式的協(xié)調(diào)，實現(xiàn)集群的列表維護(hù)和失效通知，客戶端可以選擇hash算法或者roudrobin實現(xiàn)負(fù)載均衡；對于master-master模式、master-slave模式，可以通過zookeeper分布式鎖的機(jī)制來支持。
4)消息Message
對于平臺各個系統(tǒng)之間的異步交互，是通過MQ組件進(jìn)行的。
在設(shè)計消息服務(wù)組件時，需要考慮消息一致性、持久化、可用性、以及完善的監(jiān)控體系。
業(yè)界開源的消息中間件主要RabbitMQ、kafka有兩種，
RabbitMQ,遵循AMQP協(xié)議，由內(nèi)在高并發(fā)的erlanng語言開發(fā)；kafka是Linkedin于2010年12月份開源的消息發(fā)布訂閱系統(tǒng),它主要用于處理活躍的流式數(shù)據(jù),大數(shù)據(jù)量的數(shù)據(jù)處理上。
對消息一致性要求比較高的場合需要有應(yīng)答確認(rèn)機(jī)制，包括生產(chǎn)消息和消費(fèi)消息的過程；不過因網(wǎng)絡(luò)等原理導(dǎo)致的應(yīng)答缺失，可能會導(dǎo)致消息的重復(fù)，這個可以在業(yè)務(wù)層次根據(jù)冪等性進(jìn)行判斷過濾；RabbitMQ采用的是這種方式。還有一種機(jī)制是消費(fèi)端從broker拉取消息時帶上LSN號，從broker中某個LSN點(diǎn)批量拉取消息，這樣無須應(yīng)答機(jī)制，kafka分布式消息中間件就是這種方式。
消息的在broker中的存儲，根據(jù)消息的可靠性的要求以及性能方面的綜合衡量，可以在內(nèi)存中，可以持久化到存儲上。
對于可用性和高吞吐量的要求，集群和主備模式都可以在實際的場景應(yīng)用的到。RabbitMQ解決方案中有普通的集群和可用性較高的mirror queue方式。 kafka采用zookeeper對集群中的broker、consumer進(jìn)行管理，可以注冊topic到zookeeper上；通過zookeeper的協(xié)調(diào)機(jī)制，producer保存對應(yīng)topic的broker信息，可以隨機(jī)或者輪詢發(fā)送到broker上；并且producer可以基于語義*分片，消息發(fā)送到broker的某分片上。
總體來講，RabbitMQ用在實時的對可靠性要求比較高的消息傳遞上。kafka主要用于處理活躍的流式數(shù)據(jù),大數(shù)據(jù)量的數(shù)據(jù)處理上。
 
5)Cache&Buffer
Cache系統(tǒng)
在一些高并發(fā)高性能的場景中，使用cache可以減少對后端系統(tǒng)的負(fù)載，承擔(dān)可大部分讀的壓力，可以大大提高系統(tǒng)的吞吐量，比如通常在數(shù)據(jù)庫存儲之前增加cache緩存。
但是引入cache架構(gòu)不可避免的帶來一些問題，cache命中率的問題, cache失效引起的抖動，cache和存儲的一致性。
Cache中的數(shù)據(jù)相對于存儲來講，畢竟是有限的，比較理想的情況是存儲系統(tǒng)的熱點(diǎn)數(shù)據(jù)，這里可以用一些常見的算法LRU等等淘汰老的數(shù)據(jù)；隨著系統(tǒng)規(guī)模的增加，單個節(jié)點(diǎn)cache不能滿足要求，就需要搭建分布式Cache；為了解決單個節(jié)點(diǎn)失效引起的抖動 ，分布式cache一般采用一致性hash的解決方案，大大減少因單個節(jié)點(diǎn)失效引起的抖動范圍；而對于可用性要求比較高的場景，每個節(jié)點(diǎn)都是需要有備份的。數(shù)據(jù)在cache和存儲上都存有同一份備份，必然有一致性的問題，一致性比較強(qiáng)的，在較新數(shù)據(jù)庫的同時，較新數(shù)據(jù)庫cache。對于一致性要求不高的，可以去設(shè)置緩存失效時間的策略。
Memcached作為高速的分布式緩存服務(wù)器，協(xié)議比較簡單，基于libevent的事件處理機(jī)制。
Cache系統(tǒng)在平臺中用在router系統(tǒng)的客戶端中，熱點(diǎn)的數(shù)據(jù)會緩存在客戶端，當(dāng)數(shù)據(jù)訪問失效時，才去訪問router系統(tǒng)。
當(dāng)然目前更多的利用內(nèi)存型的數(shù)據(jù)庫做cache，比如redis、mongodb；redis比memcache有豐富的數(shù)據(jù)操作的API；redis和mongodb都對數(shù)據(jù)進(jìn)行了持久化，而memcache沒有這個功能，因此memcache較加適合在關(guān)系型數(shù)據(jù)庫之上的數(shù)據(jù)的緩存。
 
 
 
強(qiáng)一致的數(shù)據(jù)訪問
MVCC
HBase的一致性數(shù)據(jù)訪問是通過MVCC來實現(xiàn)的。
HBase在寫數(shù)據(jù)的過程中，需要經(jīng)過好幾個階段，寫HLog，寫memstore，較新MVCC;
只有較新了MVCC，才算真正memstore寫成功，其中事務(wù)的隔離需要有mvcc的來控制，比如讀數(shù)據(jù)不可以獲取別的線程還未提交的數(shù)據(jù)。
高可靠
HBase的數(shù)據(jù)存儲基于HDFS，提供了冗余機(jī)制。
Region節(jié)點(diǎn)的宕機(jī)，對于內(nèi)存中的數(shù)據(jù)還未flush到文件中，提供了可靠的恢復(fù)機(jī)制。
 
 
可伸縮，自動切分，遷移
通過Zookeeper定位目標(biāo)Region Server，最后定位Region。
Region Server擴(kuò)容，通過將自身發(fā)布到Master，Master均勻分布。
 
可用性
存在單點(diǎn)故障，Region Server宕機(jī)后，短時間內(nèi)該server維護(hù)的region無法訪問，等待failover生效。
通過Master維護(hù)各Region Server健康狀況和Region分布。
多個Master，Master宕機(jī)有zookeeper的paxos投票機(jī)制選取下一任Master。Master就算全宕機(jī)，也不影響Region讀寫。Master僅充當(dāng)一個自動運(yùn)維角色。
HDFS為分布式存儲引擎，一備三，高可靠，0數(shù)據(jù)丟失。
HDFS的namenode是一個SPOF。
為避**個region訪問過于頻繁，單機(jī)壓力過大，提供了split機(jī)制
HBase的寫入是LSM-TREE的架構(gòu)方式，隨著數(shù)據(jù)的append，HFile越來越多，HBase提供了HFile文件進(jìn)行compact，對過期數(shù)據(jù)進(jìn)行清除，提高查詢的性能。
Schema free
HBase沒有像關(guān)系型數(shù)據(jù)庫那樣的嚴(yán)格的schema，可以自由的增加和刪除schema中的字段。
 
HBase分布式數(shù)據(jù)庫，對于二級索引支持的不太好，目前只支持在rowkey上的索引，所以rowkey的設(shè)計對于查詢的性能來講非常關(guān)鍵。
7、管理與部署配置
統(tǒng)一的配置庫
部署平臺
 
 
8、監(jiān)控、統(tǒng)計、日志
 
大型分布式系統(tǒng)涉及各種設(shè)備，比如網(wǎng)絡(luò)交換機(jī)，普通PC機(jī)，各種型號的網(wǎng)卡，硬盤，內(nèi)存等等，還有應(yīng)用業(yè)務(wù)層次的監(jiān)控，數(shù)量非常多的時候，出現(xiàn)錯誤的概率也會變大，并且有些監(jiān)控的時效性要求比較高，有些達(dá)到秒級別；在大量的數(shù)據(jù)流中需要過濾異常的數(shù)據(jù)，有時候也對數(shù)據(jù)會進(jìn)行上下文相關(guān)的復(fù)雜計算，進(jìn)而決定是否需要告警。因此監(jiān)控平臺的性能、吞吐量、已經(jīng)可用性就比較重要，需要規(guī)劃統(tǒng)一的一體化的監(jiān)控平臺對系統(tǒng)進(jìn)行各個層次的監(jiān)控。
 
平臺的數(shù)據(jù)分類
應(yīng)用業(yè)務(wù)級別：應(yīng)用事件、業(yè)務(wù)日志、審計日志、請求日志、異常、請求業(yè)務(wù)metrics、性能度量
系統(tǒng)級別：CPU、內(nèi)存、網(wǎng)絡(luò)、IO
 
時效性要求
閥值，告警：
實時計算：
近實時分鐘計算
按小時、天的離線分析
實時查詢
 
架構(gòu)
節(jié)點(diǎn)中Agent代理可以接收日志、應(yīng)用的事件以及通過探針的方式采集數(shù)據(jù)，agent采集數(shù)據(jù)的一個原則是和業(yè)務(wù)應(yīng)用的流程是異步隔離的，不影響交易流程。
數(shù)據(jù)統(tǒng)一通過collector集群進(jìn)行收集，按照數(shù)據(jù)的不同類型分發(fā)到不同的計算集群進(jìn)行處理；有些數(shù)據(jù)時效性不是那么高，比如按小時進(jìn)行統(tǒng)計，放入hadoop集群；有些數(shù)據(jù)是請求流轉(zhuǎn)的跟蹤數(shù)據(jù)，需要可以查詢的，那么就可以放入solr集群進(jìn)行索引；有些數(shù)據(jù)需要進(jìn)行實時計算的進(jìn)而告警的，需要放到storm集群中進(jìn)行處理。
數(shù)據(jù)經(jīng)過計算集群處理后，結(jié)果存儲到Mysql或者HBase中。
監(jiān)控的web應(yīng)用可以把監(jiān)控的實時結(jié)果推送到瀏覽器中，也可以提供API供結(jié)果的展現(xiàn)和搜索。




無錫紅豬網(wǎng)絡(luò)科技有限公司專注于java,b2b2c,多用戶商城等

• 詞條

  詞條說明

• java 多用戶商城系統(tǒng)源碼仿京東淘寶

  電商多用戶商城購物系統(tǒng)中，php商城系統(tǒng)和java商城系統(tǒng)是電商系統(tǒng)的兩個大門派，一直在暗自較勁，但是也是勝負(fù)難分。今天來和大家聊聊關(guān)于java多用戶商城的那些事兒。??? 什么是java多用戶購物商城Java多用戶電子商城，顧名思義，就是使用java程序語言開發(fā)、支持多個用戶一同建設(shè)網(wǎng)上商城的電商購物系統(tǒng)。Java多用戶網(wǎng)上商城就像是淘寶商城一樣，很多的商家都可以在

• (十一）Java springcloud B2B2C o2o多用戶商城 springcloud架構(gòu)- - SSO單點(diǎn)登錄之OAuth2.0登錄流程(2)

  之前寫了很多關(guān)于spring cloud的文章，今天我們對OAuth2.0的整合方式做一下筆記，首先我從網(wǎng)上找了一些關(guān)于OAuth2.0的一些基礎(chǔ)知識點(diǎn)，幫助大家回顧一下知識點(diǎn)：?一、oauth中的角色client：調(diào)用資源服務(wù)器API的應(yīng)用Oauth 2.0 Provider：包括Authorization Server和Resource Server（1）Authorization

• java多用戶商城B2B2C 源碼 微商

  1??????O2O周邊門店繼發(fā)布2.7版本后，繼續(xù)對門店這塊的功能做重大升華，新版對周邊門店列表、門店主頁、定位及整個購物流程做了大幅度改造，以限度的滿足商家開展線上線下的相關(guān)業(yè)務(wù)，提升效益及競爭力。主要功能較新如下：1.1???????LBS定位：獲取用戶當(dāng)前的位置

• B2B2C商城系統(tǒng)解決方案，多種模式讓平臺運(yùn)營較靈活多變

  摘要： RedPigMall B2B2C綜合商城系統(tǒng)是專為企業(yè)級客戶研發(fā)支持多供貨商、多商戶店鋪入駐的綜合商城平臺，集團(tuán)購、電商零售、批發(fā)于一體，提供給供應(yīng)商商品售賣服務(wù)，對用戶提供購買服務(wù)，支持運(yùn)營、聯(lián)營、招商等多種運(yùn)營模式，讓企業(yè)低成本快速構(gòu)建在線商城，開啟電子商... RedPigMall B2B2C綜合商城系統(tǒng)是專為企業(yè)級客戶研發(fā)支持多供貨商、多商戶店鋪入駐的綜合商城平臺，集團(tuán)購、電商零售