京麦消息中心业务模型分析
|
京麦消息中心是京麦平台核心业务之一，负责向京麦平台商家用户提供消息推送，ISV消息订阅，以及消息追踪，消息监控，消息统计等功能。 京麦消息中心（以下简称MC）经过4个618的洗礼，技术及业务模型日趋成熟和稳定，本文将为您揭开京麦消息中心业务模型及涉及到的技术点内幕。 首先简单聊下整体架构，整个消息中心承载业务系统消息，资讯类消息，其他类消息。
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 (文／李振发) ©著作权归作者所有 |
