原文地址：http://www.iam3y.com/html/878.htmlphp
最近須要設計open api的接口頻次控制相關實現，便查閱相關文檔。html
接口頻次控制主要包括兩方面：node
（1）業務ID對某一個接口某時間間隔（如一分鐘）內訪問的次數 限制算法
（2）業務ID在某個時間週期（如一天）內訪問的次數 限制數據庫
對於存儲並進行頻次計數的服務來講，要具有如下的特色：編程
（1）自更新能力，在某個約定的時間點對全部的node（節點）進行自更新操做，也就是常說的出廠設置api
（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文件平均劃分爲m塊存儲區域(稱爲關鍵節點，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級別日訪問量的開放平臺，保證了有效的服務質量以及系統安全。實踐代表，將平臺內部功能 抽象爲服務，能提升其應用服用程度，明顯下降了功能的維護和擴展成本，具備必定的推廣意義。