notify的介绍和应用场景

Notify是一款高可靠、高实时的消息中间件，是交易链路的核心节点。具有了如下的特性

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

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

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

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

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

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

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

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

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

随着业务的扩大，杭州的机房已经达到瓶颈，没法容纳更多的机器，须要进行多单元的部署。notify具有了单元化的特性，能够支持消息在不一样单元之间的路由，把消息投递到准确的单元订阅者。单元1发布的消息，会被单元1的订阅者收到，单元化的应用流量会被均衡分配到每一个单元。对于一些未单元化的订阅者，经过中心机房的全量投递，也能收到单元机房发送的消息。 单元路由规则详见http://baike.corp.taobao.com/images/8/8b/Notify%E5%8D%95%E5%85%83%E5%8C%96%E6%95%B4%E7%90%86.pdf

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

notify管控系统提供了消息发布、订阅申请、应用下线一条龙服务，提供完善的消息堆积报警体系，让用户及时发现系统异常进行处理。提供消息轨迹查询，任何一条消息都能查到投递去向。提供客户端诊断工具，用户能够快速定位使用过程当中的问题。 管控平台平常 http://ops.jm.taobao.net/notify-side/index 线上 http://ops.jm.taobao.org:9999/notify-side/index?spm=0.0.0.0.EyuYOj