SpringCloud微服務(wù)實(shí)現(xiàn)秒殺系統(tǒng)

    • 分析

    • 在做秒殺系統(tǒng)的設(shè)計(jì)之初，一直在思考如何去設(shè)計(jì)這個(gè)秒殺系統(tǒng)，使之在現(xiàn)有的技術(shù)基礎(chǔ)和認(rèn)知范圍內(nèi)，能夠做到最好；同時(shí)也能充分的利用公司現(xiàn)有的中間件來完成系統(tǒng)的實(shí)現(xiàn)。
    原有方案：
    新增方案“

    專注于為中小企業(yè)提供網(wǎng)站建設(shè)、成都網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)禹城免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了數(shù)千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

我們都知道，正常去實(shí)現(xiàn)一個(gè)WEB端的秒殺系統(tǒng)，前端的處理和后端的處理一樣重要；前端一般會(huì)做cdn，后端一般會(huì)做分布式部署，限流，性能優(yōu)化等等一系列的操作，并完成一些網(wǎng)絡(luò)的優(yōu)化，比如IDC多線路（電信、聯(lián)通、移動(dòng)）的接入，帶寬的升級(jí)等等。而由于目前系統(tǒng)前端是基于微信小程序，所以關(guān)于前端部分的優(yōu)化就盡可能都是在代碼中完成，CDN這一步就可以免了；

關(guān)于秒殺的更多思考，在原有的秒殺架構(gòu)的基礎(chǔ)上新增了新的實(shí)現(xiàn)方案

通過分布式鎖的方式控制最終庫存不超賣，并控制最終能夠進(jìn)入到下單環(huán)節(jié)的訂單，入到隊(duì)列中慢慢去消費(fèi)下單

請(qǐng)求進(jìn)來之后，通過活動(dòng)開始判斷和重復(fù)秒殺判斷之后，即進(jìn)入到消息隊(duì)列，然后在消息的消費(fèi)端去做庫存判斷等操作，通過消息隊(duì)列達(dá)到削峰的操作

其實(shí)，我覺得兩種方案都是可以的，只是具體用在什么樣的場(chǎng)景；原有方案更適合流量相對(duì)較小的平臺(tái)，而且整個(gè)流程也會(huì)更加簡(jiǎn)單；而新增方案則是許多超大型平臺(tái)采用的方案，通過消息隊(duì)列達(dá)到削峰的目的；而這兩種方案都加了真實(shí)能進(jìn)入的請(qǐng)求限制，通過redis的原子自增來記錄請(qǐng)求數(shù)，當(dāng)請(qǐng)求量達(dá)到庫存的n倍時(shí)，后面再進(jìn)入的請(qǐng)求，則直接返回活動(dòng)太火爆的提示；

1、架構(gòu)介紹

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發(fā)便利性巧妙地簡(jiǎn)化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)，如服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開發(fā)風(fēng)格做到一鍵啟動(dòng)和部署。Spring Cloud并沒有重復(fù)制造輪子，它只是將各家公司開發(fā)的比較成熟、經(jīng)得起實(shí)際考驗(yàn)的服務(wù)框架組合起來，通過Spring Boot風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開發(fā)者留出了一套簡(jiǎn)單易懂、易部署和易維護(hù)的分布式系統(tǒng)開發(fā)工具包。

后端項(xiàng)目是基于SpringCloud+SpringBoot搭建的微服務(wù)框架架構(gòu)

前端在微信小程序商城上

核心支撐組件

  • 服務(wù)網(wǎng)關(guān) Zuul

  • 服務(wù)注冊(cè)發(fā)現(xiàn) Eureka+Ribbon

  • 服務(wù)框架 Spring MVC/Boot

  • 服務(wù)容錯(cuò) Hystrix

  • 分布式鎖 Redis

  • 服務(wù)調(diào)用 Feign

  • 消息隊(duì)列 Kafka

  • 文件服務(wù) 私有云盤

  • 富文本組件 UEditor

  • 定時(shí)任務(wù) xxl-job

  • 配置中心 apollo

2、關(guān)于秒殺的場(chǎng)景特點(diǎn)分析

