等啊等，盼啊盼，11月份終於來了，在11月01日的00:00分，你可以清空掉所有的預售訂單，還有購買商家所推出的限時折扣如前十五分鐘購買5折等，買的人很開心，商家也很開心。然而程式設計師們不開心了，提**用服務的團隊、提供監控服務的團隊、提供基礎設施服務的團隊都繃著一根神經，生怕是自己這一環掛了，導致整個服務鏈路崩塌，最後被老闆祭天了。
而今天我們給大家帶來了一劑良藥，那便是針對高併發的解決方案。所謂高併發指的是請求突然大量地襲來，比如雙十一整點搶購這種，伺服器正常情況下的流量請求是50000個，雙十一來了500000個，這叫人伺服器咋扛得住嘛。而應對高併發，我們也有三**寶：快取、降級、限流。所謂快取就是把使用者最常訪問的資料放起來，使用者請求來時，先訪問快取中的資料，如果快取沒有命中，再訪問後端資料，一定程度緩解了高併發。所謂降級就是非核心服務不讓訪問了、核心服務返回上一級頁面，使用者請求來時，最重要的頁面就是支付，其餘的積分啥的都不重要，因此集中資源給到支付模組使用。所謂限流就是限制流量，原來可以支撐50000個請求，突然來了500000個請求，限制只有60000個請求可以正常訪問，其餘的都暫時先訪問不了。
在限流中，常用的演算法有兩個：漏桶演算法、令牌桶演算法。漏桶演算法就像是乙個漏掉的水桶一樣，水桶底部是空的，無論上面倒多少水下來，漏出去的水都是固定的。漏桶演算法如下所示，在流量場景中，burstyflow代表流量，在0-2秒內突然來了12mbps的突發流量，中間2-7秒沒有流量過來，7-10秒是平穩的流量，可以看到資料不是平穩的，通過漏桶可以將資料變得平穩，每秒出去的流量是3mbps。
它的偽**實現如下，我們定義了乙個漏桶的demo，定義了桶容量、水流出速度、當前水量、時間，通過水量與容量的差來看看是否繼續加水（也就是流量是否還可以繼續進來），如果小於總容量，則請求可以繼續進來，如果大於則請求無法進來了。
另乙個限流演算法是令牌桶演算法，它與漏桶演算法的區別在於允許流量一定程度的改變，不像漏桶演算法始終是固定的流量。那麼什麼是令牌桶演算法呢？
令牌桶演算法就是在桶裡面有一定令牌，我們可以往桶裡不斷的去新增令牌，請求到來時拿到令牌就可以進入下一階段去處理了，拿不到令牌的請求就會處於等待狀態。
它的偽**實現如下，我們定義了令牌桶的大小，令牌放入的速度，當前的令牌量，執行演算法不斷的去新增令牌，如果大於桶容量則停止增加，反之則繼續增加令牌，如果當前令牌數小於1，則不發放令牌，拒絕請求，如果大於1則發放令牌，處理請求。
講完了兩個限流演算法後，我們看看在業務中是如何去實現限流。在微服務架構下，我們把乙個大的應用分為多個微服務，服務與服務之間通過遠端呼叫進行通訊，服務與資料庫之間通過資料庫連線池進行連線，服務內部則通過介面相互呼叫來實現功能。因此整個限流的層次也包含應用層級限制、資源層級限制、介面層級限制。
在應用層級的限制，主要是總併發數的限制，如果超過了閾值則不響應使用者請求，比如tomcat自帶的設定，如maxconnector設定最大連線數、maxthreads設定最大執行緒數。在資源層級的限制，可以使用資料庫連線池、執行緒池等技術，超過執行緒池數則不能連線資料庫，無法響應服務。在介面層級可以對核心介面的呼叫進行限制，單位時間內（如每秒/每分鐘/每小時）最大允許呼叫量，超過之後則呼叫失敗。表層的限制策略都是依託於深層的演算法，而這演算法可以是漏桶或者令牌桶演算法。
無論是漏桶演算法還是令牌桶演算法，都只是工具，最終要服務於業務，通過原理與偽**的結合，你明白如何做實現了嘛？趕緊在你的業務中碼起來吧。無論是直接面對使用者的業務部門，還是服務於業務的基礎設施部門，都必須要對高併發謹慎起來，做好快取降級限流措施。
樹莓派4b公升級核心 樹莓派4B千呼萬喚始出來！
等了n久的樹莓派4b終於在今天下午15點左右在英國發布上市了！我們期待了很久也猜測了很久，看看新發布的樹莓派4b和之前3b 的區別吧！首先我們來看看樹莓派4b的產品特性，以下均以4b作為簡稱。如果下游usb外設總共消耗的電流低於500ma，則可以使用高質量的2.5a電源。這次raspberry pi...