自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

500萬(wàn)日訂單下的高可用拼購(gòu)系統(tǒng),到底暗藏了什么“獨(dú)門(mén)秘籍”?

原創(chuàng)
開(kāi)發(fā) 架構(gòu) 開(kāi)發(fā)工具
零點(diǎn)提交訂單峰值破 1 萬(wàn) TPS,單日總訂單量超 500 萬(wàn),活躍用戶(hù)數(shù) 200 萬(wàn),蘇寧 88 拼購(gòu)日活動(dòng)取得了豐碩的成果。

[[240146]]

【51CTO.com原創(chuàng)稿件】在大流量、高銷(xiāo)量的背后,是我們近半年來(lái)付出的努力,針對(duì)拼購(gòu)系統(tǒng)瞬時(shí)高并發(fā)能力的優(yōu)化與升級(jí),才能保證消費(fèi)者絲滑順暢的購(gòu)物體驗(yàn)。下面就來(lái)介紹下蘇寧拼購(gòu)系統(tǒng)應(yīng)對(duì)大促的術(shù)與道。

術(shù)為用:拼購(gòu)系統(tǒng)高可用的架構(gòu)設(shè)計(jì)

“術(shù)”是架構(gòu)設(shè)計(jì)的方法論。拼購(gòu)系統(tǒng)的架構(gòu)歷經(jīng)多次更新和迭代,其目的是打造一個(gè)高可用、高性能、易擴(kuò)展、可伸縮性強(qiáng)的應(yīng)用系統(tǒng)。

將整個(gè)過(guò)程精煉出來(lái),我們主要做了三個(gè)方面的工作:

  • 系統(tǒng)架構(gòu)優(yōu)化設(shè)計(jì)
  • 數(shù)據(jù)庫(kù)性能的優(yōu)化
  • 應(yīng)用高可用的優(yōu)化

系統(tǒng)架構(gòu)優(yōu)化設(shè)計(jì)

根據(jù)康威定律,組織形式等同系統(tǒng)設(shè)計(jì)。拼購(gòu)系統(tǒng)之前為了滿(mǎn)足快速的開(kāi)發(fā)迭代節(jié)奏,所有功能是放在一個(gè)集群中的。

隨著業(yè)務(wù)的發(fā)展,功能越來(lái)越復(fù)雜,單一集群已經(jīng)成為限制系統(tǒng)性能的***瓶頸。

圖 1:蘇寧拼購(gòu)系統(tǒng)架構(gòu)設(shè)計(jì)

因此,系統(tǒng)優(yōu)化所做的***件事情就是對(duì)拼購(gòu)系統(tǒng)架構(gòu)進(jìn)行了重構(gòu)。一方面,進(jìn)行橫向切分,將系統(tǒng)分層,包括:

  • 網(wǎng)絡(luò)層:通過(guò) CDN 加速響應(yīng)。一方面 CDN 緩存提高靜態(tài)內(nèi)容訪問(wèn)速度,減少服務(wù)端壓力;另一方面,CDN 內(nèi)部網(wǎng)絡(luò)專(zhuān)線(xiàn),加快回源速度。
  • 負(fù)載層:包括四層負(fù)載和七層負(fù)載。功能包括流量調(diào)度、流量控制、安全防護(hù)、黃牛防護(hù)等,另外在負(fù)載層也做了一些輕量級(jí)業(yè)務(wù)的 Lua 聚合,以提高響應(yīng)性能。
  • 應(yīng)用層:這層主要實(shí)現(xiàn)業(yè)務(wù)功能邏輯。
  • 服務(wù)層:為應(yīng)用層提供原子服務(wù),如會(huì)員、領(lǐng)券、尋源、時(shí)效、生成訂單、支付等。
  • 數(shù)據(jù)層:提供數(shù)據(jù)存儲(chǔ)訪問(wèn)服務(wù),如數(shù)據(jù)庫(kù)、緩存等;提供數(shù)據(jù)抽取分析服務(wù),如 Hbase、Hive。

另一方面,針對(duì)拼購(gòu)的業(yè)務(wù)特性,進(jìn)行縱向切分,將原來(lái)耦合的功能邏輯拆分為三層:PGS-WEB、PGS-TASK-WEB、PGS-ADMIN_WEB。

