REST-MQ研发更好用的MQ(2)

有了上一节的协议定义，本节来思考下如何实现。客户端的实现非常容易，先考虑服务端

整个MQ需要具有以下几个部分

1：消息接收

2：消息持久话

3：消息的分发，需要根据tv参数，发送给所有关注了此消息的消费者

4：需要个后台配置系统用来配置MQ的消息使用者

消息接受与消息持久化接收到发送发送的消息将其持久化起来，只要按照之前定义的规范接收dt和tv参数生成消息ID（消息id必须为全局唯一，或者系统内唯一）存储到数据库中，一般会数据库增删改查的都可以实现，插入成功后返回

{"code":200,"msg":""}

或失败后code为500

数据库设计也是十分简单的一张表

create table message_info(   mq_id                bigint not null comment '消息ID',   tv                   varchar(20) not null comment '频道名称',   content              text not null comment '消息内容',   create_time          datetime not null comment '创建时间',   primary key (mq_id));alter table message_info comment '消息信息表';

消息的分发收到消息后根据消息的频道找到对应的所有消费者，把消息进行复制后分发出去。说白了就是把一条数据复制成N份发送到不同的url去

需要考虑的是消息的处理状态，消费主机正在维护停止服务了，所以后面需要引入健康检查。但是挤压消息多的话也要注意流控，不能把消费主机给压死这些都是自己研发MQ的好处，需要什么功能就加吧：）

数据库设计需要存储消息和对应的消费者地址，另一张表用来存储消息的状态，失败次数。

配置系统应该是最简单的一个，使用两张表或一张表来记录对应的关系

一个频道可以被多个消费者关注，关注后所有发往该频道的收据都应该被接收到