二，令牌取號方案設計
三，richclient號碼桶設計
任何乙個服務都有自己的能力上限（qps上限）。為了服務有良好的健壯性，當請求超過能力上限時期望服務仍然健康的對外提供服務，而不是資源耗盡服務不可用。該wiki提供一種通用的限流方案，該方案不僅適用於提供http服務的專案，也使用於提供thrift介面的服務（octo已經提供了限流支援）。
本質上存在兩種限流的機制，一種是基於桶容器均勻流速的方法，另外一種是基於令牌取號的方案。
思路很簡單：有乙個容器桶，該桶裡面裝有需要待處理的request請求。桶均勻的按照一定的流速（處理請求服務的可接受處理速度）將請求餵給服務。
優勢：劣勢：
思路比較巧妙：有個號碼桶，裡面裝的是號碼。有乙個生產者按照一定速度（服務的可接受速度）放號碼到號碼桶。
每次外圍來乙個請求，先去號碼桶取號。如果取到號碼，則對該請求做業務處理。如果取不到號碼，對請求做限流處理（拋棄或者別的簡易操作）。
優勢：劣勢：
限流流程如下圖：
問題的關鍵就是號碼桶的設計。因為該方案中的限流並不是僅針對單機，而是針對乙個服務（集群），所以乙個集群需要乙個號碼桶。
號碼桶有兩種設計方案，一種是集中式號碼桶，另外一種是richclient號碼桶。
針對乙個api，在限流系統server端有乙個對應的號碼桶（可以採用redis的queue實現）。服務提供者在處理乙個請求的時候先需要從限流系統的server獲取乙個號碼。
如果獲取到號碼，則進行業務邏輯處理。如果獲取不到碼號，則進行限流處理。
優勢：劣勢：
該方案與集中式號碼桶思路相反，將壓力巨大的號碼桶分布在限流系統的客戶端（為服務提供方支援乙個限流client）。限流server只需做指令下達就行。
號碼的生產直接放在client端。這樣能減輕限流server的壓力，同時減少獲取號碼的時間。
優勢：劣勢：
每個節點針對乙個需要限流的api有乙個單獨的號碼桶，該號碼桶需要滿足：
過期號碼自動及時剔除。當生產者速度很大，消費者速度很小的時候，會有大量的過期號碼牌。這個時候需要能及時的清楚佇列中過期的號碼牌，避免占用過多的記憶體
佇列有界。防止過大的消耗記憶體資源，導致資源耗盡
滿足高併發，執行緒安全
消費者優先消費新的號碼牌
當生產者生產號碼速度超過消費者消費速度的時候就會導致號碼過剩現象。號碼過剩會帶來兩個問題：
生產過多的號碼會給**過期號碼帶來壓力
會占用較多的記憶體資源
因為號碼桶能**過期號碼，同時佇列有界。所以不會導致資源耗盡問題。
號碼不足就是限流的場景。如果沒有從本地節點獲取到號碼就進入限流分支。
節點增加（或者減少）會導致單個節點生產號碼速度下降（或者上公升）。
通過將活著的節點註冊到zk上
預先配置好的該api集群的qps
通過maxqps以及當前活著的節點數目就可以知道每個節點生產者的速度
通知每個生產者修改發放號碼速度
TinyURL設計方案
現在貌似tinyurl很火爆，也逐漸成為一種流行趨勢。對應於php版本的tinyurl也有一些演算法，其實本質上來說是一種hash。除此之外，還有另外一種tinyurl方案 類似於http img.ly 其實這種設計 是最簡單的，沒有使用hash，而是遞增，這種的好 處就是資料庫 可以無限擴充套件，...
許可權設計方案
簡要介紹一下該許可權管理系統的特點，該系統功能上做到了靈活授權，操控細緻，許可權可以細到按鈕及超鏈級別,而且部署簡單，下面談談我自己的設計經驗。該系統主要功能如下 1 自定義操作動作 如增加 刪除 修改 審核等，不再是以前見過的那種粗粒度的 按模組分配許可權，或者稍微先進點的規定死某幾個操作了 2 ...
快取設計方案
redis提供的快取的api，但是在開發階段，如果每個人都自己呼叫原生api實現快取時，由於每個人的水平問題，會導致實現方案千差萬別，同事又很難統一管理維護 通過提供spring的annotation，實現快取方案的統一 target retention retentionpolicy.runtim...