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

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

　　以軟件工程師的身份工作

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

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

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

分析之前

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

分布式限流強烈推薦使用redis lua或者nginx lua來實現(xiàn)。

這里用2個限流條件來做示例講一下常見的限流算法：

接口1它10秒鐘很大允許訪問100次

接口2它10秒鐘很大允許每個人訪問100次。

計數(shù)器算法

這個算法可以說是限流算法中簡單的一種算法了。

核心思想

計數(shù)器算法的意思呢就是當接口在一個時間單位中被訪問時，我就記下來訪問次數(shù)，直到它訪問的次數(shù)到達上限。

涉及變量

接口（key）

時間單位（expire）

允許訪問多少次（limit）

訪問次數(shù)（value）

條件一

當一個請求過來時，我們就會得到這個key。

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

條件二

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

相比于條件一來說就是同一個key對應了多個用戶。那么我們只需要把key加上用戶的信息就可以了。比如說 key_用戶1、key_用戶2。

漏桶算法核心思想

漏桶算法的意思呢就是一個接口在一個時間單位中允許被訪問次數(shù)是動態(tài)變化的（假如一分鐘允許訪問60次，那么從開始計時時不管有沒有被訪問第59秒只允許訪問59次，30秒只允許30次）。為什么這樣呢，因為有另外一個線程在進行遞減操作

遞減間隔時間（interval）

遞減步長（step）

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

key的訪問時間（lastUpdateTime）

當前時間（nowTime）（注意nowTime的取值應為應用取得的時間而不是redis或者nginx取得的時間）

條件一線程一：

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

快進5個月……

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

由于受到許多其他問題的困擾，工程師們又回到了繪圖板——這次是用Azure SQL替換存儲層！我不記得具體的細節(jié)，但是這個改變增加了大約40%的額外時間和成本。

管理層很不高興，這個項目幾乎掉了。但是團隊的工程師們非常好，他們能夠完成這個項目，盡管有了一些延遲和初的錯誤的技術決定。

這個項目有一個圓滿的結局——但它也可能不是這樣的。事實上，很多內(nèi)部項目都被關閉了，因為他們不能在承諾的日期范圍內(nèi)交付承諾的功能。

那么，您如何知道NoSQL解決方案適合您的下一個軟件項目呢？首先問問你自己和你的團隊這十個問題：