深夜，我偷聽到程序員要對session下手……

我是一個web服務器

我是一個web服務器，個人工做是給人類提供上網服務，我天天要爲數以萬計的人提供網頁瀏覽服務。

已是深夜了，我還在和手下幾個兄弟爲了一件事緊張討論着。

「老大，如今我們天天處理的請求愈來愈多了，session同步的問題不能再拖了，必須想個辦法」

「二哥說的是啊，老大，不能再拖了」

「老二，老三，我們是一個集羣，大家說的問題我不是不知道，我昨天聽程序員們在討論說要給咱們接入一個叫Redis的傢伙，相信這一問題很快就能獲得解決啦，你們再忍忍。」

「Redis，他是誰，什麼來頭？怎麼沒聽過這號人物」

「我也沒見過，等等看吧」

session-cookie時代

究竟是什麼問題，讓咱們兄弟幾個如此着急上火？事情還得從多年之前提及······

那時候，這倆兄弟還沒來，就我一個web服務器，天天處理的不過是一些靜態資源文件，像HTML、CSS、JS、圖片等等，日子過的悠閒自在。

日子一每天過着，互聯網卻悄然發生着變化。除了靜態網頁以外，能夠動態交互的網絡應用開始如雨後春筍般涌現，像各類各樣的論壇啊，購物網站啊之類的。

這家公司的老闆也不例外，招了一幫程序員要搞一套支持動態網頁交互的網站出來。

以往的時候，我只須要按照HTTP協議的規範處理請求就完事兒了。不過動態交互應用出現後，我還得記住每個請求背後的用戶是誰，要否則就張冠李戴，全亂套了。

爲了解決這個問題，程序員們想出了一個叫session的辦法：

瀏覽器登錄之後，我就分配一個session id，表示一個會話，而後返回給瀏覽器，讓它保存着。後續再來請求的時候，就把它給帶上，我就能知道是誰啦！

還別說，這辦法仍是挺管用的，成功解決了用戶身份識別的問題，這一用就是好幾年。

不過，互聯網的發展實在是太快了，用戶量蹭蹭上漲，而我卻發起了愁。

原先用戶量少的時候，session id管理起來倒也簡單，如今用戶愈來愈多，對應的session id數量也與日俱增，我有點不堪重負了。

終於前不久，公司對web服務器進行了擴展，給我找來了兩個小弟，還專門添置了一個nginx來進行負載均衡，這一下咱們變成了3臺web服務器組成的小集羣了。

個人工做一下輕鬆了許多，兩位小兄弟爲了分擔了很多。我原覺得之後的日子要好過一些了，可沒想到，兩位小兄弟的加入卻引入了新的問題。

原先的session id雖然不少，我一我的累是累點，可是方便管理啊！如今人手是增長了，但是這個session id的管理問題卻變得複雜起來。

由於我們如今是個集羣，請求若是發到我這，我給登記了session id，但下一次請求說不定就發到老二那裏，一下子又發到老三那裏，這個就說不許了，這樣咱們幾個手頭的信息不一致，就會出現一些異常狀況，用戶估計要破口大罵：這什麼辣雞網站？

後來咱們跟nginx商量了一下，讓他同一個用戶來的請求都發給咱們固定的一我的，這才穩住了局面。

不過好景不長，後面咱們三兄弟都相繼出現過宕機的狀況，這時候nginx仍是得把請求交給還在工做的兄弟，原來的問題就又出現了！

咱們幾個逼急了，商量了一下，乾脆你們夥來同步session id的信息好了，有新增、失效的狀況都給其餘幾個兄弟招呼一下，你們都管理一份，這樣就不會出現不一致的問題了。

搞了半天，又變成之前一我的管理全部session id的狀況了，不只如此，還要抽出時間和幾位兄弟同步，把session id搬來搬去，工做量不減反增了。

就這樣艱難的過了一段日子，你們都怨聲載道，因此有了開頭的那一番討論。

