優(yōu)惠券優(yōu)惠的思路以及實(shí)踐

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

簡(jiǎn)介

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

分支1.1

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

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

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

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

分支1.2

1：加入操作日志

目的：跟蹤熱點(diǎn)數(shù)據(jù)，查詢?nèi)罩究焖俑檻?yīng)用程序中的慢查詢或慢操作，為后面的優(yōu)化奠定基礎(chǔ)

2：加入異常日志

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

3：采用技術(shù) 通過(guò)aop和rabbitmq中間件來(lái)做，這樣減少由于日志問題給程序帶來(lái)的效率問題

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

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

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

業(yè)務(wù)：一個(gè)會(huì)員消費(fèi)同時(shí)滿足這25個(gè)活動(dòng)要送50張優(yōu)惠券。

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

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

分支1.3

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

具體方案：

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

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

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

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

效果分析：

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

分支1.4

目的：通過(guò)異步和消息隊(duì)列來(lái)進(jìn)行發(fā)券

具體方案：

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

2：對(duì)代碼進(jìn)行一次重構(gòu)

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

分支1.5

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

2：加入定時(shí)任務(wù)，在每天12點(diǎn)時(shí)候更新緩存（這個(gè)時(shí)間可以通過(guò)熱點(diǎn)數(shù)據(jù)來(lái)監(jiān)控）

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

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

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

源碼地址

以上就是本文的全部?jī)?nèi)容，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助，同時(shí)也希望多多支持億速云！