輕型的介面訪問頻率限制服務模型的設計與實現【轉】

標籤：

原文地址：http://www.iam3y.com/html/878.html

最近需要設計open api的介面頻次控制相關實現，便查閱相關文檔。

介面頻次控制主要包括兩方面：

（1）業務ID對某一個介面某時間間隔（如一分鐘）內訪問的次數 限制

（2）業務ID在某個時間周期（如一天）內訪問的次數 限制

 

對於儲存並進行頻次計數的服務來說，要具備以下的特點：

（1）自更新能力，在某個約定的時間點對所有的node（節點）進行自更新操作，也就是常說的出廠設定

（2）協議輕型能力，協議必須儘可能簡單，才能達到高效的目的

（3）增刪查改能力，允許業務調用方對某個節點的資料增刪查改

以上所提節點，如node，大體包含了如下分支

node.bizid,業務id,給某個客戶分配的業務id,是客戶在頻次計數系統裡的唯一標識

node.m_count,某分鐘周期內訪問次數

node.count,某計數周期內訪問次數，如一天。

node.starttime，計數開始周期

node.endtime,計數結束周期，記錄客戶最後一次介面訪問的時間，也用於頻次計數系統的自更新

node.m_starttime,分鐘計數開始時間

node.m_endtime,分鐘計數結束時間，當（node.m_endtime-node.m_starttime）<60 && node.m_count>M_MAX_COUNT，介面訪問被拒絕，當（node.m_endtime- node.m_starttime）> 60,同時更新node.m_endtime，node.m_starttime為目前時間，重設node.m_count

 

同樣，天計數周期的原理也如此。

 

基於以上目標，我們看系統要怎麼去實現，如下內容為轉載內容。

原文連結 輕型的訪問頻率限制服務模型的設計與實現

 

        為防止開放系統的公用介面被過度調用，本文提出一種面向系統內部的訪問頻率限制服務輕型模型，並給出泛型索引值索引、頻率約束演算法等關鍵技術實現。該服務模 型抽象了各種業務的訪問頻率限制邏輯，記錄各個索引值對特定業務的訪問間隔和訪問時間，通過頻率約束演算法，為系統公用介面提供訪問頻率約束依據，使得公用接 口可以對外界請求做出拒絕，消除了因介面過調用而帶來的系統安全隱患，提高了系統的服務品質以及介面調用的有效性。

關鍵字：訪問頻率限制； MMAP叢集；泛型索引值索引

1.引言
對於大型開放平台，其公開的服務介面會被外界頻繁調用，在不加任何訪問頻率的控制策略，這些介面甚至可能會被過度調用。給系統帶來額外的負擔。
過度調用，會導致兩方面的後果：介面調用者通過對服務介面的多次調用間接擷取系統安全資訊，對系統造成隱患，常見的有：短時間內對登陸服務介面，通過枚舉組合，破解使用者系統密碼。另一方面，因為使用者個體數量龐大，單個使用者對介面大量的調用，會影響其他使用者的服務品質，降低系統的有效負荷。

        使用者訪問數達到一定量級的系統平台均會遇到上述問題，並各自都有相應的解決方案。但現成的方法是，把訪問限制功能作為獨立的模組，系統內部需要使用此功能的業務，就把該模組的拷貝納入作為業務的子模組。這種系統組織方式既不利於維護，也不利於管理。而且訪問約束所適用的類型往往是固定的，不易於擴充。使用者訪問資料的儲存方面，已有的方式主要分兩種：用戶端記錄，或在服務端用資料庫儲存。前者的訪問資料可能被篡改，有安全隱患；作為一種基礎功能模組，後者的做法代價較為昂貴，可能會佔用大量的資料庫連接，降低業務處理能力。

        針對上述問題，本文提出一種輕型的訪問頻率限制服務模型(Access Frequency Restrict Service Model, AFRSM)。此模型本身是一種面向平台內部的私人服務介面。系統邊界以內的一切需要進行訪問頻率限制的模組和對外服務介面均可通過簡單的協議共同使用此服務(Frequency Restrict Service, FRS)。最終達到統一管理和使用訪問頻率限制服務的目的。

