京麦消息中心业务模型分析
您目前处于:架构  2017年07月28日

京麦消息中心是京麦平台核心业务之一,负责向京麦平台商家用户提供消息推送,ISV消息订阅,以及消息追踪,消息监控,消息统计等功能。

京麦消息中心(以下简称MC)经过4个618的洗礼,技术及业务模型日趋成熟和稳定,本文将为您揭开京麦消息中心业务模型及涉及到的技术点内幕。


首先简单聊下整体架构,整个消息中心承载业务系统消息,资讯类消息,其他类消息。

  • 业务系统消息首先经Anycall系统接入,然后分发给MC。

  • 资讯类消息经过运营系统,下发给MC。

  • 其他类消息通过MQ Topic下发给MC。

MC作为京麦消息协议中转中心,将接入进来的消息转换为京麦协议,下发给推送系统。

推送系统是TCP网关的一个部分,采用自研的Session作为应用层协议,底层采用Netty作为网络通信框架,来实现消息接收、推送、确认,整个过程的完全异步化处理。

下图是京麦消息中心整体架构图:


MC系统

MC系统包括接入,校验,分发,消息配置中心,消息存储,消息统计,消息日志模块。

其中接入模块采用MQ方式接入各个系统消息,校验模块负责对消息的合规性进行校验,分发模块可以根据配置中心的配置进行消息分发,消息存储模块负责对协议消息进行存储,消息日志负责整个消息全链路的追踪。

如下是MC系统的模型图:

因为之前的模型不支持一个类型消息的分发,随着业务扩展,衍生出了Broker这个概念,一个类型的消息可以根据配置中心的配置,可以有不同的Broker。

Broker实际上是一个接口,可以根据不同的业务扩展Broker去实现不同的存储逻辑等等,提高了业务承载能力,来达到隔离的目的。


MQ的运用

整个消息的流转大量采用异步的方式去处理,而且根据业务进行Topic的隔离,达到互不影响的目的,提升了系统承载能力。

如图:Anycall系统根据业务不同分发到不同的MQ,发送给MC。每一个厂商一个Topic,离线推送互不影响,提升推送性能。


snowflake算法实战中的应用

消息id作为全链路消息的唯一标志,作为客户端确认消息的唯一标识,之前是采用数据库生成递增long类型id,此方式缺点是依赖数据库,高并发环境下性能低下, 生成一条id可达到150ms,在此基础上采用snowflake算法生成趋势递增消息id,优势是不依赖任何第三方资源,性能高,实战中仅需要1ms。


Es的使用

考虑到消息数据量大,过期性,及查询性能,所以采用es存储消息数据,同时也根据消息类别创建多个索引,来达到消息数据的分离,起到隔离保护作用,对于类似新订单类的消息采用一天过期机制。

消息日志采用按天创建索引,使用别名,运用routing策略,最多保存7天的机制,大大提升了日志查询效率。


缓存策略

因为消息的实时性,所以缓存策略必不可少,针对业务类型不同,采用的缓存策略不同。

1. 对于基本配置信息,采用本地缓存 + redis + 数据库的方式

优势:三级缓存机制,本地缓存guava cache的运用采用时效机制,提高系统性能,不怎么依赖第三方资源,redis二级缓存采用时效机制,大大提高了空间的利用,最后是数据库兜底,这样下来基本上不怎么依赖第三方起到了自保的作用。

2. 消息未读数计数器

优势:考虑到频繁更新和查询操作,如果用数据库去实现,因消息量太大会造成性能瓶颈,所以采用redis incr的方式处理,原因是此方式性能高,保证了原子性,解决了并发问题。


分布式锁运用

拉取消息接口,目前采用多线程方式调用京麦接口,轮训拉取,考虑到并发,所以运用分布式锁解决此问题。

利用redis特性,setNX(SET if Not eXists)命令。


推送系统

基于 Netty 作为网络层框架,构建海量推送模型,使用静默长连接通道,实现从消息接收、推送、确认,整个过程的完全异步化处理。


总结和感悟

针对消息有太多的事情要做,我们不仅仅做一个消息推送,我们要打造一个完整的稳定的消息闭环,我们要做一个完备的消息体系,支持各种业务,监控,统计,分析,为决策层提供数据依据,为上游提供便利的接入,为ISV提供便利的消息推送能力,为运营提供便利的统计分析等等,最终达到提供丰富的消息提醒,来为商家提供便利的京麦服务,增加商家对京麦的粘性。


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/李振发)