当博主在写 基于spark-streaming实时推荐系统（一）， 基于spark-streaming实时推荐系统（ 二）时，心里还曾暗自窃喜：“五年多推荐系统设计研发工作，再搭一套推荐系统还不是轻松的事么！”。只有真正做了之后才知道这其中的辛酸与血泪。
首先博主前期的推荐系统经验主要是基于传统电商网站，推荐的主体是用户，推荐的内容是商品。商品只要能够满足销售的基本要素便一直是众多商品推荐池中的一份子，这样的大背景的有几个优势：1.待推荐结果集百万千万级；2.无需实时考虑商品状态是否可售；3.可以直观的反馈商品相似度；4.商品容易分类等。可以设想一种新的推荐场景：虽然推荐主体依旧还是用户，但是推荐的内容是人。人存在着诸多的不确定性，不能保证人状态的长期有效，也无法准确的通过除了性别之外的标签去完全准确无误的将人进行分类。
这期博主主要从推荐系统的工程化方面简单介绍。实时推荐系统核心主线设计图大致如下：
上图主要是依托 spark+kafka+redis搭建实时在线推荐系统。矩形代表业务处理模块，竖条代表kafka，圆柱形代表redis。logSystem模块是日志采集系统实时传输数据写进kafka；reparation模块是日志清洗及根据用户进行hash，使相同的用户只会写到某一个paration中；statue模块可以根据系统设计需要，主要考虑到随着用户浏览时长等因素作为权重值所需，并进行hashParation保证每个分区数据分布均匀；bussines模块主要根据具体的业务逻辑计算用户对某一篇好的得分；rank模块在设计之初是与bussines模块合并的，但是在实际环境中运行时会出现系统堆积的现象，故单独拆开，主要是根据用户偏好得分并进行一定规则的过滤直接推荐，能够更加实时。
kafka有很多特性，其中最重要的是快，再次是同一个topic可以被多个业务模块单独消费。redis当然就不用在介绍了。至于spark么，如果非要说为啥会选择spark-streaming，那只能说博主最近一直从事spark的开发工作~~
代码结构图
看到此图的你或许会问，设计图中才那么几个模块，怎么代码中会有这么多模块呀~~~基于保密协议，博主只能给大伙简单介绍梗概。多推荐模块当然也是在同步开发中。
遇到的问题
1.rank模块是当前系统中性能的瓶颈所在，经常会出现在一个批次中无法完成任务出现大量堆积的现象，可以通过spark UI页面，观察kafka各分区offset大小：
如果发现各个partition的offset差值出现不均匀的现象，则需要在statue模块写入kafka进行reparation，spark默认的是hashParation，也可以自定义reparation方法。
2.在流量高峰时会出现任务基本在死亡线的边缘徘徊
真心有点丢人，博主对代码进行了各种优化，代码虐我千百遍，我依旧待它如初恋。能想像么，白天是这样的：
事实告诉我们，这真是一个悲伤的故事。最后的最后怀疑的重点是带宽问题，但是这个问题至今还尚未被证实。哎，这真是个悲伤的故事。
结束语
本博文只是为从事推荐系统开发设计的算法工作者们提供一个系统设计的思路，因为保密协议的约束，不在此处介绍推荐系统算法设计方案，系统详细设计方案，以及其带来的影响收益。
同行们可以根据上述设计图进行符合自身业务需要的模块拆分与新增，详细可以参考 基于spark-streaming实时推荐系统（ 二）中设计图，未来的一段时间博主都会围绕那张设计图进行系统的扩展，以期能给公司带来巨大收益。