现在几乎所有的电商平台都或多或少的上了推荐系统,常用的推荐系统有。热门推荐、最近浏览、猜你喜欢、看了还看、买了还买、绑定销售,等等,这么多NB的系统都依赖一点,就是用户行为数据,这些用户行为数据都从那来的呢,那就是埋点系统了,埋点系统是一切推荐系统的生命源。
所谓埋点系统,按本人理解就是埋点引擎+存储系统,埋点引擎位于前端系统与后端存储系统之间,主要是接收前端的埋点数据,经协议转换以后存储到后端存储系统。
整个系统的架构如下所示:
1,用户行为搜索存储格式选择
数据存储格式一定要考虑到足够的可伸缩性,因为业务方的需要总是千奇百怪,一个NB的存储设计可以减少后续很多工作量,下面是我设计埋点系统存储的数据项,欢迎讨论。
Name | Des&R |
msg_id | 消息ID |
realuserid | 用户ID,登录后存在, |
sysname | 来源系统的名称 |
servicetype | 具休来源页面 |
oper_type | 行为类型 |
appid | 移动应用会有APPID |
location | 移动应用会有APPID位置信息 |
accesstime | 访问时间 |
ip | PC端IP地址 |
itemid | 商品ID |
anomoususerid | 用户ID,没有登录存匿名,登录以后存实际用户ID |
descinfo | 描述信息,日志类型是评分时,此处写评分 |
sessioninfo | 会话IDs,随机生成的10位数字,每位单独生成 |
2,存储系统选择
当时选择HBASE主要是考虑到两点因素,一是它的可伸缩性,一是它较高的实时性,当然也有很多其它的选择,比如mongodb 也不行,只是我没有用过,不熟。
3,埋点引擎
埋点引擎是本系统的核心所在,主要负责解析前端发来的http消息,解析以后通过thrift协议丢给thriftserver,thriftserver再放到HBASE。
这个设计上来讲还是比较简单,主要是要考虑到高并发,短连接的情况,下面是单机的一个设计。
采用了比较典型的多线程设计模型。
Monitor是主线程,负责接收前端的埋点消息,通过某种调度算法放到对应的队列,给客户端应答埋点成功消息。
Scheduler:调度模块,Monitor调用,不是单独线程。
QX:消息队列,采用无锁队列设计,可以理解为一个先进先出的缓存机制,Monitor负责生产消息,Worker负责消费消息。
Worker:负责消息的校验,合法性检查,解析,打包,发送任务。