超賣問題

分析秒殺的業(yè)務(wù)場景,最重要的有一點就是超賣問題，假如備貨只有100個，但是最終超賣了200，一般來講秒殺系統(tǒng)的價格都比較低，如果超賣將嚴重影響公司的財產(chǎn)利益，因此首當其沖的就是解決商品的超賣問題。

高并發(fā)

秒殺具有時間短、并發(fā)量大的特點，秒殺持續(xù)時間只有幾分鐘，而一般公司都為了制造轟動效應(yīng)，會以極低的價格來吸引用戶，因此參與搶購的用戶會非常的多。短時間內(nèi)會有大量請求涌進來，后端如何防止并發(fā)過高造成緩存擊穿或者失效，擊垮數(shù)據(jù)庫都是需要考慮的問題。

接口防刷

現(xiàn)在的秒殺大多都會出來針對秒殺對應(yīng)的軟件，這類軟件會模擬不斷向后臺服務(wù)器發(fā)起請求，一秒幾百次都是很常見的，如何防止這類軟件的重復(fù)無效請求，防止不斷發(fā)起的請求也是需要我們針對性考慮的。

秒殺URL

對于普通用戶來講，看到的只是一個比較簡單的秒殺頁面，在未達到規(guī)定時間，秒殺按鈕是灰色的，一旦到達規(guī)定時間，灰色按鈕變成可點擊狀態(tài)。這部分是針對小白用戶的，如果是稍微有點電腦功底的用戶，會通過F12看瀏覽器的network看到秒殺的url，通過特定軟件去請求也可以實現(xiàn)秒殺。或者提前知道秒殺url的人，一請求就直接實現(xiàn)秒殺了。這個問題我們需要考慮解決。

數(shù)據(jù)庫設(shè)計

秒殺有把我們服務(wù)器擊垮的風險，如果讓它與我們的其他業(yè)務(wù)使用在同一個數(shù)據(jù)庫中，耦合在一起，就很有可能牽連和影響其他的業(yè)務(wù)。如何防止這類問題發(fā)生，就算秒殺發(fā)生了宕機、服務(wù)器卡死問題，也應(yīng)該讓他盡量不影響線上正常進行的業(yè)務(wù)。

秒殺系統(tǒng)的數(shù)據(jù)庫設(shè)計

針對秒殺的數(shù)據(jù)庫問題，應(yīng)該單獨設(shè)計一個秒殺數(shù)據(jù)庫，防止因為秒殺活動的高并發(fā)訪問拖垮整個網(wǎng)站。這里只需要兩張表，一張是秒殺訂單表，一張是秒殺貨品表：

其實應(yīng)該還有幾張表，商品表：可以關(guān)聯(lián)goods_id查到具體的商品信息，商品圖像、名稱、平時價格、秒殺價格等，還有用戶表：根據(jù)用戶user_id可以查詢到用戶昵稱、用戶手機號，收貨地址等其他額外信息，這個具體就不給出實例了。

秒殺URL的設(shè)計

為了避免有程序訪問經(jīng)驗的人通過下單頁面url直接訪問后臺接口來秒殺貨品，我們需要將秒殺的url實現(xiàn)動態(tài)化，即使是開發(fā)整個系統(tǒng)的人都無法在秒殺開始前知道秒殺的url。具體的做法就是通過md5加密一串隨機字符作為秒殺的url，然后前端訪問后臺獲取具體的url，后臺校驗通過之后才可以繼續(xù)秒殺。

秒殺頁面靜態(tài)化

將商品的描述、參數(shù)、成交記錄、圖像、評價等全部寫入到一個靜態(tài)頁面，用戶請求不需要通過訪問后端服務(wù)器，不需要經(jīng)過數(shù)據(jù)庫，直接在前臺客戶端生成，這樣可以最大可能的減少服務(wù)器的壓力。具體的方法可以使用freemarker模板技術(shù)，建立網(wǎng)頁模板，填充數(shù)據(jù)，然后渲染網(wǎng)頁。

單體redis升級為集群redis

秒殺是一個讀多寫少的場景，使用redis做緩存再合適不過。不過考慮到緩存擊穿問題，我們應(yīng)該構(gòu)建redis集群，或采用哨兵模式，可以提升redis的性能和可用性。

使用nginx

nginx是一個高性能web服務(wù)器，它的并發(fā)能力可以達到幾萬，而tomcat只有幾百。通過nginx映射客戶端請求，再分發(fā)到后臺tomcat服務(wù)器集群中可以大大提升并發(fā)能力。

精簡SQL

