2023-03-22 21:15 已編輯門頭溝學(xué)院 Java 發(fā)布于江蘇

關(guān)注

秒殺項目常見問題

1.講一下你這個高并發(fā)搶購系統(tǒng)(秒殺)

是什么，用了什么（Redis、動靜分離、隱藏鏈接、限流、削峰），壓測結(jié)果

這個系統(tǒng)主要是模擬秒殺活動，實(shí)現(xiàn)一個支持高并發(fā)的服務(wù)。

為了解決高并發(fā)帶來的問題，我用Redis實(shí)現(xiàn)了緩存預(yù)熱、預(yù)減庫存的功能，通過使用Nginx實(shí)現(xiàn)動靜分離來降低服務(wù)器的壓力，加快用戶訪問速度。隱藏了秒殺接口地址，防止用戶提前知道秒殺地址。還通過輸入驗(yàn)證碼的方式防止惡意秒殺，同時還起到了削峰的作用。最后通過Jmeter壓力測試，QPS從最初的150/s提升到2000/s左右。

2.秒殺中如何處理超賣問題？

在定時上架秒殺商品時，使用分布式信號量作為商品的庫存緩存到Redis中，當(dāng)活動開始接收到秒殺請求時，在Redis中進(jìn)行預(yù)減庫存，如果Redis中的庫存不足時，直接返回秒殺失??；如果有庫存，就將請求放入異步隊列中，給用戶返回一個秒殺成功，正在創(chuàng)建訂單，然后訂單服務(wù)監(jiān)聽這個隊列，生成秒殺訂單，減少數(shù)據(jù)庫庫存等一系列操作。

3.秒殺中如何解決重復(fù)下單問題？(普通訂單也一樣操作)

mysql唯一索引（商品索引）+ 分布式鎖

4.熱點(diǎn)數(shù)據(jù)失效（緩存擊穿）問題如何解決？

因?yàn)槊恳粓龅拿霘⒒顒映掷m(xù)的時間都是確定的嘛，所以可以把熱點(diǎn)數(shù)據(jù)的過期時間設(shè)置的跟活動持續(xù)時間一樣，這樣活動一結(jié)束，熱點(diǎn)數(shù)據(jù)自己就刪除了，也不會導(dǎo)致在活動期間數(shù)據(jù)就失效了。

5.Redis緩存和數(shù)據(jù)庫數(shù)據(jù)一致性如何保證？

使用canal組件實(shí)現(xiàn)（canal的原理，模擬MySQL的主從復(fù)制機(jī)制）
更新數(shù)據(jù)庫后立即刪緩存，然后下一次查緩存找不到數(shù)據(jù)后會再次從數(shù)據(jù)庫同步到緩存。

6.★減庫存成功了，但是生成訂單失敗了，該怎么辦？(分布式事務(wù)的數(shù)據(jù)一致性問題)

使用mq來解決這個問題。如果扣減庫存成功了但是下單失敗了，訂單服務(wù)就給mq發(fā)送一個消息，然后庫存服務(wù)就來監(jiān)聽這個mq，如果能從mq中拿到消息說明訂單失敗了，然后就進(jìn)行回滾操作。

【tips】seata雖然能控制分布式事務(wù)，但是不適合高并發(fā)，像下訂單就是一個高并發(fā)操作，所以我們不用seata來實(shí)現(xiàn)下訂單的分布式事務(wù)。因?yàn)閟eata實(shí)現(xiàn)分布式事務(wù)需要加鎖，一加鎖相當(dāng)于把高并發(fā)變成串行化了。

7.做了什么限流削峰的措施？

（1）點(diǎn)擊秒殺按鈕以后要先填一個驗(yàn)證碼（前端）；

（2）在定時上架秒殺商品時，使用分布式信號量作為商品的庫存緩存到Redis中，當(dāng)活動開始接收到秒殺請求時，在Redis中進(jìn)行預(yù)減庫存，如果Redis中的庫存不足時，直接返回秒殺失?。?/span>

8.如何解決客戶的惡意下單問題？

如果客戶想偽造請求來快速秒殺，通過我們的鏈接加密可以實(shí)現(xiàn)。

使用腳本的惡意請求可以用驗(yàn)證碼來解決。

9.多機(jī)器扣減庫存，如何保證它的線程安全的？

