我們在生產(chǎn)中會遇到這樣的場景：
1：接口限速：針對每個接口分不同維度的限制調(diào)用次數(shù)：
如：請求url -/order/xxx/ , -/stock/xxx//
A接口限制 200次/分鐘稳强，1000次/小時，10000次/天
B接口限制 300次/分鐘，2000次/小時偏友，50000次/天
那么我們怎么設(shè)計這套服務(wù)那，
第一步設(shè)計后臺管理功能，支持針對不同的接口設(shè)置不同維度的限制規(guī)則。 存儲到redis中
第二步設(shè)計規(guī)則控制引擎：首先想到用分布式redis 存儲規(guī)則后藕甩，針對每種規(guī)則生成計數(shù)器，每個計數(shù)器都設(shè)置相應(yīng)的過期時間周荐，在過期時間內(nèi)的計數(shù)都是有效的狭莱。超過訪問計數(shù)閾值或者次數(shù)減為零，則認為訪問無效做無效處理概作。
這樣做看似沒有問題但是針對大型的開放平臺來說調(diào)用量是海量的腋妙，redis本身的吞吐將成為瓶頸。如果是小型網(wǎng)站是可以采用這種方案的讯榕。
那么如何解決這個問題那骤素，我們想能不能用內(nèi)存緩存來做那，這樣我們用每個應(yīng)用服務(wù)的本地緩存來記錄規(guī)則和來計數(shù)就不會有分布式緩存的瓶頸了愚屁。那么本地緩存又存在數(shù)據(jù)如何持久化济竹，保證一致性的問題，一般我們都是用應(yīng)用的本地緩存來做讀服務(wù)霎槐，那么針對這種計數(shù)服務(wù)也用應(yīng)用的本地緩存的話就要考慮是否可以犧牲嚴格的一致性問題送浊，只要保證最終相對一致性就可以， 我們從全局分析這個場景其實是沒有那么嚴格的要求一定要保證強一致性的丘跌，好了我們看怎么來這幾這套架構(gòu)吧：
第一：要考慮我們的服務(wù)一定是分布式部署多臺的袭景，那么每個上面都是全量數(shù)據(jù)，就限制不住了闭树，相當(dāng)于N倍的計數(shù)耸棒，還有一種方案就是在負載均衡層做hash保證同一個接口總是命中同一個服務(wù)，那么服務(wù)又成了單點蔼啦。
第二榆纽，怎么破，我們用redis存儲全量數(shù)據(jù)捏肢，然后我們事先預(yù)估我們部署了幾個服務(wù)，那么我們每個服務(wù)只從redis中將自己分到的那部分減掉饥侵，以此類推鸵赫，這樣每個服務(wù)就差不多均勻啦，如果還有剩余那么某個服務(wù)消耗完之后再去緩存中去取躏升，直到減為零辩棒，這個也有個問題那就是可能偶爾會提示用戶調(diào)用資源不足，但是再次調(diào)用打到其他服務(wù)上，可能又可以了一睁，不過沒關(guān)系钻弄，我們這樣已經(jīng)保證了海量調(diào)用的可靠和性能，犧牲一些一致性也是沒辦法的事情者吁，這個用戶容忍度應(yīng)該可以接受窘俺，
場景二，再有黑白名單的場景复凳，也可以用這個方式不過還得借助zk瘤泪，在注冊zk的時候添加Watcher 事件來監(jiān)聽此節(jié)點的變化，當(dāng)節(jié)點來時再看會通知watcher列表中正在監(jiān)聽此節(jié)點的所有機器實現(xiàn)時刷新黑白名單的切換
下圖為引用小灰的圖： watcher 過程
場景三育八，全局唯一訂單號对途，每個業(yè)務(wù)的當(dāng)前最大單號都存在mysql或者redis中，是一天記錄髓棋，每個應(yīng)用服務(wù)按照規(guī)則每次加鎖后取出一定的號段实檀，放到本地內(nèi)存，這樣每次從本地內(nèi)存就可以獲取到訂單號啦按声，非常高效劲妙，但是這樣如果有某一臺服務(wù)掛了，會浪費一些單號儒喊，不過也是可以忍受的镣奋，如果怕浪費的多可以把偏移量設(shè)置的小一些
