2017-12-27

工作遇到的小問題

根據(jù)篩選條件獲取用戶id存入redis
啟動異步腳本，根據(jù)id獲取全部信息（令牌之類）分批推送

問題一：獲取用戶id仍然耗時過長，采用異步腳本獲取，可以直接獲取全部信息

問題二：獲取數(shù)據(jù)耗時長，推送快，導(dǎo)致下一批數(shù)據(jù)進(jìn)入時異步腳本已經(jīng)全部關(guān)閉
解決方式：動態(tài)維護(hù)進(jìn)程數(shù)
結(jié)果：不夠理想
不能優(yōu)化好數(shù)據(jù)存入和消息推送的速度協(xié)調(diào)性，導(dǎo)致腳本的開關(guān)過于頻繁，內(nèi)部的循環(huán)不能很好利用

問題三：合理使用switch合并方法，去除三種推送的重復(fù)代碼
結(jié)果：不夠理想
符合業(yè)務(wù)邏輯將導(dǎo)致代碼冗余，代碼簡約時業(yè)務(wù)邏輯有瑕疵

注意：異步腳本必須采用命令行形式啟動
命令行的參數(shù)不能太復(fù)雜，需存入redis供跨進(jìn)程交互

分析記錄

一、現(xiàn)有方式
推送對象拉取速度小于腳本推送時間，導(dǎo)致推送中斷，推送對象剩余（之前不會出問題嗎）
完美情況下仍舊存在推送數(shù)量的上限

二、獲取完整推送對象后再推送
內(nèi)存占用大，整體延時高
不清楚推送消息的及時性需要滿足到什么程度？

三、動態(tài)控制進(jìn)程數(shù)量
目前考慮存在redis中，異步維護(hù)進(jìn)程數(shù)量的變量會沖突嗎？
命令行獲取？
每個進(jìn)程循環(huán)數(shù)少，使用效率低，進(jìn)程開關(guān)頻率相對高

四、每拉取一次開啟固定腳本數(shù)
消息延遲比一次多開慢
推送速度快會導(dǎo)致循環(huán)數(shù)低
推送速度慢進(jìn)程數(shù)量激增
不會出現(xiàn)推送對象剩余

五、按需開啟腳本，一次循環(huán)pop存數(shù)組
不會浪費進(jìn)程但存在固定的延時代價