一、把用戶ID加密存儲在Cookie中
1． 把用戶ID，用可逆加密的方式，存儲於Cookie中。當用戶登陸成功時，ID經過加密存儲。用戶第一次訪問A頁面，通過解密ID，如果解密成功，然后調用SOA（或者其他分布式服務實現，可以達到隨意擴展，而不用更改調用端），獲取用戶信息，然后把用戶信息存儲在Session中，如果這時用戶從A頁面跳轉到B頁面，同樣可以通過解密獲取用戶信息。這樣導致的問題是，大量訪問登陸服務，降低了Session的利用率。如果能實現，同一個用戶固定負載均衡到同一台服務器上，就可以實現比較高的Session利用率。
2． 可以隨時更換密鑰，但是必須所有服務器都使用相同的密鑰，否則會出現混亂。
3． 如果客戶端禁用Cookie將產生致命問題。
4． Cookie容量有限，存儲的數據量必須要嚴格控制,並且把一組信息寫到同一個Cookie中，避免過多的Cookie。
二、把Session寫到Memcache、Redis等分布式共享緩存中。
1． 必須實現分布式緩存的容災機制，否則一台機器掛掉，將導致大量用戶不能登陸。
2． 並且要能水平擴展，這將導致分布式緩存的維護成本上升。
三、把Session存放在數據庫中。
1． 可靠性高，進程掛掉，也能處理。
2． 需要單獨程序的實現，數據庫開銷大。
3． 數據庫會是單點，可以用Hash的方式解決。
四、NET提供把Session存儲在內存中。
1． 可以是單獨的存儲Session的服務器的內存中，也可以是和IIS同一台機器的內存中，集群化實現比較困難，如果Session存放在單獨一台機器，其也是單點，有風險；如果存放和IIS同一台機器上，集群化有實現不易，負載均衡受制，必須保證同一個用戶，一直訪問同一台機器才能保證Session。
五、NET也提供把Session存儲在IIS進程中。
1． 問題同把Session存放在內存中。
2． 同時由於和IIS共有進程，可能由於IIS的問題導致Session無法使用問題，崩潰的幾率上升。
六、無聊想法自定義的Session解決方案。
1． 把用戶ID加密存儲在Cookie中，通過“方式一”，解密得到用戶ID，然后把用戶相關信息，存儲在Memcache/Redis等上，用戶再次訪問時，優先從分布式緩存上取用戶更多信息，如果沒有從數據庫中去取，然后同時以異步的方式把用戶信息，緩存，而且分布式緩存的淘汰算法，是最近最少使用法。其實現方式是封裝在基類中，在分布式緩存上，存儲基於ID的key/Value數據。即使掛掉也可以從數據庫中恢復用戶的主要信息。
2． 該方式是基於加密算法和分布式緩存的結合體。
七、NET的Session值的共享，需要在配置machineKey。
1． 配置sessionState置節點，使用StateServer或SQLServer來實現Session共享。
為實現跨服務器共享，必須在Web.config配置：
<machineKey decryptionKey="FD69B2EB9A11E3063518F1932E314E4AA1577BF0B824F369" validationKey="5F32295C31223A362286DD5777916FCD0FD2A8EF882783FD3E29AB1FCDFE931F8FA45A8E468B7A40269E50A748778CBB8DB2262D44A86BBCEA96DCA46CBC05C3" validation="SHA1" decryption="Auto"/> ；即要求集群有相同的值。