MetaQ

拉模式： 点对点消费，如果没有消费者在监听队列，消息将保留在队列中，直至消费者连接到队列，在这种模型中，消息不是自动推动给消费者的，而是要由消费者从队列中请求活动（拉模式）。 优点： 1.保证每条消息都被接收。 2.消息不会丢失。 推模式 消息会自动广播，消息消费者无需主动请求或轮询主题的方法来获得新消息。 对比： 1.不保证每条消息都会被消费， 2.发布消息时，只有正在监听该topic的能够接收，如果没人监听，则会消息丢失。 MetaQ Client 订阅消息，因其是Pull的模型。MetaQ Server收到Pull消息的请求，会从磁盘上读取出消息，然后返回给MetaQ Client。这一步有大量的read系统调用。 消息中间件MetaQ高性能原因分析-转自阿里中间件 https://www.cnblogs.com/felixzh/p/6197707.html 来源： oschina 链接： https://my.oschina.net/u/3421984/blog/1633582

对于大型的互联网业务来说，消息系统是必不可少的基础服务。 子柳 在《淘宝技术这十年》中为大家展示了阿里消息系统架构的概貌，作为集团业务使用的核心基础服务，目前消息系统现在可以承受每天几百亿规模的请求，并在历年的双十一、双十二大促中承受住抗住了更加严峻的考验，消息系统背后的中间件团队还陆续开源了诸如 MetaQ 、 RocketMQ 等项目。近期，InfoQ 采访了阿里消息中间件团队消息和分布式数据层负责人王晶昱（花名：沈询），话题涉及案例中间件系统的选型、系统扩容与数据一致性、团队文化等内容。 InfoQ ：对于阿里的消息中间件系统，大家所广泛了解的是 @ 子柳 在《淘宝技术这十年》中介绍的 Notify ，但是从最近的阿里的开源计划中，我们经常看到 MetaQ / RocketMQ ，在阿里内部 Notify 和 MetaQ 是怎样的关系？我看到早期的 MetaQ 是采用的 Kafaka 的设计思路，那么可能大家就比较好奇 “ 问什么要重复造轮子 ” ，能不能介绍这个方面的考虑以及所做的工作？ 沈询： 要讲明白这个问题，就需要从产品的实际需求角度入手开始做个介绍了。Notify作为一个已经存在了5年多的消息产品，被广泛的应用在整个阿里巴巴集团的大部分消息通信领域。它的核心特性是： 提供事务支持、不保证消息顺序、消息可能会重复、推模型。 因为淘宝是个交易类网站

Java Message Service (JMS)Java的消息中间件. metaq作为i额消息中间件,应该是在这个范畴中.二者范围有一定差异. jms应该说是一种规范. metaq是一种框架,用于实现消息推送的功能. 1.metaq的消息机制与jms也有区别,涉及领域也有差异.目前淘宝商用(非开源版本)的metaq据说要闭源. 而且要改名,真是个坑爹的消息.连接: https://yq.aliyun.com/articles/2892 2.另外还有一个开源的版本.据说是他在淘宝发起的这个项目.目前也没维护了...版本还停留在1.4.6.果然没利益是跑不远的.连接: https://github.com/killme2008/Metamorphosis 第一个版本收费的,但是使用简单.第二个版本需要自己搭建.免费开源. 一些基本概念与使用手册: https://my.oschina.net/lmxy1990/blog/789919 这里 记录自己的理解: 整体流程: 生产者(producer): 1.生产者产生的消息可以分为多个片段,存储在不同的broker中. 消息定义(message) id 消息的唯一id，系统自动产生，用户无法设置，在发送成功后由服务器返回，发送失败则为0。 topic 消息的主题，订阅者订阅该主题即可接收发送到该主题下的消息，必须 data

3.1、Notify Notify是淘宝自主研发的一套消息服务引擎，是支撑双11最为核心的系统之一，在淘宝和支付宝的核心交易场景中都有大量使用。消息系统的核心作用就是三点：解耦，异步和并行。下面让我以一个实际的例子来说明一下解耦异步和并行分别所代表的具体意义吧： 假设我们有这么一个应用场景，为了完成一个用户注册淘宝的操作，可能需要将用户信息写入到用户库中，然后通知给红包中心给用户发新手红包，然后还需要通知支付宝给用户准备对应的支付宝账号，进行合法性验证，告知sns系统给用户导入新的用户等10步操作。 那么针对这个场景，一个最简单的设计方法就是串行的执行整个流程，如图3-1所示： 图3-1-用户注册流程 这种方式的最大问题是，随着后端流程越来越多，每步流程都需要额外的耗费很多时间，从而会导致用户更长的等待延迟。自然的，我们可以采用并行的方式来完成业务，能够极大的减少延迟，如图3-2所示。 图3-2-用户注册流程-并行方式 但并行以后又会有一个新的问题出现了，在用户注册这一步，系统并行的发起了4个请求，那么这四个请求中，如果通知SNS这一步需要的时间很长，比如需要10秒钟的话，那么就算是发新手包，准备支付宝账号，进行合法性验证这几个步骤的速度再快，用户也仍然需要等待10秒以后才能完成用户注册过程。因为只有当所有的后续操作全部完成的时候，用户的注册过程才算真正的“完成”了