用redission實(shí)現(xiàn)分布式鎖。在扣減庫存前，先獲取分布式鎖getLock()，然后上鎖lock，再進(jìn)行扣減，最后再釋放鎖。

（1）如果扣減失敗，沒有釋放鎖會導(dǎo)致什么情況？怎么解決？

會造成死鎖。

給鎖設(shè)置過期時間，防止出意外釋放不了鎖造成死鎖。

（2）怎么保證釋放的就是自己的鎖？

在getLock時可以給鎖一個名字，只要名字一樣就是同一把鎖。

10.如何去減Redis中的庫存？

在秒殺系統(tǒng)中Redis中的商品庫存是用分布式信號量存的，通過tryAcquire()來獲取信號量，獲取信號量的操作就相當(dāng)于扣減了庫存。

【tips】tryAcquire()是不阻塞的，tryAcquire()不傳參是獲取一個信號量，tryAcquire(int n)是獲取n個信號量(有這么多的話)。

11.緩存中的數(shù)據(jù)突然失效，導(dǎo)致請求全部打到了數(shù)據(jù)庫，如何解決？

(典型的緩存雪崩問題)

給緩存中的數(shù)據(jù)的過期時間加隨機(jī)數(shù)。

12.如果項目中的Redis掛掉，如何減輕數(shù)據(jù)庫的壓力？

可以搭建redis集群，通過哨兵機(jī)制來監(jiān)控主節(jié)點(diǎn)，如果主節(jié)點(diǎn)掛了就從從節(jié)點(diǎn)中選一個新的主節(jié)點(diǎn)，實(shí)現(xiàn)故障轉(zhuǎn)移。

13.頁面靜態(tài)化

那就把能提前放入cdn服務(wù)器的東西都放進(jìn)去，反正把所有能提升效率的步驟都做一下，減少真正秒殺時候服務(wù)器的壓力。

14.秒殺系統(tǒng)面臨的問題有哪些？

高并發(fā)、腳本惡意請求、加了緩存之后的緩存三大問題（擊穿、穿透、雪崩）。

15.秒殺系統(tǒng)如何設(shè)計？

獨(dú)立部署+動靜分離+限流+熔斷降級+緩存預(yù)熱+異步訂單+秒殺鏈接加密。

（1）獨(dú)立部署

把秒殺系統(tǒng)單獨(dú)作為一個微服務(wù)，這樣一旦秒殺系統(tǒng)實(shí)在頂不住了，也不會影響其他服務(wù)。

（2）動靜分離

使用Nginx實(shí)現(xiàn)動靜分離，讓靜態(tài)資源從nginx直接返回，減輕服務(wù)器的壓力。

（3）限流

前端限流+后端限流。

前端可以使用一個驗(yàn)證碼，通過手速快慢可以進(jìn)行一部分限流，還可以過濾機(jī)器人的惡意請求。

后端可以使用sentinel在網(wǎng)關(guān)設(shè)置一些限流規(guī)則，比如url必須正確；還可以用分布式信號量，在Redis中保存用分布式信號量代替庫存，搶不到信號量就不用去查數(shù)據(jù)庫了。

（4）熔斷降級

如果出現(xiàn)問題，給前端返回一個快速失敗的提示，將用戶引導(dǎo)到一個降級頁面，這樣可以保證整個調(diào)用鏈不是阻塞的。

（5）緩存預(yù)熱

使用定時任務(wù)在每天凌晨三點(diǎn)上架要秒殺的商品，將商品信息提前保存到Redis中。

（6）異步訂單
秒殺成功后發(fā)送消息給mq然后給用戶返回"秒殺成功，正在創(chuàng)建訂單"，讓訂單服務(wù)監(jiān)聽mq，然后異步進(jìn)行訂單創(chuàng)建、扣減庫存等操作，這樣可以防止一條秒殺請求阻塞等待訂單完成才給用戶返回結(jié)果。

（7）秒殺鏈接加密

緩存商品數(shù)據(jù)時給每個商品隨機(jī)生成一個uuid，在發(fā)送秒殺請求時，必須保證請求帶上skuId和這個隨機(jī)碼才能進(jìn)來。

16.分布式會話問題?

