电子商务时代，商家急切的寻求着对用户展示商品达到千人千面的效果，并且实时根据用户行为去实时更新待推荐的商品集。正如百度大boos李彦宏同学在乌镇物联网大会上所说:"机器学习的时代即将到来。"
博主从事推荐系统开发设计五年有余，深深的触摸到了机器学习时代的影子，从刚开始接触推荐，到先如今各大电子商务平台，甚而流媒体平台等都是搭建自己的推荐系统平台，让机器去学习用户的行为以便达到精准营销的目标。 最近博主借助flume-kafka-spark-streaming-redis搭建了一套实时在线推荐系统，从零开始逐步摸索出了一套非常适合当前业务背景的实时在线推荐系统架构。
实时推荐么，顾名思义就是快速响应。既然要做到快速响应，就要让系统做最少的事。当我们最开始搭建实时推荐平台的时候，不管是日志解析、状态的管理、权重的计算、结果的推荐、实时数据的过滤、离线数据的补充等模块都在一个线程中，通过spark-streaming中mapPartitions分布式去处理任务，效果相当的糟糕，出现了大量的堆积。后续便开始尝试着对业务模块进行拆分，每个模块只负责一块业务，系统允许一定时间的误差。最终选择了如下架构设计：
由于算法模块会不断的进行迭代，为了满足AB测试的需要，借助kafka group的特性，对用户ID进行hash分流，部署不同版本的score模块，最终输出到同一个topic中即可。因为当前业务推荐场景中有停留时间这个因子，选择了redis保存中间状态，放弃了使用spark自身的checkpoint机制（缺点：checkpoint每次都是全量），然而噩耗还是传来，此处竟然成为了整个系统快速响应的瓶颈。由于暂时没有想到更好的优化方案，竟然退而求其次在系统设计中加入了fastRespons模块，只要用户有行为就会在1秒内通过各种方式产生推荐结果（这实在是太尴尬了）。
附score模块运行spark ui图：
批次耗时：
spark-streaming由于存在批次提交的问题，始终感觉都没有storm速度快，毕竟处理时间会小于批次时间间隔~~~