實際上，session在php,.net,java等只要是後端語言都會用到。session的存儲機制，各種語言都大體差不多。我覺得這跟cookie在各個語言中都會用到差不多。.net，java我沒去了解過。但是存儲原理是差不多的。區別就是，php，java，.net調用的函數，讀和取session數據的方式不同。默認都是存儲在本地文件中的(不然怎麼會涉及到session共享問題呢，存儲在數據庫本身就可以實現共享的)。
所以，無論是.net還是java都會涉及到session數據共享的問題。
其實我的理解是，session的原理都是一樣的。討論session共享方案設計，是可以拋開具體的語言去討論session共享方案設計。
目前業界解決session共享的幾種思路，我總結如下：
第一種辦法：把原來存儲在服務器磁盤上的session數據存儲到客戶端的cookie中去。
這樣子，就不需要涉及到數據共享了。a客戶端請求的時候，原來生成在服務器的數據生成到瀏覽器的cookie中，根據cookie中的數據識別用戶。
php由原來的”從本地(也就是服務器)磁盤上讀取session數據”轉變爲”瀏覽器的cookie中讀取數據”，
這樣子，在多臺php服務器負載均衡的情況下，即便第一秒請求是a服務器，第二秒請求是b服務器，都不需要管哪臺服務器了。反正都是讀取客戶端上的cookie數據。
一般是把session數據按照自己定義的加密規則，加密後後存在cookie中。
數據保存在cookie中這種做法有好處，也有壞處。
好處是服務器的壓力減小了，因爲session數據不存在服務器磁盤上。根本就不會出現session讀取不到的問題。
帶來的弊端是：
網絡請求佔用很多。每次請求時，客戶端都要通過cookie發送session數據給服務器。
另外，瀏覽器對cookie的大小存在限制。每個瀏覽器限制是不同的。
Firefox和Safari允許cookie多達4097個字節，包括名（name）、值（value）和等號。
Opera允許cookie多達4096個字節，包括：名（name）、值（value）和等號。
Internet Explorer允許cookie多達4095個字節，包括：名（name）、值（value）和等號。
所以第一種方案不適合高訪問量的情況下，因爲高訪問量的情況下，每次請求瀏覽器都要發送session數據給服務器。一般一個cookie大小2k的樣子。
要佔用很多帶寬了(服務器購買帶寬是一個很大費用)，成本增高。歸納爲帶寬性能，速度問題。
存儲到cookie中去，第二方面是安全問題：把session數據放到客戶端，一般session中存的都是重要性數據(帳號、暱稱、用戶id等)，會存在安全問題。
瞭解到，淘寶以前用過這種方式，把session數據存儲到cookie中，根據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數據。
使用這種中間層的思想來實現共享，具體的技術方案，我歸納爲以下幾種：
1、 通過NFS文件共享的方式，多臺php服務器共享保存session文件的磁盤。
2、保存在數據庫中，這種方式的擴展性很強，可以隨意增加WEB而不受影響。放在數據庫裏面安全方面好。
弊端
放在數據庫裏面，訪問量小沒有問題。大流量網站這麼做，只會拖慢速度。因爲得查詢數據庫，造成數據庫壓力大。
高併發訪問的情況下,會出現很大的性能問題。
有些做法跟這種思想是類似的：比如ecshop、phpcms是把session數據都存儲在數據庫中去。服務端就是從數據庫中拿session的數據。
放到數據庫存儲後，就可以實現：多臺web服務器統一操作數據庫，因爲數據都在數據庫，web服務器都能從數據庫進行讀取，那麼session數據就能實現共享。
存儲在數據庫的做法，在線人數決定了其瓶頸，主要問題是影響性能。在線人數,因爲登錄的session數據存儲在數據庫中，只要是登錄的用戶就會涉及到頻繁操作數據庫。
我覺得小網站，同時1-2萬個人在線情況下。應該沒什麼問題。
看網上丟出一個問題：對於大訪問量的網站，數據庫存儲session方法可行性有待商榷。
3、可以將session數據保存在memcached，redis之類內存數據庫中，memcached是基於內存存儲數據的，性能很高，用戶併發量很大的時候尤其合適。
主要是利用內存的數據讀取速度是很快的，與磁盤讀取的速度不是一個數量級的。
使用內存存儲：方便統計在線人數，內存的速度比磁盤訪問快、內存數據庫系統能夠控制內存中的過期數據自動失效(剛好符合session過期需要)。
存儲在redis比較理想的選擇，存儲在數據庫中方便存儲統計在線人數，那麼存儲在redis中也實現了這個要求。
也可以存儲在memcache中。但redis支持的數據類型多。所以用它好點。