前言：最近做關于優(yōu)惠券的開發(fā)，但是發(fā)現(xiàn)優(yōu)惠券量大了之后，性能完全跟不上，庫中存200萬條優(yōu)惠券，發(fā)一張券竟然需要5分鐘之久，然后我就著手優(yōu)化，最終到發(fā)一張券只需要15毫秒左右，現(xiàn)在把整個思路以及代碼貼出來，供大家一起討論和學習。

簡介

主要實現(xiàn)優(yōu)惠券促銷活動，首先創(chuàng)建活動，然后創(chuàng)建券組，采用預處理的方式提前進行制券，在第一版本主要實現(xiàn)，功能的基本業(yè)務。然后在分支實現(xiàn)，大數(shù)量和高并發(fā)問題。

分支1.1

1：解決優(yōu)惠券編碼重復問題，原先采用的是獲取數(shù)據(jù)庫所有的券，然后去比對是否重復，如果庫數(shù)據(jù)量達百萬的時候就會出現(xiàn)非常緩慢，而且會 出現(xiàn)經(jīng)常制券失敗等，所以此版本舍棄原先采用隨機數(shù)的模式，通過推特的雪花算法來避免唯一，但是依然保留優(yōu)惠券前綴和后綴。

2：由原來的異步采用線程修改為線程池，以為高并發(fā)時候存在大量的線程占內(nèi)存空間。

3：由原來制券采用for循環(huán)模式修改為批量制券，而且采用分配插入優(yōu)惠券，一批次目前定為5000.

4：加入消息隊列（采用rabbitMQ）對于某一批次添加失敗，把失敗的放入對列中，通過隊列進行補救，已到達高可用。避免大批量優(yōu)惠券來回重新導入 消息隊列對于異常信息拒絕解決并重返消息隊列中，配置2個消費者以避免其中一個服務異常，消息處理出現(xiàn)死循環(huán)

分支1.2

1：加入操作日志

目的：跟蹤熱點數(shù)據(jù)，查詢?nèi)罩究焖俑檻贸绦蛑械穆樵兓蚵僮?，為后面的?yōu)化奠定基礎

2：加入異常日志

目的：快速的獲取線程的異常問題，通過日志中的數(shù)據(jù)能快速修改

3：采用技術 通過aop和rabbitmq中間件來做，這樣減少由于日志問題給程序帶來的效率問題

未做優(yōu)化效率統(tǒng)計

采用數(shù)據(jù)庫mysql

數(shù)據(jù)：添加25個有效活動，每個活動下分別有2個券組，每個券組下制券是5萬張。優(yōu)惠券表中250萬條記錄

業(yè)務：一個會員消費同時滿足這25個活動要送50張優(yōu)惠券。

統(tǒng)計：整個發(fā)券過程經(jīng)過10次統(tǒng)計得出大約消耗是306s，其中每次獲取優(yōu)惠券耗時6s。如果多次循環(huán)必然帶來性能的瓶頸

更新優(yōu)惠券狀態(tài)大約耗時是0.5s，從上我們可以看出我們的性能問題主要出在獲取優(yōu)惠券上。所以才1.3版本主要通過程序來解決這個問題

分支1.3

目的：通過程序代碼和優(yōu)化數(shù)據(jù)庫來提高性能

具體方案：

1：以前獲取券組下所有的優(yōu)惠券現(xiàn)在修改為每次只獲取100條(經(jīng)測試統(tǒng)計得出發(fā)送50張券消耗時間是106s，每次獲取優(yōu)惠券大約耗時是2s多，整體性能提升近3倍)

2：優(yōu)化sql，加入組合索引（統(tǒng)計得出發(fā)送50張優(yōu)惠券消耗總時間是2.5s，每次獲取優(yōu)惠券大約耗時是0.015s，整體的性能提升了近42倍）

3：加入本地緩存（如果一次性獲取的優(yōu)惠券先放入map中,那么下次如果還有就不需要從庫中獲取優(yōu)惠券。統(tǒng)計發(fā)現(xiàn)：10件商品，每件商品發(fā)50張優(yōu)惠券

不加本地緩存效率耗時是7.5s，加入本地緩存后耗時約5.5s，整體性能提升了2s）

效果分析：

4：對于發(fā)券采用批量更新來替代for循環(huán)(由上面的約5.5s性能提升為大約4.8s)

分支1.4

目的：通過異步和消息隊列來進行發(fā)券

具體方案：

1：通過異步進行發(fā)券，這樣可以提高cpu的利用率，同時通過消息隊列來保證穩(wěn)定性，避免出現(xiàn)異常導致返回前端發(fā)券成功，但是異步制券時候出現(xiàn)異常在發(fā)500張優(yōu)惠券的時候效率大約提升了0.5s

2：對代碼進行一次重構

原則：把大方法修改小方法，每個小方法處理一個業(yè)務，比如獲取活動，那么這個方法的職責就是獲取活動，同時每個小方法盡量有返回值，這樣可以增加代碼的可讀性

分支1.5

1：采用redis做緩存，取當天有效的活動，活動下券組，券組下500張券存入緩存中。

2：加入定時任務，在每天12點時候更新緩存（這個時間可以通過熱點數(shù)據(jù)來監(jiān)控）

3：統(tǒng)計結果發(fā)現(xiàn)：

加入緩存后發(fā)送500張優(yōu)惠券耗時只有2.7s，比之前的4.8s快了2.1s，大大的提升了性能

總結：代碼我就不貼，大家可以自己去看。感興趣的朋友可以在這個基礎繼續(xù)研發(fā)學習。在版本1.6可能加入分庫分表，目前想采用的是當當?shù)膕harding-jdbc

源碼地址

以上就是本文的全部內(nèi)容，希望本文的內(nèi)容對大家的學習或者工作能帶來一定的幫助，同時也希望多多支持腳本之家！

最新評論