系統架構中，對於熱點資料的處理
阿新 • • 發佈：2019-02-16
一 背景 某個業務線 商品開放開使用者申請免費試用，當某個商品特別吸引人時，比如iPhone6 。肯定有一大波人為了少賣一個腎 瘋狂去搶申請資格。有甚者利用機器人申請註冊,於是簡單的申請操作變成了秒殺行為. 大量請求同時更新資料庫中的同一個商品的申請次數，update 操作給表加上行鎖，導致後面的請求全部排隊等待前面一個update完成,釋放行鎖後才能處理下一個請求。大量後來請求等待，佔用了資料庫的連線。一旦資料庫連線數被佔滿，就會導致後來的全部請求因拿不到連線而超時，業務請求出現無法及時處理的情況,資料庫系統的RT會異常飆高,業務層由於等待出現超時，app 層的連線耗盡，一系列的雪崩效應！
限制介面的呼叫次數，降低對資料庫的請求壓力。
選擇不更新請求次數，弱化該商品申請次數的展現。類似於閱讀次數，申請次數 ，與金額，庫存無關的功能點。 b 通過非同步更新來避免直接寫資料庫 。 應用使用分散式快取(比如tair)來儲存某項商品的申請次數或者某人的申請次數，以商品id/user_id 或者將where 條件作為key，申請試用人數為value/符合某項具體條件的 count結果為value, 有使用者申請成功則更新申請試用人數。不需要查詢和實時寫資料庫，每隔一定時間/次數將結果寫入資料庫。
限制介面的呼叫次數，降低對資料庫的請求壓力。
選擇不更新請求次數，弱化該商品申請次數的展現。類似於閱讀次數，申請次數 ，與金額，庫存無關的功能點。 b 通過非同步更新來避免直接寫資料庫 。 應用使用分散式快取(比如tair)來儲存某項商品的申請次數或者某人的申請次數，以商品id/user_id 或者將where 條件作為key，申請試用人數為value/符合某項具體條件的 count結果為value, 有使用者申請成功則更新申請試用人數。不需要查詢和實時寫資料庫，每隔一定時間/次數將結果寫入資料庫。