大數據量下的高并發分布式訪問控制（ACL）優化方案(一)

1. 目前的設計方案

   1.1.控制計數：

   在目前的項目中，有很多接口需要對訪問方進行權限訪問控制。目前設計方案是：利用redis集群來存儲每個訪問控制點的訪問計數信息。Key值為=PlatformId（接入平臺方）+InterfaceId（系統接口）+dayTime（日期時間），value值為當天每個時段的訪問次數統計列表。

   1.2.控制規則：

   通過頁面配置并制定控制規則、業務系統在啟動時加載控制規則，并訪問redis獲取控制次數,然后在業務系統中做邏輯判斷完成，ACL控制做請求攔截處理。

2. 目前的痛點：

   2.1.在大數據量高并發時，由于業務系統是集的并且是并發處理，會出現瞬間redis單點的qps峰值達到13w/s。出現這種情況的原因是Platform+InterfaceId+Day作為key的設計，會造成一個接入方的請QPS過大時直接映射到后端的redis的單點請求上，沒有利用到redis的集群效應。

   2.2.當前的訪問控制功能和業務代碼緊密耦合在一起，無法做到單獨對訪問控制功能進行水平擴展，造成管理與優化不便。

3. 結構圖：
   

   
   

4. 初步解決思路：

   4.1. 減少redis的訪問量、并將redis的key值做細分使其能均勻分布到所在redis集群上.

   4.2. 對ACL訪問控制功能進行服務化處理，做成無狀態支持水平擴展。

   4.3. 引入異步處理邏輯、將ACL服務與業務方分離。后續ACL服務的變動對業務系統無感知。

   4.4.實現預先計算功能，在做redis匯總統計時現在ACL系統中做分組預計算，減少更新redis的頻率。

   4.5.延遲檢測控制，ACL訪問控制目的主要是對一些過量請求進行攔截處理，非一定要保證實時性和一致性。通過延遲統計策略實現高吞吐量的處理能力。

   4.6.通知攔截機制，業務方不需要做任何攔截控制統計和分析，只需要接受ACL系統通知并執行通知動作即可。

5. 具體實施細則：

   5.1. 所有配置信息統一由配置中心管理，ACL和Service（服務系統）都到zk上注冊和訂閱服務。

   5.2. Service方發送統計消息到MQ上，ACL去訂閱該TOPIC來消費

   5.3. ACL在自身內存中做初步預處理計算，并定時刷新到redis集群做聚合運算。

   5.4. 啟動定時服務掃描所有控制規則，檢測到需要攔截的規則后，創建廣播消息，發送到MQ上。

   5.5. Service方訂閱廣播消息，發現消息后，解析并在內存中對滿足規則的訪問進行攔截控制。

   5.6. 配置中心信息變更時，通過廣播推送給所有訂閱方，訂閱方獲取消息后到服務提供方來拉取信息并更新自身內存信息。

6. 結構圖如下：

   

7. 目前該項目的重構方案正在實施，后續實施效果待更新第二版。