典型的一個場景是在進行扣減庫存的時候，傳統(tǒng)的做法是先查詢庫存，再去update。這樣的話需要兩個sql，而實際上一個sql我們就可以完成的。可以用這樣的做法：update miaosha_goods set stock=stock-1 where goos_id={#goods_id} and version=#{version} and sock>0; 。這樣的話，就可以保證庫存不會超賣并且一次更新庫存,還有注意一點這里使用了版本號的樂觀鎖，相比較悲觀鎖，它的性能較好。

redis預(yù)減庫存

很多請求進來，都需要后臺查詢庫存,這是一個頻繁讀的場景。可以使用redis來預(yù)減庫存，在秒殺開始前可以在redis設(shè)值，比如 redis.set(goodsId,100)，這里預(yù)放的庫存為100可以設(shè)值為常量)，每次下單成功之后，Integer stock = (Integer)redis.get(goosId); 然后判斷sock的值，如果小于常量值就減去1。不過注意當取消的時候,需要增加庫存，增加庫存的時候也得注意不能大于之間設(shè)定的總庫存數(shù)(查詢庫存和扣減庫存需要原子操作，此時可以借助lua腳本)下次下單再獲取庫存的時候,直接從redis里面查就可以了。

接口限流

秒殺最終的本質(zhì)是數(shù)據(jù)庫的更新，但是有很多大量無效的請求，我們最終要做的就是如何把這些無效的請求過濾掉，防止?jié)B透到數(shù)據(jù)庫。限流的話，需要入手的方面很多：

• 前端限流：首先第一步就是通過前端限流，用戶在秒殺按鈕點擊以后發(fā)起請求，那么在接下來的5秒是無法點擊（通過設(shè)置按鈕為disable）。這一小舉措開發(fā)起來成本很小，但是很有效。
• 同一個用戶x秒內(nèi)重復(fù)請求直接拒絕：具體多少秒需要根據(jù)實際業(yè)務(wù)和秒殺的人數(shù)而定，一般限定為10秒。具體的做法就是通過redis的鍵過期策略，首先對每個請求都從String value = redis.get(userId);。如果獲取到這個value為空或者為null，表示它是有效的請求，然后放行這個請求。如果不為空表示它是重復(fù)性請求，直接丟掉這個請求。如果有效,采用redis.setexpire(userId,value,10).value 可以是任意值，一般放業(yè)務(wù)屬性比較好,這個是設(shè)置以userId為key，10秒的過期時間（10秒后,key對應(yīng)的值自動為null）。
• 令牌桶算法限流：接口限流的策略有很多，我們這里采用令牌桶算法。令牌桶算法的基本思路是每個請求嘗試獲取一個令牌，后端只處理持有令牌的請求，生產(chǎn)令牌的速度和效率我們都可以自己限定。

異步下單

為了提升下單的效率，并且防止下單服務(wù)的失敗。需要將下單這一操作進行異步處理。最常采用的辦法是使用隊列，隊列最顯著的三個優(yōu)點：異步、削峰、解耦。這里可以采用rabbitmq，在后臺經(jīng)過了限流、庫存校驗之后，流入到這一步驟的就是有效請求。然后發(fā)送到隊列里，隊列接受消息，異步下單。下完單，入庫沒有問題可以用短信通知用戶秒殺成功。假如失敗的話，可以采用補償機制，重試。

服務(wù)降級

假如在秒殺過程中出現(xiàn)了某個服務(wù)器宕機，或者服務(wù)不可用，應(yīng)該做好后備工作。之前的博客里有介紹通過Hystrix進行服務(wù)熔斷和降級，可以開發(fā)一個備用服務(wù)，假如服務(wù)器真的宕機了，直接給用戶一個友好的提示返回，而不是直接卡死，服務(wù)器錯誤等生硬的反饋。

帶掃描階段

待掃描階段也就是流程圖中 1~5 階段，即生成二維碼階段，這個階段跟移動端沒有關(guān)系，是 PC 端跟服務(wù)端的交互過程。

首先 PC 端攜帶設(shè)備信息想服務(wù)端發(fā)起生成二維碼請求，服務(wù)端會生成唯一的二維碼 ID，你可以理解為 UUID，并且將 二維碼 ID 跟 PC 設(shè)備信息關(guān)聯(lián)起來，這跟移動端登錄有點相似。

PC 端接受到二維碼 ID 之后，將二維碼 ID 以二維碼的形式展示，等待移動端掃碼。此時在 PC 端會啟動一個定時器，輪詢查詢二維碼的狀態(tài)。如果移動端未掃描的話，那么一段時間后二維碼將會失效。