秒殺系統(tǒng)的場(chǎng)景特點(diǎn)

  • 秒殺時(shí)大量用戶會(huì)在同一時(shí)間同時(shí)進(jìn)行搶購，網(wǎng)站瞬時(shí)訪問流量激增；

  • 秒殺一般是訪問請(qǐng)求量遠(yuǎn)遠(yuǎn)大于庫存數(shù)量，只有少部分用戶能夠秒殺成功；

  • 秒殺業(yè)務(wù)流程比較簡(jiǎn)單，一般就是下訂單操作；

秒殺架構(gòu)設(shè)計(jì)理念

  • 限流：鑒于只有少部分用戶能夠秒殺成功，所以要限制大部分流量，只允許少部分流量進(jìn)入服務(wù)后端（暫未處理）；

  • 削峰：對(duì)于秒殺系統(tǒng)瞬時(shí)的大量用戶涌入，所以在搶購開始會(huì)有很高的瞬時(shí)峰值。實(shí)現(xiàn)削峰的常用方法有利用緩存或者消息中間件等技術(shù)；

  • 異步處理：對(duì)于高并發(fā)系統(tǒng)，采用異步處理模式可以極大地提高系統(tǒng)并發(fā)量，異步處理就是削峰的一種實(shí)現(xiàn)方式；

  • 內(nèi)存緩存：秒殺系統(tǒng)最大的瓶頸最終都可能會(huì)是數(shù)據(jù)庫的讀寫，主要體現(xiàn)在的磁盤的I/O，性能會(huì)很低，如果能把大部分的業(yè)務(wù)邏輯都搬到緩存來處理，效率會(huì)有極大的提升；

  • 可拓展：如果需要支持更多的用戶或者更大的并發(fā)，將系統(tǒng)設(shè)計(jì)為彈性可拓展的，如果流量來了，拓展機(jī)器就好；

Spring Cloud微服務(wù)實(shí)現(xiàn)秒殺系統(tǒng)

Spring Cloud微服務(wù)實(shí)現(xiàn)秒殺系統(tǒng)

秒殺設(shè)計(jì)思路

  • 由于前端是屬于小程序端，所以不存在前端部分的訪問壓力，所以前端的訪問壓力就無從談起；

  • 1、秒殺相關(guān)的活動(dòng)頁面相關(guān)的接口，所有查詢能加緩存的，全部添加redis的緩存；

  • 2、活動(dòng)相關(guān)真實(shí)庫存、鎖定庫存、限購、下單處理狀態(tài)等全放redis；

  • 3、當(dāng)有請(qǐng)求進(jìn)來時(shí)，首先通過redis原子自增的方式記錄當(dāng)前請(qǐng)求數(shù)，當(dāng)請(qǐng)求超過一定量，比如說庫存的10倍之后，后面進(jìn)入的請(qǐng)求則直接返回活動(dòng)太火爆的響應(yīng)；而能進(jìn)入搶購的請(qǐng)求，則首先進(jìn)入活動(dòng)ID為粒度的分布式鎖，第一步進(jìn)行用戶購買的重復(fù)性校驗(yàn)，滿足條件進(jìn)入下一步，否則返回已下單的提示；

  • 4、第二步，判斷當(dāng)前可鎖定的庫存是否大于購買的數(shù)量，滿足條件進(jìn)入下一步，否則返回已售罄的提示；

  • 5、第三步，鎖定當(dāng)前請(qǐng)求的購買庫存，從鎖定庫存中減除，并將下單的請(qǐng)求放入kafka消息隊(duì)列；

  • 6、第四步，在redis中標(biāo)記一個(gè)polling的key（用于輪詢的請(qǐng)求接口判斷用戶是否下訂單成功），在kafka消費(fèi)端消費(fèi)完成創(chuàng)建訂單之后需要?jiǎng)h除該key，并且維護(hù)一個(gè)活動(dòng)id+用戶id的key，防止重復(fù)購買；

  • 7、第五步，消息隊(duì)列消費(fèi)，創(chuàng)建訂單，創(chuàng)建訂單成功則扣減redis中的真實(shí)庫存，并且刪除polling的key。如果下單過程出現(xiàn)異常，則刪除限購的key，返還鎖定庫存，提示用戶下單失敗；

  • 8、第六步，提供一個(gè)輪詢接口，給前端在完成搶購動(dòng)作后，檢查最終下訂單操作是否成功，主要判斷依據(jù)是redis中的polling的key的狀態(tài)；

  • 9、整個(gè)流程會(huì)將所有到后端的請(qǐng)求攔截的在redis的緩存層面，除了最終能下訂單的庫存限制訂單會(huì)與數(shù)據(jù)庫存在交互外，基本上無其他的交互，將數(shù)據(jù)庫I/O壓力降到了最低；