在實(shí)現(xiàn)用戶社交登錄時，發(fā)現(xiàn)有時候已經(jīng)登錄過了但是系統(tǒng)還是會提示去登錄，后來發(fā)現(xiàn)是session和cookie的問題，這個問題其實(shí)是在分布式下session不能共享的問題。用戶第一次登錄時把登錄信息放在session里(session.setAttribute("sessionName",value))，然后把session保存在服務(wù)器里，并把token返回給瀏覽器的cookie，這樣用戶第二次請求時就帶著有token的cookie，服務(wù)器就認(rèn)為已經(jīng)登陸過了。但是在分布式下會存在一些問題，首先這個過程只能在當(dāng)前域名下(同一微服務(wù))起作用，其次如果有多臺服務(wù)器的話，兩次請求轉(zhuǎn)發(fā)到不同的服務(wù)器，即使是同一服務(wù)也不能共享session數(shù)據(jù)。

解決方案是通過SpringSession，自定義一個cookie的序列化器，先將作用域擴(kuò)大到整個項目(setDomainName())。同時在用戶第一次登錄時，將session都存到Redis里，讓所有服務(wù)都去Redis里根據(jù)sessionId去獲取對應(yīng)的session，

然后通過設(shè)置cookie跨域分享以及利用redis存儲token信息得以解決。

17.線程池的執(zhí)行過程？

當(dāng)任務(wù)進(jìn)來后，會先判斷線程池中的核心線程數(shù)是否小于corePoolSize，如果小于的話會直接創(chuàng)建一個核心線程去處理任務(wù)；如果大于說明沒有核心線程了，就將任務(wù)放入阻塞隊列中等待。如果核心線程和阻塞隊列都滿了，就創(chuàng)建非核心線程，去處理阻塞隊列中的任務(wù)。當(dāng)線程數(shù)達(dá)到了maximumPoolSize并且阻塞隊列也滿了，就會采用拒絕策略來處理任務(wù)。

18.你項目中的難點(diǎn)是什么？

（1）Feign遠(yuǎn)程調(diào)用丟失請求頭問題

在進(jìn)行遠(yuǎn)程調(diào)用時cookie需要帶上sessionId，來標(biāo)注用戶登錄狀態(tài)的session，但是發(fā)現(xiàn)還是提示要先登錄，而且cookie中并沒有sessionId。后來查了資料發(fā)現(xiàn)feign在遠(yuǎn)程調(diào)用時會先構(gòu)造一個新的請求，而這個新請求里面并沒有請求頭，所以導(dǎo)致沒有攜帶sessionId。

解決：feign在構(gòu)造請求之前可以經(jīng)過請求攔截器(RequestInterceptor)，通過攔截器的apply方法可以給請求加一些東西，但是默認(rèn)情況下是沒有攔截器的，那么我們就可以自己定義一個RequestIterceptor并重寫apply方法，通過RequestContextHolder來獲取原來請求中的sessionId，然后讓后面feign構(gòu)造的新請求攜帶上sessionId。

（2）用戶登錄的問題（分布式session）

在實(shí)現(xiàn)用戶社交登錄時，發(fā)現(xiàn)有時候已經(jīng)登錄過了但是系統(tǒng)還是會提示去登錄，后來發(fā)現(xiàn)是session和cookie的問題。用戶第一次登錄時把登錄信息放在session里(session.setAttribute("sessionName",value))，然后把session保存在服務(wù)器里，并把token返回給瀏覽器的cookie，這樣用戶第二次請求時就帶著有token的cookie，服務(wù)器就認(rèn)為已經(jīng)登陸過了。但是在分布式下會存在一些問題，首先這個過程只能在當(dāng)前域名下(同一微服務(wù))起作用，其次如果有多臺服務(wù)器的話，兩次請求轉(zhuǎn)發(fā)到不同的服務(wù)器，即使是同一服務(wù)也不能共享session數(shù)據(jù)。

19.項目中Redis都做了些什么？

（1）在項目中用Redis保存購物車數(shù)據(jù)；

（2）通過令牌機(jī)制實(shí)現(xiàn)接口的冪等性，將token保存在Redis中；

（3）在實(shí)現(xiàn)社交登錄時，將session存在Redis中來解決session共享問題；

（4）在實(shí)現(xiàn)秒殺時，將秒殺商品信息緩存到Redis中。

20.項目中RabbitMQ都做了什么？

作為異步下單的中間件，實(shí)現(xiàn)解鎖庫存和定時關(guān)單。

（1）解鎖庫存

