人工智慧，零基礎入門！1、訊息佇列（以下簡稱mq）天生就是處理高併發的有力工具，因為他可以把乙個完整的流程拆為多部分，併發進行，或者不是很重要的步驟模組延遲進行。大家所熟悉的是訊息佇列在大基數使用者專案的註冊模組和電商專案的訂單模組運用的比較多，**就是最好的案例。但是這裡並不是想要介紹這個，而是想簡談一下訊息佇列處理拼團秒殺活動的高併發的運用：
秒殺活動有個特點，就是在某個特定的時間點，併發請求量特別大，峰值遠遠高於平常，所以秒殺應用伺服器就有可能承受不了這麼大的併發而導致系統崩潰；
這個時候就可以考慮使用mq，mq在這裡可以起到削減高峰流量的作用，實現場景是搭乙個mq伺服器，擋在秒殺應用伺服器前面，承受這個大量的請求數，然後再把符合條件的前多少個請求傳送到應用伺服器，去正常消費庫存，mq在這個流程中做了三件事：收集請求-->篩選過濾請求-->傳送符合條件請求/返回秒殺失敗資訊給不符合條件的請求者，其中"返回秒殺失敗資訊給不符合條件的請求者"這個可以最後來做，往大的方向來說就是**請求；
舉個實際的例子，我配置了乙個秒殺活動，活動配置是開始時間為第二天早上八點，名額數為100個人。到了第二天7點50多分，估計好人都在守著手機等著搶秒殺商品，所以到了準時8：00這個點，所有人一擁而入，1000個人同時進來搶秒殺的商品，如果直接訪問秒殺應用伺服器，可能會讓系統受不了這麼高的併發直接伺服器崩潰，但是有了訊息佇列的話，可以將這1000個人先擋住，收集他們的資訊，然後將符合條件的前100個人的請求發給秒殺伺服器，從而達到削減併發高峰和篩選的作用，以下是實現方案圖：
高併發下商城秒殺活動的處理
秒殺搶購活動是現在很多 常見的營銷手段，小公尺搶購 的整點免單 聚划算等都是成功的例子。從簡單處著手，秒殺是很好理解的 設定要秒殺的商品的數量，搶完為止。但是，實際應用中一瞬間的高併發壓力 以及併發帶來的負庫存是要著重考慮。要避免負庫存的出現，可以在資料庫加鎖，不管外部多少請求，都可以在資料庫操作前...
訊息佇列處理高併發
用mq來將耗時比較長或者耗費資源的請求排隊，非同步處理，減輕伺服器壓力增加穩定性。如果是高併發的實時請求，我個人覺得不適用這個方案。如果是為了高併發，我覺得應該朝解決高併發的方向考慮。集群 分布式 動靜分離 資料庫讀寫分離之類的。web的話，只能客戶端頁面輪訓處理結果。因為，據我個人了解啊，現在we...
拼團業務的併發問題分析
最近有個專案，拼團的業務，但區別於一般的拼團完成就發貨，我們的業務時拼團完成後，有乙個 活動，從參加活動的成員中抽出一名幸運兒。拼團下單的業務如下 拼團下單 邏輯 func paymoney 2 建立支付訂單 funcb funcb2 db commit 提交事務 活動流程為 a使用者 uid 22...