一、消息推送功能
1、点对点推送：
（1）RegistrationID方式，RegistrationID为app启动时由sdk发送给极光后台服务注册的用来识别本设备的唯一ID，使用此种方式需要app后台服务自行保存设备与用户间的关联关系
（2）alias别名，app启动sdk向极光注册时，将一个alias（一般是userID）上报给极光，极光后台负责将此alias与设备唯一ID RegistrationID关联起来，之后app后台可使用alias直接调用极光rest api进行消息推送。
2、广播推送
优选方案：
（1）利用极光推送后台为本app保存的全量RegistrationID（或alias）、由极光找出需要推送的设备
（2）利用极光的延迟推送功能，使推送在一定时长内平均分配，而不是在太短时间内完成，以免短时间激活大量用户的读取，对App服务器造成太大的压力。
3、组播推送
可用作为组播筛选的选项：App版本，SDK版本，用户注册时间，用户活跃时间，用户所在地区、自定义Tag。
其中自定义tag一般为：性别、年龄段、喜好、关注等用户画像标签。
存储： userID tag1|tag2|...|tagN 根据制定的列(tagX)可以快速的查询到符合该tag的用户集，输出到推送file进行推送；
msgId tag1|tag2|...|tagN tagX为消息属性的标签
设计：（1）新增用户标签
（2）执行job对推送用户表新增tag列；选择用户方法：sql查询用户表，或用户行为分析给定的用户集合。
（3）编辑消息，设置消息tag并建立与用户tag的关联。
（4）推送程序执行，根据消息ID得到消息tag进而得到用户tag，按照用户tag进行推送。
二、消息查询功能
1、点对点消息： 使用userId查询【点对点消息表】查询出该用户收到的点对点消息
2、广播消息：使用userId查询【广播消息表】，查询出该用户注册时间之后发送的广播消息
3、组播消息：根据userId得到该用户的tag，查询【消息tag与用户tag关联表】，得到消息tag。进而得到消息。
三、几点说明
1、对于点对点与广播消息，我们认为一般属于个人交易记录、办件明细、以及重要通知等性质的消息，实际推送与消息中心的展示应具有强一致性。
而对于组播消息，一般认为是带有营销性质的、或其他的平台对用户的行为进行引导与推介的消息，在不使得用户产生明显困惑的情况下，应允许实际推送与"消息中心"（具体位置应与广播和点对点区分）具有一定的偏差。
2、关于送达率与打开率：参考https://www.oschina.net/question/861681_224273
送达率可以由实际的推送服务商提供的接口获得。打开率可借由app用户行为分析平台对消息页面的访问与否记录进行分析
3、组播推送消息：推送服务商有可能提供了设备（或alias）的tag信息服务，用于使用方对设备或alias进行自定义分群，如此，使用者只需要对拟发送的消息按照消息tag分类，并建立维护消息tag与上述设备或alias tag的关联表即可。
四、主要数据结构
- 点对点消息表(mysql)
msgID, userID, send_time, msg_content (partition by send_time)
- 广播消息表(mysql)
msgId, send_time, msg_content
- 组播消息表(mysql)
msgID, send_time, msg_content
- tag表
tagID, tagName, tagType(msgTag/userTag)
- 组播消息tag表(hbase/es)
msgID, msgTagID1|msgTagID2|...|msgTagIDn
- 用户tag表(hbase/es)
userID, userTagID1|userTagID2|...|userTagIDn
- 组播消息tag与用户tag关联表(hbase/es)
msgTagID, userTagID1|userTagID2|...|userTagIDn
参考：https://www.cnblogs.com/jpush88/p/5337261.html
mysql、hbase、es的特点和区别： https://www.cnblogs.com/029zz010buct/p/10366775.html
HBase - ES -Redis 的设计模式有很多共同点 ： https://www.cnblogs.com/ruili07/p/10964361.html
用户画像在携程的实践 ： https://blog.csdn.net/chenjunji123456/article/details/54966633