上一章中講到項目開發中實際應用場景，我們應該如何進行設計，今天接着上一章的內容，我們繼續來講敘。
想學習分佈式、微服務、JVM、多線程、架構、java、python的童鞋，千萬不要掃碼，否則後果自負~
場景應用
1.商品規格設計問題
業務背景： 每一個商品都需要關聯一個三級分類，每一個三級分類都會關聯一個規格屬性模板。因爲商品-分類-規格屬性模板-規格-商品價格，所以如果規格屬性模板中的規格發送變化，就會導致商品獲取價格的時候出錯。
技術實現：
方案一： 在修改規格的時候，判斷此規格是否綁定規格屬性模板，如果是，則查詢此規格屬性模板是否被使用，如果被使用則不能刪除，除非將所有關聯此模板的商品取消關聯。
方案二： 在修改規格的時候，判斷此規格是否綁定規格屬性模板，如果是，則查詢此規格屬性模板是否被使用，如果被使用則下架所以關聯到此模板的商品。
方案三： 分類不直接綁定規格屬性模板，而是綁定規格屬性模板的快照，這樣就可以避免上述的問題了。
2.多狀態問題
業務背景： 用戶交易記錄中存放多種類型的提現記錄，但是查詢類型只有一種，無法進行區分（用戶交易記錄，存放所有的交易記錄，例如：支付、退款、提現、充值等）。
技術實現： 設計字段的時候不要只用一個字段來區分所有的類型，最好用多個字段來區分，例如提現可以加上一個渠道，從商品分銷賬戶這個渠道，進行提現操作。
3.用戶註冊產生多條註冊數據
業務背景： 在高併發情況下，用戶註冊產生多條重複數據。
技術實現： 首先註冊流程一定要簡單，可以將耗時的操作放在MQ中執行，儘量保證註冊的流暢性。還有數據流一定要短，不要發生A-》B-》C-》D這麼長的微服務調用，如果這樣，有很大可能A會被熔斷掉，造成錯誤重試。最重要的一條：註冊接口一定要做成冪等，否則就會出現上述所說的，出現重複數據問題。
4.對接第三方問題
業務背景： 用戶資金相關的操作需要對接第三方支付公司，所以就涉及到接口互調問題，比如用戶開戶審覈，第三方公司需要將審覈結果推送給我們。
技術實現： 首先任何和第三方對接的接口都需要將請求日誌和返回值記錄下來，方便以後追蹤查看問題。比如上面提到用戶開戶問題，對方將審覈結果推送給我們的時候，需要記錄下返回值，我們也需要主動去查詢審覈結果。最後還要定期掃描長時間沒審覈的記錄，主動去獲取審覈結果或者找對方客服進行諮詢。
5.供應商入住問題
業務背景： 供應商入駐需要進行基礎資料審覈和財務審覈，所以入駐的狀態就分爲多種：待提交、基礎資料待審覈、基礎資料審覈不通過、基礎資料審覈通過、財務待審覈、財務審覈不通過、財務審覈通過（入駐成功），審覈不通過跳轉頁面出錯。
技術實現： 首先要確定具體有多少種狀態，每一種狀態可以做的事情。千萬不要用一種狀態來區分這些狀態（例如1是待提交、2是已經提交等等），最好採用多字段的標識，基礎資料審覈狀態、財務審覈狀態。
還需要注意的是，審覈不通過頁面跳轉地址也需要和前端商量好，比如基礎資料審覈不通過跳轉到資料提交頁面，財務審覈不通過跳轉到支付頁面等。基礎資料提交頁面最好做成分步驟操作並添加保留草稿的功能，這樣可以有效的提高用戶體驗。
6.供應商財務結算問題
業務背景： 平臺需要定期將已經確認收穫的訂單結算給供應商，供應商可以申請提現，運營平臺需要對申請進行審覈，審覈通過則可以提現（通過其實就是從總賬轉賬給供應商賬戶）。但是這對審覈人員的工作量會特別大，也可能存在失誤的風險。
技術實現： 要有一個對賬程序，定期去和第三方支付公司進行賬戶對賬，如果賬戶出現問題，則推送給相關人員，如果對賬沒有問題，數額比較小的情況下，可以直接程序審覈通過，如果數據比較大的情況下，可以程序+人工審覈。
7.訂單下單問題
業務背景： 商品下單的時候會生成一個待支付的訂單，同時商品的庫存會對應的扣除。但是庫存爲1的時候，併發操作會造成庫存小於0，修改地址和商品價格，訂單數據跟着改變。
技術實現： 首先訂單數據是歷史數據，不能因爲商品或者收穫地址修改而變化，所以在設計庫表的時候，就需要將商品、地址、用戶信息等通通保留下來，作爲一份快照。下單的時候要加redis併發鎖，保證同一時刻只有一個用戶下單，但是要注意鎖的顆粒。如果用戶取消訂單，就需要將庫存加回去。
8.失效商品問題
業務背景： 收藏或者歷史記錄的商品點擊出錯。
技術實現： 商品可以用邏輯刪除，查詢的時候如果查無此商品，可以用一個失效狀態標識，前端直接顯示商品已經失效，跳轉到其它頁面。禁止因爲商品不錯在就報null指針錯誤，因爲這類失效商品是合法的。
9.同一賬號多臺手機登錄問題
業務背景： 同一個賬號可以多臺設備登錄，導致數據錯誤。
技術實現： 可以採用token機制進行校驗，當用戶登錄時候在redis存入一個key值爲用戶Id，值爲token值，然後將token值返回給前端，當該用戶在另一臺設備登錄的時候，查詢key是否存在，如果存在則說明在另一臺設備上面已經登錄，發送極光推送（前端收到推送消息，強制性退出登錄），並將token值更新，然後返回給前端。
前端每次請求接口都必須帶上用戶id、token值，如果返回其它設備已經登錄，則強制性退出登錄。
項目應用案例就介紹到這邊了，如果對上述分析有疑問或者問題，都可以留言，博主會一一解答。
林老師帶你學編程：https://wolzq.com