眾所周知，對於一個流量兇猛、穩定性要求極高的商品秒殺功能，傳統的PHP技術很難滿足要求，所以需要藉助於網站架構設計、伺服器配置、負載平衡、cdn加速、雲端解析、redis等多種手段方能實現，本課程屬於PHP高階課程，主要介紹功能實現思路，不涉及程式碼具體實現，小白慎入！
課程播放網址：http://www.php.cn/course/279.html
該老師講課風格:
講課親切自然，樸實無華，沒有矯揉造作，也不刻意渲染，而是婁娓而談，細細道來，師生之間在一種平等、協作、和諧的氣氛下，進行默默的情感交流，將對知識的渴望和探索融於簡樸、真實的教學情景之中，學生在靜靜的思考、默默的首肯中獲得知識
本影片中較為困難是秒殺項目架構-資料處理層了：
#1 秒殺業務分析
正常電子商務流程（1）查詢商品；（2）創建訂單；（3）扣減庫存；（4）更新訂單；（5）付款；（6）賣家出貨
秒殺業務的特性（1 ）低廉價格；（2）大幅推廣；（3）瞬時售空；（4）一般是定時上架；（5）時間短、瞬時並發量高；
2 秒殺技術挑戰
#假設某網站秒殺活動只推出一件商品，預計會吸引1萬人參加活動，也就說最大並發請求數是10000，秒殺系統需要面對的技術挑戰有：
對現有網站業務造成衝擊秒殺活動只是網站行銷的一個附加活動，這個活動具有時間短，並發訪問量大的特點，如果和網站原有應用部署在一起，必然會對現有業務造成衝擊，稍有不慎可能導致整個網站癱瘓。解決方案：將秒殺系統獨立部署，甚至使用獨立域名，使其與網站完全隔離。
高並發下的應用程式、資料庫負載使用者在秒殺開始前，透過不停刷新瀏覽器頁面以保證不會錯過秒殺，這些請求如果按照一般的網站應用架構，訪問應用伺服器、連接資料庫，會對應用程式伺服器和資料庫伺服器造成負載壓力。解決方案：重新設計秒殺商品頁面，不使用網站原來的商品詳細頁面，頁面內容靜態化，使用者要求不需要經過應用程式服務。
突然增加的網路及伺服器頻寬假設商品頁面大小200K（主要是商品圖片大小），那麼需要的網路和伺服器頻寬是2G（200K×10000），這些網路頻寬是因為秒殺活動新增的，超過網站平時使用的頻寬。解決方案：因為秒殺新增的網路頻寬，必須和營運商重新購買或租借。為了減輕網站伺服器的壓力，需要將秒殺商品頁面快取在CDN，同樣需要和CDN服務商臨時租借新增的出口頻寬。
直接下單秒殺的遊戲規則是到了秒殺才能開始對商品下單購買，在此時間點之前，只能瀏覽商品信息，不能下單。而下單頁面也是普通的URL，如果得到這個URL，不用等到秒殺開始就可以下單了。解決方案：為了避免使用者直接存取下單頁URL，需要將改URL動態化，即使秒殺系統的開發者也無法在秒殺開始前造訪下單頁的URL。辦法是在下單頁面URL加入伺服器端產生的隨機數作為參數，在秒殺開始的時候才能得到。
如何控制秒殺商品頁面購買按鈕的點亮購買按鈕只有在秒殺開始的時候才能點亮，在此之前是灰色的。如果該頁面是動態生成的，當然可以在伺服器端建構回應頁面輸出，控制該按鈕是灰色還是點亮，但是為了減輕伺服器端負載壓力，更好地利用CDN、反向代理等效能最佳化手段，該頁面設計為靜態頁面，快取在CDN、反向代理伺服器上，甚至使用者瀏覽器上。秒殺開始時，使用者刷新頁面，請求根本不會到達應用程式伺服器。解決方案：使用JavaScript腳本控制，在秒殺商品靜態頁面中加入一個JavaScript檔案引用，該JavaScript檔案中包含秒殺開始標誌為否；當秒殺開始的時候產生一個新的JavaScript檔案（檔案名稱保持不變，只是內容不一樣），更新秒殺開始標誌為是，加入下單頁面的URL及隨機數參數（這個隨機數只會產生一個，即所有人看到的URL都是同一個，伺服器端可以用redis這種分散式快取伺服器來保存隨機數），並被使用者瀏覽器加載，控制秒殺商品頁面的展示。這個JavaScript檔案的載入可以加上隨機版本號碼（例如xx.js?v=32353823），這樣就不會被瀏覽器、CDN和反向代理伺服器快取。這個JavaScript檔案非常小，即使每次瀏覽器刷新都存取JavaScript檔案伺服器也不會對伺服器叢集和網路頻寬造成太大壓力。
如何只允許第一個提交的訂單被發送到訂單子系統由於最終能夠成功秒殺到商品的用戶只有一個，因此需要在用戶提交訂單時，檢查是否已經有訂單提交。如果已經有訂單提交成功，則需要更新 JavaScript文件，更新秒殺開始標誌為否，購買按鈕變灰。事實上，由於最終能夠成功提交訂單的用戶只有一個，為了減輕下單頁面伺服器的負載壓力， 可以控制進入下單頁面的入口，只有少數用戶能進入下單頁面，其他用戶直接進入秒殺結束頁面。解決方案：假設下單一伺服器叢集有10台伺服器，每台伺服器只接受最多10個下單請求。在還沒有人提交訂單成功之前，如果一台伺服器已經有十單了，而有的一單都沒處理，可能出現的用戶體驗不佳的場景是用戶第一次點擊購買按鈕進入已結束頁面，再刷新一下頁面，有可能被一單都沒有處理的伺服器處理，進入了填寫訂單的頁面，可以考慮透過cookie的方式來應對，符合一致性原則。當然可以採用最少連接的負載平衡演算法，出現上述情況的機率大大降低。
如何進行下單前置檢查
如果超過10條，直接返回已結束頁面給使用者；
如果未超過10條，則使用者可進入填寫訂單及確認頁面；
已超過秒殺商品總數，返回已結束頁面給用戶；
未超過秒殺商品總數，提交到子訂單系統；
檢查全域已提交訂單數目：
下單伺服器檢查本機已處理的下單請求數目：
秒殺一般是定時上架該功能實現方式很多。不過目前比較好的方式是：事先設定好商品的上架時間，使用者可以在前台看到商品，但無法點選「立即購買」的按鈕。但要考慮的是，有人可以繞過前端的限制，直接透過URL的方式發起購買，這就需要在前台商品頁面，以及bug頁面到後端的資料庫，都要進行時脈同步。越在後端控制，安全性越高。定時秒殺的話，就要避免賣家在秒殺前對商品做編輯帶來的不可預期的影響。這種特殊的變更需要多方面評估。一般禁止編輯，如需變更，可以走資料訂正多的流程。
減庫存的作業有兩種選擇，一種是拍下減庫存 另一種是付款減庫存；目前採用的「拍下減庫存」的方式，拍下就是一瞬間的事，對使用者體驗會好些。
庫存會帶來「超賣」的問題：售出數量多於庫存數量由於庫存並發更新的問題，導致在實際庫存已經不足的情況下，庫存依然在減，導致賣家的商品賣得件數超過秒殺的預期。
以上是PHP電商網站商品秒殺功能實現的影片資源推薦的詳細內容。更多資訊請關注PHP中文網其他相關文章！