已掃碼待確認階段

流程圖中第 6 ~ 10 階段，我們在 PC 端登錄微信時，手機掃碼后，PC 端的二維碼會變成已掃碼，請在手機端確認。這個階段是移動端跟服務(wù)端交互的過程。

首先移動端掃描二維碼，獲取二維碼 ID，然后將手機端登錄的信息憑證（token）和 二維碼 ID 作為參數(shù)發(fā)送給服務(wù)端，此時的手機一定是登錄的，不存在沒登錄的情況。

服務(wù)端接受請求后，會將 token 與二維碼 ID 關(guān)聯(lián)，為什么需要關(guān)聯(lián)呢？你想想，我們使用微信時，移動端退出， PC 端是不是也需要退出，這個關(guān)聯(lián)就有點把子作用了。然后會生成一個一次性 token，這個 token 會返回給移動端，一次性 token 用作確認時候的憑證。

已確認

流程圖中的 第 11 ~ 15 步驟，這是掃碼登錄的最后階段，移動端攜帶上一步驟中獲取的臨時 token ，確認登錄，服務(wù)端校對完成后，會更新二維碼狀態(tài)，并且給 PC 端生成一個正式的 token ，后續(xù) PC 端就是持有這個 token 訪問服務(wù)端。

PC 端的定時器，輪詢到了二維碼狀態(tài)為登錄狀態(tài)，并且會獲取到了生成的 token ，完成登錄，后續(xù)訪問都基于 token 完成。

在服務(wù)器端會跟手機端一樣，維護著 token 跟二維碼、PC 設(shè)備信息、賬號等信息。

數(shù)據(jù)結(jié)構(gòu)

首要考慮的就是數(shù)據(jù)該如何存儲，用什么數(shù)據(jù)結(jié)構(gòu)存儲。最簡單的就直接用Map來存儲數(shù)據(jù)，或者復(fù)雜的如redis一樣提供了多種數(shù)據(jù)類型哈希，列表，集合，有序集合等，底層使用了雙端鏈表，壓縮列表，集合，跳躍表等數(shù)據(jù)結(jié)構(gòu)。

對象上限

因為是本地緩存，內(nèi)存有上限，所以一般都會指定緩存對象的數(shù)量比如1024，當達到某個上限后需要有某種策略去刪除多余的數(shù)據(jù)。

清除策略

上面說到當達到對象上限之后需要有清除策略，常見的比如有LRU(最近最少使用)、FIFO(先進先出)、LFU(最近最不常用)、SOFT(軟引用)、WEAK(弱引用)等策略。

過期時間

除了使用清除策略，一般本地緩存也會有一個過期時間設(shè)置，比如redis可以給每個key設(shè)置一個過期時間，這樣當達到過期時間之后直接刪除，采用清除策略+過期時間雙重保證。

線程安全

像redis是直接使用單線程處理，所以就不存在線程安全問題。而我們現(xiàn)在提供的本地緩存往往是可以多個線程同時訪問的，所以線程安全是不容忽視的問題，并且線程安全問題是不應(yīng)該拋給使用者去保證。

簡明的接口

提供一個傻瓜式的對外接口是很有必要的，對使用者來說使用此緩存不是一種負擔而是一種享受，提供常用的get，put，remove，clear，getSize等方法即可。

是否持久化

這個其實不是必須的，是否需要將緩存數(shù)據(jù)持久化看需求。本地緩存如ehcache是支持持久化的，而guava是沒有持久化功能的。分布式緩存如redis是有持久化功能的，memcached是沒有持久化功能的。

阻塞機制

簡明的接口

提供一個傻瓜式的對外接口是很有必要的，對使用者來說使用此緩存不是一種負擔而是一種享受，提供常用的get，put，remove，clear，getSize等方法即可。

是否持久化

這個其實不是必須的，是否需要將緩存數(shù)據(jù)持久化看需求。本地緩存如ehcache是支持持久化的，而guava是沒有持久化功能的。分布式緩存如redis是有持久化功能的，memcached是沒有持久化功能的。

阻塞機制

我們使用緩存的目的就是因為被緩存的數(shù)據(jù)生成比較費時，比如調(diào)用對外的接口，查詢數(shù)據(jù)庫，計算量很大的結(jié)果等等。這時候如果多個線程同時調(diào)用get方法獲取的結(jié)果都為null，每個線程都去執(zhí)行一遍費時的計算，其實也是對資源的浪費。最好的辦法是只有一個線程去執(zhí)行，其他線程等待，計算一次就夠了。但是此功能基本上都交給使用者來處理，很少有本地緩存有這種功能。