2017-12-27
工作遇到的小问题
根据筛选条件获取用户id存入redis
启动异步脚本，根据id获取全部信息（令牌之类）分批推送
问题一：获取用户id仍然耗时过长，采用异步脚本获取，可以直接获取全部信息
问题二：获取数据耗时长，推送快，导致下一批数据进入时异步脚本已经全部关闭
解决方式：动态维护进程数
结果：不够理想
不能优化好数据存入和消息推送的速度协调性，导致脚本的开关过于频繁，内部的循环不能很好利用
问题三：合理使用switch合并方法，去除三种推送的重复代码
结果：不够理想
符合业务逻辑将导致代码冗余，代码简约时业务逻辑有瑕疵
注意：异步脚本必须采用命令行形式启动
命令行的参数不能太复杂，需存入redis供跨进程交互
分析记录
一、现有方式
推送对象拉取速度小于脚本推送时间，导致推送中断，推送对象剩余（之前不会出问题吗）
完美情况下仍旧存在推送数量的上限
二、获取完整推送对象后再推送
内存占用大，整体延时高
不清楚推送消息的及时性需要满足到什么程度？
三、动态控制进程数量
目前考虑存在redis中，异步维护进程数量的变量会冲突吗？
命令行获取？
每个进程循环数少，使用效率低，进程开关频率相对高
四、每拉取一次开启固定脚本数
消息延迟比一次多开慢
推送速度快会导致循环数低
推送速度慢进程数量激增
不会出现推送对象剩余
五、按需开启脚本，一次循环pop存数组
不会浪费进程但存在固定的延时代价
