主要內(nèi)容

• 數(shù)據(jù)庫(kù)設(shè)計(jì)
• 明文密碼兩次MD5處理
• JSR303參數(shù)檢驗(yàn)+全局異常處理
• 分布式Session

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

• 不做注冊(cè)，直接登錄，在MySQL中直接創(chuàng)建表
• 用戶表包括id、nickname、password、salt、頭像、注冊(cè)時(shí)間、上次登錄時(shí)間、登錄次數(shù)等字段

對(duì)登錄密碼進(jìn)行兩次MD5：細(xì)節(jié)描述

• 加密的目的：第一次是因?yàn)閔ttp是明文傳輸?shù)?#xff0c;第二次為了防止數(shù)據(jù)庫(kù)被盜

JSR303參數(shù)檢驗(yàn)

• 通過(guò)對(duì)輸入的參數(shù)LoginVo加注解@validated，然后在傳入的參數(shù)mobile和password上加上注解判斷，如@NotNull判斷是否為空，也可以自定義
• 全局異常處理

分布式Session？

• 數(shù)據(jù)庫(kù)設(shè)計(jì)
• 商品列表頁(yè)
• 商品詳情頁(yè)
• 訂單詳情頁(yè)

商品詳情頁(yè)

訂單詳情頁(yè)

內(nèi)容

• 頁(yè)面緩存+URL緩存+對(duì)象緩存
• 頁(yè)面靜態(tài)化，前后端分離
• 靜態(tài)資源優(yōu)化
• CDN優(yōu)化

頁(yè)面緩存+URL緩存+對(duì)象緩存

• 秒殺的瓶頸在于數(shù)據(jù)庫(kù)，所以要加上各種粒度的緩存，最大的是頁(yè)面緩存、最小的是對(duì)象緩存
• 頁(yè)面緩存步驟（這里指的是商品列表）：
  • 從redisService中取緩存
  • 若緩存中沒(méi)有則手動(dòng)渲染，利用thymeleaf模板
  • 然后將頁(yè)面加入緩存，并返回渲染頁(yè)面
  • 不宜時(shí)間太長(zhǎng)，設(shè)置為60s即可
• URL緩存（指的是商品詳情頁(yè)）
  • 與頁(yè)面緩存步驟基本一致，但是需要取緩存和加緩存時(shí)要加入?yún)?shù)，GoodsId
• 對(duì)象緩存（指的是User對(duì)象）
  • 前面的頁(yè)面緩存和URL緩存適合變化不大的，緩存時(shí)間比較短
  • 對(duì)象緩存是長(zhǎng)期緩存，所以需要有個(gè)更新的步驟
  • 第一步是取緩存
  • 若緩存中沒(méi)有則去數(shù)據(jù)庫(kù)中查找，并加入緩存；如數(shù)據(jù)庫(kù)中沒(méi)有就報(bào)錯(cuò)
  • 更新用戶的密碼
• 加緩存之后的QPS大概3000
• 需要先更新數(shù)據(jù)庫(kù)，后刪除緩存；順序不能反，會(huì)導(dǎo)致數(shù)據(jù)不一致：若線程1先刪除緩存，然后線程2讀操作，發(fā)現(xiàn)緩存中沒(méi)有，把數(shù)據(jù)庫(kù)中的舊數(shù)據(jù)加入緩存，然后線程1更新數(shù)據(jù)庫(kù)，就會(huì)導(dǎo)致緩存與數(shù)據(jù)庫(kù)數(shù)據(jù)不一致

頁(yè)面靜態(tài)化，前后端分離

• 頁(yè)面靜態(tài)化無(wú)非就是使用純html頁(yè)面+Ajax請(qǐng)求json數(shù)據(jù)后再填充頁(yè)面
• 若A頁(yè)面跳轉(zhuǎn)到B頁(yè)面之前需要條件判斷可以先在A頁(yè)面中利用ajax請(qǐng)求判斷后再跳轉(zhuǎn)
• 如果不需要條件判斷可以直接跳轉(zhuǎn)到B的靜態(tài)頁(yè)面，讓B自己用ajax請(qǐng)求數(shù)據(jù)

防超賣

• 發(fā)生在減庫(kù)存的時(shí)候
• 解決方法是在Update語(yǔ)句中加一個(gè)判斷

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-pBQCw6T3-1596466141006)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/752fa7ac-cacc-4761-90a7-36803e689e22/Untitled.png)]

• 還有一種情況是一個(gè)用戶同時(shí)發(fā)了兩個(gè)請(qǐng)求，假如庫(kù)存充足，且沒(méi)有訂單生成，那么就會(huì)減兩次庫(kù)存
• 解決辦法是建立用戶和商品的唯一索引
• 做到以上兩點(diǎn)是不會(huì)發(fā)生超賣的

