程序在全国总决赛中获得第九名

赛事要求简介： 实现一个基于发布-订阅模型的消息中间件（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，消息堆积能力，削峰填谷能力。 性能压测场景

4k消息，一个发布者发布topicA，一个订阅者订阅这个topicA的所有消息，订阅者健康消费每条消息，无堆积

4k消息，一个发布者发布topicA，20个订阅者分别订阅topicA不同属性的消息，消费者健康消费，无堆积

4k消息，一个发布者发布topicA，一个订阅者订阅这个topicA的所有消息，订阅者消费超时，大量堆积

4k消息，一个发布者发布topicA，20个订阅者分别订阅topicA不同属性的消息，20个订阅者只有一个订阅者消费成功，其他订阅者消费超时、失败以及不在线，消息出现大量堆积。

4k消息，20个发布者发布20个不同的topic，每个topic都有20个订阅者，他们分别订阅不同属性值的消息，消费健康，无堆积

4k消息，20个发布者发布20个不同的topic，每个topic都有20个订阅者，他们分别订阅不同属性值的消息，所有消费均超时，大量堆积。堆积持续一段时间后，减少90%的发送量，并让消费者恢复正常，broker需要尽可能快的投递堆积的消息。