最近公司新的项目规划，牵涉到了消息队列的技术分析与选型，我做完了对比和选型之后，所以想干脆我自己也写一个自己想要的消息队列试试，就这样opMQ消息队列中间件由此诞生。
首先思考，大致的框架：消息队列无外乎三部分：producer（生产者），broker（消息服务者），consumer（消费者）。producer负责生产消息（投递消息）到broker，然后consumer消费（处理，运用）消息。consumer消费消息有两种模式：推和拉（push，pull）。推就是broker把消息推送给consumer，拉则是consumer自己去broker拉取消息。我这里用的是两种结合，推用来做发布订阅，拉用来让consumer自己拉取要消费的消息（边缘化处理原则）。ack机制。consumer消费消息完成后，需要“回复”broker，该消息已被处理。回复机制支持手动和自动处理（手动则需要调用broker消费响应接口）。
consumer端处理（借助之前我的opRPC框架的分布式锁处理），并加上幂等。
选用的levelDB存储（【tps：10万，存储1亿大概占用1GB磁盘】其本质为将随机写转变为顺序写（一般磁盘顺序写速率500MB/s，随机写1MB/s），简化版谷歌三轮马车bigtable），后期会支持redis等存储。
支持。为了支持延时，所以opMQ的消息是有状态的。
ready：就绪状态。消息被投递到broker时，就是该状态，consumer获取的消息只能是ready状态的消息。
relay：延迟状态。消息只能在某个时间之后才能被读取，broker会有线程自动将到了延时时间的消息转变为ready状态。
running：运行状态。consumer获取消息后，需要处理之前需要将该消息（或者一批）状态修改为running，表示被独占使用，处理完之后发送ack，并设置该消息（或者一批消息）状态为deleted或者reentrant状态。deleted：删除状态（消费成功完成）。consumer获取获取消息后，并设置消息为running，消费成功后，则该消息状态变为deleted。reentrant：可重入状态（消息消费失败或者处理时间超时）。consumer获取获取消息后，并设置消息为running，消费失败后，则该消息状态变为reentrant，该消息可再次被转变成ready，以便再次消费。
我的opMQ目前功能还未全部完善，有兴趣的小伙伴可以随时fork，献出你宝贵的代码~~~地址：https://gitee.com/opjesus/opmq
