秒杀业务的基础点
秒殺的是一個很常見的業(yè)務(wù)了。就是在某個時刻，讓大量用戶搶購少量的優(yōu)惠的商品，從而達(dá)到商品曝光和電商網(wǎng)站的曝光，增大用戶流量，從而提升整體銷售額。
比如今年疫情下，各大電商網(wǎng)站，就針對口罩開展了秒殺業(yè)務(wù)。
通用秒殺邏輯
1、秒殺頁動態(tài)獲取服務(wù)器時間，前端根據(jù)時間倒計時
2、倒計時結(jié)束，開始秒殺
3、獲取后端秒殺接口
4、真正執(zhí)行秒殺（減庫存，下訂單insert）
一般減庫存是放在redis中頂?shù)?#xff0c;因為秒殺那一刻，會有大量請求過來。
下單秒殺
說說之前的一種秒殺場景，就是下單秒殺。
就是每個人都可以下單，只有你下單成功了，然后減庫存成功了，才算秒殺成功。
這種秒殺，相對上面那種，會比較重一些，比較難一點。
這種情況，就必不可少的會用數(shù)據(jù)庫。
做的復(fù)雜點，是將所有的操作先在nosql中保存起來，或者發(fā)出一個mq消息，然后讓數(shù)據(jù)庫慢慢消化，但這樣就可能會出現(xiàn)不一致的問題。
所以，如果用戶量不是特別大，也可以直接考慮用數(shù)據(jù)庫頂。
如果用數(shù)據(jù)庫頂，也要考慮，比如先下單，再減庫存好，還是先減庫存，再下單好。
直接說結(jié)果，那就是先下單，再減庫存比較好。
以 MySQL 作為 DB 為例，下訂單就是 insert，在使用索引的情況下，insert 插入是行級鎖，支持每秒 4W 的并發(fā)。減庫存就是 update 操作，命中索引時也是行級鎖，但是這是個獨占鎖，所有的操作都要等待前一個釋放鎖后才能繼續(xù) update。
問題就在這里，根據(jù) MySQL 兩段鎖協(xié)議，我們應(yīng)該把熱點操作放到離 commit 近的位置，這樣可以減少行級鎖的持有時間！自然處理效率就更好一些。
購買資格秒殺
比如京東的那個賣口罩的秒殺，秒殺成功只是代表你獲得了購買的資格，然后你跳到結(jié)算頁，就可以購買成功了，而沒有獲取秒殺資格的人，短時間也可以跳到結(jié)算頁，最終會購買失敗。如果庫存減完了，頁面直接置灰，顯示秒殺結(jié)束。
那這個實現(xiàn)方式，相比秒殺完還要下單的場景，就簡單多了，redis搞一個原子計數(shù)器，設(shè)置好庫存，秒殺成功減庫存，同時記錄秒殺成功的用戶。后面只有這些記錄的用戶才可以購買。
mysql
如果你是一個小的商城服務(wù)，成本有限，沒有時間和錢去維護那么多nosql，mq等高可用服務(wù)，實在沒辦法了就直接用mysql先抗吧，畢竟小商城，既要有秒殺這種活動，又不想多花錢，但好在用戶量也不大，所以用mysql，我覺得用的好的話，也能抗住不少。
比如可以寫存儲過程，將insert和update放在一個存儲過程中，這樣的好處是可以減少java客戶端與mysql的執(zhí)行次數(shù)，最終是減少了事務(wù)鎖的時間。
但存儲過程，我并沒有在真正的生產(chǎn)環(huán)境見過這樣用的，甚至一些大并發(fā)的部門，都是禁止用存儲過程的，所以這個用存儲過程，也只是一種民間說法，可以作為一個思考方向吧。
緩存
cdn緩存
一般秒殺頁的靜態(tài)資源，包括一些基本不變的css，js都可以靜態(tài)化處理推送在cdn緩存上。
redis緩存
redis緩存，為了擋住大部分到數(shù)據(jù)庫的請求。
緩存和數(shù)據(jù)庫的一致性考慮，需根據(jù)業(yè)務(wù)不同自行判斷。
對于幾乎不可改的數(shù)據(jù)，可以用redis的過期時間，過期了就再從數(shù)據(jù)庫查一次。
對于常改的數(shù)據(jù)，就需要每次改完數(shù)據(jù)庫都同步一下redis了。
普通業(yè)務(wù)，只要產(chǎn)品經(jīng)理靠譜點，都會搞成不可改的數(shù)據(jù)，如果錯了就廢棄掉，新建一條。
序列化
redis由于不能存對象，一般可以存json，或者byte數(shù)組。
一般使用java原生的序列化也行，就存byte數(shù)組，或者糙一點，存json字符串也有，但講究點的，可以選擇換種序列化方式。
這里個人推薦用protobuf序列化。
protostuff序列化包，使用protobuf序列化協(xié)議，相比java原生的序列化，速度快，占用空間還小。
為什么又快又小，可參考：https://github.com/eishay/jvm-serializers/wiki
總結(jié)
- 上一篇： mysql联合索引数据库查询数据会变慢_
- 下一篇： synchronized锁