前言

開(kāi)放平臺(tái)流控需求分析

?

對(duì)于開(kāi)放平臺(tái)來(lái)說(shuō)，有一個(gè)功能是必須要有的，那就是API的流控。

?

對(duì)于每一個(gè)接入開(kāi)放平臺(tái)的應(yīng)用，都會(huì)分配一個(gè)Appkey，這個(gè)Appkey下面會(huì)關(guān)聯(lián)你申請(qǐng)了哪些API。然后接入的API有些是不限量，可以一直調(diào)用。有些是需要申請(qǐng)調(diào)用包，比如一天10萬(wàn)次的調(diào)用量。

?

除了總量的限制，還有對(duì)頻率的限制。比如每秒每個(gè)API調(diào)用頻率的限制，每秒每個(gè)Appkey調(diào)用頻率的限制。

?

要實(shí)現(xiàn)這些流控的功能，最好的方式就是已經(jīng)有一個(gè)流量治理平臺(tái)，里面提供了限流的功能。像開(kāi)放平臺(tái)這種還不屬于普通的系統(tǒng)限流，有點(diǎn)偏業(yè)務(wù)限流了，因?yàn)橛芯唧w的數(shù)量指標(biāo)。

技術(shù)選型

?

這也就是前面文章里面跟大家講什么時(shí)候要自研，什么時(shí)候可以直接用開(kāi)源。當(dāng)需求無(wú)法滿足，就只能自研了。

?

自研可以在開(kāi)源的基礎(chǔ)上開(kāi)發(fā)，增加業(yè)務(wù)限流的功能，支持租戶的功能，可以多租戶接入。支持按Appkey時(shí)間內(nèi)的總量限流，支持API時(shí)間內(nèi)的數(shù)量限流。

?

如果沒(méi)有現(xiàn)成的治理平臺(tái)可以接入，那么就需要業(yè)務(wù)方自己進(jìn)行開(kāi)發(fā)。自己開(kāi)發(fā)一般都會(huì)使用MySQL+Redis去實(shí)現(xiàn)。

?

實(shí)現(xiàn)原理

MySQL用于存儲(chǔ)基本配置信息，比如Appkey對(duì)應(yīng)的流控信息，API對(duì)應(yīng)的流控信息。

?

Redis用于數(shù)量扣減提高性能使用，使用這個(gè)方案必然會(huì)帶來(lái)一個(gè)數(shù)據(jù)一致性的問(wèn)題，就是MySQL里的數(shù)據(jù)如何跟Redis保持一致。

?

為什么要用Redis?

?

假設(shè)不用Redis也就意味著每次調(diào)用后都需要更新MySQL里面的調(diào)用次數(shù)。在高并發(fā)的情況下，性能肯定是需要優(yōu)先考慮的問(wèn)題。

?

用Redis還是為了扛高并發(fā)，而且這個(gè)業(yè)務(wù)場(chǎng)景也不復(fù)雜，就一個(gè)計(jì)數(shù)而已，Redis本身也支持原子操作。

?

Redis只是用來(lái)輔助使用的，并不是作為業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)系統(tǒng)。所以這里就涉及到數(shù)據(jù)一致性的問(wèn)題。

?

如何保持一致？

?

這里我們?cè)偎伎枷?，是否需要?qiáng)一致性？

?

不需要，而且這個(gè)場(chǎng)景也不好做。所以只需要保證最終一致即可。

?

對(duì)于計(jì)數(shù)信息，可以采取提前同步到Redis中，也可以采用延遲加載的方式。比如對(duì)某個(gè)Appkey下的某個(gè)API進(jìn)行計(jì)數(shù)，key可以這樣設(shè)計(jì) Appkey:API ，過(guò)期時(shí)間就是你要限制的時(shí)間段，比如按天來(lái)限制。

?

這里需要有個(gè)定時(shí)同步Redis里面的計(jì)數(shù)信息到MySQL里面的任務(wù)，時(shí)間間隔可以自行設(shè)置。假設(shè)Redis沒(méi)做持久化，重啟后數(shù)據(jù)丟失，這個(gè)時(shí)候會(huì)從MySQL里面查出計(jì)數(shù)信息進(jìn)行初始化，如果你同步間隔是10分鐘一次，那么只會(huì)有這10分鐘的調(diào)用次數(shù)丟失。

?

?

?

我認(rèn)為對(duì)于一般開(kāi)放平臺(tái)來(lái)說(shuō)，丟了一些計(jì)數(shù)信息沒(méi)啥大問(wèn)題，無(wú)非就是讓三方多調(diào)用一些數(shù)量的接口。但是具體業(yè)務(wù)具體分析，如果你們的API是按次計(jì)費(fèi)的，那么本方案可能不適合，涉及到錢的還是得強(qiáng)一致。

?

?

?

單機(jī)還是集群？

這個(gè)話題，前面的文章《流量治理神器-Sentinel的限流模式，選單機(jī)還是集群？》里面我們也聊到過(guò)。

?

那么在開(kāi)放平臺(tái)的這個(gè)業(yè)務(wù)場(chǎng)景下，毫無(wú)疑問(wèn)的是要選擇集群限流。首先它是一個(gè)業(yè)務(wù)場(chǎng)景的限流，有明確的限流指標(biāo)，單機(jī)限流沒(méi)有全局的存儲(chǔ)，無(wú)法反饋本身的結(jié)果給其他服務(wù)，就會(huì)導(dǎo)致業(yè)務(wù)結(jié)果不正確。

?

大家好，我是從古代穿越過(guò)來(lái)的美男子：架構(gòu)擺渡人。我將把我的武功秘籍全部傳授與你們，覺(jué)得有用請(qǐng)分享給身邊的朋友。來(lái)個(gè)三連吧，感謝各位！另外我還在B站錄制了《真實(shí)訂單業(yè)務(wù)，億級(jí)數(shù)據(jù)帶你實(shí)戰(zhàn)分庫(kù)分表》的實(shí)戰(zhàn)課程，記得去學(xué)習(xí)哦！

點(diǎn)擊閱讀原文直達(dá)主頁(yè)