搜尋湊單頁大促顯示延遲方案設計

考拉湊單頁為整單類活動湊單頁面，從大促的表現來看，承載在考拉全站差不多5%左右的請求量，尤其在大促整單類活動比較多的情況，對於湊單商品的實時性就有更高的要求，要不然使用者沒有入口做湊單，已考拉目前的湊單頁位址如效果如下

考拉目前的搜尋湊單頁基於杭研的ndir去構建doc，但是考拉在大促的時候零點那乙個時刻，按照3月8大促的量，存在幾十萬商品更新索引資訊，因為所有商品的**資訊都需要更新到ndir裡面，隨著考拉業務的不斷發展，商品的數量級仍然會不斷增加，但是對於ndir來說，更新索引是比較耗時，基於lucene全文檢索實現，更新一般分為刪除和插入操作doc，之前考拉的方案由於商品不多，所以在變更活動資訊基於mq訊息通知搜尋，搜尋觸發更新索引操作會呼叫**介面更新ndir，**會給出當前的實時**資訊，活動結束的時候也會觸發mq訊息通知，這樣保證活動開始和活動結束這個搜尋可以即使的構建活動。

但是隨著考拉商品sku數量不斷擴大，ndir的更新瓶頸顯得尤為明顯，尤其在大促時候，瞬間有幾十萬商品參加活動，這樣mq訊息就顯得特別的龐大，按照之前資料量全部更新一次索引差不多兩個小時，但是大促開始那個時刻是下單量最大的，這段時間的湊單頁不實時直接影響轉化率和使用者體驗。

所以整個大促的活動整體優化方案

1.搜尋增加乙個索引字段專門為湊單頁去匹配，這個欄位只給湊單頁使用

2.**對於整單類活動的時間，**提前返回全部未開始的整單類活動，整單類活動在發動發布的時候就重新整理進快取

3.**的整單類活動的開始時間以會員時間為準，如果處於提前購階段或者未開始的時間存在提前購增加返回提前購標示，整單類還需要把非會員開始時間，整單類結束時間落庫

4.對於中途整單類活動已經刷進ndir，運營變更活動，修改，刪除等活動都需要的實時重新整理到ndir去

新增乙個索引字段，主要是為了避免正在進行的活動和未開始的活動的區分，在考拉的主搜那邊會根據goods_tag去獲取正在進行的活動，使用者前台可以根據是否有**搜尋商品資訊，這塊資訊要保證實時的一致性，否則會引起很大的客訴，湊單頁的url比較固定，這樣會被使用者窮舉，加入使用者訪問了乙個未開始的活動，這樣也會有問題。對於這個窮舉問題，考拉目前的做法是頁面和資料分兩個請求，頁面請求為同步請求，同步請求的時候會根據活動方案號去**系統查詢改方案是否有效，如果為非法的方案號，直接渲染404錯誤頁面，否則跳轉正常的湊單頁，然後再根據ajax請求搜尋資料

整個基於mq訊息通知去更新索引資訊，由於活動的資料時間經常變更，因此需要在活動發布，活動開始，**審核通過，活動暫停，活動恢復等活動變更的流程中去控制ndir裡面的索引資料，目前這塊業務整合在**的訊息通知裡面，為了避免一次訊息量過大，**傳送訊息時候做了一次分批處理

@override
public void sendactivitynotifymessage(listgoodsidlist) 
listnotifygoodsidlist = new arraylist<>(new hashset<>(goodsidlist));
int batchsize = promotionconfig.getinteger(sendactivitynotifybatchsize, 500);
listutils.split(notifygoodsidlist, batchsize, new pageprocess() ",pageidlist);
map> param = maps.newhashmap();
param.put("goodsidlist", pageidlist);
rabbittemplate.convertandsend(param); 
} });
}

活動變更時候為了減少傳送量，只會把變更商品傳送給ndir那邊，變更資料主要為新增，修改和刪除的商品id，**這邊基於定時任務傳送變更資訊，定時任務每一分鐘傳送一次，資料表乙個商品在同乙個時間點存在多個活動，這時候變更記錄只會有一條，所以資料庫設計以商品id和時間維度，具體表設計如下

create table tb_activity_notify
(id varchar2(32) not null,
goods_id number(10) not null,
update_time timestamp(6) default sysdate not null,
send_flag number(1) default 0 not null,
constraint pk_tb_activity_notify primary key (id)
);

該錶為了保證通知效能，需要定時清除，因為大促的商品資料量很大，如果不做定時清理或者分割槽，會導致通知表的效能下降，所以增加乙個send_flag表示通知標示，如果已經傳送的成功的話，則修改為y，這樣定時清除就可以通過標示清除已傳送資料

【推薦】容器平台選型的十大模式：docker、dc/os、k8s 誰與當先？

【推薦】 mysql innodb 索引原理

搜尋湊單頁大促顯示延遲方案設計

搜尋湊單頁大促顯示延遲方案設計

搜尋湊單頁大促顯示延遲方案設計

織夢 搜尋頁

相關推薦

織夢搜尋頁