京东-JMQ框架介绍.docx

京东-JMQ框架JMQ是京东自主研发的一款消息中间件系统，具有高可用、数据高可靠等特性。广泛应用于公司内部系统，包括订单、支付、库房等场景。整体结构系统包括服务端、客户端、管理端与其他支撑模块。JFS( JOURNAL FILE SYSTEM)：一种字节级日志文件系统，借鉴了数据库保护系统的技术，以日志的形式记录文件的变化。JFS通过记录文件结构而不是数据本身的变化来保证数据的完整性。这种方式可以确保在任何时刻都能维护数据的可访问性。Redis：是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。HBase：Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。服务端　　服务端提供了配置信息分发、重试消息管理和消息存储与分发这三大类功能。每个服务端实例都具备这三类功能的服务能力，但是在实际部署上这三类功能对应三个不同的集群，对应每一个实例功能不叠加。在测试环境和库房等资源有限的环境下，这三类功能由同一个服务端实例提供服务。　　配置信息分发：负责客户端参数变更时与消息分配的服务端实例变更时通知客户端。　　重试消息管理：主要用于对业务系统临时处理不了的消息进行存放，然后再按照一定的策略投递给客户端处理。可以提供错误原因、错误处理次数等查询。　　消息存储与分发：接收生产者投递的消息，把消息存放在本地磁盘上，消费者从该服务上拉取消息进行消费。　　客户端　　目前只提供了JAVA语言的SDK和支持HTTP协议的proxy，非JAVA语言通过proxy接入。管理端　　主要功能有：接入申请、消息元数据管理、重试消息信息查询、消息发送和消费日志查询、服务端状态信息管理查看、客户端连接信息管理查看等。支撑模块　　主要有报警模块、任务模块、归档模块、信息采集模块等。数据可靠性　　针对公司的业务特点，消息服务主要应用于订单、支付、物流等环节。服务端采用MASTER-SLAVE结构，消息在正常情况下会同时存放两份，其中一份会强制持久化到磁盘，磁盘做RAID-5。默认情况下客户端采用同步发送，每条消息到达服务端MASTER后会强制刷入磁盘同时并行推送一份到SLAVE上，SLAVE写入文件系统后不等待强制刷盘就反馈给MASTER。根据不同的场景为了提高服务的可用性，普通级别的消息SLAVE断开后，该组服务可以正常使用，当SLAVE连接上后又会自动切换为保存两份。当然对数据可靠级别高的消息是强制要求数据必须写两份才算成功的。服务高可用　　每类消息一般都会分配3组及以上的服务组，每组服务包括一个MASTER和一个SLAVE，当然如果有需要也可以挂载多个SLAVE。　　客户端发送消息时，如果其中一组出现故障会重试发送给其他的组。　　虽然MASTER-SLAVE支持切换，提高服务的可用性，但是在实际生产中MASTER出现故障时会优先采用通过其他服务组自动接替生产服务的方式，本组服务只提供从SLAVE读取的方式，而不是让SLAVE接替MASTER的写入，避免临界状态下丢失消息。　　对要求严格顺序的消息，不能通过简单的切换服务组实现，具体实现方式参考《高可用保证消息绝对顺序消费的BROKER设计方案》（点击“阅读原文”查看这篇文章）。消费模型　　由于公司以前有使用基于ACTIVEMQ二次开发的服务，服务端会存放客户端的消费位置，因此在自主研发JMQ时也延续了这种方式（可以兼容ACTIVEMQ的客户端）。但是ACTIVEMQ生产和消费都会操作索引文件，影响性能，JMQ吸取了这个经验教训。消费者在消费时按照索引分区顺序的消费，消费确认时只需要变更最后确认位置的值，不需要操作索引文件，而且多个消费者共用一个索引文件，各自保存自己的消费偏移位置就可以了。　　当然在实践过程中，由于一些特殊场景需要，会允许一定范围内不完全按照顺序消费，但是服务端会记录已经消费的索引区间。　　与KAFKA的对比　　JMQ在服务端存储设计上与KAFKA有一些相似的地方，借鉴了文件按照偏移位置管理、顺序追加等特点。不过JMQ的存储和消费模型有自己的特点：消息存放