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