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的好处，需要什么功能就加吧：） 数据库设计需要存储消息和对应的消费者地址，另一张表用来存储消息的状态，失败次数。

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

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