Notify公司自研消息中间件，目前已经和metaQ合并，对事物消息没有强需求的场景建议使用metaQ。

基本概念

发送方

负责发送消息到Notify Server的应用。控制台申请了发送权限后，应用可以发送消息到Notify Server。

订阅方

订阅发送方消息的应用。控制台申请订阅权限后，订阅方应用启动成功后，Notify Server就会把消息投递到订阅方。发送方和订阅方是解耦的，发送方不需要关注订阅方的任何信息，订阅方的变更（增加/减少订阅）不会影响发送方。

Notify Server

负责接收发送方的消息，并且投递到订阅方。使发送方和订阅方实现异步通信、解耦。还可以起到削峰填谷的作用。

消息

Notify的消息主要包括四个部分：Topic、MessageType、用户自定义属性、消息体。其中，Topic、MessageType都是用来区别不同业务发送方发送的消息:

• Topic：一级消息类型(又名消息主题)。如TRADE，ic-common等不同的消息主题;
• MessageType：二级消息类型，区别同一Topic主题下的不同类型的消息; 如：TRADE(交易主题)下有2300-trade-created-done(交易创建)，2300-trade-success(交易成功)等不同类型的消息。可以用于订阅方进行指定类型订阅（参考demo的SimpleSubscriber）
• 用户自定义属性：Key-Value类型的属性，由发送方调用Message.setXXXProperty方法设置，可以用于订阅方进行更细粒度的过滤（参考demo的HeaderSubscriber）。
• 消息体：消息的具体内容，发送方定义的消息详细内容，默认64kb大小限制，超过则发送失败。订阅方不能根据消息体的内容进行过滤。

发送方需知：

• 需要发送新的Topic的时候，请在控制台左侧菜单——发送接入申请，然后根据Demo在代码进行发送配置
• 需要在已有Topic下发送新的MessageType，请在控制台左侧菜单——增删MessageType。增加星号()默认可以发送任何MessageType。`强烈注意代码里不要直接使用 作为消息类型发送，否则会发送失败`

订阅方需知：

• 需要新增订阅Topic的时候，请在控制台左侧菜单——订阅接入申请，然后根据Demo在代码进行订阅配置
• 需要在已经订阅的Topic新增订阅MessageType/消息属性等，直接根据Demo在代码进行订阅配置
• 如果所有应用机器不想接收消息，必须首先删掉Notify订阅的代码, 然后在控制台应用配置查询，订阅配置里删掉订阅组
• 如果单机不想接收消息，可以使用优雅上下线

消息ID

消息ID是消息唯一标识，是Notify自动生成。

发送/订阅方绝对不能自己调用Message.setMessageId() 自己设置消息Id！否则会导致消费异常！

发送方和订阅方最好都在日志中记录消息ID，可以通过投递消息轨迹进行问题排查，获取消息ID方法

UniqId.getInstance().bytes2string(message.getMessageId()) 或者 发送方可以调用发送接口返回的SendResult.getMessageId()。 如果可以建议同时记录下TOPIC、MessageType

GroupId

又称组名, 发送方和订阅方都必须设置GroupId。Notify server根据groupId来识别客户端机器， 配置为同一groupId视为同一集群的机器。符合订阅关系的消息只会随机投递到同一个groupId的任一台机器（消费失败后的重投同样也是随机重投），每个groupId之间互相独立，互不影响。

因此, 各个业务之间，发送方和订阅方之间的GroupId不能重复。

订阅方的GroupId必须要到控制台注册申请权限，才可以使用。在控制台注册权限的时候，一个groupId只能注册到一个应用上。

MessageType和GroupId命名长度最大为64个字符, 且不能包含空格。

订阅关系

订阅方订阅消息需要设置的属性。只有符合订阅关系的消息，才会投递到订阅者，可以简单理解订阅关系为消息过滤的配置。订阅关系可以直接配置MessageType过滤，或者根据消息属性进行表达式过滤，具体可以参考demo工程，SimpleSubscriber和HeaderSubscriber。

客户端通过xml配置好订阅方需要订阅的消息，在应用启动时，订阅关系会推送到Notify Server，Notify Server才会把消息投递给应用（注意：应用启动前，应该到对应环境的控制台，左侧菜单，订阅接入申请，申请订阅权限）

Notify Server端将这份订阅关系保存，并根据保存在Server上的订阅关系将消息投给订阅方。

发送和订阅是解耦的，订阅方不需要了解发送方的groupId和如何发送的细节，同理，任何订阅方的操作也不会影响发送方，只要订阅对应的消息即可，只要符合订阅关系的消息都会投递给订阅方

Notify是一款高可靠、高实时的消息中间件，是交易链路的核心节点。

具备的特性以及他的应用场景

分布式事务特性-交易状态最终性的保证一致

