618 临近复盘最近推荐系统一些情况

召回集大小问题，线上实时推荐引擎服务能够处理请求数量是有限制的，需要在离线做更多工作，这是长期深入做推荐真正深入下去必然得到结论，浮在表面是无法深入理解推荐系统的。

ABTest便捷性，AB本质是测试数据效果好坏，在便捷AB框架也需要，算法测试人员花费智慧去设计有意义测试，而不是不找方向的胡乱测试。

推荐系统存储，因为推荐系统架构特殊性，需要存储性能极高单条数据2ms，批量数据10ms，对存储性能要求极高，并且由于推荐系统特殊性，每个人数据均不相同，在电商互联网公司业务请求量极大，通常业务10万/分钟 几十万/分钟。

微服务架构下推荐系统数据存储，有量的压力，请求量读写的量，并且最近出现了一个新的问题，连接数。redis连接数过多对于redis配置中心产生过大压力，公司自研架构。

想了几个办法来处理连接数过多问题，增加一层通用数据，redis中间件修改架构减少连接数，都没达到目的。经定位连接数增加是由于不断增加的业务以及不断增加数据，数据产生通过实时以及离线任务生成，离线hadoop任务写redis，storm准实时框架写redis导致大量连接增加，redis不堪重负，前边两种优化方案治标不治本。

需要有更彻底一些办法能够应对短期、中期业务增长，方案就是将redis进行分离，每个业务一个redis，每个微服务一个redis，避免redis在业务间共享导致连接数过多。

线上为什么尽量少去进行拉取数据计算，因为存储波动会导致业务性能不稳定，超时后会导致下游取不到结果。所以为了所有计算都能真正产生效益，需要我们精打细算，线上服务做合适量数据拉取以及计算。

与其他系统一样只要是线上业务必然会出现功能或者性能问题，线上服务应尽量避免出现问题，出现问题后要能快速规避，或者快速定位解决问题。

功能问题需要有必要数量日志，来辅助快速定位功能异常。但又要避免过多打印日志，线上服务需要打印过多日志，说明几个问题对于业务没有深入理解，对于技术没有把握能力，需要异常多日志定位问题，最后过多日志由导致磁盘满服务不可用，可真是够尴尬的。

最近还遇到一个问题，就是定时拉取通用数据拉取不到，首先去看redis存储是否存在，其次看数据是否读取时发生了超时，后来经定位发现是redis增加了授权检查需要程序重新编译启动即可。

性能，高并发下性能始终是一个比较大的挑战，需要存储、网络、服务、内存、cpu都处在比较好情况下，输出服务性能才是比较好的。

性能问题出现，要通过历史经验快速分析定位，快速解决问题，避免线上服务影响过多用户。性能问题从上面看很复杂，因为可能是应用写错了算法导致cpu高导致性能下降，可能是应用程序内存占用过多导致性能变差，还可能是存储比如redis性能变差，例如热点数据、大数据，还可能是网络出现问题，包重传过多导致性能变差，还有可能是两个或多个原因综合导致性能变差，需要我们做好监控，发现问题时快速定位，从最可能原因开始排除，解决性能问题，并及时进行总结复盘，为将来应对性能问题打好基础。

功能问题，做好完备测试，要覆盖大绝大部分路径，或者关键路径，这个是避免问题关键。

除了问题要有应急预案快速决策快速处理是避免事态进一步扩大关键。

时光飞逝，转眼又是半年，总结半年收获与得失，规划下半年规划，是一件目前需要做的事情，有了规划才能有目的有方向，并且达到目的提升我们自己。前半年项目有周末紧急上线，有周末去公司定位极其难定位的bug，有喝酒喝到懵逼的时刻，有这些难忘时刻。

也有很多问题还没有解决，比如前边说功能以及性能定位怎样做到全自动化监控，或者更全面监控，来到发生报警，即能快速定位问题目的。这是一个值得思考并且不断去自动化完善的有价值的问题。

规划重要有三点，对于过去问题思考、对于未来业务发展展望、以及团队执行能力。三位一体缺一不可，规划要立足于我们对过去问题思考，对于我们没有解决好问题，进行更好解决方案找寻，对于半年一年业务发展水平对技术进行规划，避免技术方案过于容易过时。