“你們的公司文化是什么樣的？”

公司文化也許是個(gè)非常含糊的概念，但即便像開(kāi)放辦公室還是小隔間這樣的小事情都會(huì)顯著改變你與同事的日?；?dòng)。這方面沒(méi)有普遍性的危險(xiǎn)信號(hào)，但是要確保他們的答案是你可以按照每周 40 小時(shí)的節(jié)奏持續(xù)相處數(shù)年的東西。

　　以軟件工程師的身份工作

在這個(gè)階段，如果你面試過(guò)程中表現(xiàn)不錯(cuò)并且喜歡面試官回答你問(wèn)題的方式，你被錄用的可能性就很高了。

祝賀，你正式成為一名工程師了！

那現(xiàn)在又該如何呢？好吧，現(xiàn)在是時(shí)候重新學(xué)量編碼和工作方面的東西了。既然我們是程序員，我們就從討論代碼開(kāi)始。

分析之前

依我個(gè)人的理解來(lái)說(shuō)限流的話應(yīng)該靈活到可以針對(duì)每一個(gè)接口來(lái)做。比如說(shuō)一個(gè)類里面有5個(gè)接口，那么我的限流插件就應(yīng)該能針對(duì)每一個(gè)接口就行不同的限流方案。所以呢，既然針對(duì)的每個(gè)接口所以就需要一個(gè)可以標(biāo)示這個(gè)接口的key（我取的是類名 方法名 入?yún)ⅲＩ习鄷r(shí)間：開(kāi)發(fā)經(jīng)常加班熬夜，常常一天24小時(shí)睡不了多久，更別提照顧家庭。

分布式限流強(qiáng)烈推薦使用redis lua或者nginx lua來(lái)實(shí)現(xiàn)。

這里用2個(gè)限流條件來(lái)做示例講一下常見(jiàn)的限流算法：

接口1它10秒鐘很大允許訪問(wèn)100次

接口2它10秒鐘很大允許每個(gè)人訪問(wèn)100次。

計(jì)數(shù)器算法

這個(gè)算法可以說(shuō)是限流算法中簡(jiǎn)單的一種算法了。

核心思想

計(jì)數(shù)器算法的意思呢就是當(dāng)接口在一個(gè)時(shí)間單位中被訪問(wèn)時(shí)，我就記下來(lái)訪問(wèn)次數(shù)，直到它訪問(wèn)的次數(shù)到達(dá)上限。

涉及變量

接口（key）

時(shí)間單位（expire）

允許訪問(wèn)多少次（limit）

訪問(wèn)次數(shù)（value）

條件一

當(dāng)一個(gè)請(qǐng)求過(guò)來(lái)時(shí)，我們就會(huì)得到這個(gè)key。

123456789 if(存在key){ value ; if(value>=limit){ 不能訪問(wèn) } }else{ 添加key，value為1 設(shè)置key過(guò)期時(shí)間為expire }

條件二

既然條件一已經(jīng)實(shí)現(xiàn)了，那條件二會(huì)復(fù)雜么 ？

相比于條件一來(lái)說(shuō)就是同一個(gè)key對(duì)應(yīng)了多個(gè)用戶。那么我們只需要把key加上用戶的信息就可以了。比如說(shuō) key_用戶1、key_用戶2。

漏桶算法核心思想

漏桶算法的意思呢就是一個(gè)接口在一個(gè)時(shí)間單位中允許被訪問(wèn)次數(shù)是動(dòng)態(tài)變化的（假如一分鐘允許訪問(wèn)60次，那么從開(kāi)始計(jì)時(shí)時(shí)不管有沒(méi)有被訪問(wèn)第59秒只允許訪問(wèn)59次，30秒只允許30次）。為什么這樣呢，因?yàn)橛辛硗庖粋€(gè)線程在進(jìn)行遞減操作

遞減間隔時(shí)間（interval）

遞減步長(zhǎng)（step）

剩余可訪問(wèn)次數(shù)（value）

key的訪問(wèn)時(shí)間（lastUpdateTime）

當(dāng)前時(shí)間（nowTime）（注意nowTime的取值應(yīng)為應(yīng)用取得的時(shí)間而不是redis或者nginx取得的時(shí)間）

條件一線程一：

12345678 if(存在key){ value--； if(value<=0){ 不能訪問(wèn) } }else{ 添加key，設(shè)置value為limit }

快進(jìn)5個(gè)月……

該系統(tǒng)開(kāi)始經(jīng)歷許多關(guān)于維護(hù)CRUD操作完整性的問(wèn)題。設(shè)計(jì)用來(lái)處理事務(wù)的瘦應(yīng)用程序邏輯層已經(jīng)不再那么薄了。升級(jí)和向后兼容性的故事開(kāi)始變得更加復(fù)雜。

由于受到許多其他問(wèn)題的困擾，工程師們又回到了繪圖板——這次是用Azure SQL替換存儲(chǔ)層！我不記得具體的細(xì)節(jié)，但是這個(gè)改變?cè)黾恿舜蠹s40%的額外時(shí)間和成本。

管理層很不高興，這個(gè)項(xiàng)目幾乎掉了。但是團(tuán)隊(duì)的工程師們非常好，他們能夠完成這個(gè)項(xiàng)目，盡管有了一些延遲和初的錯(cuò)誤的技術(shù)決定。

這個(gè)項(xiàng)目有一個(gè)圓滿的結(jié)局——但它也可能不是這樣的。事實(shí)上，很多內(nèi)部項(xiàng)目都被關(guān)閉了，因?yàn)樗麄儾荒茉诔兄Z的日期范圍內(nèi)交付承諾的功能。

那么，您如何知道NoSQL解決方案適合您的下一個(gè)軟件項(xiàng)目呢？首先問(wèn)問(wèn)你自己和你的團(tuán)隊(duì)這十個(gè)問(wèn)題：