https://github.com/iemi/imooc-seckill
https://github.com/yoyo185644/seckill/tree/master/src
ChatGPT:
綜合上述內容,我們可以整理出以下關於CDN和秒殺操作最佳化的要點:
CDN:
- CDN(內容分發網路)是一個加速使用者獲取資料的系統,尤其適用於提供靜態資源和JavaScript等不變的資源。
- CDN部署在離使用者最近的網路節點上,可以提高資料的載入速度。
- 使用CDN可以避免訪問後端伺服器,提高效能並減輕後端伺服器的負載。
秒殺操作最佳化:
- 秒殺操作無法使用CDN快取,因為它涉及到寫操作或核心資料的請求,通常無法被快取。
- 對於秒殺操作,後端快取困難,因為庫存問題無法在快取中直接減少庫存,需要使用事務來保證資料的一致性。
- 秒殺操作可能會產生對資料庫表中某一行資料的大量update減庫存競爭,這是熱點資料的特點。
最佳化方向:
- 減少行級鎖持有的時間,快速執行commit/rollback操作,以釋放行級鎖,減少其他等待行鎖的執行緒的等待時間。
- 在秒殺操作中,將客戶端邏輯放到MySQL伺服器端,避免網路延遲和GC影響,可以使用定製SQL方案或儲存過程來實現。
- 儲存過程的設計可以讓一組SQL組成一個事務,在MySQL伺服器端完成,避免客戶端控制事務造成的性能干擾。
總結最佳化要點:
1. 前端控制:暴露介面,防止按鈕重複請求。
2. 動靜態資料分離:使用CDN快取和後端快取來提高效能。
3. 事務競爭最佳化:減少事務鎖持有的時間,將客戶端邏輯放到MySQL伺服器端,並使用儲存過程等方式實現秒殺操作的效能優化。
投影片~~~~~~
投影片~~~~~~
Mybatis 中寫 store producer
投影片~~~~~~
ChatGPT:
更新庫存是一個熱點操作,容易產生行級鎖,而插入購買記錄的行為則不會產生行級鎖。為了避免重複秒殺帶來的不必要的庫存更新操作和減少行級鎖的佔用,可以先插入購買明細,然後再進行庫存的更新。
在程式碼中,根據熱點商品競爭的結果,可以根據判斷來決定下一步是回滾(rollback)還是提交(commit)事務。這樣做的好處是可以降低網絡延遲和垃圾回收(GC)對系統的影響,節省了一部分時間。
將插入操作放在前面的原因是,插入操作組成了一個元件,包含秒殺單的資訊、使用者ID和電話等,這個元件的衝突機率並不高。因此,可以平行執行插入操作,網絡延遲和GC的影響可以並行進行。之後再執行更新庫存的操作,這時候需要處理行級鎖(rowLock)。
行級鎖(rowLock)是最小粒度的鎖,並行度最高,但加鎖的過程比較慢。
總的來說,以上策略的最終目的是為了降低MySQL行級鎖的持有時間,以提高系統的並行度和效率。需要根據具體情況和需求來選擇最佳的策略,並進行性能測試和優化。
Protostuff是一個高效的Java序列化框架,它使用基於協定緩衝區(Protocol Buffers)的二進制編碼格式,可以將對象序列化為緊湊且高效的字節數據。相比於JVM默認的Java序列化方式,Protostuff在效率上具有一些優勢。
投影片~~~~~~
方法一:成本高,大公司使用
=================================
===============================
方法二:放到服务器端完成,MySQL执行sql效率非常高
===========================
投影片~~~~~
為什麼要單獨獲取系統時間?
ChatGPT:
在秒殺操作的最佳化分析中,你提到了CDN的限制以及資料一致性和庫存減少的競爭問題。這些觀點是正確的,以下是對這些問題的一些進一步解釋和建議:
1. CDN限制:CDN主要用於快取靜態資源,無法有效地快取動態和個別的秒殺地址。對於變化頻繁的秒殺地址,CDN的快取效果不佳。因此,在秒殺操作中,我們無法依賴CDN來提高性能或減輕服務器負載。
2. 寫操作和核心資料的問題:秒殺操作通常涉及到大量的寫操作,例如庫存減少和購買記錄的更新。這些操作需要直接與核心資料庫交互,而CDN無法幫助我們處理這些寫操作。在這種情況下,我們需要依賴更強大的資料庫和事務管理來確保資料的一致性。
3. 資料一致性和庫存減少的競爭:在高並發的秒殺場景中,多個使用者同時競爭庫存資源,可能會導致庫存的不一致性和競爭條件。這是一個很難處理的問題,需要仔細考慮並使用相應的解決方案。
在解決這些問題時,以下是一些建議:
1. 使用事務管理:使用MySQL的事務來確保庫存減少和購買記錄的更新操作的一致性。通過將相關的操作放入一個事務中,可以確保這些操作的原子性和一致性。
2. 優化資料庫性能:優化資料庫的性能是關鍵。使用適當的索引、分區、緩存等技術來提高資料庫的查詢和寫入性能,以應對高並發的秒殺場景。
3. 使用緩存:在合適的場景下,可以使用緩存來減輕資料庫的負載,例如將熱門商品的庫存信息存儲在緩存中,以減少對資料庫的頻繁查詢。
4. 拆分和分流:如果處理大量並發
請求的單一服務器成為瓶頸,可以考慮拆分和分流技術,將請求分發到多個服務器上,以提高系統的擴展性和性能。
總的來說,秒殺操作是一個具有挑戰性的問題,需要綜合考慮多個方面的解決方案。除了上述建議,還可以根據具體需求和情況,探索更多的優化方法和技術來實現高效且穩定的秒殺系統。
【高并发的点】
详情页→开始前用户会不断刷新 解决方案:详情页部署到CDN上,不直接访问系统
系统时间→ 该处不用优化,因为不会访问后端
地址暴露接口→随着秒杀环节的进展会更换地址,无法使用CDN缓存 解决方案:使用redis服务端缓存后访问Mysql
执行秒杀操作→秒杀按钮,无法使用CDN缓存,因为库存时效问题也不能使用后端缓存,一瞬间会产生大量竞争 解决方案:下一章
【CDN】
内容分发网络,一般互联网公司会有,
静态内容部署在上面加速用户访问,
会部署在离用户最近的网络节点上,
命中CDN后就不需要访问后端服务器
此处的断点调试方法可以学习
秒杀系统架构
MySQL低效
运维成本分析
秒杀技术方案分析
秒杀地址接口优化
高并发分析
MySQL效率低下的原因是因为行级锁,当一个线程进行对行资源的操作时,下一个线程必须等待这个线程完成commit 或者 rollback 操作释放锁才能进行操作
并发优化:
流量分析:
系统可能用到哪些服务
存储过程总结:
简单优化:
序列化工具对比
详情页优化流程分析
优化总结:
放到MySQL服务端的两种解决方案
如何判断Update更新库存成功?
延迟分析:同城ip