1. 程式人生 > >解決session共享的幾種思路

解決session共享的幾種思路

數據共享 解決 png coo img 內置 文件中 請求 方案

session與cookie的區別在於:session是保存在服務器端,cookie保存在客戶端。session怎麽樣保存的?以文件的形式保存。

第一種辦法:把原來存儲在服務器磁盤上的session數據存儲到客戶端的cookie中去。php由原來的”從本地(也就是服務器)磁盤上讀取session數據”轉變為”瀏覽器的cookie中讀取數據”,一般是把session數據按照自己定義的加密規則,加密後後存在cookie中。數據保存在cookie中這種做法有好處,也有壞處。
好處是服務器的壓力減小了,因為session數據不存在服務器磁盤上。根本就不會出現session讀取不到的問題。
帶來的弊端是:
網絡請求占用很多。每次請求時,客戶端都要通過cookie發送session數據給服務器。
另外,瀏覽器對cookie的大小存在限制。每個瀏覽器限制是不同的。

第二種思路:用一種算法(簡單理解為規則),什麽機制下session是保存在哪臺服務器下,那麽讀取的時候就按照這種規則去讀取,就能定位到原來的服務器。叫做分發請求,分發到特定的服務器上去,我理解其原理是存session和讀session數據保證都在一臺服務器操作,就不會需要涉及到共享,具體實現方式是通過約定一種分發機制來實現。
也叫做sticky模式(粘性會話模式),同一個用戶的訪問請求都被派送到同一個服務器上。
假設是同一個用戶user1,每次訪問都路由到同一臺服務器上,這樣即便是在負載均衡的情況下,也能保證每次訪問都能讀取到session,不需要做session數據共享了。
關鍵多臺server的原因是為負載均衡而做的,那麽就得把原來負載均衡的規則假設是—a,現在改為按照session來均衡分發請求的規則—b。
如果這臺機子掛掉了,那麽後續的請求按照session的規則還是會分發到這臺服務器上去,但是現在不可用了。
本來負載均衡有一個目的就是

:當其中一臺機子不可用的時候,會自動分發到可用的機子上去(自動判斷現在要請求的機子是否可用)。
因為某種規則的session都是保存在一臺服務器上,比如用戶編號是1-200涉及到的session數據保存到a服務器上去。所以只要一臺出問題,1-200的用戶就無法實現登錄了。後面就不可用了(可能想到1-200用戶的session服務器用多臺進行復制,這感覺很蹩腳,仍然需要用到復制的話,還不如用其他簡便的方法)


第三種思路:做一個中間層,專門來存儲所有訪問涉及到的session。也就是所有的session都存儲在這裏。
服務器端統一從這裏讀取session數據。由這個session框架來維護所有網站的session數據。

使用這種中間層的思想來實現共享,具體的技術方案,我歸納為以下幾種:

1、 通過NFS文件共享的方式,多臺php服務器共享保存session文件的磁盤。
通過nfs的方式,各個php服務器操作session數據的時候,是讀取本地磁盤目錄,但實際上是一個共享網絡文件。各個php服務器實際上操作的都是同一個目錄的文件。
具體的操作細節。到時候還需要詳細寫一下。我根據理解,畫了下面的圖:技術分享

2、保存在數據庫中,這種方式的擴展性很強,可以隨意增加WEB而不受影響。放在數據庫裏面安全方面好。



其實我理解本質是:自己寫程序(php,java都可以實現,反正是保存在數據庫中)模擬實現session的機制。



具體為,把以前存儲在文件中的session數據存儲到數據庫中去,那麽這樣做,其實就不用到php內置的session機制了(像session_start()之類的函數都不需要去用了)。

寫程序要模擬的是,從數據庫拿session數據,約定什麽情況下數據過期了然後自動清理,這裏是指刪除數據庫中的行。保存在文件中的時候,php有垃圾回收機制會去自動清理過期的session文件。

====================================弊端

解決session共享的幾種思路