2.FRSM概述
2.1 架構
頻率限制服務(Frequency Restrict Service, FRS)作為CGI、Web-Service等公用服務介面的依賴服務，自身對效能有較高的要求。在設計模型時我們偏重其並發處理能力以及輕型的資料存放區。
FRS由三大塊組成：微伺服器架構、MMAP檔案群以及一組設定檔。其中伺服器我們採用了並發度較高的epoll模型，除守護進程外還可配置n個子進程進一步增加其並發效能。服務只處理兩種類型的請求:Query和Update，分別對應FRS的查詢介面和更新介面。公用服務(記為PS)通過FRS的查詢介面可以獲知：目前使用者/當前IP是否仍對於該服務(PS)有使用權，如有權使用則表示該使用者在服務(PS)中沒有被限制；反之，則表示該使用者在服務(PS)中已被約束。

在FRS的核心處理模組中，包含了一些核心演算法，用以訪問和更新MMAP檔案群。
Config-Cache是FRS的重要組成部分之一，在守護進程啟動時，指定設定檔內容機會被緩衝在中，之後每次訪問設定檔實際上都會在記憶體中命中需擷取的配置項。設定檔在此分兩種類型：(1)伺服器相關的配置(srv.xml)，用於指定伺服器的子進程數，所綁定的主機連接埠等；(2)業務配置(map.xml)，用於註冊各個業務的頻率限制細則：業務標識、時間間隔、間隔內最大訪問次數。

2.2協議
FRS採用TCP協議，並在此基礎之上構建應用程式層協議。由於FRS是內部服務，不對外公開，因此不存在資料包的保密問題；同時FRS屬於輕型服務，在一次服務要求過程中不會傳輸過多資料，因此不需要考慮資料包壓縮的問題。應用程式層協議的構建原則是:簡單並易於擴充。
HTTP-XML協議是我們所採用的應用程式層協議。即，使用HTTP頭描述資料包體的長度、請求命令類型等資訊。具體請求/響應資料則採用XML協議描述，以便在此基礎上進行擴充修改。

2.3 部署與使用
FRS作為一種內部服務，其使用者是位於系統最外層的CGI、Web-Service、其他Server等公開服務介面。通用的HTTP-XML協議使得其它服務的邏輯中可以很方便實現對FRS的調用。
FRS的用戶端使用模式相對固定，主要分=兩個步驟: a. Query, b. Update.
若且唯若key在服務(BizID)中沒有被約束，調用者key才能繼續使用該業務，並在使用完畢後，必須更新記錄key對這次業務的使用方式
4 FRS使用模式
由於從步驟(02)開始需要依賴步驟(01)的結果，步驟(01)必須使用同步模式請求FRS。如該業務採用非同步I/O模型[3]的可能在此進行特殊處理，採取局部的同步請求。

3.關鍵問題分析
3.1 泛型的索引值索引
FRS中的訪問記錄我們採用輕型的MMAP儲存，使用時只需把檔案資料對應到記憶體中即可。然而遍曆檔案找到真正需要的資料是一項耗時的操作，尤其在檔案較大的情況下。為此，本文採用泛型的索引值索引，將MMAP檔案平均劃分為mBlock Storage地區(稱為關鍵節點，key-node)，在目標資料存放區或檢索之前，預先為其估算出一個關鍵節點，使MMAP可以快速定位到該地區。索引值不同的資料有可能會被安排在同一個關鍵節點中，稱為估算衝突。衝突的資料會被安排在該關鍵節點的一條衝突鏈上，進行小區域細部搜尋檢索。

