A. 淘寶提示api限流什麼意思
淘寶客API限流是做淘寶客的數據介面許可權被限制了，在應用上的源碼中接入API數據口，就可以在應用上使用API數據等信息。
API 是淘寶網一個數據開放介面，主要是面向開發人員的，如果是具備開發能力可以到淘寶開放平台去看參考文檔自己開發基於API的淘寶客程序。
(1)api訪問限流擴展閱讀：
API限流最直接的原因就是伺服器爆滿，限制部分用戶登陸。
API（Application Programming Interface，應用程序編程介面）是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟體或硬體的以訪問一組常式的能力，而又無需訪問源碼，或理解內部工作機制的細節。
B. 百度地圖API是否有訪問頻率的限制
網路地圖的Place API今年悄悄的加入了調用次數限制策略：「Place API 是一套免費使用的API介面，調用次數限制默認為2000次/天」。
一旦超過該限制，API就會一直返回：{"status":302,"message":"天配額超限，限制訪問"}。
C. 關於API網關（四）——限流
通俗的說，流量控制就是控制用戶請求的策略，主要包括：許可權、限流、流量調度。
許可權上一篇已經講過了，這一篇講限流，下一篇講流量調度。
限流是指限制用戶調用的頻率（QPS/QPM）或者次數。
流量限制，站在用戶或者運營的角度看，最直觀能感受到的作用是——收費
各大主流開放平台的對外API，一般都有一些免費的額度，可以供個人測試用，一旦想大規模調用，就需要付費購買更大的額度（頻率、次數），根據調用次數或者頻率進行收費。一旦超過擁有的額度，就會被限制調用。
其實這才是限流最大的用處，只是用戶或者運營同學無感，所以不太被大多數人了解。
網關後面是各個服務，各個服務的介面通過網關透出去給用戶調用。理論上說，用戶的流量是不可預知的，隨時可能來一波，一旦流量的峰值超過了服務的承載能力，服務就掛了，比如有大新聞發生時的某浪微博，比如前些年的12306.
所以， 網關必須保證，放過去到達後端服務的流量一定不可以超過服務可以承載的上限 。這個上限，是網關和各個服務協商出來的。
由簡到難，限流可以 分為單機限流、單集群限流、全集群限流 。
這里不討論具體的如漏桶、令牌桶等限流演算法，只說概念和思想。
單機限流的思想很簡單，就是每個機器的限流值 x 機器數量 = 總的限流值。
舉個例子，A用戶的QPS限制是100，網關部署了10台機器，那麼，每台機器限制10QPS就可以了。
先說好處，這種方法實現起來非常簡單，每台機器在本地內存計算qps就可以了，超過閾值就拒流。
不過單機限流的缺陷也十分明顯，主要體現在兩點：
當網關部署的機器數量發生變化時，每台機器的限流值需要根據機器數調整。現實中，因為擴容、縮容、機器宕機等原因，機器數的變化是常有的事。
單機限流的前提是，每台網關承載的用戶的流量是平均的，但是事實上，在某些時間，用戶的流量並不是完全平均分布在每台機器上的。
舉個例子：
10台機器，每台限qps10，其中3台每台實際qps是15，因為超限導致用戶流量被拒。其餘7台每台qps是7。這樣用戶總的qps = 15 * 3 + 7 * 7 = 94. 用戶qps並沒有超限，但是卻有一部分流量被拒了，這樣就很有問題。
實際上，單台限流的閾值也會設置的稍微大一些，以抵消流量不均的問題。
因為上面的問題， 單機限流通常作為一種兜底的備用手段，大多數時候用的還是集群限流 。
先來看一個示意圖：
相比單機限流，集群限流的計數工作上移到redis集群內進行，解決了單機限流的缺陷。
但是集群限流也不是完美的，因為引入了redis，那麼，當網關和redis之間的網路抖動、redis本身故障時，集群限流就失效了，這時候，還是得依靠單機限流進行兜底。
也就是說， 集群限流 + 單機限流配合，才是一個比穩妥的方案 。
接下來我們來思考這樣一個問題：大型網關一般都是多機房、多地域部署的，當然，後端的服務也是多機房、多地域部署的，在保護服務這一點來說，集群限流是夠用了。但是對用戶來說，還是有一些問題：
比如，用戶購買的QPS上限是30，我們的網關部署在中國北、中、南三個地域，那麼這30QPS怎麼分配呢？
平均肯定不行，用戶的流量可能是明顯不均衡的，比如用戶的業務主要集中在中國北方，那麼用戶的流量大部分都會進入北方的網關，網關如果限制QPS為10的話，用戶肯定來投訴。
那每個地域都限制為30行不行？也不行，如果用戶的流量比較均勻的分布在各個地域，那麼用戶購買了30QPS，實際上可能使用了90QPS，這太虧了。
按照解決單機限流流量不均的思路，搞一個公共的redis集群來計數行不行？
也不行，受限於信號傳播速度和天朝的廣闊疆域，每個流量都計數，肯定不現實，rt太高會導致限流失去意義，帶寬成本也會變得極其昂貴，對redis的規格要求也會很高。總之，很貴還解決不了問題。
有一種巧妙的解決辦法是：本地集群階梯計數 + 全集群檢查。
還是剛才的例子：
限流閾值時90，那麼三個地域各自計數，當本地域的數值達到30時，去其他兩個地域取一次對方當前的計數值，三個地域的計數值加起來，如果超了，告訴另外兩個地域超了，開始拒流。如果沒超，本地QPS每上漲10，重復一次上述的動作。
這樣就能有效的減少與redis的交互次數，同時實現了全地域真·集群限流。
當然，這種全地域集群限流，因為rt和階梯計數間隔的存在，一定是不準的，但是，比單集群限流還是好很多。
當某個用戶流量特別大的時候，redis計數就會遇到典型的熱點key問題，導致redis集群單節點壓力過大， 有兩種辦法可以解決這個問題：打散和抽樣。
打散是指，把熱點key加一些後綴，使其變成多個key，從而hash到不通的redis節點上，均攤壓力。
比如熱點key是abcd，那麼打散後，key變成了abcd1、abcd2、abcd3、abcd4。技術時，輪流加1、2、3、4的後綴就可以了。
抽樣是指，針對熱點key，不是每個每個請求到來時都進行計數，而是進行一個抽樣，比如每10個請求記一次數，這樣redis的壓力就會降低到十分之一。
說著把流量調度的也說完了哈哈，那下一篇再說說監控好了，順便推一下我現在在用的國產網關：GOKU，來自Eolinker。我覺得比KONG好用，感興趣的同學可以自行去了解一下。
www.eolinker.com