前言 再说mq之前我们先说说背景吧，MQ(message queue简称消息队列)主要作用不是通讯，主要是用于解除子系统间的耦合，所以异构系统间的通讯实际并不是mq发挥作用的场景，那反而是RPC（remote procedure call）发挥作用的时候, mq更适合于需要更大流量和高并发的大型系统场景，可以将消息队列视为一个可靠的通道，主交易过程在处理时，遇到需时较多同时又已经确定了条件的处理就丢到消息队列里进行后续处理，这样可以将主交易过程划分为一个一个可以异步处理的更小的处理过程，减少了主交易流程的处理时间，可以提供更快的响应速度和并发速度，例如，像淘宝这样的处理逻辑非常多的系统，在处理付款时，就可以将通知买家和卖家、记日志甚至记帐流程都放到消息队列里处理，整个主流程能够快速处理完成，继续处理下一个买家的请求 1.MetaQ简介 MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，思路起源于LinkedIn的Kafka，但并不是Kafka的一个Copy。MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景 2.MetaQ使用场景 (1) 日志传输，用于高吞吐量的日志传输； (2) 消息广播，将消息放入Topic中，供所有的消费者消费； (3) 数据的顺序同步功能

前言 ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得ZooKeeper解决很多分布式问题。网上对ZK的应用场景也有不少介绍，本文将结合作者身边的项目例子，系统地对ZK的应用场景进行一个分门归类的介绍。 值得注意的是，ZK并非天生就是为这些应用场景设计的，都是后来众多开发者根据其框架的特性，利用其提供的一系列API接口（或者称为原语集），摸索出来的典型使用方法。 zookeeper典型应用场景 1 数据发布与订阅（配置中心） 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。 应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。 分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点，供各个客户端订阅使用。 分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、简介 RocketMQ的前身是Metaq，当 Metaq 3.0发布时，产品名称改为 RocketMQ MetaQ2.x版本由于依赖了alibaba公司内部其他系统，对于公司外部用户使用不够友好，推荐使用3.0版本。 项目地址： https://github.com/alibaba/RocketMQ 二、安装RocketMQ 安装RocketMQ需要jdk1.6, maven,git环境 如果本机没有安装git，请使用如下命令安装 yum install git 具体安装步骤可以参考 RocketMQ 项目组给出的步骤，参见： https://github.com/alibaba/RocketMQ/wiki/Quick-Start git clone https://github.com/alibaba/RocketMQ.git cd RocketMQ sh install.sh cd devenv 安装完成后，因为install.sh脚本中创建devenv 符号链接写错了目录，需要在RocketMQ目录下执行如下命令： rm -rf devenv ln -s target/alibaba-rocketmq-3.0.7/alibaba-rocketmq devenv 启动RocketMQ cd devenv

Notify(2007)--->Napoli(2010)--->MetaQ(2011)--->RocketMQ(2012) 第一代的Notify主要使用了 推模型 ，解决了事务消息。 第二代的MetaQ主要使用了 拉模型 ，解决了顺序消息和海量堆积。 RocketMQ 基于长轮询的拉取方式 ，兼有两者的优点。 来源： https://www.cnblogs.com/i-hard-working/p/11925499.html

这几天琢磨其他的东西，Jafka源码搁置了，对其解读已经失去了兴趣。为了给自己一个交代，还是写个结尾系列吧。 log Log模块并非是log4j一套，而是Jafka的 消息持久化系统 ，当初一扫而过，这么精华的部分竟然没注意到。 不过所谓O(1)的持久化效率而并非多么复杂，其实就是在offset处append而已。这个最重要的部分，现在算是弄清楚了。 剩余部分都没有仔细读过源码，有些是从 rockybean 的博客中直接看的。 Jafka对NIO这块的使用，相当值得参考和借鉴。不过对一些细节的处理，只有自己真正开发相关功能才能体会，于是决定先搁置了。 关于MetaQ MetaQ据说是淘宝内部的MQ，在Kafka上做了改进，可以看成跟Jafka同源。clone了一份MetaQ的代码， https://github.com/killme2008/Metamorphosis ，粗略看了一下，看得出来是公司级别的开发，并非为开源而生，所以精细程度不如Jafka(指代码级别的技巧)，但是各种接口定义要更清晰一点。 找了MetaQ的文档，对于MQ的特性和问题，做了一些总结，好好读了一遍： http://alibaba.github.io/metaq/document/design/design.pdf 有几个东西，确实是实践出真知： 关于MQ的优先级 MetaQ支持在内存中排序

MetaQ是一款分布式、队列模型的消息中间件。基于发布订阅模式，有Push和Pull两种消费方式，支持严格的消息顺序，亿级别的堆积能力，支持消息回溯和多个维度的消息查询。 消费模型 metaq采用发布-订阅模型，发布者发布消息到metaq，订阅者向metaq订阅消息。 消息的消费方式是pull方式，由消费者主动从metaq服务器拉取数据，解析成消息并消费。 消息持久性 metaq 接收到消息之后，会先把消息持久化到本地。 常用的持久化方式： 持久化到DB 持久化到KV存储，如levelDB，伯克利DB 持久化到文件 持久化部分的性能会直接影响消息中间件的性能。 消息堆积能力：metaq每台服务器提供大约亿级的消息堆积能力（多个业务方共用），超过堆积阈值，订阅消息吞吐量会下降。 消息过滤 对于应用比较多，访问量比较大的情况，消息量也就随之增大，一方面服务端给每个客户端发送消息时，总不能把全站的消息都发送过去，这样大量的无用消息在网络上传输是一种资源浪费。另一方面，客户端也不需要接收所有的消息，而只需要接收自己需要的消息。这时，消息中间件就需要一个消息过滤的功能。 metaq支持两种过滤方式：服务器端过滤，客户端过滤。 消息实时性 metaq客户端通过长轮询的方式连接服务端，可以保证消息非常实时，实时性不低于push 每个消息至少投递一次 Consumer先pull消息到本地