這一次，但願這位新來的叫Redis的夥伴能拯救咱們。

獨立緩存——Redis

過了幾天，總算把這個叫Redis的小夥伴給盼來了！

這小子看起來特別精神，瞭解清楚狀況後，告訴咱們說：「三位老哥，之後這session id都統一存在我這裏吧，大家別各自保存了，這不是各位的擅長」

「你行嗎？」，老二看着不太相信他的話，一臉不屑。

「行不行，試試不就知道了嗎？」

接下來，咱們遵從了Redis的建議，再也不保存這煩人的session id，所有一古腦兒交給了他，咱們須要的時候再找他獲取。

你還別說，這小子個子不大，本事不小，讀寫速度都特快，讓咱們頭疼的問題總算是解決了！

Token時代

幾個月後的一天···

「據說了嗎？程序員們又要更改session id的存儲方案了」，這一天，老二神神祕祕的說到。

「不對不對，我聽到的版本是之後不用session id了，要變天了！」，老三也湊了上來。

一旁的redis老哥一聽不樂意了，「咋的？是嫌我乾的很差嗎？」

我也趕忙催促，「你倆就別賣關子了，聽到了什麼，快說說」

老三示意你們圍攏一些，小聲說到：「我上次聽兩個程序員在議論，不知道他們在哪裏學來了一套叫JWT（JSON Web Token） 的技術，硬說讓咱們來管理保存session id負擔過重了，之後不保存了！還說，還說···」

「還說啥，你卻是說啊！」

「還說，Redis也不是萬能的，也有崩潰的風險，一崩潰就全完了，因此要革新技術」，老三繼續說到。

Redis一聽更着急上火了，「我工做這麼久以來，從沒有撂過挑子吧，怎麼能這麼說我呢？再不行我也能夠像大家搞個集羣嘛」

「Redis老弟你先別急。唉，老三，這不保存session id，之後怎麼鑑別用戶呢？你有沒有聽到他們怎麼說的？」

「聽他們說，沒有session id，可是換了一個token，用它來識別用戶」

老二一聽不覺得意：「換了個名字，換湯不換藥嘛！我們還不是要保存token，才能匹配誰是誰」

老三搖了搖頭：「不是的，這可不僅是改了個名字那麼簡單！這個token是由三部分構成，就像這樣：」

「大家看，第一部分是JWT的基本信息，而後把用戶的身份信息放在第二部分，接着和第一部分合在一塊兒作一個計算，計算的時候加入了一個只有咱們才知道的密鑰secretkey，計算結果做爲第三部分。最後三部分拼在一塊兒做爲最終的token發送給客戶端保存着···」

還沒等老三說完，老二點出了其中的關鍵：「我知道了，後面我們再收到這個token的時候，就能夠經過一樣的算法驗證前面兩部分的結果和第三部分是否是相同，就知道這個token是否是僞造的啦！由於密鑰只有咱們知道，別人沒辦法僞造出一個token的！最後確認有效以後，再取第二部分的用戶身份信息，就知道這是誰了！」

聽完他們的分析，我和Redis老兄都默默的點了點頭，「有點意思啊，這樣一來，我們確實不用存了！不過如今我們幾個工做配合的也挺好的，他們費這麼大勁是爲了什麼啊？」

「我猜他們是想節約開支，把Redis老哥給裁掉！」，老二說到。

老三搖了搖頭，「依我看，八成他們是想展現技術給領導看，這不又快到職級晉升答辯了，他們想搞事情！唉，老大，這事你怎麼看？」

「我啊，我···」

朋友們，你怎麼看？session-cookie和JWT，你更傾向誰？

往期TOP5文章

我是Redis，MySQL大哥被我害慘了！

CPU明明8個核，網卡爲啥拼命折騰一號核？

由於一個跨域請求，我差點丟了飯碗

完了！CPU一味求快出事兒了！

哈希表哪家強？幾大編程語言吵起來了！