(超時未支付、用戶自己取消訂單、鎖完庫存但是其他遠(yuǎn)程調(diào)用失敗了導(dǎo)致的訂單回滾都要解鎖庫存)

當(dāng)需要解鎖庫存的時候，比如說訂單回滾了，就給交換機(jī)發(fā)送一個消息，然后交換機(jī)根據(jù)路由鍵轉(zhuǎn)發(fā)給解鎖mq，庫存解鎖服務(wù)監(jiān)聽到這個消息以后，就根據(jù)消息進(jìn)行庫存解鎖的操作?！梢陨婕暗?strong>方法重載

【庫存工作單表】記錄了庫存鎖了多少，是哪個訂單鎖的，方便回滾。

（2）定時關(guān)單

當(dāng)訂單創(chuàng)建成功了，就給交換機(jī)發(fā)送(rabbitTemplate.convertAndSend())一個消息(訂單實(shí)體對象)，然后交換機(jī)根據(jù)路由鍵將消息轉(zhuǎn)發(fā)到延遲隊列，延遲隊列設(shè)置了30min的過期時間，當(dāng)30分鐘一過，延遲隊列會把過期的消息，再發(fā)給交換機(jī)，由交換機(jī)轉(zhuǎn)發(fā)給關(guān)單的消息隊列，由關(guān)單服務(wù)進(jìn)行監(jiān)聽，關(guān)單服務(wù)拿到消息以后要先判斷訂單狀態(tài)，如果是待支付狀態(tài)，就進(jìn)行關(guān)單，把訂單狀態(tài)設(shè)置為已取消；如果是其他狀態(tài)就不用操作了。

21.線程池技術(shù)中核心線程數(shù)的取值有經(jīng)驗(yàn)值嗎？

CPU密集型業(yè)務(wù)：N+1
IO密集型業(yè)務(wù)：2N

22.TPS(每秒處理的事務(wù))提升了多少？如何提高tps?

基礎(chǔ)架構(gòu)下的tps是200，經(jīng)過做動靜分離、引入redis緩存、nginx反向代理（集群）后達(dá)到了2000左右。

23.一個人同時用電腦和手機(jī)去搶購商品，會頒發(fā)幾個token？

（多臺設(shè)備登錄屬于SSO問題，用戶登錄一端之后另外一端可以通過掃碼等形式登錄。）

雖然用戶登錄了多臺設(shè)備，但是用戶名是一樣的，所以為用戶頒發(fā)的token是相同的，只會頒發(fā)一個token。

24.線程池的拒絕策略能詳細(xì)說一下嗎？

AbortPolicy：直接丟棄任務(wù)，并拋出RejectedExecutionException拒絕執(zhí)行異常；
DiscardPolicy：丟棄(discard)任務(wù)，但是不拋出異常；
DiscardOldestPolicy：丟棄位于阻塞隊列最前面的任務(wù)（也就是最早進(jìn)來的任務(wù)），然后重新提交被拒絕的任務(wù)；
CallerRunsPolicy：由提交任務(wù)的線程處理該任務(wù)。

25.被線程池拒絕掉的那部分用戶的秒殺令牌還有效嗎？

無效，會從redis中刪除，當(dāng)該用戶再去秒殺搶購時，需要重新獲取秒殺令牌。

26.線程池中阻塞隊列的大小設(shè)置為多少合適？

設(shè)置為（秒殺商品的個數(shù) - 核心線程數(shù)）。這樣的話所有秒殺任務(wù)最終都可以被處理，而不會說明明有庫存，用戶秒殺了但是隊列滿了導(dǎo)致秒殺任務(wù)被丟失了。

27.項目上線之后想看JVM的GC情況在Linux中用什么命令？

jstat -gc vmid count // jstat-統(tǒng)計jvm信息的指令
jstat -gc 12538 5000 // 表示將12538進(jìn)程對應(yīng)的Java進(jìn)程的GC情況，每5秒打印一次

29.能不能詳細(xì)描述一下使用MQ異步減redis與MySQL庫存的過程？

redis中的庫存減成功后，生成一條消息，包含了商品信息(包含了庫存信息)和用戶信息，然后將消息發(fā)送給交換機(jī)；交換機(jī)轉(zhuǎn)發(fā)到生成訂單服務(wù)監(jiān)聽的隊列，然后該服務(wù)會消費(fèi)這條消息，根據(jù)商品信息和用戶信息創(chuàng)建一條訂單，并修改數(shù)據(jù)庫中對應(yīng)商品的庫存。

