参加阿里巴巴中间件比赛时的mom项目源码
##题目要求 实现一个基于发布-订阅模型的消息中间件（broker+client） 必选特性： 提供可靠消息服务，broker要保证数据同步落盘才能向生产者返回发送成功的ack，并保证投递给所有的消费者，直至所有的消费者都消费成功（消费者消费成功或者失败都会返回对应的ack）。一旦消费者对一条消息发生订阅后，那么该消费者消费失败，消费超时（如果消息推送给消费者后，10秒没有返回响应，那么认为消费超时），或者不在线，消息不能丢失，需要尽快重投，让消费者在恢复后可以尽快消费完堆积的消息。 采用实时推送模型（只能push，push完后等待消费者ack，不能使用长轮询），消息一旦到达broker，要立马推送给消费者，消息延迟不能高于50ms。 消息支持自定义属性，能够支持简单的消息属性过滤订阅，broker只能投递符合属性条件的消息给订阅者。例如订阅者发起topic为trade，filter为area=hz的订阅，那么只有topic为trade，并带有area属性值为hz的消息才会投递给订阅者。client要实现提供的api，发送接口必须消息持久化成功才能返回成功。 消息存储必须基于文件系统自己实现，不能使用现成的存储系统，数据存储的根目录为$userhome/store/。系统运行过程中如果突然宕机或者断电(一定要保障消息数据落盘后才能向发送者响应发送成功)，重启后消息数据不能丢失。（数据丢失的定义：生产者消息发送返回成功ack后，如果broker出现宕机或者断电后重启，消息丢失了，无法投递给所有的订阅者，直至所有订阅组都消费成功） 消费者和生产者启动的时候可以指定需要连接的broker ip，也就是实现broker单机的模式，前期跑分主要看broker的单机能力。 支持消费者集群，消费负载均衡。比如消费者A是一个集群，订阅了topicA。broker收到topicA的某条消息后，只投递给消费者A集群的某台机器，消费者集群的每台机器每秒消息消费量是均衡的。 加分特性（如果最后实现了必选特性，性能脱颖而出的几个团队，则还会综合考虑系统设计是否能支持以下的特性）： 服务高可用，broker可以集群化部署，统一对外提供服务。broker集群中部分机器当机，不会导致消息发送失败，或者无法消费，对消息服务的影响越小越好。 数据高可用，消息存储多份，单一数据存储损坏，不会导致消息丢失。 具备良好的在线横向扩容能力。 支持大量的消息堆积，在大量消费失败或者超时的场景下，broker的性能和稳定不受影响，有良好的削峰填谷能力。 高性能、低成本。 考核方式 从系统设计角度和运行功能测试用例来评判必选特性，不满足必选特性，直接淘汰。 服务高可用、数据高可用、在线横向扩容能力从系统设计角度来评判 性能指标包括：每秒消息接收量，每秒消息投递量，消息投递延迟，消息发送的rt，消息堆积能力，削峰填谷能力。
该项目同步落盘的情况下tps能达到2w/s，虽然最后没有进入决赛，但是在前期我的这个mom一直处于前5的名次，最后没有跟上是因为其他原因。主要的部件就是rpc，使用多个连接来进行rpc通讯，broker服务器刷盘采用组提交的方式
作者是一名软件工程学生党。目前在上海某985高校就读研究生，热爱新技术，热爱编程，为人幽默，热爱开源，研究方向有分布式数据库、高性能网络编程、java中间件 邮箱:zhujunxxxxx@163.com 博客: http://blog.csdn.net/zhujunxxxxx