1樓：阿呆
令牌桶演算法
令牌桶演算法(Token Bucket)和 Leaky Bucket 效果一樣但方向相反的演算法,更加容易理解.隨著時間流逝,系統會按恆定1/QPS時間間隔(如果QPS=100,則間隔是10ms)往桶裡加入Token(想象和漏洞漏水相反,有個水龍頭在不斷的加水),如果桶已經滿了就不再加了.新請求來臨時,會各自拿走乙個Token,如果沒有Token可拿了就阻塞或者拒絕服務.
令牌桶的另外乙個好處是可以方便的改變速度. 一旦需要提高速率,則按需提高放入桶中的令牌的速率. 一般會定時(比如100毫秒)往桶中增加一定數量的令牌, 有些變種演算法則實時的計算應該增加的令牌的數量.
2樓：Misko Lee
先計數後邏輯。redis的incr是併發安全的，而且會直接返回新值。理論上保證了會有多餘的connection進來，但是邏輯卻是永遠在限制範圍內的。
3樓：yaoyao
這是兩個問題！
第乙個問題是高併發下的限流問題，可以通過限制客戶端在設定時間內（譬如3秒）只對第一次請求進行應答，設定時間內的該客戶的其他請求都會被攔截。
第二個問題是每天限制請求次數的問題，這裡的次數應當是請求成功的次數，也就是說：如果設定為每天限制請求5次，那麼該客戶端在成功請求5次後，所有的請求都將被攔截。
這其實是限流這一功能的兩個維度的應用。限流的核心問題不是如何統計次數或時間，而是如何鑑別請求是否是同乙個客戶端的請求。IP作為依據什麼的就算了，同一內網的客戶端你就無法區別，會造成誤殺。
裝置序列號什麼的只對移動裝置有效，PC上面太容易偽造。我的做法是偷偷地給客戶端埋個坑，這個不能告訴你，告訴你就不靈了。。。
如果乙個介面同時包含獲取和新增，RESTful API 該如何設計？
小馬 以前按著restful的介面寫過幾個專案，也看過一些其他作者的一些看法，感覺restful是乙個不夠通用的設計風格，所以也不建議為啦 restful 而 restful 只吸取優點就好。比如無狀態的優點，至於介面用get還是post還是patch等，建議按通用的post或者同時支援多種meth...
如果有乙個學霸她每次數學能考109 滿120 突然有一次沒及格，老師還會喜歡他嗎？
韓小光 初三時我也是，從來沒下過110，後來有一次考了九十多，數學老師很驚訝，把我家長叫來問我最近怎麼了，是不是壓力大。老師不會不喜歡你的，只會幫你找原因。放心吧 今天做數學題了嗎 人有失手，馬有失蹄。一次失誤不會影響啥的，好好學習，仔細認真就好。分數是乙個方面，更重要的是乙個人的品質，比如 勤奮，...
如果有4個門，只有乙個門後面有你想要的東西，怎麼選擇得到的概率最大？
綠葉海天牛 這種問題本質是,原本4個門,每個門之後是車的概率是1 4,然後問題來了,當確定了2個門不是的時候,這2個門的概率 1 4 2 1 2 分配 到哪些門上?如何分配?聽起來很詭異,因為實際上這麼理解與現實不符,概率是針對事件的,而不是物體 第一種情況,主持人知道每一扇門後面是什麼,他故意排除...