電商項目_秒殺_架構升級

1. 秒殺當前架構設計

當前架構面臨的痛點：

????????秒殺系統redis是單節點（主從）部署，讀redis時并發量會成為瓶頸。

????????所以考慮將增加redis從節點個數。秒殺系統為提交讀庫存的性能，將redis從節點和nginx節點部署在一起的，如果升級成redis集群， nginx讀哪個從節點呢？-》考慮將nginx也水平擴展。

（nginx可以擴容原因：商品詳情頁的靜態頁面發布到OpenResty上，那么就可以考慮將不同商品的頁面發布到不同的openResty上）

????????當前架構面臨的痛點：

????????秒殺商品比較多時，單個主redis節點更新庫存、主redis節點同步從節點數據，會成為性能瓶頸。所以考慮將Redis升級成集群。

nginx讀取的redis從節點，就可能不在一個機器了。
Redis 的集群化部署，多個 SKU 的數據，會分散到各個 Redis 節點當中，就可以解決 Redis 數據量太?的問題。并且，基于 Redis 集群的?式，Redis 服務的可?性也得到了提?。我們可以通過再加?哨兵機制等?式，保證少量 Redis 節點掛了后，整個 Redis 集群不會出現問題。????????

當前架構面臨痛點：

???????Redis連接池：取決于具體的客戶端實現，客戶端可以配置針對單節點的連接池，也可以配置集群的連接池。

使?TwemProxy于 Redis 之間建?單鏈接交互，并通過Twemproxy實現分?邏輯。這樣我們就可以?平擴展出更多的Twemproxy來增加連接數。
Twemproxy實例眾多，應?維護、配置困難，需要在這之上做負載均衡。?如，通過LVA/HaProxy 實現VIP(虛擬 IP)，就可以做到節點切換對應?透明、故障?動轉移。還可以通過實現內? DNS 來做其負載均衡。

????????解決無法保證Nginx只讀本地?Redis的問題。同時也解決了集群redis線程池的問題。

????????在很多互聯?企業中，不會直接使? Redis 的集群架構，?是搭建多個 Redis 節點。并通過庫存預分配的?式，??控制 Redis 中的數據分布。

優點：

缺點：

前端引導用戶進入不同的靜態頁面，但是如果想要多個服務承擔同一個商品的秒殺服務，前端如何進行合理的引導，需要將引導與庫存進行溝通
服務出現問題，庫存很難回收：二級redis是單點部署（主從），如果redis在活動過程崩潰，基于這個redis的庫存數據無法回滾，從而影響整體庫存管理。（純粹單節點，活動數據可以通過日志恢復，后續的返廠活動進行補救）
各個服務之間無法溝通，導致有庫存，但是用戶秒殺不到的問題。 APP1有庫存，APP2無庫存，但是APP2進來的秒殺請求卻無法下單。搶購多個商品也是類似問題。

解決不同二級redis服務之間不溝通的問題。

獨立出庫存分配服務
每個二級redis緩存配置個閾值，當庫存低于域閾值時，通知庫存分配服務，庫存分配服務再訪問各個Redis，對庫存進行統一分配
- 優先從一級redis分配，這樣速度更快
- 一級redis扣減完成后，再協調二級redis進行動態庫存分配
當秒殺活動快結束時或者庫存快全部售完時，所以二級redis的庫存都低于一個臨界值，可以將所有庫存回收，統一分配給某一個二級Redis。

存在問題：

前端引導用戶進入不同的靜態頁面，但是如果想要多個服務承擔同一個商品的秒殺服務，前端如何進行合理的引導，需要將引導與庫存進行溝通
服務出現問題，庫存很難回收：二級redis是單點部署（主從），如果redis在活動過程崩潰，基于這個redis的庫存數據無法回滾，從而影響整體庫存管理。（純粹單節點，活動數據可以通過日志恢復，后續的返廠活動進行補救）

相同點：

不同點：

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/bicheng/90357.shtml
繁體地址，請注明出處：http://hk.pswp.cn/bicheng/90357.shtml
英文地址，請注明出處：http://en.pswp.cn/bicheng/90357.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！