上側描述的是單個MMAP檔案儲存體。垂直排布示意的是關鍵節點，與其緊連的是該節點的衝突鏈。衝突鏈是有長度限制的，因為m=1的極端情況下，衝突鏈將佔滿整個檔案，檢索演算法會退化為檔案遍曆檢索。較為理想的情況是盡量減少衝突鏈的長度，儘可能一次命中。當某條衝突鏈用盡的時候，我們需要考慮採用淘汰演算法，將到期的節點抹掉/複用。假定允許的衝突長度為Length conflict (包含關鍵節點本身)，每個節點儲存大小為size node，則可計算出MMAP檔案的大小：
size MMAP = size node * Length conflict * m

上述的泛型是指FRS的擴充性。在FRS中通過編程擴充可以支援：以不同資料類型作為索引主鍵，只要實現該種資料類型的索引估算介面，和比較介面即可。其中，索引估算介面在知道關鍵節點總量m的前提下，用來計算關鍵節點。如：Integer類型的索引值可以採用求模運算得到關鍵節點索引，而String類型則可以使用現成的Bob Hash演算法[5]；而比較介面則是在衝突鏈上用來進行索引值比較，最終定位到目標資料。

MMAP叢集由多個同構的MMAP檔案構成。它適用於更大資料量儲存。假定一個MMAP群當中有n個隱藏檔。即相當於將資料存放區容量擴充了n倍。根據上述說明，可得出總的資料存放區大小為
size MMAP = size node * Length conflict * m* n。

總體看來，使用MMAP群模式對資料進行儲存檢索，實際上使用了2級檢索：第一級，索引到檔案；第二級，索引到關鍵節點。
為了使用方便，我們把上述對MMAP的訪問步驟封裝成一組操作：Init-MMAP、Find-Node、Erase-Node、Update-Node。由於MMAP是多進程共用訪問的，因此這些操作（尤其是修改檔案資料的操作）都需要使用訊號量互斥處理。
Init-MMAP：在守護進程啟動時，根據設定檔初始化MMAP/MMAP群的規模。
Create-Node：建立新節點。
Find-Node：找到目標資料節點。
Erase-Node：刪除目標節點。通常在淘汰處理時調用。
Update-Node：更新目標資料節點。

3.2 頻率限制
頻率限制是FRS的核心模組之一。在保證它的有效性的前提下，我們盡量簡化了它的實現邏輯。它基於以下簡單的資料結構和演算法(圖6)：
其中Interval和Max分別是某業務ID所對應的時間間隔和限制次數（於設定檔中設定）。這兩個參數控制了個體在一個時間段內訪問業務的次數。
由演算法可知，在Interval時間段內：
第1次訪問一個業務時，會通過FRS建立一個新的記錄節點（記為node），並把node.Start和node.End更新為目前時間戳，node.Count記為1圖6 頻率限制演算法示意
第n次（n<=Max）訪問該業務，則保持node.Start不變，node.End更新為目前時間戳，node.Count記為n；
第n次（n> Max）訪問該業務，仍然繼續保持node.Start的值不變，node.End更新為目前時間戳，但由於node.Count已到達極限值，訪問被拒絕。
若且唯若，在下次訪問時滿足：解除時間間隔約束(node.end-node.start>=Interval)條件，node.start才會重設為目前時間戳。回到處理第1次訪問邏輯的狀態。有兩種情況會促使FRS調用Create-Node去建立一個新節點：(1)第一次訪問；(2)因為節點過舊而被淘汰，需要建立。

4.結束語
通過簡單的協議和高並發的伺服器模型，我們在本文中把訪問頻率限制功能抽象成一種內部服務介面，並在實現中使用MMAP叢集確保了其資料訪問儲存的輕型性。在實際應用運營過程中，該服務模型可勝任10,000,000層級日訪問量的開放平台，保證了有效服務品質以及系統安全。實踐表明，將平台內部功能抽象為服務，能提高其應用服用程度，明顯降低了功能的維護和擴充成本，具有一定的推廣意義。

輕型的介面訪問頻率限制服務模型的設計與實現【轉】