-
存在著成本性問題
查看全部 -
使用redis/NoSQL的數據驗真，將邏輯操作解析等校驗后調用MQ進行解耦，發送消息隊列，或調用MQ的異步操作提高效率異步處理事務；最后根據隊列執行結果對MySQL進行操作，這一步需要根據消費消息的結果來操作，即落地實現
騰訊 阿里之前做的解決方案中常用的方案
查看全部 -
【秒殺操作優化分析】
CDN只能緩存url固定的資源：
秒殺地址是變化的，無法用CDN進行緩存
大部分寫操作和最核心的數據的請求，無法用CDN
不能在緩存里減庫存，因為并發，會有不一致的問題
——>通過mysql的事務來保證數據的一致性；
難點：一瞬間大量用戶參與熱門商品競爭，MySQL一行數據會有大量競爭，有大量的updata減庫存競爭
查看全部 -
【秒殺地址接口優化】
無法使用CDN緩存，(因為秒殺地址是會變化的)
適合服務器端緩存:redis等
一致性維護成本低：超時穿透/主動更新
緩存半小時,半小時之后,這個redis的秒殺對象就會超時,超時之后 ,重新訪問mysql服務器獲取數據,或者是當我們的mysql更新時 我主動的更新一下redis緩存,這樣也非常方便? ? ? 暴露秒殺地址
查看全部 -
無法使用CDN緩存：CDN對應不變的東西，秒殺地址是變化的
可以使用業務系統控制，所以適合服務端緩存
因為一致性維護成本低，適合服務端緩存
查看全部 -
獲取系統時間的請求不會緩存到CDN上，而是直接調用服務器
查看全部 -
【為什么要單獨獲取系統時間？】
靜態資源會部署到CDN上，訪問detail頁，靜態資源等不需要訪問秒殺系統，因此要單獨做一個請求獲取系統時間。
【CDN的理解】
大部分的視頻加速完全依賴于CDN
查看全部 -
33333
查看全部 -
為高并發優化做鋪墊
查看全部 -
紅色：可能出現高并發的點
綠色：無影響
查看全部 -
典型的部署架構
查看全部 -
當mysql執行update會獲得行級鎖，所以將insert語句調到update語句的前面，減少其獲得行級鎖的時間，來達到并發優化查看全部 -
代碼調整，先insert后update，減少獲取rowlock的時間，優化性能
查看全部 -
?代碼增加redis訪問
查看全部 -
在serviceImpl中注入redis層的數據
查看全部
舉報