每個(gè)模塊獨(dú)立集群部署,集群之間通過(guò)分布式遠(yuǎn)程調(diào)用與服務(wù)層提供的原子服務(wù)協(xié)同工作。其中:

  • PGS-WEB:前臺(tái)業(yè)務(wù)處理模塊。包括展示、交易、營(yíng)銷(xiāo)三個(gè)單元模塊。每個(gè)模塊又能分割為更小粒度的子模塊。

比如營(yíng)銷(xiāo)模塊就又能細(xì)分為四個(gè)輕量級(jí)玩法模塊:邀新團(tuán)、砍價(jià)團(tuán)、膨脹紅包和助力團(tuán),可以針對(duì)業(yè)務(wù)需要,對(duì)不同模塊進(jìn)行拔插、拆分和擴(kuò)展。

  • PGS-TASK-WEB:中臺(tái)定時(shí)任務(wù)處理模塊,主要用于處理定時(shí)任務(wù),另外支付邏輯也在這一層。
  • PGS-ADMIN_WEB:后臺(tái)管理模塊,主要用于運(yùn)營(yíng)人員維護(hù)活動(dòng)、商品、玩法等。

數(shù)據(jù)庫(kù)性能優(yōu)化

在高并發(fā)場(chǎng)景下,提交訂單、生成拼團(tuán)記錄、查詢(xún)訂單等操作,會(huì)對(duì)數(shù)據(jù)庫(kù)造成很大壓力,而這些一致性要求高的操作又不能直接使用分布式緩存替代數(shù)據(jù)庫(kù)。

而給數(shù)據(jù)庫(kù)降溫,提高數(shù)據(jù)庫(kù)的并發(fā)處理能力,必須讓數(shù)據(jù)庫(kù)具備橫向擴(kuò)展能力。因此我們基于 Mycat 數(shù)據(jù)庫(kù)中間件實(shí)現(xiàn)了拼購(gòu)系統(tǒng)數(shù)據(jù)庫(kù)的分庫(kù)分表策略。

圖 2:高并發(fā)場(chǎng)景下 MySQL 數(shù)據(jù)庫(kù)負(fù)載能力趨勢(shì)

Mycat 是 MySQL 分庫(kù)分表中間件,和 Web 服務(wù)器的 Nginx 類(lèi)似,是應(yīng)用與數(shù)據(jù)庫(kù)之間的代理層。

由于 Mycat 是開(kāi)源中間件,這里對(duì)技術(shù)實(shí)現(xiàn)不做闡述,主要講下它在拼購(gòu)系統(tǒng)下是如何應(yīng)用的。

如下圖所示,業(yè)務(wù)邏輯的數(shù)據(jù)操作通過(guò) Mycat 分為三個(gè)庫(kù) DataNode 1~3,這個(gè)分庫(kù)過(guò)程應(yīng)用本身是無(wú)感知的。

圖 3:蘇寧拼購(gòu)系統(tǒng)基于 Mycat 的分庫(kù)架構(gòu)

每個(gè)庫(kù)一寫(xiě)兩讀,針對(duì)團(tuán)和團(tuán)詳情的操作分片規(guī)則基于團(tuán) ID(GROUP_ID),針對(duì)訂單的操作分片規(guī)則基于訂單 ID(ORDER_ID)。

另外,還有一個(gè)單獨(dú)的 BackupDB 用于大數(shù)據(jù)抽取和數(shù)據(jù)備份,通過(guò) Canal 保證 BackupDB 中是全量數(shù)據(jù)。

當(dāng) Mycat 出現(xiàn)問(wèn)題時(shí),我們可以通過(guò)應(yīng)用層的數(shù)據(jù)源切換,降級(jí)為單庫(kù),保證業(yè)務(wù)。

應(yīng)用高可用優(yōu)化

對(duì)于應(yīng)用層面的優(yōu)化,主要包括分布式緩存和異步化兩方面。

利用 Redis 分布式鎖解決并發(fā)場(chǎng)景一致性問(wèn)題

