參考:樂優**的秒殺思路借下圖
秒殺設計到的微服務
註冊中心(eurake) : @enableeurekaserver開啟註冊中心,實現對各種微服務的集中管理
閘道器徽服務(zuul) : @enablediscoveryclient將服 務註冊到到註冊中心,@enablezuulproxy開啟 閘道器服務,對微服務路口做統一管理, 實現路由,降級(容錯回退),限流的功能。如果多台伺服器,可以通過路徑和服務的繫結path: /user-service/* ; serviceld: user-service2,實現負載均衡(預設是ribbon輪詢,還有隨機)
使用者中心微服務(user-service) :@enablediscoveryclient將 使用者中心微服務註冊到到註冊中心,實現註冊和登入功能
授權中心微服務(auth-service) : @enablediscoveryclient將使用者中心微服務註冊到到註冊中心實現對登入的鑑權。
商品微服務(item-service) : @enablediscoveryclient將商品微服務註冊到到註冊中心,做商品的新增和查詢。
閘道器對部分不需要登入認證的介面放行(要優化)1.註冊使用者,閘道器對註冊放行
登入介面到閘道器,被路由到授權中心,授權中心微服務呼叫使用者中心的登入介面進行校驗,校驗成功,利用jwt生成token,然後利用rsa非對稱加密token,生成公鑰和私鑰儲存,然後將token返回到客戶端
秒殺業務
在商品微服務中設定秒殺引數,根據引數的商品id查詢商品,構建商品秒殺表,新增,然後更新redis快取
boundhashoperationshashoperations = this.stringredistemplate.boundhashops(key prefix);
1/判斷是否存在此k值
if (hashoperations.haskey(key prefi){
hashoperations.delete(key_ prefix);
seckiloods.foreach(goods > hashoperatiosput(goos.getkud(.totring(), goods.getstock).totrin));))
使用秒殺功能需要登入驗證,建立登入攔截(logininterceptor extends handlerinterceptoradapter)對token進行驗證,認證通過將使用者資訊存放到執行緒域中,並且走乙個限流攔截accessinterceptor extends handlerinterceptoradapter)實現限流功能
構建秒殺路徑(限流),加密,儲存到redis快取,隱藏秒殺路徑,防止刷單。
4. 秒殺
4.1. 驗證秒殺路徑
4.2. 讀取庫存, 減1後更新快取
4.3. 庫存不足直接返回「排隊中」
4.4. 庫存充足, 將商品資訊封裝入隊mq,然後直接返回「排隊中」
5. 然後訂單微服務監聽佇列,消費佇列,5.1判斷庫存不足,將該商品設定成不可秒殺狀態,5.2檢視是否秒殺到,秒殺到直接返回,5.3沒有秒殺到,建立訂單
github:正版參考:
php分布式微服務開發 分布式微服務架構
隨著業務的不斷發展,使用者體量的快速擴張.從單體 垂直架構轉移到分布式 微服務架構是自然而然的選擇.分布式理論是分布式系統的基礎,在任何情況下分布式系統都要滿足網路分割槽容錯性,因此分布式系統都是在可用性和一致性方面做平衡.cap理論指的是在乙個分布式系統中,一致性 可用性 分割槽容錯性 在任何情況...
分布式 微服務面試
分布式 微服務面試 為什麼要拆分成多個微服務?微服務架構與傳統架構的優缺點?我們為什麼要使用分布式?分布式事物問題出現場景?如何解決分布式事物的問題?tcc是什麼?實現原理是怎麼樣的?2pc,3pc的概念是什麼?實現原理是怎樣的?訊息的最終一致性是什麼意思?如何實現訊息的最終一致性?訊息的最大努力通...
什麼是分布式 微服務
單體 傳統web專案 比較適合小專案,優點是 它的缺點也非常明顯,特別對於網際網路公司來說 通俗點說就是對於網際網路專案,屬於一直運營中有客戶一直在使用。單體應用的缺陷就暴露出來了,比如可能會因為乙個小問題,需要緊急上線,而導致整個 需要停止,這樣的情況對客戶 業務都是影響很大的,重新部署 備份對於...