商家信誉体系

1.日志上报格式

 1.用户APP日志上报格式

字段类型	字段	字段名
通用字段	uuid	用户唯一标识
	v_name	APP版本
	user_id	用户ID
	imei	设备IMEI号
	ss	设备屏幕大小
	a_os_v	安卓系统版本
	ios_v	苹果系统版本
	brand	设备品牌
	model	设备型号
	nw	网络（wifi=nw，2g，3g，4g）
	mac	设备mac地址
	lon	经度
	lat	维度
	tt	事件发生时间戳（毫秒）
	ip	IP地址
	pr	省
	ci	市
	di	区
业务字段	ev_type	事件类型(点击:C)
	ev_id	事件ID
	store_id	店铺ID
	goods_info_id	货品ID
	times	使用时常、曝光时长

2.商户APP日志上报格式

字段类型	字段	字段名
通用字段	uuid	商户唯一标识
	v_name	APP版本
	store_id	商户ID
	imei	设备IMEI号
	ss	设备屏幕大小
	a_os_v	安卓系统版本
	ios_v	苹果系统版本
	brand	设备品牌
	model	设备型号
	nw	网络（wifi=nw，2g，3g，4g）
	mac	设备mac地址
	lon	经度
	lat	维度
	tt	事件发生时间戳（毫秒）
	ip	IP地址
	pr	省
	ci	市
	di	区
业务字段	ev_type	事件类型(点击:C)
	ev_id	事件ID
	times	使用时长、曝光时长

3.商户WEB日志上报格式

字段类型	字段	字段名
通用字段	uuid	商户唯一标识
	store_id	商户ID
	browser	浏览器
	br_v	浏览器版本
	tt	事件发生时间戳（毫秒）
业务字段	ev_type	事件类型(点击:C)
	ev_id	事件ID
	times	使用时长、曝光时长

 

2.架构图

       埋点数据通过Collector收集因子数据，经过logstash有两个输出，落入ES做报表分析，发送因子消息到MQ作为信誉体系的源数据。

       存量数据分为两部分，店铺数据和因子数据，店铺数据在店铺有信息变更时，通过发送店铺消息到MQ，因子数据在相关行为触发时，实时发送因子消息到MQ。

       MQ的数据由信誉体系核心系统（埋点系统放到一起）消费，存储到数据库，定时计算用户信誉分支。

3.MQ队列

消息格式：

因子消息

字段	字段名	类型
msgId	消息ID	String
storeId	店铺ID	Long
factorId	因子ID	Long
factorExpand	因子扩展字段	String
comment	备注	String
timestamp	时间戳	Long

店铺消息

字段	字段名	类型
msgId	消息ID	String
id	店铺ID	Long
name	店铺名字	String
bizType	店铺类型	String
status	店铺状态	Byte
comment	备注	String
timestamp	时间戳	Long

埋点消息

字段	字段名	类型
msgId	消息ID	String
ev_id	事件ID	String
storeId	店铺ID	Long
goods_info_id	货品ID	Long
timestamp	时间戳	Long

 

队列名	数据源	消息格式	说明
store_edit_queue	Olink	店铺消息	监听店铺状态数据变更
credit_factor_queue	Olink、shop-web、shop-api	因子消息	因子触发时，发送消息
burying_sys_queue	Collector	埋点消息

        为避免重复消费，需生成全局唯一的msgId。

生成策略1：

        日期 + redis当日自增

缺点：依赖于redis，一旦redis中数据有丢失，没有可靠的重新载入机制。

生成策略2：

        时间戳 + redis自增

生成策略3：

        MD5（UUID() + timestamp + factorId）

缺点：不能保证全局唯一

 

生成策略4：

       时间戳 + 机器号 + 机器自增ID

4.信誉体系核心系统

       数据存储

              因子数据：参考当前埋点数据，五月份只有160M（26W条）的数据量，每天大概有1W条数据。因子数据1K大小，考虑平台的数据增长，预估每天有10W（100M）条因子数据，一个月有300W（3G）。

      这部分数量增长不可控，具有时效性，选择将其放入Elasticsearch中按月分索引存储，方便将数据淘汰且不会丢失（关闭过期索引即可），易于扩容且利于数据做聚合分析。

             店铺每日因子基数：每个月3KW=店铺数量（4W）*因子数(24)*天数(30)，其为中间结果数据，且数据增长可控（与店铺、因子个数线性相关，不会爆发式增长），可以定时清除数据。

       系数数据来源：SQL初始化。初始化后保存修改版本，版本号加入日期，若当日有多次修改，只保存当日最终修改的数据。

       信誉分值计算：每天凌晨计算前一天的店铺信誉分值、店铺每个因子的基数、所有店铺总的因子基数、保存当日使用的系数版本号。

 

数据库表：店铺因子源数据表（ES）、店铺数据表、店铺因子系数版本表、店铺因子每日基数表、店铺信誉得分表、每日信誉设置表（基数、因子系数版本）。

5.信誉体系计算引

6.部署

略

7.数据初始化

初始化

        埋点因子数据：没有数据可供初始化。

        存量因子数据：Olink、Shop-Web分别提供存量因子初始化接口，发送数据到初始换的MQ队列，由商家信誉核心系统触发。

        店铺数据：由Olink初始化，初始化策略与存量因此数据一致，自营店铺数据需SQL初始化。

商家信誉核心系统状态：正常 （接受同步数据、不接受初始换数据）、格式化中或格式化完成（不接受任何数据）、初始化（接受初始换数据）

8.故障修复监控

    MQ连接断开：发送失败的数据写入本地文件缓存，邮件提醒，恢复正常后重新发送。

    Collector时间异常，接口检验失败：增加错误检验失败统计，设置阈值警报；将时间戳异常的数据单独按日存储，同时保存服务器时间戳、及客户端时间戳，待时间恢复正常后，手动调用接口处理此类数据，接口参数为服务器异常时间于正常时间的差值。

    信誉分值重算： 线上环境不可预测，提供重新计算某天的信誉分值功能，用于补全修复数据。