1、不使用session，換用cookie session是存放在服務器端的，cookie是存放在客戶端的，我們可以把用戶訪問頁面產生的session放到cookie里面，就是以cookie為中轉站。你訪問web服務器A，產生了session然后把它放到cookie里面，當你的請求被分配到B服務器時，服務器B先判斷服務器有沒有這個session，如果沒有，再去看看客戶端的cookie里面有沒有這個session，如果也沒有，說明session真的不存，如果cookie里面有，就把cookie里面的sessoin同步到服務器B，這樣就可以實現session的同步了。 說明：這種方法實現起來簡單，方便，也不會加大數據庫的負擔，但是如果客戶端把cookie禁掉了的話，那么session就無從同步了，這樣會給網站帶來損失；cookie的安全性不高，雖然它已經加了密，但是還是可以偽造的。 2、session存在數據庫（MySQL等）中 可以配置將session保存在數據庫中，這種方法是把存放session的表和其他數據庫表放在一起，如果mysql也做了集群了話，每個mysql節點都要有這張表，并且這張session表的數據表要實時同步。 說明：用數據庫來同步session，會加大數據庫的IO，增加數據庫的負擔。而且數據庫讀寫速度較慢，不利于session的適時同步。 3、session存在memcache或者redis中 memcache可以做分布式，php配置文件中設置存儲方式為memcache，這樣php自己會建立一個session集群，將session數據存儲在memcache中。 說明：以這種方式來同步session，不會加大數據庫的負擔，并且安全性比用cookie大大的提高，把session放到內存里面，比從文件中讀取要快很多。但是memcache把內存分成很多種規格的存儲塊，有塊就有大小，這種方式也就決定了，memcache不能完全利用內存，會產生內存碎片，如果存儲塊不足，還會產生內存溢出。 4、ip\_hash upstream www.erp.com { server 192.168.15.131:8080; server 192.168.15.131:8090; server 192.168.15.131:8100; ip\_hash;#一種IP的算法，只要用戶使用同一個IP請求，nginx會分流到之前請求的服務器 } nginx中的ip\_hash技術能夠將某個ip的請求定向到同一臺后端應用服務器，這樣一來這個ip下的某個客戶端和某個后端就能建立起穩固的session，ip\_hash是在upstream配置中定義的： 說明：因為這種方式只能用IP來分配后端，所以要求nginx一定要是最前端的服務器，否則nginx會取不到真實的客戶端ip，那ip\_hash就失效了。例如在服務器架構中使用squid做前端高速緩存，那么nginx取到的就是squid服務器的ip，用這個ip來做ip\_hash肯定是不對的。再有，如果nginx的后端還有其他的負載均衡，將請求又分流了，那么對于某個客戶端的請求，肯定不能定位到同一臺應用服務器（例如php的fast-cgi服務器等），這樣也不能做到session共享，如果在nginx后面再做負載均衡，我們可以再搭一臺squid，然后再直接到應用服務器，或者用 location作一次分流，將需要session的部分請求通過ip\_hash分流，剩下的走其它后端。