開放平台，我相信大家並不陌生。當需要把一個產品本身的一些功能開放出去，可以讓三方開發者接入和使用，這就是開放平台做的事情。
為什么我們能用微信登錄很多其他的應用，這就是因為這些應用通過接入微信開放平台提供的能力實現了授權登錄。
開放平台流控需求分析
對於開放平台來說，有一個功能是必須要有的，那就是API的流控。
對於每一個接入開放平台的應用，都會分配一個Appkey，這個Appkey下面會關聯你申請了哪些API。然后接入的API有些是不限量，可以一直調用。有些是需要申請調用包，比如一天10萬次的調用量。
除了總量的限制，還有對頻率的限制。比如每秒每個API調用頻率的限制，每秒每個Appkey調用頻率的限制。
要實現這些流控的功能，最好的方式就是已經有一個流量治理平台，里面提供了限流的功能。像開放平台這種還不屬於普通的系統限流，有點偏業務限流了，因為有具體的數量指標。
技術選型
這也就是前面文章里面跟大家講什么時候要自研，什么時候可以直接用開源。當需求無法滿足，就只能自研了。
自研可以在開源的基礎上開發，增加業務限流的功能，支持租戶的功能，可以多租戶接入。支持按Appkey時間內的總量限流，支持API時間內的數量限流。
如果沒有現成的治理平台可以接入，那么就需要業務方自己進行開發。自己開發一般都會使用MySQL+Redis去實現。
實現原理
MySQL用於存儲基本配置信息，比如Appkey對應的流控信息，API對應的流控信息。
Redis用於數量扣減提高性能使用，使用這個方案必然會帶來一個數據一致性的問題，就是MySQL里的數據如何跟Redis保持一致。
為什么要用Redis?
假設不用Redis也就意味着每次調用后都需要更新MySQL里面的調用次數。在高並發的情況下，性能肯定是需要優先考慮的問題。
用Redis還是為了扛高並發，而且這個業務場景也不復雜，就一個計數而已，Redis本身也支持原子操作。
Redis只是用來輔助使用的，並不是作為業務數據的存儲系統。所以這里就涉及到數據一致性的問題。
如何保持一致？
這里我們再思考下，是否需要強一致性？
不需要，而且這個場景也不好做。所以只需要保證最終一致即可。
對於計數信息，可以采取提前同步到Redis中，也可以采用延遲加載的方式。比如對某個Appkey下的某個API進行計數，key可以這樣設計 Appkey:API ，過期時間就是你要限制的時間段，比如按天來限制。
這里需要有個定時同步Redis里面的計數信息到MySQL里面的任務，時間間隔可以自行設置。假設Redis沒做持久化，重啟后數據丟失，這個時候會從MySQL里面查出計數信息進行初始化，如果你同步間隔是10分鍾一次，那么只會有這10分鍾的調用次數丟失。
我認為對於一般開放平台來說，丟了一些計數信息沒啥大問題，無非就是讓三方多調用一些數量的接口。但是具體業務具體分析，如果你們的API是按次計費的，那么本方案可能不適合，涉及到錢的還是得強一致。
單機還是集群？
這個話題，前面的文章《流量治理神器-Sentinel的限流模式，選單機還是集群？》里面我們也聊到過。
那么在開放平台的這個業務場景下，毫無疑問的是要選擇集群限流。首先它是一個業務場景的限流，有明確的限流指標，單機限流沒有全局的存儲，無法反饋本身的結果給其他服務，就會導致業務結果不正確。