站内消息2.0
版本 操作人 版本 日期 备注 王建成 2.0 2015-11-03 2.0设计文档
站内消息设计:
一、功能概述:
站内消息是为了增加用户活跃度,传递运营消息,增加用户参与度,从而达到留住用户,使用户消费的目的,是拉新、活跃、留存里重要的一环。
功能需求:
1、用户在个人中心对应入口能看到是否有未读消息的标志(红点)。
2、已读消息和未读消息列表,未读消息优先展示。
3、所有消息可删除清空。
4、运营平台可以指定渠道和用户级别群发消息,也可以指定用户发送消息。
5、运营平台可以查看发送消息的记录。
6、消息推送时可关联影片,关联的影片需嵌入超链,在用户点击消息详情中
的连接直接跳转到对应影片页面。
二、功能设计:
1、相关表设计
1).发送通知消息表(send_message)
字段名 类型 含义 备注
id Int(10) 主键
P_id Int(10) 项目id
Type Int(1) 1是指定用户
Title Varchar(200) 消息的标题
content Varchar(1000) 消息的内容
tag Varchar(200) 消息的标签
channels Varchar(500) 渠道号
user_types Varchar(200) 用户级别
mv_ids Varchar(2000) 相关影片的id
mv_names Varchar(2000) 相关影片的名称
Remark Varchar(500) 备注
detail1 Varchar(200) 备用字段
detail2 Varchar(200) 备用字段
update_time datetime 更新时间 发送时间也是这样
2).通知消息关联用户表(send_message_user)
字段名 中文名 类型 说明
id Int(10) 主键
s_id Int(10) 发送通知的id send_message的id
user_id Int(10) 移动用户的id mobile_user的id
update_time datetime 更新时间
3).通知消息表(message)
字段名 类型 含义 备注
id Int(10) 主键
p_id Int(10) 项目id
s_id Int(10) 相关发送表的id 通知类型的才有,其他默认为0
type Int(2) 消息的类型 0通知1留言2评论
comment_type Int(2) 评论的类型 1、时间点2、全篇默认为0,非评论
origin Int(2) 消息的来源 0系统1用户
Title varchar(200) 消息的标题
content varchar(1000) 消息的内容
tag varchar(200) 消息的标签
target Varchar(200) 相关目标 如果是评论就是id
send_time datetime 发送时间
detail1 Varchar(200) 备用字段
detail2 Varchar(200) 备用字段
update_time datetime 更新时间
4).用户消息表(user_message_check)
字段名 类型 含义 备注
id int(10) 主键
user_id int(10) 用户的id
unread text 用户未读消息 存储message的id,多个id用,连接
readed text 用户已读消息 存储message的id,多个id用,连接
status int(2) 是否有未读消息 1有未读,0是没有
update_time datetime 更新时间
2、相关缓存设计
1).messageobj:${msgId} hmset类型,存储对应id的消息通
知对象,有效期7天
2).usermessagecheckobj:${checkId} hmset类型,存储对应id的用户消息状
态表对象,有效期7天
3).proj:${pid}:userid:${userid}:checkid string类型,存储check对象
的id,有效期7天
3、运营平台逻辑设计
1)、创建通知消息,选择发送消息的方式,【渠道+用户级别】或【指定用户】两种方式
2)、创建通知消息内容时,如需加超链则选择影片,多个影片id用,隔开连接,
展示影片名称在配置页面
3)、发送通知消息时,如果是【指定用户】类型需要判断是否有用户选择,
没有则进行提醒
4)、发送通知消息的时候,如果有关联影片要将超链加到对应影片名称的标签里,
生成message对象,放入Redis缓存中,有效期为7天。
5)、发送通知消息的时候,关联的用户如果在缓存中则更新相关消息(message)
的id到未读消息中,并改变用户是否有未读消息的状态,更新有效期为7天。
如果不存在缓存中则直接更新mysql对应的表数据。
6)、发送消息通知的时候,如果是ios客户端的用户,则需要推送角标信息到
客户端,目前采用友盟的PUSH方法。
4、接口逻辑设计
1)、获取用户未读消息状态及消息数量的接口(ios用)接口,此时查找用户
信息时,先查Redis,如Redis没有数据,则查Mysql,并将对应数据缓存到redis中
,时长为7天,如果有则直接更新Redis键值过期时间
2)、获取用户消息列表接口,先查Redis缓存,再查Mysql数据库,返回最终数据。
3)、用户已读、删除上报,更新对应的redis键值,同时更新mysql数据库数据表。