結束了一周繁忙的工作，趁着周末，小編手中的鍵盤早已飢渴難耐了，想知道上期省略號中發生了什么有趣的故事么？且聽小編娓娓道來，結尾有彩蛋。
目錄
風月前場
春風再續，書接上回，春香園的老鴇媽媽，給這位血氣方剛的騷年挑選了一位佳人A，於是乎騷年興致勃勃的進入了閨房，宜言飲酒，與子同歡，琴瑟在御，莫不靜好，誰知佳人A突然來月事了(這個事先老鴇是不知道的)
我了個擦，春宵一刻值千金啊，趕召喚系老鴇兒，老鴇先是把A從侍客名單中剔除，隨后趕緊給這位騷年換了一位佳人B，歌管樓台聲細細，秋千院落夜沉沉，哈哈哈，又是一個難忘的夜晚......
夢回現實
哎，少年，醒醒，別做夢了，快起來搬磚了
其實在實際生產中，我們的負載均衡器可能要更加溫柔體貼智能，不能讓用戶有一絲感覺到服務器也來大姨媽。
-
還記得我們的TT貓，下單失敗的場景么？被強行跳轉到登陸頁。
-
還記得雙十一妹子那幽怨的小眼神么？可能你已在偷偷樂了。
-
還記得程序員小明瞎白活了一頓原理么？其實可能他自己都沒搞明白。
模擬老鴇
在講如何體貼之前，先給大家傳授幾種老鴇經常使用的分配手法，為了讓大家更加形象直觀的了解老鴇的內心，小編決定帶大家扒開來看，當然了鴇媽的內心也是一坨代碼而已。
首先我們定義一個OldBird，接着安排四個smallBirds值班。
/**
* 老鴇
* 創建時間 2017年9月17日
*/
public class OldBird {
// Key代表風塵X子，Value代表該風塵X子的受歡迎程度
public static Map<String, Integer> smallBirds = new ConcurrentHashMap<String, Integer>();
static {
smallBirds.put("野雞", 1);
smallBirds.put("幺二", 2);
smallBirds.put("長三", 3);
smallBirds.put("書寓", 4);
}
}
開張了，開張了，顯然第一位客人並沒有入的了鴇兒的法眼，隨機了一個后繼續嗑她的瓜子。
/**
* 隨機
* 創建時間 2017年9月17日
*/
public class Random {
public static String getServer() {
// 獲取值班名單
Set<String> keySet = ServerMap.servers.keySet();
ArrayList<String> keyList = new ArrayList<String>();
keyList.addAll(keySet);
// 老鴇看人辦事 精打細算了一下、隨即了一個
java.util.Random random = new java.util.Random();
int randomPos = random.nextInt(keyList.size());
// 程序員小明獲取了一個smallBird
return keyList.get(randomPos);
}
}
可能是鴇媽的隨機有點看心情，導致后院有些人有點不高興了，於是乎趕緊采取了另一種策略。
/**
* 輪詢
* 創建時間 2017年9月17日
*/
public class RoundRobin {
private static Integer pos = 0;
public static String getServer() {
//獲取今日值班名單
Set<String> keySet = ServerMap.servers.keySet();
ArrayList<String> keyList = new ArrayList<String>();
keyList.addAll(keySet);
//有些人 活太少 可能會不高興 還是排號來吧
String server = null;
synchronized (pos) {
if (pos >= keySet.size())
pos = 0;
server = keyList.get(pos);
pos++;
}
// 程序員小明獲取了一個smallBird
return server;
}
}
這時候大茶壺急急忙忙的趕到老鴇身邊，哎，別嗑了，韋爺點名要書寓，趕緊給安排安排，老鴇一想常客啊，不行，我得好好編排一下，省的老被打擾。
/**
* 源地址哈希
* 創建時間 2017年9月17日
*/
public class Hash {
public static String getServer()
{
//獲取今日值班名單
Set<String> keySet = ServerMap.servers.keySet();
ArrayList<String> keyList = new ArrayList<String>();
keyList.addAll(keySet);
//韋爺 悠哉的進來的 點名要書寓
String remoteGuest = "韋爺";
//老鴇給韋爺 設置固定編號
int hashCode = remoteGuest.hashCode();
int serverListSize = keyList.size();
int serverPos = hashCode % serverListSize;
//韋爺獲取到了指定服務
return keyList.get(serverPos);
}
}
讀到最后，小伙伴們可能要問了，那個Map中的Value並沒有起作用啊，讓老鴇吃了么？其實，只是感覺用在這里不妥而已，有些事，你懂我懂大家都懂。
具體到生產架構中，應該是這個樣子的
/**
* 服務器負載均衡集群組
* 創建時間 2017年9月17日
*/
public class ServerMap {
// Key代表服務器，Value代表該服務的權重
public static Map<String, Integer> servers = new ConcurrentHashMap<String, Integer>();
static {
//這里有四個服務 權重分別是1234
servers.put("1核1G-服務器", 1);
servers.put("2核2G-服務器", 2);
servers.put("3核3G-服務器", 3);
servers.put("4核4G-服務器", 4);
}
}
能者多勞，權重視服務器的性能而定，下面的算法，服務器4每次有百分之四十的幾率被獲取到。
/**
* 加權輪詢
* 創建時間 2017年9月17日
*/
public class WeightRoundRobin {
private static Integer pos = 0;
public static String getServer()
{
//取得服務器List
Set<String> keySet = ServerMap.servers.keySet();
Iterator<String> iterator = keySet.iterator();
//計算權重總數 累加 比如 4核4G-服務器 權重為4 上述10個服務器中存在4個4核4G-服務器服務 增加隨機或者輪詢幾率
List<String> serverList = new ArrayList<String>();
while (iterator.hasNext())
{
String server = iterator.next();
int weight = ServerMap.servers.get(server);
for (int i = 0; i < weight; i++)
serverList.add(server);
}
String server = null;
synchronized (pos)
{
if (pos >= keySet.size())
pos = 0;
server = serverList.get(pos);
pos ++;
}
return server;
}
}
說了這么多，以上只是幾種簡單的負載均衡算法，在 記一次JavaWeb網站技術架構總結 中有提到十種負載均衡策略以及其優缺點，有興趣的同學可以一看。
會話機制
各位看官莫急，要想弄明白故障轉移是怎么回事，必須要弄明白客戶端-服務端的會話認證機制。
由於HTTP協議本身是無狀態的，這與HTTP協議本來的目的是相符的，那么小馬哥是怎么知道那些用戶買了那些東西的呢？
以Tomcat為例，大家都知道session是在服務器端創建並存儲到容器的JVM內存中的，瀏覽器初次訪問服務器會生成一個叫JSESSIONID的cookie，瀏覽器的每次請求都會附帶這個cookie，服務端通過JSESSIONID會找到內存中對應的狀態信息。
程序員小明，打開TT貓，輸入自己的賬號密碼，附帶cookie信息請求到了后台，TT貓后台校驗成功以后，會把用戶信息保存到JSESSIONID對應的內存中，這樣小明和TT貓就可以無障礙的深入交流了。
這個過程也可以用以下示意圖來描述：
如果你覺得會話機制如此簡單，那可就有點高看小編了，篇幅有限，對會話機制感興趣的同學只能自行查閱資料了。
故障轉移
老鴇之所以能快速安撫騷年使其順利度過這纏綿之夜，有沒有感受到老鴇強大的人工智能氣息？
其實我們的負載均衡器Nginx，也是做的相當智能的，如果后端節點服務器宕掉的話，Nginx通過自帶的模塊可以把這台壞掉的服務踢出upstream負載集群組，然后自動切換到健康節點來提供訪問。
有過開發經驗的小伙伴，都知道服務分有狀態和無狀態。
-
無狀態服務（Stateless Service）：游客瀏覽商品、搜索商品等等這種不需要鑒權的操作。
-
有狀態服務（Stateful Service）: 添加購物車，下單，支付等等需要用戶認證的操作。
對於這種無狀態的服務請求，不管集群組使用任何負載均衡算法（隨機、輪詢、hash），只要有一個存活，小馬哥的TT貓就可以提供正常服務。
但是對於支付這種需要用戶認證的操作，不得不說，我們要選擇合適的負載均衡算法。
服務獨自存儲用戶狀態
- 隨機、輪詢算法，小明可能一輩子都無法登陸TT貓
- hash算法，單一服務宕掉的話會導致用戶狀態丟失
服務統一存儲用戶狀態
總結
秋名山上行人稀，常有框架較高低，如今原理依舊在，不見當年老框架。
底層原理可能你這輩子都不過時，解決問題的能力永遠都不過時，積極向上的求知欲永遠是你的強大后盾。
既定目標，做個有追求的程序員，如果你連算法數據結構都能搞得明白，網絡傳輸都可以手到擒來，怎學不會簡單的API調用？
塞內加在《論生命之短暫》中說過“如果一個人出海遇到狂風暴雨，被變換肆虐的風吹得團團轉，你可能會覺得他航行了很遠。其實航行得並不遠，只是浮沉動盪的時間長而已”，沒錯如今的知識就像出海時遇到的狂風暴雨，我們只是被吹的原地團團轉而已，並沒有在知識的海洋航行很遠。