發(fā)展史
1、很久很久以前，Web 基本上就是文檔的瀏覽而已， 既然是瀏覽，作為服務(wù)器， 不需要記錄誰在某一段時間里都瀏覽了什么文檔，每次請求都是一個新的HTTP協(xié)議， 就是請求加響應(yīng)， 尤其是我不用記住是誰剛剛發(fā)了HTTP請求， 每個請求對我來說都是全新的。這段時間很嗨皮。
2、但是隨著交互式Web應(yīng)用的興起，像在線購物網(wǎng)站，需要登錄的網(wǎng)站等等，馬上就面臨一個問題，那就是要管理會話，必須記住哪些人登錄系統(tǒng)， 哪些人往自己的購物車中放商品， 也就是說我必須把每個人區(qū)分開，這就是一個不小的挑戰(zhàn)，因為HTTP請求是無狀態(tài)的，所以想出的辦法就是給大家發(fā)一個會話標(biāo)識(session id), 說白了就是一個隨機的字串，每個人收到的都不一樣， 每次大家向我發(fā)起HTTP請求的時候，把這個字符串給一并捎過來， 這樣我就能區(qū)分開誰是誰了
3、這樣大家很嗨皮了，可是服務(wù)器就不嗨皮了，每個人只需要保存自己的session id，而服務(wù)器要保存所有人的session id ！ 如果訪問服務(wù)器多了， 就得由成千上萬，甚至幾十萬個。
這對服務(wù)器說是一個巨大的開銷 ， 嚴(yán)重的限制了服務(wù)器擴展能力， 比如說我用兩個機器組成了一個集群， 小F通過機器A登錄了系統(tǒng)， 那session id會保存在機器A上， 假設(shè)小F的下一次請求被轉(zhuǎn)發(fā)到機器B怎么辦？ 機器B可沒有小F的 session id啊。
有時候會采用一點小伎倆： session sticky ， 就是讓小F的請求一直粘連在機器A上， 但是這也不管用， 要是機器A掛掉了， 還得轉(zhuǎn)到機器B去。
那只好做session 的復(fù)制了， 把session id 在兩個機器之間搬來搬去， 快累死了。