關(guān)于限流

SpringCloud zuul的層面有很好的限流策略，可以防止同一用戶的惡意請(qǐng)求行為

 1 zuul:
 2     ratelimit:
 3         key-prefix: your-prefix  #對(duì)應(yīng)用來標(biāo)識(shí)請(qǐng)求的key的前綴
 4         enabled: true
 5         repository: REDIS  #對(duì)應(yīng)存儲(chǔ)類型（用來存儲(chǔ)統(tǒng)計(jì)信息）
 6         behind-proxy: true  #代理之后
 7         default-policy: #可選 - 針對(duì)所有的路由配置的策略，除非特別配置了policies
 8              limit: 10 #可選 - 每個(gè)刷新時(shí)間窗口對(duì)應(yīng)的請(qǐng)求數(shù)量限制
 9              quota: 1000 #可選-  每個(gè)刷新時(shí)間窗口對(duì)應(yīng)的請(qǐng)求時(shí)間限制（秒）
10               refresh-interval: 60 # 刷新時(shí)間窗口的時(shí)間，默認(rèn)值 (秒)
11                type: #可選 限流方式
12                     - user
13                     - origin
14                     - url
15           policies:
16                 myServiceId: #特定的路由
17                       limit: 10 #可選- 每個(gè)刷新時(shí)間窗口對(duì)應(yīng)的請(qǐng)求數(shù)量限制
18                       quota: 1000 #可選-  每個(gè)刷新時(shí)間窗口對(duì)應(yīng)的請(qǐng)求時(shí)間限制（秒）
19                       refresh-interval: 60 # 刷新時(shí)間窗口的時(shí)間，默認(rèn)值 (秒)
20                       type: #可選 限流方式
21                           - user
22                           - origin
23                           - url

關(guān)于負(fù)載與分流

當(dāng)一個(gè)活動(dòng)的訪問量級(jí)特別大的時(shí)候，可能從域名分發(fā)進(jìn)來的nginx就算是做了高可用，但實(shí)際上最終還是單機(jī)在線，始終敵不過超大流量的壓力時(shí)，我們可以考慮域名的多IP映射。也就是說同一個(gè)域名下面映射多個(gè)外網(wǎng)的IP，再映射到DMZ的多組高可用的nginx服務(wù)上，nginx再配置可用的應(yīng)用服務(wù)集群來減緩壓力；

這里也順帶介紹redis可以采用redis cluster的分布式實(shí)現(xiàn)方案，同時(shí)springcloud hystrix 也能有服務(wù)容錯(cuò)的效果；

而關(guān)于nginx、springboot的tomcat、zuul等一系列參數(shù)優(yōu)化操作對(duì)于性能的訪問提升也是至關(guān)重要；

補(bǔ)充說明一點(diǎn)，即使前端是基于小程序?qū)崿F(xiàn)，但是活動(dòng)相關(guān)的圖片資源都放在自己的云盤服務(wù)上，所以活動(dòng)前活動(dòng)相關(guān)的圖片資源上傳CDN也是至關(guān)重要，否則哪怕是你IDC有1G的流量帶寬，也會(huì)分分鐘被吃完；

文章標(biāo)題：SpringCloud微服務(wù)實(shí)現(xiàn)秒殺系統(tǒng)
標(biāo)題來源：http://muchs.cn/article44/ghioee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、微信小程序、App開發(fā)、靜態(tài)網(wǎng)站、軟件開發(fā)、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)

小程序開發(fā)