『壹』 為什麼要在電子商務中引入會話跟蹤呢
這涉及的是電子商務安全問題，都是計算機網路方面的知識。弄明白會話跟蹤技術有什麼好處後，你就知道在電子商務中為什麼要引入它了。
『貳』 電子商務與集群經濟的關系
必須提高全社會對電子商務和現代物流的認識。電子商務是商業領域內的一次革命，而現代物流則是物流領域內的一次革命。國家與企業共同參與，共建電子信息化環境。同時，企業要通過信息網路進行商貿活動，為客戶提供快捷的服務，吸引更多的製造企業和商業企業上網，提高企業的競爭力和盈利水平，從而促進電子商務和現代物流的發展。
選擇適應電子商務發展的現代物流發展模式，實現現代物流配送體系的產業化、社會化。在我國目前條件下電子商務企業不宜採用自建物流中心的物流模式，應與第三方物流公司簽訂長期穩定的合作關系，建立共同配送模式，削減物流企業間的不當競爭，從整體上提高供方取得價格優惠的能力，並實現優勢互補，促進企業走向聯合的規模經濟之路。
整合業務流程，提供優質的多樣化和個性化服務。電子商務的個性化、多樣化特點，企業在商品生產、經營和配送上充分對應不同區域，不同時間和不同消費需求的客戶需要，客觀上也要求多品種、少批量、大頻度的現代物流服務，通過電子化、集成化現代物流管理把供應鏈上各環節緊密聯系起來，對顧客的個性化需求做出快速反應，如採用電子商務的「量身定製」的方式，客戶可以利用計算機或手機來決定商品何時送達目的地，收到後，信息將自動反饋到客戶指定的計算機或手機上。 建立以信息化為核心的信息平台對電子商務與現代物流的協同發展極為有利。搭建信息平台是運用互聯網對企業業務流程的重新設計，電子商務是信息流、商流、資金流和物流的高度對稱、融合與互動，信息流貫穿於商務活動的始終，引導著商務活動的發展，現代物流是商流的繼續，是商務活動中實際的物資流通過程，同樣需要信息流的引導和整合。現代物流朝著信息化、自動化、網路化、智能化、柔性化方向發展，具有良好的信息處理和輿系統才能快速、准確地獲取銷售反饋信息和配送貨物跟蹤信息，從而大大提高現代物流企業的服務水平，提高電子商務的效率，贏得客戶信賴，並不斷降低成本。
制定一套電子商務與現代物流發展的可行性方案。根據消費者的收入、需求偏好、地理分布等條件的不同，合理定位銷售區域，對不同的銷售區域採取判別性的物流服務政策；認真篩選銷售品種，確定最適合銷售的商品，將品種限制在一定范圍之內，減少流通中的過多費用；再由專業人員精心策劃配送方案。 高度重視物流專業人才培養，把國外先進物流的經驗與本土化人才有機結合起來。加強電子商務和現代物流人才的培養，要培養從事現代物流理論研究與實務操作的專門人才。懂電子商務又懂現代物流的有創新思想的復合型人才，市場的競爭就是人才的競爭，應該注重人才的培養和教育，加深對電子商務與現代物流協同發展的研究。
『叄』 集群環境下怎麼保證用戶會話的一致性
讓大家感到有共同的利益。
CAS的集群環境，包括CAS的客戶應用是集群環境，以及版CAS服務本身是集群環境這兩種情況權。在集群環境下使用CAS，要解決兩個問題，一是單點退出時，CAS如何將退出請求正確轉發到用戶session所在的具體客戶應用伺服器，而不是轉發到其他集群伺服器上，二是解決CAS服務端集群環境下各種Ticket信息的共享。
『肆』 多機集群如何提供內存復制
HTTP 協議本身是「連接 - 請求 - 應答 - 關閉連接」的模式，是一種無狀態協議；然而隨著 web 動態化的需求，我們往往需要把兩次連續的請求關聯起來，從而使得客戶端和服務端的會話變得有狀態。Session 就是滿足這種需求的一種實現方式。
它的基本原理是伺服器端為每一個 session 管理一份會話信息數據。而客戶端和伺服器端依靠一個全局唯一標示符 —— sessionID 來訪問會話信息數據。當用戶訪問 web 應用時，伺服器端會先檢查客戶端的請求里是否包含 sessionID，如果沒有或者檢索不到，伺服器端會自動創建一個新的 sessionID，同時開辟數據存儲空間， 並且在本次響應中將 sessionID 返回給客戶端保存。
當伺服器端需要開辟數據存儲空間時， 一般會在內存中創建相應的數據結構，但在訪問量非常大的系統中，session 會佔用大量的內存空間，而且系統一旦宕掉或者掉電，所有的會話數據就會丟失，這種事故在電子商務網站中會造成嚴重的後果。當然也可以將 session 內容存儲在資料庫中，從而在某種程度上實現持久化，但是這樣會增加 I/O 開銷，影響系統的性能。
在 IBM Websphere Application Server 中提供了兩種不同的 session 持久化管理方案，如圖 1 所示，分別是
1.使用資料庫做 session 持久化管理 所有的 session 信息被集中存放於資料庫中.
2.內存到內存的復制 所有 session 的信息會存放在各個應用伺服器的內存中.
使用資料庫存儲 session 數據時需要對存儲的信息作序列化操作，在某種程度上影響了響應的時間和效率，適用於 session 數據量大，並且對持久化要求比較高的應用場景。在內存到內存的復制方案里，session 管理者可以把最近經常使用的 session 保存在內存裡面，極大地降低了獲取 session 數據的時間開銷，從而滿足了對效率和響應時間要求高的應用需求。從內存到內存的 session 復制，一般適用於 session 數據量不大的應用場景。本文將詳細介紹內存到內存復制的持久化管理方案。
內存到內存復制
內存到內存的 session 復制指的是將 sessions 復制到另一個 WebSphere Application Server 上。在這個模式下，sessions 可以被復制到一個或者多個應用伺服器上，從而防止 HTTP Session 單點失敗（single point of failure）的發生。
Session 復制的目的，是將 session 的信息進行備份保存，以便在伺服器發生故障的情況下，session 狀態不會丟失，實現 session 的高可用性，從而保證即使有故障發生，也不會影響到客戶正在進行的業務，避免造成損失，進而提高客戶滿意度。
目前 WebSphere Application Server 提供了三種復制方式：
僅伺服器模式： 所謂僅伺服器，指的是該應用伺服器只會存儲其他應用伺服器的 session 備份，而不會把自己創建的 session 分發並復制到其他應用伺服器上。
僅客戶機模式： 所謂僅客戶機，指的是該應用伺服器只會把自身的 session 分發並復制到其他應用伺服器上，但不會存儲其他應用伺服器的 session 備份。
客戶機和伺服器模式： 所謂客戶機和伺服器，指的是該應用伺服器既能作為伺服器存儲其他應用伺服器的 session 備份，也能作為客戶機把自身的 session 分發並復制到其他應用伺服器上。
WebSphere Application Server 默認的是客戶機和伺服器模式。用戶也可以根據需要選擇合適的復制模式。目前 WebSphere Application Server 支持兩種 session 復制拓撲結構，分別為：
客戶機 / 伺服器 (Client/Server)
點對點 (Peer-to-Peer)
針對這兩種拓撲結構，我們將在餘下的章節中作詳細的介紹。
復制域
首先，內存到內存復制功能是通過應用伺服器上的數據復制服務實例來實現的，我們要確保這些數據復制服務實例是屬於同一個復制域的，否則這些實例相互間就不能進行復制，從而影響內存到內存復制功能的實現。
如圖 3 所示 , 復制域 Domain1 包含三個成員 Server1，Server2 和 Server3，因此這三個 server 之間能相互進行復制。但是由於 Server4 並不屬於復制域 Domain1 裡面的成員，因此 Server4 上的 session 不能復制到復制域 Domain1 的成員上，同時也不能備份 Domain1 上成員的 session 信息。
圖 3. session 復制域
其次，屬於同一個復制域的所有會話復制都必須具有相同的拓撲結構。如果同一個復制域中的一個會話管理實例使用的是客戶機 / 伺服器拓撲結構，則其餘所有的會話管理實例只能是「僅伺服器」模式或者「僅客戶機」模式。相反，如果有一個會話管理實例使用的是點對點的拓撲結構，則其餘 所有的會話管理實例只能被配置成「客戶機和伺服器」模式。「僅伺服器」模式或者「僅客戶機」模式不能與「客戶機和伺服器」模式共存於同一個復制域裡面。
在集群環境中，默認採用的是點對點的單備份復制，但是我們也可以在復制域裡面修改復制的數量。如圖 4 所示，如果副本數選擇單個副本，那麼 session 只會被備份到一個復制域成員上，如果選擇整個域，則 session 就會備份到所有其他復制域成員。當然，我們也可以根據實際需要來指定復制的副本數目。
內存到內存復制拓撲結構：點對點
在這個結構圖中，每一個復制域成員都把 session 的信息保存在自己的內存中。同時它也會把 session 的備份信息發送並保存到其他復制域成員上，同時，它也從其他的復制域成員上獲取 session 的信息。在這種情況下，每個復制域成員既可以作為一個客戶端，從其他的復制域成員上獲取 session 的信息；也可以作為服務端，把自身 session 的信息存儲到其他復制域成員上。也就是說，每個復制域成員的復制模式都是「客戶機和伺服器」。
在這種配置方式下，不同的服務端之間的關系是平等的，而且需要最少的伺服器進程，因此它代表了最牢固的拓撲結構。尤其當各個節點具有相同的性能（CPU，內存等等）和處理相同數量的工作時，該拓撲結構可以達到最穩定的實施。
點對點復制的拓撲結構的優勢是不需要額外的進程和產品來避免單點失敗，從而減少了配置和維持額外進程或產品的時間和費用的成本。但這個拓 撲結構的局限性就是它需要佔用一定的內存空間，因為每個服務端都需要備份這個復制域里所有 session 的信息。假如一個 session 需要 10KB 的空間來存儲信息，那麼當 100 萬個用戶同時登陸到這個系統中時，每個應用伺服器就需要花費 10GB 的內存空間來保存所有 session 的信息。它的另一個局限性是每一個 session 信息的修改都會被復制到其他所有的應用伺服器上，這極大地影響了整個系統的性能。
在 Websphere Application Server V7 開始支持 session 熱故障恢復 (session hot failover) 功能。這個功能只適用於點到點復制模式。在集群環境中，session affinity 會把客戶的所有後續請求分發到同一台應用伺服器上。啟用這一特性之後，如果運行某個實例的服務端突然宕掉，那麼 Websphere Application Server plug-in 就會把其後續請求轉發到集群環境中其他合適的服務端上。
對於設置成點到點復制模式的集群來說，這個新特性可以觸發插件程序，從而讓保存這些 session 備份的復制域成員來直接接管宕掉的復制域成員的工作，這樣可以減少從另一個復制域成員那裡再次獲取 session 備份的開銷。
內存到內存復制拓撲結構：客戶機 / 伺服器
「客戶機 / 伺服器」拓撲就是把集群中的復制域成員分別設置成「僅伺服器」模式或者「僅客戶機」模式。這種拓撲可以把備份數據和本地數據分離開來，所有「僅客戶機」成 員共享「僅伺服器」成員上 session 備份，減少了單個復制域成員的復制開銷。拿「僅客戶機」成員來說，它就不用再負責為別的成員進行 session 備份，可以有更多的資源來運行業務；而對於「僅伺服器」成員來說，它只負責備份 session，不需要處理業務，其上不需要部署任何應用程序。
這種拓撲結構的優勢是它明確區分了客戶機和伺服器的角色。「僅伺服器」成員將所有的 session 信息保存在內存中，而「僅客戶機」成員專門處理業務。這樣可以減少每個客戶機的內存開銷和性能影響。
所有「僅客戶機」成員可以共享「僅伺服器」成員，當有「僅伺服器」成員且數據有多餘兩個以上的備份時，就可以實現故障恢復的目的。
在實際操作中，我們推薦使用多個備份伺服器從而減少單點錯誤的發生。
兩種復制拓撲的比較
在前面兩個章節中，我們分別介紹了點到點和客戶機 / 伺服器兩種復制拓撲結構的原理及其優勢和局限性，在本章節中，我們將進一步比較這兩種復制拓撲。
『伍』 白山市集群電子商務有限公司怎麼樣
簡介：白山市集群電子商務有限公司成立於2013年01月23日，主要經營范圍為網上銷售回：日用答百貨、家用電器、電子產品、文教用品等。
法定代表人：馬士義
成立時間：2013-01-23
注冊資本：200萬人民幣
工商注冊號：220600000030301
企業類型：有限責任公司(自然人投資或控股)
公司地址：渾江區紅旗街永祥大廈104門市
『陸』 如何理解分布式與集群，二者區別是什麼
分布式是指不同的業務分布在不同的地方，集群指的是將幾台伺服器集中在一起，實現同一業務。白話理解的話，比如公司項目上線初期（舉例電子商務網站）
初期：用戶訪問量低，只弄了一台伺服器，一個tomcat項目運行一個web工程。
中期：用戶訪問量提高，伺服器崩了，為了解決這個問題，購買伺服器，增加伺服器數量，然後每個伺服器中個各放了一份，使用nginx代理轉發。（這就是運用集群原理）
後期：用戶訪問量不斷增加，響應速度變慢，伺服器又崩了，在不考慮增加伺服器帶寬、內存和CPU的情況下如何解決這個問題？先解決響應速度變慢，用戶頻繁調用資料庫，在客戶端與資料庫之間，使用redis緩存。解決之後，又發現問題：由於每台伺服器運行一個tomcat，放著一個web工程，用戶有可能在商品詳情存在大幅度調用資料庫，而訂單列表調用幅度小，此時就存在著模塊之間耦合度高，一個功能升級其他也需要升級，擴展性差，不能靈活部署。是該考慮項目重構，把項目按照模塊分為不同的系統（使用zookeeper進行模塊之間通信），例如：訂單系統，會員系統、搜索系統、商品信息系統。把每個模塊進行拆分，用戶在哪個系統訪問頻繁，就針對哪個系統進行對症下葯，增加緩存還是使用其他技術。（這樣我們就可以單獨對這個模塊進行服務性能的提升，不用全部都一起提升。也降低了代碼的耦合度，模塊之間互不影響，即使後期增加開發人員，也可按照敏捷開發思想只對其負責模塊進行開發，效率大大提升）。這樣一個web工程就拆分成多個web工程（多個tomcat部署）。那這個項目就可以在一台伺服器部署多個工程（不同埠進行通信）或者多台伺服器運行單個項目。（這就是分布式原理）
總而言之，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
『柒』 如果有多台伺服器做集群的話 如何解決session的問題
會話狀態（Session
State）的機制。而這樣的機制應該可以使Web伺服器從多次單獨的HTTP請求中看到「會話」，也就是知道請求是來自哪個會話的。
具體實現方式為：在會話開始時，分配一個唯一的會話標識（SessionId），通過Cookie把這個標識告訴伺服器，以後每
『捌』 會員用戶數量在2000萬，這樣的電子商務系統需求，需要一個怎樣的集群伺服器架構，使用LAMP架構。
2000W已經算是大型網站抄了，不論襲數據量還有訪問量都是非常大的，像這種情況下可以有兩種配置方案，第一就是用很多台伺服器通過集群來滿足咱們的需要 第二就是配置高端的伺服器來滿足需求比如IBM的刀片伺服器或者小型機，總體沒個一二百W下不來
我們是IBM伺服器的代理商 主做機房建設 系統集成 有需要了可以聯系我 資料有我的聯系方式
『玖』 tomcat集群 大量用戶session同時失效,有可能是什麼原因
session對象是保存在來伺服器端自的，如果大量失效有可能服務端代碼有問題。
另一個問題有可能是客戶端無法傳遞正確的jsessionid，導致會話失效。
如果是用apache負載的話，請看一下apache的配置或者重啟一下apache看看