比如為了防止訂單被重復(fù)處理,我們使用 Jedis 的事務(wù) Transaction + SETNX 命令來(lái)實(shí)現(xiàn) Redis 分布式鎖:

  1. Transaction transaction = jedis.multi();//返回一個(gè)事務(wù)控制對(duì)象 
  2. transaction.setnx(tmpLockKey, "lock");//Set if Not Exist 
  3. transaction.expire(tmpLockKey, locktime); 
  4. List<Object> rets = transaction.exec();//事務(wù)執(zhí)行 

利用 Redis 實(shí)現(xiàn)活動(dòng)庫(kù)存,解決數(shù)據(jù)庫(kù)資源競(jìng)爭(zhēng)問(wèn)題

對(duì)于每一個(gè)拼團(tuán)活動(dòng),我們是維護(hù)了活動(dòng)庫(kù)存的,或者叫做資格/剩余數(shù),并非真正的實(shí)際庫(kù)存。

在 1 元秒殺等活動(dòng)中,這個(gè)活動(dòng)庫(kù)存的變化會(huì)很迅速,大量數(shù)據(jù)庫(kù) UpDate 操作,造成行鎖非常影響系統(tǒng)吞吐率。

優(yōu)化方案是 在Redis 中做活動(dòng)庫(kù)存扣減,并以一定周期同步給數(shù)據(jù)庫(kù):

  1. /** 
  2.  * Redis緩存扣減活動(dòng)庫(kù)存 
  3.  * */ 
  4. private Long updateStoreByRedis(String actId, String field, int count) { 
  5.         String key = redis.key(PGS_STORE_INFO, actId); 
  6.         // 如果活動(dòng)庫(kù)存緩存信息存在,則更新對(duì)應(yīng)field的數(shù)量 
  7.         if (!redis.exists(key)) { 
  8.             // 從數(shù)據(jù)庫(kù)讀取該活動(dòng)庫(kù)存信息并初始化到redis 
  9.             ActivityStoreEntity entity = queryStoreInfoFromDb(actId); 
  10.             if (entity == null) { 
  11.                 return -1L; 
  12.             } 
  13.             Map<String, String> values = new HashMap<String, String>(); 
  14.             values.put(PGS_STORE_ALL,…); 
  15.             values.put(PGS_STORE_REMAIN, …); 
  16.             values.put(PGS_STORE_LOCK, …) 
  17.             redis.hmset(keyvalues); 
  18.             // 若活動(dòng)有效期內(nèi)庫(kù)存緩存信息失效,初始化緩存信息一小時(shí) 
  19.             redis.expire(key, ONE_HOUR); 
  20.         } 
  21.         return redis.hincrby(key, field, count); 
  22.     } 
  1. /** 
  2.  * Redis同步活動(dòng)庫(kù)存給數(shù)據(jù)庫(kù) 
  3.  * */ 
  4. public int syncActivityStoreToDB(String actId) { 
  5.         … 
  6.         try { 
  7.  // 判斷同步鎖狀態(tài) 
  8.             String key = redis.key(PGS_STORE_SYNC, actId); 
  9.             if(!redis.exists(key)){ 
  10.                     更新活動(dòng)可被鎖庫(kù)存數(shù)量 
  11.                     redis.setex(key, actId,STORE_SYNC_TIME); 
  12.                 } 
  13.             } 
  14.         } catch (Exception e) { 
  15.             Log; 
  16.         } 
  17.         … 

異步化操作,消除并發(fā)訪問(wèn)高峰

比如支付完成后,有一系列的后續(xù)處理流程,包括活動(dòng)庫(kù)存扣減、拼團(tuán)狀態(tài)變更等,其中有些邏輯實(shí)時(shí)性要求高,要同步處理。

有些則可以通過(guò)異步化的方式來(lái)處理,像通知物流發(fā)貨。我們采用 Kafka 隊(duì)列來(lái)進(jìn)行異步通信,讓下游系統(tǒng)進(jìn)行消費(fèi)處理。

道為體:拼購(gòu)系統(tǒng)高并發(fā)下的保障體系

“以道馭術(shù),術(shù)必成。離道之術(shù),術(shù)必衰。”我們所有的架構(gòu)優(yōu)化與升級(jí)最終目的是為了保障促銷(xiāo)高峰的穩(wěn)定性。

