高並發的優化：
http://blog.csdn.net/qq_33290787/article/details/51899042
業務分析與DAO層
第1章：課程介紹
1.1 秒殺API之業務分析
秒殺\紅包類需求越來越常見；
1.2 項目效果演示
第2章：相關技術及搭建工程
2.1 相關技術
MySQL:1.這里我們采用手寫代碼創建相關表，掌握這種能力對我們以后的項目二次上線會有很大的幫助；2.SQL技巧；3.事務和行級鎖的理解和一些應用。
MyBatis:1.DAO層的設計與開發。2.MyBatis的合理使用，使用Mapper動態代理的方式進行數據庫的訪問。3.MyBatis和Spring框架的整合:如何高效的去整合MyBatis和Spring框架。
Spring:1.Spring IOC幫我們整合Service以及Service所有的依賴。2.聲明式事務。對Spring聲明式事務做一些分析以及它的行為分析。
Spring MVC:1.Restful接口設計和使用。Restful現在更多的被應用在一些互聯網公司Web層接口的應用上。2.框架運作流程。3.Spring Controller的使用技巧。
前端:1.交互設計。2.bootstrap。3.JQuery。設計到前端的頁面代碼我們直接拷貝即可，畢竟真正開發中這樣一個項目是由產品經理、前端工程師、后端工程師一起完成的。
高並發:1.高並發點和高並發分析。2.優化思路並實現。
2.2 創建項目和依賴
第3章：秒殺業務分析
3.1 秒殺業務分析
3.2 mysql實現秒殺的難點
3.3 實現哪些秒殺功能
秒殺系統業務流程如下:
由圖可以發現，整個系統其實是針對庫存做的系統。用戶成功秒殺商品，對於我們系統的操作就是:1.減庫存。2.記錄用戶的購買明細。下面看看我們用戶對庫存的業務分析:
記錄用戶的秒殺成功信息，我們需要記錄:
1.誰購買成功了。
2.購買成功的時間/有效期。
3.付款/發貨信息。這些數據組成了用戶的秒殺成功信息，也就是用戶的購買行為。
為什么我們的系統需要事務?看如下這些故障:
1.若是用戶成功秒殺商品我們記錄了其購買明細卻沒有減庫存。導致商品的超賣。
2.減了庫存卻沒有記錄用戶的購買明細。導致商品的少賣。對於上述兩個故障，若是沒有事務的支持，損失最大的無疑是我們的用戶和商家。
在MySQL中，它內置的事務機制，可以准確的幫我們完成減庫存和記錄用戶購買明細的過程。
事務機制依然是目前最可靠的落地方案 為什么要用事務機制： 
一切非關系型的數據庫都可以視作Nosql。 Nosql主要追求的是性能、分布式、高可用，但對事務支持的不是很好。
MySQL實現秒殺的難點分析:當用戶A秒殺id為10的商品時，此時MySQL需要進行的操作是:
1.開啟事務。
2.更新商品的庫存信息。
3.添加用戶的購買明細，包括用戶秒殺的商品id以及唯一標識用戶身份的信息如電話號碼等。
4.提交事務。若此時有另一個用戶B也在秒殺這件id為10的商品，他就需要等待，等待到用戶A成功秒殺到這件商品然后MySQL成功的提交了事務他才能拿到這個id為10的商品的鎖從而進行秒殺，而同一時間是不可能只有用戶B在等待，肯定是有很多很多的用戶都在等待拿到這個行級鎖。秒殺的難點就在這里，如何高效的處理這些競爭？
行級鎖伴隨着競爭,同一時間只有一個用戶能夠修改,其他用戶都在同一時間內等待
如何高效的完成事務?在后面第4個模塊如何進行高並發的優化為大家講解。
我們這個系統需要完成秒殺的哪些功能?先來看看天貓的一個秒殺庫存系統:
大家看了是不是覺得很復雜?當然不用擔心，我們只是實現秒殺的一些功能:
1.秒殺接口的暴露。
2.執行秒殺的操作。
3.相關查詢，比如說列表查詢，詳情頁查詢。
我們實現這三個功能即可。接下來進行具體的編碼工作，首先是Dao層的編碼。
第4章：DAO層設計與開發
4.1數據庫設計與編碼
4.2 DAO實體和接口編碼
4.3 基於mybatis實現DAO層理論
4.4 基於mybatis實現DAO編程
4.5 mybatis整合spring理論
4.6 mybatis整合spring 編程
4.7 DAO層單元測試和問題排查
數據庫初始化腳本
秒殺成功明細表 聯合主鍵,防止一個用戶秒殺多次
秒殺表 SeckillDao 設計<br> 1.減庫存，int reduceNumber(long seckillId,Date killTime);<br> 2. 根據id查詢秒殺對象 queryById(long seckillId);<br> 3. 根據偏移量查詢秒殺商品列表：List<Seckill> queryALL(int offset,int limit);
秒殺詳情表 SuccessKilledDao<br> 1. 插入購買明細，可過濾重復：insertSuccessKilled(long seckillId,long userPhone);<br> 2. 根據Id查詢SuccessKilled並攜帶秒殺產品對象實體：SuccessKilled queryByIdWithSeckill(long seckillId);
mybatis的有兩種方式提供SQL: 1.XML提供SQL 2.注解提供SQL 推薦利用XML提供SQL,利於維護.
Service層：
第1章：秒殺業務接口設計與實現
1.1 service開發之前說明
1.2 秒殺serviece接口設計
1.3 秒殺service接口實現
第2章：基於spring托管service實現類
2.1 使用spring托管service依賴理論
2.2 使用spring托管service依賴配置
第3章：配置並使用spring聲明式事務
3.1 使用spring聲明式事務理論
3.2 使用spring聲明式事務配置
3.3 使用集成測試service邏輯
聲明式事務的使用方式:
1.早期使用的方式:ProxyFactoryBean+XMl.
2.tx:advice+aop命名空間，這種配置的好處就是一次配置永久生效。
3.注解@Transactional的方式。在實際開發中，建議使用第三種對我們的事務進行控制，優點見下面代碼中的注釋。
web層：
第1章：設計restful接口
-
前端交互流程設計
-
學習restful接口設計
第2章：springmvc整合spring
2.1 使用springmvc理論
2.2 使用springmvc框架
第3章：實現秒殺相關的restful接口
3.1 使用springmvc實現restful接口
第4章：基於bootstrop開發頁面結構
4.1 基於bootstrap開發頁面結構
第5章： 交互邏輯編程
5.1 cookie登錄交互
5.2 計時交互
5.3 秒殺交互
第6章：測試部署web接口
SpringMVC配置
高並發的優化
秒殺系統面臨着如下問題：
（1）無法使用cdn緩存，因為系統邏輯不可能放在cdn中。
（2）后端緩存困難：庫存問題，因為運用到了mysql事務操作(設置聯合主鍵)。
（3）一行數據競爭:熱點商品，因為多個用戶同時對數據庫某條數據進行操作。
秒殺系統的優化方案：
（1）前端控制：暴露接口，按鈕防重復提交。
（2）動靜態數據分離：cdn緩存，后端Redis緩存。
（3）事務競爭優化：減少事務鎖時間，把客戶端邏輯放在mysql服務端，避免網絡延遲和GC的影響。 GC(Garbage Collection)垃圾回收機制
第1章：秒殺高並發優化分析
優化分析： 行級鎖在Commit之后釋放 優化方向減少行級鎖持有的時間
判斷Update更新庫存成功 優化思路： 把客戶端邏輯放在MySQL服務端，避免網絡延遲和GC影響
使用存儲過程： 整個事物在MySQL端完成。
第2章：redis后端緩存優化編碼
序列化到redis 主要通過這節內容學習了redis服務端的下載，和在linux機器上的安裝方法和命令，以及用jedis Java客戶端操作java對象緩存的api方法，和谷歌的protostuff序列化開源方案（比Java原生的序列化效率要高）來序列化和反序列化對象，緩存對象必須轉換為byte字節數組存入redis緩存，不像memcached可以直接緩存對象。實際操作思路是初次查詢redis緩存，如果沒有就從數據庫取出對象放入redis緩存，下次取就會直接從redis緩存取數據了。但緩存有超時時間限制。 具體操作：
用jedis Java客戶端操作java對象緩存的api方法，和谷歌的protostuff序列化開源Protostuff 序列化方案（比Java原生的序列化效率要高）來序列化和反序列化對象，緩存對象必須轉換為byte字節數組存入redis緩存. 
第3章：並發優化
簡單優化 減少行級所的存在時間 深度優化 事務sql在mysql端執行，使用存儲過程，整個事物在MySQL端完成。
利用存儲過程將執行秒殺的一條事務邏輯放到mysql服務端去執行，減少了客戶端和服務端之間的延遲和gc時間，客戶端只需要傳入參數執行存儲過程並根據得到的返回結果做相應的邏輯處理。存儲過程比較適合於簡單的邏輯。
第4章：系統部署架構