30.做到了什么程度、庫存量與并發(fā)度是多少？

QPS：單機(jī)2000/s

31.秒殺系統(tǒng)中MySQL中的表是怎么設(shè)計的？

秒殺用戶表、商品信息表、秒殺商品表（記錄該商品的秒殺始末時間，秒殺價和剩余量）、秒殺訂單表（記錄了秒殺用戶名和秒殺的商品還有訂單號）、訂單詳情表（通過秒殺訂單號來查找對應(yīng)的訂單詳情，里面記載更詳實(shí)的業(yè)務(wù)信息）。

32.如何只使用MySQL保證商品沒有超賣？

將查庫存、減庫存兩個sql語句作為一個事務(wù)進(jìn)行控制，保證每一個庫存只能被一個用戶消費(fèi)。兩條語句都執(zhí)行成功進(jìn)行事務(wù)提交，否則回滾。

缺點(diǎn)：低并發(fā)。

33.數(shù)據(jù)庫改庫存的SQL？

update table set stock = stock-1 where sku_id = ? and stock > 1;

34.如何防止用戶一直點(diǎn)擊下單按鈕？（防止重復(fù)下單、冪等性問題）

前端限制：一次點(diǎn)擊之后按鈕置灰?guī)酌腌姟?br /> 后端限制：由于秒殺令牌的設(shè)置，用戶的一個下單請求會先判斷用戶當(dāng)前是否已經(jīng)持有令牌了，因?yàn)橛脩羧种荒塬@取一次令牌，然后存入到Redis緩存中。用戶有令牌的話直接返回 “正在搶購中”。

35.定時任務(wù)的框架選型？為什么選Quartz？

我了解的實(shí)現(xiàn)定時任務(wù)的方法有Java自帶的，比如Timer和ScheduledExecutor，還有Quartz，我在項目中用的就是Quartz。

Timer是通過創(chuàng)建一個TimerTask，實(shí)現(xiàn)自己的run方法，然后通過Timer調(diào)用schedule方法來調(diào)度這個任務(wù)，可以指定延遲一段時間后再調(diào)度。Timer的缺點(diǎn)就是所有的任務(wù)都是用一個線程來調(diào)度的，也就是說這些任務(wù)是串行執(zhí)行，不適合用在分布式中。
ScheduledExecutor是基于線程池設(shè)計的，每一個調(diào)度的任務(wù)都由線程池中的一個線程去執(zhí)行，所以說這些任務(wù)時并發(fā)執(zhí)行的。但是ScheduledExecutor只能實(shí)現(xiàn)基于開始時間與重復(fù)間隔定時任務(wù)，像設(shè)置每天3點(diǎn)執(zhí)行一個任務(wù)就實(shí)現(xiàn)不了了，所以也不滿足我的需求。
Quartz支持分布式調(diào)度任務(wù)，可以通過Cron表達(dá)式來實(shí)現(xiàn)更復(fù)雜的定時任務(wù)。
怎么使用Quartz？
使用異步執(zhí)行定時任務(wù)，來保證定時任務(wù)不阻塞。默認(rèn)是阻塞的，需要等待上一次任務(wù)執(zhí)行完才能執(zhí)行下一個。因?yàn)槟J(rèn)情況下，定時任務(wù)線程池只設(shè)置了一個線程。
首先要在配置類上@EnableSchedule開啟定時任務(wù)功能，用@EnableAsync開啟異步。然后創(chuàng)建一個調(diào)度類，在里面調(diào)用定時上架商品的業(yè)務(wù)邏輯(service)，在方法的上面用@Scheduled注解標(biāo)注每天3點(diǎn)的cron表達(dá)式。

36.定時上架商品的流程？

一到我們指定的時間，會先遠(yuǎn)程調(diào)用優(yōu)惠服務(wù)，查出最近三天的秒殺活動(select * from 秒殺活動表 where starttime between xxx and xxx；)，如果能查到最近三天的秒殺活動，再查活動關(guān)聯(lián)的秒殺商品信息。然后把活動場次和商品信息緩存到Redis，同時用分布式信號量作為庫存進(jìn)行扣減，只要有一個秒殺請求進(jìn)來信號量就減1，減到0就說明沒庫存了。