拼購(gòu)系統(tǒng)高并發(fā)場(chǎng)景下的保障之道,是以合理的容量規(guī)劃為基礎(chǔ),全面覆蓋的監(jiān)控體系為支撐,形成的完善的限流+降級(jí)+防控策略。

全鏈路壓測(cè)與容量規(guī)劃

根據(jù)業(yè)務(wù)預(yù)估量,生產(chǎn)環(huán)境針對(duì)蘇寧拼購(gòu)全鏈路場(chǎng)景的壓測(cè),才能做出合理的容量規(guī)劃。

目前,我們的壓測(cè)系統(tǒng),可以支持引流壓測(cè),即將線(xiàn)上真實(shí)流量復(fù)制下來(lái),生成腳本,進(jìn)行壓測(cè)。***程度保證了壓測(cè)和真實(shí)情況的一致性,從而使容量規(guī)劃更精確。

端到端覆蓋的監(jiān)控體系

目前蘇寧拼購(gòu)的監(jiān)控體系能夠做到端到端的覆蓋,包括客戶(hù)端->網(wǎng)絡(luò)->服務(wù)端的監(jiān)控。

其中,客戶(hù)端監(jiān)控依賴(lài)于覆蓋 PC + WAP + App 的終端日志。網(wǎng)絡(luò)監(jiān)控主要是 CDN 日志和撥測(cè)數(shù)據(jù)。

服務(wù)端監(jiān)控手段最為豐富,包括:

  • 服務(wù)器系統(tǒng)狀態(tài)監(jiān)控:CPU、內(nèi)存使用率、網(wǎng)卡流量、磁盤(pán) IO 等。
  • Web 服務(wù)器監(jiān)控:實(shí)時(shí)展現(xiàn) Web 服務(wù)器的 Http 連接數(shù)、響應(yīng)時(shí)間、Http 異常、狀態(tài)碼等指標(biāo)。
  • 應(yīng)用服務(wù)器異常監(jiān)控:實(shí)時(shí)匯總應(yīng)用異常堆棧信息。
  • JVM 狀態(tài)監(jiān)控:實(shí)時(shí)展現(xiàn)JVM的內(nèi)存、線(xiàn)程、GC 和 Class 的使用狀況。
  • NoSQL 監(jiān)控:Redis 每分鐘命令數(shù)、大對(duì)象、連通性等的監(jiān)控。
  • 數(shù)據(jù)庫(kù)監(jiān)控:數(shù)據(jù)庫(kù)層面各項(xiàng)指標(biāo)監(jiān)控。
  • 調(diào)用鏈監(jiān)控:實(shí)時(shí)展現(xiàn)應(yīng)用間調(diào)用關(guān)系,反饋鏈路系統(tǒng)健康狀況。

這些監(jiān)控系統(tǒng)通過(guò) traceId 相串聯(lián),與基礎(chǔ)運(yùn)維平臺(tái)打通,最終通過(guò)決策分析平臺(tái)聚合,實(shí)現(xiàn)智能告警。

圖 4:端到端監(jiān)控體系與告警決策平臺(tái)

流量控制與風(fēng)險(xiǎn)控制

流量控制是針對(duì) 88 拼購(gòu)日零點(diǎn)峰值瘋狂流量超出預(yù)期,所設(shè)置的限流,以保護(hù)好自身應(yīng)用,否則出現(xiàn)雪崩式連鎖反應(yīng)。

目前拼購(gòu)的流控系統(tǒng)可以支持多個(gè)維度的流控策略。包括最基礎(chǔ)的 JVM 活躍線(xiàn)程數(shù)流控,針對(duì)用戶(hù) IP、UA 和會(huì)員編號(hào)的限流,針對(duì)核心接口的限流策略,針對(duì)爆款商品的限流策略等等。

圖 5:拼購(gòu)流控系統(tǒng)架構(gòu)

風(fēng)險(xiǎn)控制是針對(duì) 88 拼購(gòu)日爆款商品被黃牛刷單風(fēng)險(xiǎn)的防控策略。除了傳統(tǒng)的黃牛庫(kù)名單,拼購(gòu)的風(fēng)控策略包括對(duì)用戶(hù)、地址、事件行為、設(shè)備指紋等的判斷。

