XXX電商專案： 系統架構：分散式+SOA+SSM+AngularJS 資料庫：Mysql 技術點： 分散式框架Dubbo，業務分離成單獨服務模組，有多個計算機節點(伺服器共同完成需求，降低單個伺服器的訪問壓力 SOA面向服務架構：服務層與表現層分離，降低模組之間的耦合性，實現服務層的重複呼叫，通過zookeeper註冊服務中心，實現控制層與服務層之間的呼叫。 後臺： 主要技術點：AngularJS雙向資料繫結，MVC，注入，模組化 檔案上傳：FastDFS分散式檔案系統，原理：真正儲存檔案是storage叢集，通過tracker管理，storage會定時向tracker傳送心跳報告，tracker在相應請求時會返回可用的storage，如果不傳送，tracker會認為該storage已停用，不會將它的地址返回給請求方。 前臺：

	1.登陸：cas單點登陸系統與springSecurity整合，cas的底層是cookie，一次登陸，到處認證，我們第一次登陸時，cas服務端會對我們的資訊進行認證，認證通過後，會返回一個票據。當訪問其他應用時，請求會攜帶這個票據，cas服務端對這個票據認證後，就可以訪問了。票據時儲存在cookie中的，因為session是不能在不同伺服器間共享。
	
	2. 註冊：簡訊驗證：阿里大於
	
	3. 搜尋：solr搜尋引擎，底層是lucene，全文檢索技術：會將頂起將存入的文件(資料庫的一條記錄對應一套文件)，定期進行分詞，建立中間表，儲存分詞結果與文件索引之間的對應關係，索引庫的是使用，能購有效緩解資料庫的訪問壓力，全文檢索技術也可以提高使用者的搜尋體驗。
	
	4. 商品詳情頁：使用freemarker網頁靜態化技術：插值和一系列的指令。為什麼要用靜態頁面：緩解資料庫訪問壓力，緩解伺服器訪問壓力，提高使用者體驗
	
	5. 發現控制層呼叫服務層時，需要引入介面類，對於那些不需要返回結果的服務層方法，呼叫時採用avtivemq訊息佇列進行解耦，分為生產者(sendMessage)，消費者(MesageListener)  發現控制層呼叫服務層時，需要引入介面類，對於那些不需要返回結果的服務層方法，呼叫時採用avtivemq訊息佇列進行解耦，分為生產者(sendMessage)，消費者(MesageListener)，常用的訊息型別就是StringMessage和MapMessage，avtivemq時jms訊息中介軟體的產品，jms和jdbc一樣是一個介面，一個規範，java程式之間傳送訊息，就要遵守這個規範，它有兩種模式：點對點，釋出/訂閱。點對點是一個生產者傳送的訊息，只能被一個消費者接收，而且不管哪個先啟動，都能接收到訊息，釋出訂閱，一個生產者釋出的訊息可以被多個消費者接收，只能是消費者先啟動進行監聽，生產者啟動釋出訊息後，就會收到訊息。jms訊息型別有五種StringMessage,Obejct,Bytes,Map,Stream
	
	6. 對一些不常變動而訪問率有比較高的資料，我們採用redis儲存，也是為了提高效能，降低資料庫訪問壓力,redis是記憶體級資料庫，有五種資料型別：String,Hash,List,Set,SortedSet,因為資料儲存在記憶體中，所以讀取速度非常快，遠高於關係性資料庫，但是不支援事務繫結，而且資料量大時，不適合儲存到redis上，可以考慮MongoDB,一種介於關係型資料庫與非關係性資料庫之間的文件型資料庫，支援大資料量的儲存，同時讀寫速度也高於關係型資料庫，適合儲存資料量大，且資料價值不高的資料，它的體系結構時：資料庫--集合--文件，對應關係型資料庫的資料庫--表--行。
	
	7.  購物車解決方案：使用者不登陸，用cookie儲存，使用者登陸，用redis儲存，併合併購物車，為啥不用資料庫，操作量大，資料庫訪問壓力大，使用者不登陸，也能訪問/cart/*.do路徑是因為spring security的匿名認證機制，就是spring security提供了一個匿名使用者角色，這樣實現了“遊客模式”,認為其已有使用者登陸，但是並沒有相應的資源可以訪問，這樣登不登陸都可以請求當前路徑，但是展示的資源不同
	
    8. 訂單解決方案：一個商家的購物車對應一個訂單，  分散式id生成解決方案：推特雪花演算法：1位0(沒有意義)+41位的時間戳+5位資料中心ip+5位機器ip+12位序列號
	
	9. 分散式架構中，我們對資料庫進行分庫分表處理，這時資料的主鍵再採用自增的形式就會出現重複，以前的解決方案是使用redis的自增方法，產生一個id。incr 方法
	
	10. 跨域請求解決方案：當前端頁面訪問其他應用的後端介面時，會出現跨域請求的問題，當兩個應用的協議，地址，埠號任一出現不同時，兩個應用之間的通訊即為跨域請求CORS,跨域請求共享機制，在被請求的方法上設定兩個請求頭資訊(不操作cookie的話可以只設置一個)，springMVC框架提供了@CrossOrigin註解，設定@CrossOrigin(origins="http://localhost:9105",allowCredentials="true")就可以實現跨域請求共享
	
	11. 支付解決方案：呼叫微信支付介面(http路徑)，用sdk提供工具類的方法將map引數轉化為xml，用httpclient工具類傳送求情，再用sdk工具類解析結果，獲得支付連結的code_url，返回頁面後，用qrious生成二維碼，二維碼生成後，即開始檢查支付狀態，呼叫微信支付提供的查詢訂單介面，通過迴圈while(true)去呼叫，但是不能調那麼頻繁啊，怎麼辦，Thread.sleep（3000），當超過規定時間後，二維碼過期，返回結果給前端，如果頁面沒關閉，前端頁面傳送請求，重新整理二維碼，如果頁面關閉了，就不再呼叫查詢支付結果的方法。
	 
	12. 秒殺解決方法：所有東西都存到redis，兩個限制：時間限制，庫存限制，任意個達到要求，就更新到資料庫，清空redis。
		庫存限制：支付成功，庫存減一，庫存為0，從redis中刪除，並更新到資料庫，支付未成功，恢復庫存。
		時間限制：用spring task任務排程框架每分鐘查詢一次redis中是否有商品過期，有的話，刪除商品，更新資料庫。
		
	13. spring task 框架：定時任務，@Schedule註解cron表示式 * * * * * ?
 

當然還有部署時各種叢集的搭建！