秒殺場景的特點是短時間、高并發(fā)骄噪，業(yè)務系統(tǒng)要處理瞬時的大量高并發(fā)請求尚困，而Redis
的高性能特性就經常被用來支撐秒殺活動链蕊。
根據我們的購物體驗，我們可以把秒殺場景分為三個階段滔韵，第一個階段是秒殺前逻谦，我們
一般都會在活動開始前就進到頁面刷新，這時候我們的商品詳情頁面的流量會激增陪蜻，
所以我們通常會把這個頁面靜態(tài)化邦马，通過瀏覽器緩存或者cdn把靜態(tài)頁面緩存起來，
以此來緩解服務端壓力滋将。
第二個階段是活動開始的時候嘱腥，會有大量請求到達服務端耕渴，先是查詢庫存齿兔，庫存足夠，
扣減庫存分苇，下單進而訂單處理，如果庫存不夠則返回医寿。壓力最大的時候是查詢庫存的
時候，通常會使用redis來進行庫存的查詢及庫存扣減操作须眷，并不會在數(shù)據庫端做庫存扣減操
作沟突，首先因為數(shù)據庫相較而言比較慢花颗，而且還得進行數(shù)據庫與redis的數(shù)據同步惠拭，容易因為
數(shù)據更新慢而導致商品超賣情況，查詢庫存及庫存扣減操作，必須保證其原子性聂示。
第三個階段是訂單后續(xù)處理簇秒，物流、供應鏈宰睡、退單等等情況气筋，這個階段是請求量較小，
普通服務端基本能滿足宠默。
高并發(fā)
商品秒殺是典型的高并發(fā)場景麸恍，redis本身的特性足以滿足并發(fā)要求搀矫，需要注意的是，如果
商品較多的情況下瓤球，我們可以把這些商品分布在不同的切片實例上，避免秒殺請求集中在
少量實例上卦羡，我們需事先通過crc計算好各商品的key對應的slot，然后合理的把slot分配
到實例上欠肾。
查詢庫存及扣減庫存的原子性
我們必須保證查詢庫存及扣減庫存在同一請求下的原子性執(zhí)行拟赊，不然庫存就亂套了，我們
可以之間使用redis的原子性操作吸祟，因為查詢庫存和扣減庫存是兩條命令，所以我們得依賴
lua腳本以完成原子性操作屋匕。
另一個方案則是通過分布式鎖來保證多客戶端的互斥性，請求會先訪問鎖的實例吹埠，得到
鎖之后，再執(zhí)行后續(xù)查詢庫存及扣減庫存操作缘琅，建議把鎖和庫存放在不同實例上。
