im消息中台

架构角色

客户端：构建消息内容，发送请求到服务端

服务端：接受消息请求，并调用底层sdk发送消息，并存储消息发送记录

第三方sdk:如腾讯sdk发送消息

数据表模型

1.消息推送表：

        1.业务类型和业务ID:定义消息类型的一级分类，业务ID用于app端反查消息的明细信息

        2.消息类型:定义消息的二级分类

        3.扩展字段：用来定义业务个性化的字段需求

CREATE TABLE `push_record` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `biz_id` bigint DEFAULT NULL COMMENT '业务ID',
  `biz_type` tinyint DEFAULT NULL COMMENT '业务类型，1:预警推送',
  `msg_type` tinyint DEFAULT NULL COMMENT '消息类型',
  `title` varchar(255) DEFAULT NULL COMMENT '推送标题',
  `content` varchar(255) DEFAULT NULL COMMENT '推送内容',
  `receiver` bigint DEFAULT NULL COMMENT '消息接受者',
  `callback_status` int DEFAULT NULL COMMENT '消息反馈状态',
  `push_type` tinyint DEFAULT NULL COMMENT '推送方式，0:极光推送',
  `push_level` tinyint DEFAULT NULL COMMENT '推送级别',
  `ext` varchar(1024) DEFAULT NULL COMMENT '业务自定义扩展字段（json格式）',
  `push_success` bit(1) DEFAULT NULL COMMENT '是否推送成功',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=65 DEFAULT CHARSET=utf8mb3 COMMENT='推送记录';

2.消息明细表：

用于存储消息的明细信息。

1.为何不存储在主表？

占用一个字段存储太耗数据表存储空间

安全控制

1.鉴权

业界主流是通过appKey和appSecret控制，即客户端传入对应appKey和appSecret，服务端进行检查是否存在，然后校验对应的值是否正确。

高并发与高可用探究

1.批量多接受者异步

思考：批量多接受者的消息，如果使用同步依次批量调用底层sdk，那么性能也不够好，如果超时时间设置的较短，也有可能出现超时等情况。

方案：可以使用mq进行异步和削峰处理

2.消息发送和存储分离

思考：

1.消息的发送并发量大，而写库是一个耗时事务，做成异步是为了提供系统的吞吐量,而且用户关心的是否收到消息是主业务，而消息的存储主要为了运营人员数据分析为副业务。

2.消息发送和存储解耦合，存储的逻辑和成败，与消息的发送成败没有关系。

方案：
1.设计消息回调微服务且单独部署，与消息处理微服务解耦合。单独接收腾讯sdk的回调消息。

2.消息回调和存储使用mq解耦合，因为第三方腾讯sdk回调接口也会有超时机制

3.使用es等大数据技术进行存储

设计模式

模版模式：抽象发送流程，提供各模型构造方法和子流程抽象方法
工厂模式：生产各种模型实例对象（策略工厂）
策略模式：每种模型对各自的接口实现（消息body解析等）
建造者模式：构造消息体和参数等

命令模式：处理消息回调请求