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的好處，需要什麼功能就加吧：） 資料庫設計需要存儲消息和對應的消費者位址，另一張表用來存儲消息的狀态，失敗次數。

配置系統應該是最簡單的一個，使用兩張表或一張表來記錄對應的關系

一個頻道可以被多個消費者關注，關注後所有發往該頻道的收據都應該被接收到