小桥

笔者最近在业务上需要使用到MetaQ，也借此阅读了MetaQ的相关源码，准备分享MetaQ源码分析。先扫扫盲，如果读者对MetaQ已经较为熟悉，可以跳过下一段落。一、MetaQ简介MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，,MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，

前面，我们已经把Broker存储最重要的一个类具体分析了一遍，接下来，我们分析一下其删除的策略。前面介绍过Messagestore采用的多文件存储的组织方式，而存储空间不可能无限大，得有一定的删除策略对其进行删除以腾出空间给新的消息。MetaQ允许自定义删除策略，需要实现接口DeletePolicy，默认提供了两种删除策略：过期删除（DiscardDeletePolicy）和过期打包删除（Ar

前面介绍了Broker在网络传输过程中使用的数据结构，同时也介绍了MetaQ使用了Gecko框架作为网络传输框架。有人会问，Gecko什么调用MetaEncodeCommand的encode()方法，让命令变成可见的明文在网络传输，Gecko又在什么时候将网络传输的数据包装成一个个Command对象？或许有人已经注意到了笔者在介绍Broker启动类MetaMorphosisBroker的时

Broker接收从Producer(Client端)发送的消息，也能够返回消息到Consumer(Client)，对于Broker来说，就是网络输入输出流的处理。Broker使用淘宝内部的gecko框架作为网络传输框架，gecko是一个NIO框架，能够支持一下特性：1、 可自定义协议,协议可扩展、紧凑、高效2、 可自动管理重连，重连由客户端发起3、 需进行心跳检测，及时发现连接失效

消息，是MetaQ最重要的资源，在分析MetaQ之前必须了解的概念，我们所做的一切都是围绕消息进行的，让我们看看MetaQ中消息的定义是怎样的，MetaQ的类Message定义了消息的格式：Java代码 public class Messageimplements Serializable {    private long id;//消息的ID   

前面忘了先介绍一下Broker消息存储的组织方式，我们前面知道了一条消息属于某个Topic下的某个分区，消息存储的组织方式是按照此方式进行组织的，结构图如下：所以对于每个Topic而言，分区是最小的元素，对外API主要由MessageStore提供，一个MessageStore实例代表一个分区的实例，分区存储具体的内容。在MetaQ中，分区的存储采用的多文件的方式进行组合，即M

前几天不小心茶水泼到了笔记本上，这两天才修好，就赶紧写上一篇。前面介绍过MetaQ使用gecko框架作为网络传输框架，Gecko采用请求/响应的方式组织传输。MetaQ依据定义了请求和响应的命令，由于命令Client和Broker均需要使用，所以放在了common工程的类MetaEncodeCommand中：Java代码 public String GET

上一篇以及上上篇基本介绍了MetaQ如何使用Gecko框架在网络上传输数据，今天将继续进一步介绍在Broker，各种命令的处理逻辑（暂时将不涉及到事务处理）。依旧是在MetaMorphosisBroker的registerProcessors()方法中，我们可以注意到一点，每个Processor的实例在构造的时候都注入了一个brokerProcessor的变量，该变量的类型为CommandPr