關於hanhunmall專案的一些思考

與快取配合大量併發進來，通過分布式鎖保證只有乙個請求看到沒有快取後，拿到鎖，訪問資料庫，將資料放到快取中。其他併發請求拿到鎖後，再次檢查快取是否存在，發現快取已有資料，就算這些後來拿到鎖的請求，也不會重複去訪問資料庫。保證了只有乙個請求訪問資料庫，存放快取資料。其他請求只是讀取快取裡的資料。

可看成乙個分布式的雙重檢查鎖。

冪等性的保證

定時任務的執行通過分布式鎖保證了業務**相同的多台機器，只有一台機器執行了定時任務**。避免生成重複資料。

spu有乙個屬性分組的概念。

每個spu（比如手機）下面有屬於該spu的屬性分組和屬性。

屬性分組的作用相當於給當前spu的屬性做了分類，不同分類的屬性互不干擾，互不可見。

屬性分組的作用和nacos裡配置管理的命名空間很像。我們通常為每個微服務指定乙個命名空間，每個命名空間下的配置檔案與其他命名空間的配置檔案互不干涉。

所有系統（不同一級網域名稱）共用乙個認證系統。

某個系統在認證系統登陸成功後，認證系統給瀏覽器發放乙個共用的token（cookie）。後面其他系統的新請求再去訪問認證系統的登陸介面，因為是同乙個瀏覽器，認證中心檢測到瀏覽器以前儲存的token，將token同步給新請求。

好比開車去海淀區，給車子辦了乙個進京證，這樣同乙個車子也能去通州，朝陽了。車子對應瀏覽器，進京證對應token（cookie），需要認證的各個系統對應海淀，朝陽等區。

單點推出可以考慮刪除瀏覽器的cookie？

如果不做服務治理，某個服務被其他很多服務呼叫，如果這個服務機器宕掉或者響應過慢，就會拖慢其他所有呼叫服務，請求占用的執行緒資源也無法及時釋放，出現伺服器請求積壓，最終伺服器資源耗盡，所有相關服務崩潰。

熔斷是為了避免提供方服務出現問題，影響呼叫方採取的一種策略。

熔斷策略是放置在呼叫方服務的。

a服務通過feign呼叫b服務，為防止b服務掛掉後影響a響應速度。

可通過sentinel監控b服務。如果發現b服務異常，一段時間內不再請求b服務，直接返回降級資料（a服務的方法）。

還有一種熔斷觸發策略，對b服務做降級策略，比如，發現b服務在1s內響應慢的次數超過5次，觸發熔斷策略，一段時間內不再訪問b服務，直接返回降級資料。

降級往往是在高訪問量時期，主動將某些服務暫時降級執行，釋放伺服器資源給其他服務，所採取的策略。比如在**秒殺**時期，將註冊服務降級執行，如果註冊請求過多，直接返回降級資料，提示使用者過段時間再來註冊。

將搭載某個相同服務的多台機器註冊到註冊中心，這樣多台機器對外提供的就是乙個服務名。其他依賴方直接「享用」服務名字提供的服務了。通過引入註冊中心，多台機器抽象成乙個服務名字，實現了服務與服務之間的解耦。

直接熔斷某些不穩定的服務，避免雪崩，不要讓一顆老鼠屎壞了一鍋湯。

支付的後續對賬，通過最終一致性實現分布式事務。都是某方面做一小部分犧牲，換取其他方面更大的收益。

比如秒殺活動，只有100個商品，100個請求過來後，後面的上百萬請求就不做資料處理，不去查資料庫了，直接看作沒搶到，返回「手慢了」。這樣伺服器實際上只「認真」處理了100個請求。通過辨識出「無效請求」，做出相應的簡潔響應，提高了響應速度，也提高了伺服器吞吐量。

好的演算法能抓住資料特點，預判某些範圍的資料是無效的，可以提前打斷遍歷操作，過濾掉無效資料，這經常也是暴力演算法與高效演算法的重要區別。比如kmp演算法，再回溯時，就預判了某些位置是不可能匹配成功的，所以直接跳過這些無效位置。