CDN優(yōu)化

內(nèi)容

• Redis預(yù)減庫(kù)存減少數(shù)據(jù)庫(kù)訪問(wèn)
• 內(nèi)存標(biāo)記減少Redis訪問(wèn)
• RabbitMQ隊(duì)列緩沖，異步下單，增強(qiáng)用戶體驗(yàn)
• RabbitMQ安裝與Spring Boot集成
• 訪問(wèn)Nginx水平擴(kuò)展
• 壓測(cè)

思路：減少數(shù)據(jù)庫(kù)訪問(wèn)

• 系統(tǒng)初始化，把商品庫(kù)存數(shù)量加載到Redis中
• 收到請(qǐng)求，Redis預(yù)減庫(kù)存，庫(kù)存不足，直接返回，否則進(jìn)入3
• 請(qǐng)求入隊(duì)，立即返回排隊(duì)中
• 請(qǐng)求出隊(duì)，生成訂單，減少庫(kù)存
• 客戶端輪詢，是否秒殺成功

優(yōu)化思路

• 系統(tǒng)初始化，把商品庫(kù)存數(shù)量加載到Redis
• 收到請(qǐng)求，Redis預(yù)減庫(kù)存，庫(kù)存不足，直接返回，否則進(jìn)入3
• 請(qǐng)求入隊(duì)，立即返回排隊(duì)中（異步下單）
• 請(qǐng)求出隊(duì)，生成訂單，減少庫(kù)存，把訂單寫(xiě)入Redis中
• 客戶端輪詢，判斷是否秒殺成功

秒殺接口優(yōu)化

• 之前的沒(méi)有庫(kù)存預(yù)熱的步驟是：查庫(kù)存-查訂單-修改庫(kù)存-生成訂單
• 系統(tǒng)初始化時(shí)把庫(kù)存加載到數(shù)據(jù)庫(kù)：MiaoshaController 繼承InitializingBean實(shí)現(xiàn)afterPropertiesSet方法即可
• 在上一步庫(kù)存預(yù)熱之后，執(zhí)行步驟為：查Redis庫(kù)存-判斷是否存在訂單-進(jìn)入隊(duì)列-在出隊(duì)時(shí)才對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作
• 這一步還可以有一個(gè)優(yōu)化，就是內(nèi)存標(biāo)記，使用一個(gè)Map，將商品ID設(shè)置為false，當(dāng)買空時(shí)，設(shè)為true；然后每次不是直接訪問(wèn)Redis進(jìn)行庫(kù)存查詢，而是對(duì)商品ID進(jìn)行條件判斷
• 內(nèi)存標(biāo)記的優(yōu)點(diǎn)是減少對(duì)Redis的訪問(wèn)（當(dāng)商品已經(jīng)賣完之后）

主要內(nèi)容

• 秒殺接口地址隱藏
• 數(shù)學(xué)公式驗(yàn)證碼
• 接口限流防刷

秒殺接口地址隱藏

• 雖然前端頁(yè)面在秒殺未開(kāi)始時(shí)秒殺按鈕設(shè)置為不可用，但是有可能用戶通過(guò)前端js代碼找到秒殺地址在秒殺未開(kāi)始時(shí)直接訪問(wèn)，秒殺接口隱藏的目的是用戶通過(guò)js獲取到的秒殺地址并不能讓其完成秒殺功能
• 在秒殺之前要先通過(guò)Controller中的/path路徑下的類隨機(jī)生成一個(gè)path，然后和用戶ID一起存入Redis，在執(zhí)行秒殺的時(shí)候再?gòu)腞edis中取Path進(jìn)行驗(yàn)證，然后進(jìn)行秒殺

數(shù)學(xué)公式驗(yàn)證碼

• 作用：接口防刷；錯(cuò)開(kāi)請(qǐng)求
• 在獲取Path是進(jìn)行驗(yàn)證

接口限流防刷

• 當(dāng)一個(gè)用戶訪問(wèn)接口時(shí)，把訪問(wèn)次數(shù)寫(xiě)入緩存，并設(shè)置有效期
• 一分鐘之內(nèi)如果用戶訪問(wèn)，則緩存中的訪問(wèn)次數(shù)加一，如果次數(shù)超限進(jìn)行限流操作
• 如果一分鐘內(nèi)沒(méi)有超限，緩存中數(shù)據(jù)消失，下次再訪問(wèn)時(shí)重新寫(xiě)入緩存

使用一個(gè)通用攔截器

• 首先寫(xiě)一個(gè)注解AccessLimit
• 后面每個(gè)類只需要加注解即可設(shè)置防刷次數(shù)
• 定義攔截器：繼承HandlerInterceptorAdapter類