把应用的业务操作和消息发送组成一个分布式事务，保证业务操作和消息发送是个原子操作。 案例：交易平台本地操作创建订单，然后发送订单创建消息，需要让处理订单的系统最终看到的订单状态是一致的。如果订单创建成功，但是消息发送失败；或者消息发送成功，订单创建失败。就会导致处理订单消息的相关系统所看到的订单状态是不一致的，业务会出大问题。基于notify分布式事务的特性就可以保证订单创建和消息发送同时成功或者同时失败，而notify本身提供了可靠的消息服务，这样就保证相关系统所看到的订单状态保持最终一致性。

推送+无序-提供最高实时性的消息服务

许多场景都需要实时性的保证，而推送和无序的模型保证了高实时性，ms级别。无序模型，消息投递的并发度最高，而且不会因为一个消息消费失败，导致后面的消息消费不了；推送模型使得消息一旦到达服务器会立马推送给客户端，无间歇。 案例：淘金币兑换商品，收到交易成功消息后，迅速扣除金币。如果实时性太差就有可能出现业务漏洞。比如某个用户总共只有10个金币，用10个金币兑换商品后，剩余0个金币。如果消息推送不实时，那么用户的金币在一定的时间窗口之内没有被扣除，这样他就可以继续兑换其他商品。

双写特性-消息存储的高度可靠

数据如果只写一份的话，那么当磁盘出现问题的时候，数据就会丢失。为了解决单点故障问题，notify提供双写机制，大大提高了消息数据的可靠性。 案例：交易需要保证数据的绝对安全可靠，交易集群开启了双写机制。交易每发送一条消息都会同时写入到两个mysql实例，双写成功才代表消息发送成功。

header订阅-消息细分业务订阅

有些业务场景比较复杂，纯粹的主题+消息类型二元组订阅已经无法满足需求。header订阅支持消息属性表达式过滤，提供更加动态灵活的订阅机制。 案例：交易消息，某个业务订阅主题为交易，消息类型为订单创建的消息，但是他只关注类目A。按照传统的订阅方式，主题+消息类型二元组，notify会把这个主题+消息类型的消息全部投递给订阅者，订阅者收到消息后只处理类目A的消息，其他忽略。而采用header订阅，他可以在主题+消息类型之上，在加一个属性过滤条件property.rootcat == A，这样一来notify只会把类目A的消息投给订阅者，订阅者的处理逻辑简化了。另外，当消息量大的时候，header订阅可以节约了服务器的带宽成本，同时节约了订阅者的资源消耗。

单元化-支持多单元机房部署

随着业务的扩大，杭州的机房已经达到瓶颈，无法容纳更多的机器，需要进行多单元的部署。notify具备了单元化的特性，可以支持消息在不同单元之间的路由，把消息投递到准确的单元订阅者。单元1发布的消息，会被单元1的订阅者收到，单元化的应用流量会被均衡分配到每个单元。对于一些未单元化的订阅者，通过中心机房的全量投递，也能收到单元机房发送的消息。

运维体系-优化用户体验，提高运维效率

notify管控系统提供了消息发布、订阅申请、应用下线一条龙服务，提供完善的消息堆积报警体系，让用户及时发现系统异常进行处理。提供消息轨迹查询，任何一条消息都能查到投递去向。提供客户端诊断工具，用户可以快速定位使用过程中的问题。

消息消费投递以及重投机制

消费重试机制

• 目前notify的消息消费重试总时长最多4天（线上）（会根据磁盘空间进行调整），预发和日常环境重试2小时，期间重试次数不限制（每条消息的重试时间间隔会逐渐增加）
• Notify不支持对消费成功的某个消息进行重试
• Notify不保证重试时间间隔的具体范围，每条消息的重试时间间隔会逐渐增加。因为集群所有topic都共用当前集群的重试队列，如果下游有应用出现堆积，将会导致整个集群的堆积，从而重试时间间隔变大。
• 不支持自行设置重试间隔/重试次数等任何有关重试的参数
• message.getDeliverCount() 返回的是Notify Server重试给客户端的次数（0代表第一次消费，注意该值不代表Client收到的次数，由于应用宕机/重启或网络丢包等原因导致Client没收到也会增加此值）。消费端消费的时候可以利用。

重点：Notify并不保证重试的间隔，强烈建议应用不要依赖notify的重试间隔

事务消息中，发送方的CheckMessageListener回调和重试机制的间隔一致。

双11/12高峰会进行重试降级

双11/12零点高峰期间，Notify只能保证消息第一次投递的实时性，会停止对消费失败的消息的再次重试以及停止事务消息的回调Check，对重试失败这部分消息，会有延迟到高峰后(至少20-30分钟,延迟时间没法保证)，Recover功能恢复后，再投递消费失败的消息。（全局预案，所有订阅者都生效）