區(qū)別于非黑即白的防控,拼購(gòu)采用打分的方式對(duì)用戶(hù)進(jìn)行畫(huà)像,對(duì)潛在的風(fēng)險(xiǎn)用戶(hù)采取短信驗(yàn)證、滑動(dòng)驗(yàn)證、人臉識(shí)別等一些列挑戰(zhàn)模式。

大促準(zhǔn)備與應(yīng)急預(yù)案

大促準(zhǔn)備工作是指結(jié)合業(yè)務(wù)的促銷(xiāo)節(jié)奏,梳理的一系列大促準(zhǔn)備工作,包括非核心定時(shí)任務(wù)的提前降級(jí)、生產(chǎn)操作權(quán)限的回收等。

應(yīng)急預(yù)案是針對(duì)大促可能發(fā)生的突發(fā)性事件梳理的預(yù)案,應(yīng)急預(yù)案是建立在降級(jí)手段的基礎(chǔ)上的。

比如關(guān)鍵時(shí)候?qū)Σ糠止δ艿慕导?jí)關(guān)閉操作,棄車(chē)保帥,保障購(gòu)物流程的正常;再比如針對(duì)服務(wù)器性能瓶頸的降溫手段,只有在準(zhǔn)備好應(yīng)對(duì)一切突發(fā)情況的前提下,才能保證每次大促的順利完成。

結(jié)束語(yǔ)

路漫漫其修遠(yuǎn)兮,今年的 88 蘇寧拼購(gòu)日已經(jīng)告一段落。未來(lái)向我們提出了更多的挑戰(zhàn)與機(jī)遇。

如何進(jìn)一步突破系統(tǒng)性能瓶頸,如何給用戶(hù)提供個(gè)性化的推薦與服務(wù),如何將拼購(gòu)做成一個(gè)開(kāi)放的社交化電商平臺(tái),蘇寧拼購(gòu)技術(shù)團(tuán)隊(duì)要做的工作仍然有很多。

我們將繼續(xù)前行,勢(shì)不可擋,并為大家?guī)?lái)持續(xù)的技術(shù)分享與更新。

作者:朱羿全、任章雄、張濤、龔召忠

簡(jiǎn)介:朱羿全,南京航空航天大學(xué)碩士研究生畢業(yè),蘇寧易購(gòu)消費(fèi)者研發(fā)中心高級(jí)技術(shù)經(jīng)理,主要負(fù)責(zé)易購(gòu)各系統(tǒng)架構(gòu)優(yōu)化與大促保障工作。先后參與了易購(gòu)整站 Https 改造、蘇寧拼購(gòu)架構(gòu)改造、先知業(yè)務(wù)監(jiān)控平臺(tái)建設(shè)等工作。專(zhuān)注于打造高可靠、高性能、高并發(fā)服務(wù)系統(tǒng)的技術(shù)研究。

【51CTO原創(chuàng)稿件,合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】

責(zé)任編輯:武曉燕 來(lái)源: 51CTO技術(shù)棧
相關(guān)推薦

2018-06-06 09:48:18

保障系統(tǒng)高可用

2015-07-31 14:03:00

e袋洗

2018-11-27 09:40:55

交換機(jī)網(wǎng)絡(luò)組件

2023-11-20 08:13:01

2009-09-05 15:50:16

2015-09-24 14:24:13

2011-05-03 17:48:59

針式打印機(jī)換針技巧

2014-07-17 15:52:00

Android L

2022-04-13 16:48:51

CPU網(wǎng)絡(luò)安全

2015-05-07 14:24:36

everRun

2017-08-01 10:55:47

DRC應(yīng)用實(shí)踐

2014-10-09 10:04:23

CentOS集群

2015-05-11 10:12:18

2019-04-25 09:36:18

Kafka高可靠高可用

2023-03-16 08:19:45

數(shù)據(jù)庫(kù)MySQL

2017-11-16 09:35:56

高性能高可用架構(gòu)

2025-03-19 08:21:15

2017-01-09 10:40:02

微信小程序

2012-07-03 16:46:39

實(shí)時(shí)監(jiān)控萬(wàn)國(guó)數(shù)據(jù)

2016-07-28 13:48:02

騰訊阿里巴巴云計(jì)算
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)