背景
一鍵導(dǎo)出功能揩徊，一次可以導(dǎo)出大量數(shù)據(jù)，最終導(dǎo)出形式為壓縮包。后端需要把生成壓縮包的進度實時發(fā)給前端
痛點
1.如果用戶導(dǎo)出的數(shù)據(jù)量過大搓劫，后端生成壓縮包時間過長，超出http請求的時間限制混巧，前端會斷開連接
2.用戶需要等待較長時間枪向，體驗較差
技術(shù)方案
1.前端生成uuid，使用uuid作為websocket的userId咧党，開啟websocket
2.后端使用ConcurrentHashMap保存userId與對應(yīng)的session秘蛔，key為userId，value為session
3.在導(dǎo)出文件的http請求的參數(shù)中加入uuid傍衡，后端根據(jù)uuid找到session深员，并把文件導(dǎo)出進度通過websocket實時發(fā)送到前端
問題
以上方案，在單機系統(tǒng)沒有問題蛙埂，但如果是分布式系統(tǒng)倦畅，會有問題。
后端服務(wù)通過容器部署绣的，假設(shè)是雙實例滔迈，前端websocket連接請求發(fā)到實例A，但是http請求發(fā)到了實例B被辑，實例B上找不到userId對應(yīng)的session燎悍，因此發(fā)送消息給前端失敗。
系統(tǒng)已經(jīng)做了會話保持盼理，但是是通過cookie（JSESSIONID）實現(xiàn)的谈山，而不是nginx的iphash，因此只能控制http請求發(fā)到同一個實例宏怔，無法控制websocket連接請求和http請求發(fā)到同一個實例
解決方案一
整個導(dǎo)出功能使用websocket進行通信奏路，不使用http請求，所有請求參數(shù)通過websocket傳輸臊诊。
注意事項
websocket消息有長度限制鸽粉，需要修改org.apache.tomcat.websocket.textBufferSize
@Configuration
public class WebAppRootContext implements ServletContextInitializer {
@Override
public void onStartup(ServletContext servletContext) throws ServletException {
servletContext.addListener(WebAppRootListener.class);
// websocket消息有長度限制，默認(rèn)限制是8k個字符抓艳，這里改成1024k
servletContext.setInitParameter("org.apache.tomcat.websocket.textBufferSize", String.valueOf(1024 * 1024));
}
}
解決方案二
使用nginx配置iphash實現(xiàn)會話保持
解決方案三
使用kafka解決websocket多實例問題（實例指部署后端服務(wù)的容器實例）
1.每個實例維護一個ConcurrentHashMap触机，保存連接到該實例的userId和session
2.每個實例把要發(fā)給客戶端的消息（導(dǎo)出進度），通過kafka廣播模式發(fā)給所有kafka消費者
3.消費者收到消息后，從消息中提取出userId儡首，判斷該userId對應(yīng)的session是否存在于本實例片任，若存在，則把消息通過websocket發(fā)到前端蔬胯，若不存在对供，直接舍棄消息（因為session在其他實例）
使用nginx代理websocket的注意事項
1.客戶端與服務(wù)端之間有nginx時，nginx是七層負(fù)載均衡氛濒，即在應(yīng)用層代理真實客戶端轉(zhuǎn)發(fā)http請求产场，并代理真實服務(wù)端把響應(yīng)結(jié)果返回給客戶端，nginx與真實服務(wù)端的讀超時時間限制默認(rèn)是60s舞竿，也就是超過60s會斷開websocket長連接京景，需要把該時間限制改大一點
#改成10分鐘
proxy_read_timeout 600s
2.需要配置把http協(xié)議升級為ws協(xié)議
Error during WebSocket handshake: Unexpected response code: 404
websocket進度條準(zhǔn)確性控制
技術(shù)方案
在執(zhí)行具體業(yè)務(wù)邏輯之前，就計算好任務(wù)量炬灭，假設(shè)一次導(dǎo)出請求醋粟，包含ABCDE五個步驟，那就把任務(wù)量定為5重归，每執(zhí)行完一個步驟米愿，就把進度增加20%，全都執(zhí)行完畢后鼻吮，進度為100%育苟。
問題1
假如五個步驟的耗時不同怎么辦，比如ABCDE的耗時比例為6:1:1:1:1
解決方案
根據(jù)耗時比例椎木，加權(quán)計算任務(wù)量违柏，比如把任務(wù)量定為10，其中A占6個任務(wù)量香椎，完成A后進度增加60%
問題2
假設(shè)A步驟耗時1分鐘漱竖，那么用戶看到進度條1分鐘不動，然后突然升到60%畜伐，體驗會非常差馍惹。
解決方案
需要把A步驟繼續(xù)拆分，比如玛界，根據(jù)時間區(qū)間等入?yún)⑼蚍琧ount查詢可以確定A步驟需要查1w條數(shù)據(jù)，需要分頁查詢10次慎框，那么可以把A步驟分成10個子任務(wù)良狈，每個任務(wù)執(zhí)行完成后，進度增加60% / 10 = 6%
問題3
問題2的解決方案中笨枯，A步驟具體需要怎么拆分薪丁，很難在一開始確定遇西，需要執(zhí)行到具體的代碼段（比如count查詢）才能確定
解決方案（分治算法）
一開始計算任務(wù)量的時候，還是分配6個任務(wù)量給A窥突，至于A怎么分配這6個任務(wù)量努溃，由A執(zhí)行到具體代碼段的時候再決定硫嘶。比如執(zhí)行count查詢后發(fā)現(xiàn)需要分頁查10次阻问，那么每一次分頁查詢后進度增量為60% / 10 = 6%
