前言：最近做關于優惠券的開發，但是發現優惠券量大了之后，性能完全跟不上，庫中存200萬條優惠券，發一張券竟然需要5分鐘之久，然后我就著手優化，最終到發一張券只需要15毫秒左右，現在把整個思路以及代碼貼出來，供大家一起討論和學習。
簡介
主要實現優惠券促銷活動，首先創建活動，然后創建券組，采用預處理的方式提前進行制券，在第一版本主要實現，功能的基本業務。然后在分支實現，大數量和高并發問題。
分支1.1
1：解決優惠券編碼重復問題，原先采用的是獲取數據庫所有的券，然后去比對是否重復，如果庫數據量達百萬的時候就會出現非常緩慢，而且會 出現經常制券失敗等，所以此版本舍棄原先采用隨機數的模式，通過推特的雪花算法來避免唯一，但是依然保留優惠券前綴和后綴。
2：由原來的異步采用線程修改為線程池，以為高并發時候存在大量的線程占內存空間。
3：由原來制券采用for循環模式修改為批量制券，而且采用分配插入優惠券，一批次目前定為5000.
4：加入消息隊列（采用rabbitMQ）對于某一批次添加失敗，把失敗的放入對列中，通過隊列進行補救，已到達高可用。避免大批量優惠券來回重新導入 消息隊列對于異常信息拒絕解決并重返消息隊列中，配置2個消費者以避免其中一個服務異常，消息處理出現死循環
分支1.2
1：加入操作日志
目的：跟蹤熱點數據，查詢日志快速跟蹤應用程序中的慢查詢或慢操作，為后面的優化奠定基礎
2：加入異常日志
目的：快速的獲取線程的異常問題，通過日志中的數據能快速修改
3：采用技術 通過aop和rabbitmq中間件來做，這樣減少由于日志問題給程序帶來的效率問題
未做優化效率統計
采用數據庫mysql
數據：添加25個有效活動，每個活動下分別有2個券組，每個券組下制券是5萬張。優惠券表中250萬條記錄
業務：一個會員消費同時滿足這25個活動要送50張優惠券。
統計：整個發券過程經過10次統計得出大約消耗是306s，其中每次獲取優惠券耗時6s。如果多次循環必然帶來性能的瓶頸
更新優惠券狀態大約耗時是0.5s，從上我們可以看出我們的性能問題主要出在獲取優惠券上。所以才1.3版本主要通過程序來解決這個問題
分支1.3
目的：通過程序代碼和優化數據庫來提高性能
具體方案：
1：以前獲取券組下所有的優惠券現在修改為每次只獲取100條(經測試統計得出發送50張券消耗時間是106s，每次獲取優惠券大約耗時是2s多，整體性能提升近3倍)
2：優化sql，加入組合索引（統計得出發送50張優惠券消耗總時間是2.5s，每次獲取優惠券大約耗時是0.015s，整體的性能提升了近42倍）
3：加入本地緩存（如果一次性獲取的優惠券先放入map中,那么下次如果還有就不需要從庫中獲取優惠券。統計發現：10件商品，每件商品發50張優惠券
不加本地緩存效率耗時是7.5s，加入本地緩存后耗時約5.5s，整體性能提升了2s）
效果分析：
4：對于發券采用批量更新來替代for循環(由上面的約5.5s性能提升為大約4.8s)
分支1.4
目的：通過異步和消息隊列來進行發券
具體方案：
1：通過異步進行發券，這樣可以提高cpu的利用率，同時通過消息隊列來保證穩定性，避免出現異常導致返回前端發券成功，但是異步制券時候出現異常在發500張優惠券的時候效率大約提升了0.5s
2：對代碼進行一次重構
原則：把大方法修改小方法，每個小方法處理一個業務，比如獲取活動，那么這個方法的職責就是獲取活動，同時每個小方法盡量有返回值，這樣可以增加代碼的可讀性
分支1.5
1：采用redis做緩存，取當天有效的活動，活動下券組，券組下500張券存入緩存中。
2：加入定時任務，在每天12點時候更新緩存（這個時間可以通過熱點數據來監控）
3：統計結果發現：
加入緩存后發送500張優惠券耗時只有2.7s，比之前的4.8s快了2.1s，大大的提升了性能
總結：代碼我就不貼，大家可以自己去看。感興趣的朋友可以在這個基礎繼續研發學習。在版本1.6可能加入分庫分表，目前想采用的是當當的sharding-jdbc
以上就是本文的全部內容，希望本文的內容對大家的學習或者工作能帶來一定的幫助，同時也希望多多支持服務器之家！
原文鏈接：http://www.cnblogs.com/LipeiNet/p/6379579.html
