1、問題一：秒殺活動開始和到期引發的一系列問題，如：秒殺活動開始和到期，秒殺商品列表更新（列表資料快取在redis中）。當前時間為2023年6月29日13：30：30，商品a於2023年6月29日14：30：30開始。在當前時刻，已經開始秒殺的商品有b、c、d三個商品，該列表資訊放入快取。到2023年6月29日14：30：31時，a商品從未開始狀態變為已經開始狀態，但獲取的列表仍然是之前的快取列表，不包含a。b商品於2020-6-29 14:00:00結束，到2020-6-29 14:01:00的時候，快取中依然有b商品。
嘗試解決方案1：定期清除快取，做乙個任務，整點清除快取。然後和操作人員商定活動的開始時間和結束時間必須是整點，2020-6-29 14:00:00符合，2020-6-29 14:30:30不符合。通過這種方式，保證活動開始或者結束時快取資訊立馬更新。
2.問題二：快取資訊的動與靜的矛盾。秒殺系統中，考慮到秒殺商品列表和商品詳情頁的資料通常在一段時間內不會有什麼變化（很少說有隔三五分鐘就有新產品開始或者舊產品參與秒殺），因此列表資訊做了快取；每個秒殺商品的詳情自然也是一樣的，因此也做了快取。但是，列表資訊和詳情資訊又不是完全不變的，列表裡包含動態資訊「商品庫存」，還包括「開始時間和結束時間」這一看起來是靜態資料、實際上是動態資料的資訊（畢竟時間一直在走，走著走著某個商品就開始了，或者就結束了，列表就該變了）。由此可見，靜態資料和動態資料是交雜在一起的。做了快取，會出現資訊更新不及時的問題；不做快取，資料庫壓力太大。還有一些介面，其實也可以做快取，但資料量較小，當時沒有考慮。在做快取前，要提前分清什麼是靜態資料，什麼是動態資料，以及二者之間的關係，盡量二者之間相互交叉。
嘗試解決方案：在獲取列表和詳情資訊時，靜態資料從快取拿，動態資料每次請求都更新，從而保證資料及時更新。然後借用定時任務在關鍵時間點清除快取。
3.問題三：做快取的時候，有兩種方式，一種是利用@cacheable註解，如商品列表的大部分資訊（名稱、限購數量、開始結束時間），一種是使用set()手動加快取，如商品的庫存資料。因此，後台更新、刪除操作時，同樣需要做手動和自動刪除，相當麻煩。
解決方案：暫無
4.問題四：rabbitmq延遲佇列ttl的設定。延遲佇列ttl的設定有兩種方式，一種是設定單個訊息的ttl，那麼每個訊息的ttl可以不同；一種是設定延遲佇列的ttl，那麼每個訊息的過期時間都需要一樣，否則無法消費。
5.非技術性問題總結:回頭來看，秒殺的技術難點不多，分布式鎖、延遲佇列、定時任務，都是不複雜的技術，但實現過程可謂是一波三折，出去技術不熟之外，一些非技術問題同樣值得關注。首先，要仔細研究原型圖，思考原型圖上每一條資料的**、獲取方法和可能涉及的字段，有些是圖上顯示的，有些是**的，一定要考慮好，否則後期增加字段還是比較麻煩的。其次，要整體考慮問題，一處的改動可能導致後續巨大的變動。下單流程中，我覺得原有的ordervo封裝過於複雜（ordervo包含三個物件，下單過程中還需要對這三個物件進行操作，很麻煩，且有大量冗餘），所以我對下單的ordervo進行了重新定義，以為會簡化過程。寫到後來，發現乙個問題，流程雖然變簡單了，但是很多原有的介面沒法用了 ，只能自己重新寫，還是有些費事，有點後悔。第三，寫界面前，盡量和前端對一下思路。寫的過程中，出現了幾次我和前端思路不一致，傳參葉出現各種誤會，特別耽誤時間。還有一些問題，後端不能處理的前端其實可以做到，多問一下。
6.分布式鎖的效率問題：同事提到乙個問題，我覺得也很有價值。她說，上分布式鎖還是比較耗費效能的，幾千萬 人同時搶一把鎖，成功率太低，效能不高。她提出了乙個很獨特的思路，假如庫存數量有100份，可以將100份再分成10份，每乙份一把分布式鎖，這樣同時就可以搶10個產品，效率似乎就提高了。我感覺很靠譜，有機會實現一下 。
秒殺系統實現總結
訪問量大，對網路頻寬要求高 系統如何支援瞬間的高併發 如何防止商品超賣 如何防刷 防黃牛等 cdn快取，nginx lua實現活動資料快取2秒 高併發 限流 防刷 超賣 使用redis實現原子性的操作 防刷 openresty lua 實現限流 驗證黑名單等 黑名單機制 手動 自動收集ip user...
秒殺系統設計總結
秒殺問題 1.前端 突然增加網路訪問頻寬 使用者可能存在重複提交 2.後端 商品超賣 資料庫樂觀鎖 cas無鎖 redis分布式鎖 mq非同步形式修改庫存 使用者需要等待 單機壓力大 單獨一服務形式部署 docker。可以實現快速擴容 使用者操作頻率塊 閘道器限流 使用者作弊 資料庫訪問壓力大 分表...
功能測試總結反思
參考 引用原博很多內容 功能測試階段是測試職業生涯的基礎階段，在這段時間內要注意培養測試思維 做事方式 溝通能力 對需求及使用者體驗的理解把握能力 對於軟體開發具體實現的基本理解 對於軟體開發整體流程的理解和把握 對一些工具和簡單指令碼的熟悉使用。大部分初入測試行業的人有乙個誤區，就是侷限於執行被分...