ZBUS = MQ + RPC

朴灿烈づ我的快乐病毒、 2023-05-29 06:27 23阅读 0赞

http://git.oschina.net/rushmore/zbus

http://my.oschina.net/sbz/blog

Readme.md 18.02 KB

# ZBUS = MQ + RPC #

*  [zbus解决的问题域][zbus]
 *  [zbus特点][zbus 1]
 *  [zbus启动][zbus 2]
 *  [zbus实现消息队列][zbus 3]
 *  [zbus实现RPC][zbus_RPC]
 *  [zbus实现异构服务代理--服务总线][zbus_--]
 *  [zbus底层编程扩展][zbus 4]
 *  [zbus高可用模式][zbus 5]
 *  [zbus性能测试数据][zbus 6]

## zbus解决的问题域 ##

1.  消息队列 -- 应用解耦
2.  分布式RPC -- 远程方法调用
3.  异构服务代理 -- 跨平台语言RPC改造，实现DMZ服务总线架构

## zbus目前不解决 ##

1.  分布式事务

## zbus特点 ##

1.  极其轻量级--单个Jar包无依赖 ~300K （可个性化适配各类log包，commons-pool包）
2.  亿级消息堆积能力、支持HA高可用
3.  丰富的API--JAVA/C/C++/C\#/Python/Node.JS多语言接入
4.  兼容扩展HTTP协议接入（方便新增客户端SDK）

## QQ讨论组：467741880 猛戳右上角Star加入;) ##

## zbus启动 ##

zbus的角色是中间消息服务（Broker），默认分布式运行（当然也可以嵌入式单进程运作）

1.  通过脚本直接运行 zbus-dist发行目录下windows下对应zbus.bat, linux/mac 对应zbus.sh 运行脚本可以JVM参数优化，MQ存储路径等配置，如果运行发生错误，重点检查 （1）是否正确配置JVM （2）端口是否占用
2.  嵌入式直接 new MqServer 启动
    
    MqServerConfig config = new MqServerConfig();  
    config.serverPort = 15555;  
    config.storePath = "./store";  
    final MqServer server = new MqServer(config);  
    server.start();

启动后zbus可以通过浏览器直接访问zbus启动服务器15555端口的监控服务

![zbus监控][zbus 7]

## zbus实现消息队列 ##

消息队列是zbus的最基础服务，MQ参与角色分为三大类

1.  Broker中间消息服务器
2.  Producer生产者
3.  Consumer消费者

Producer ==> Broker ==> Consumer

逻辑上解耦分离 1. 生产者只需要知道Broker的存在，负责生产消息到Broker，不需要关心消费者的行为 2. 消费者也只需要知道Broker的存在，负责消费处理Broker上某个MQ队列的消息，不需要关心生产者的行为

不同的Broker实现在细节上会有些不同，但是在MQ逻辑解耦上基本保持一致，下面细节全部是以zbus特定定义展开

zbus与客户端（生产者与消费者）之间通讯的消息（org.zbus.net.http.Message）为了扩展性采用了【扩展HTTP】消息格式。 zbus的消息逻辑组织是以MQ标识来分组消息，MQ标识在zbus中就是MQ名字，Message对象中可以直接指定。 物理上zbus把同一个下MQ标识下的消息按照FIFO队列的模式在磁盘中存储，队列长度受限于磁盘大小，与内存无关。

编程模型上，分两个视图，生产者与消费者两个视图展开

1.  生产者视图
2.  消费者视图

生产者与消费者在编程模型上都需要首先产生一个Broker，Broker是对zbus本身的抽象，为了达到编程模型的一致，Broker可以是 单机版本的SingleBroker，也可以是高可用版本的HaBroker，甚至可以是不经过网络的本地化JvmBroker，这些类型的Broker都是不同的实现，编程模型上不关心，具体根据实际运行环境而定，为了更加方便配置，ZbusBroker实现了上述几种不同的Broker实现的代理包装，根据具体Broker地址来决定最终的版本。

例如

Broker broker = new ZbusBroker("127.0.0.1:15555"); //SingleBroker
    Broker broker = new ZbusBroker("127.0.0.1:16666;127.0.0.1:16667"); //HaBroker
    Broker broker = new ZbusBroker("jvm"); //JvmBroker

Broker内部核心实现了： 1. 连接池管理 2. 同步异步API

所以Broker在JAVA中可以理解为类似JDBC连接池一样的重对象，应该共享使用，大部分场景应该是Application生命周期。 而依赖Broker对象而存在的Producer与Consumer一般可以看成是轻量级对象（Consumer因为拥有链接需要关闭）

**生产消息**

//Producer是轻量级对象可以随意创建不用释放 
    Producer producer = new Producer(broker, "MyMQ");
    producer.createMQ();//确定为创建消息队列需要显示调用
    
    Message msg = new Message();
    msg.setBody("hello world");  //消息体底层是byte[]
    msg = producer.sendSync(msg);

**消费消息**

Consumer consumer = new Consumer(broker, "MyMQ");  
    consumer.start(new ConsumerHandler() { 
        @Override
        public void handle(Message msg, Consumer consumer) throws IOException { 
            //消息回调处理
            System.out.println(msg);
        }
    }); 
    //可控的范围内需要关闭consumer（内部拥有了物理连接）

生产者可以异步发送消息，直接调用producer.sendAsync()，具体请参考examples中相关示例

消费者可以使用更底层的API控制怎么取消息，直接调用consumer.take()从zbus上取回消息

从上面的API来看，使用非常简单，连接池管理，同步异步处理、高可用等相关主题全部留给了Broker抽象本身

### 消息队列扩展主题 ###

消息严格顺序问题 参考文章

*  [高可用保证消息绝对顺序消费的BROKER设计方案][BROKER]

## zbus实现RPC ##

MQ消息队列用于解耦应用之间的依赖关系，一般认为MQ是从更广泛的分布式RPC中演变而来的：在RPC场景下，如果某个远程方法调用耗时过长，调用方不希望blocking等待，除了异步处理之外，更加常见的改造方式是采用消息队列解耦调用方与服务方。

RPC的场景更加常见，RPC需要解决异构环境跨语言的调用问题，有非常多的解决方案，综合看都是折中方案，zbus也属其一。

RPC从数据通讯角度来看可以简单理解为：

分布式调用方A --->命令序列化(method+params) ---> 网络传输 --->  分布式式服务方B 命令反序列化（method+params）
           ^                                                                            | 
           |                                                                            v
           |<---结果反序列化(result/error)<----- 网络传输 <----结果序列化(result/error) <---调用本地方法

网络传输可以是纯网络传递消息也可以是其他服务器中转，比如消息队列

异构环境下RPC方案需要解决的问题包括以下核心问题

1. 跨语言，多语言平台下的消息通讯格式选择问题
    2. 服务端伺服问题，高性能处理模型
    3. 分布式负载均衡问题

WebService采用HTTP协议负载，SOAP跨语言描述对象解决问题1

Windows WCF采用抽象统一WebService和私有序列化高效传输解决问题1

在服务端处理模型与分布式负载均衡方面并不多体现，这里不讨论WebService，WCF或者某些私有的RPC方案的优劣之分，工程优化过程中出现了诸如Thrift，dubbo等等RPC框架，折射出来是的对已有的RPC方案中折中的不满。

针对问题1，zbus的RPC采用的是JSON数据根式封装跨语言平台协议，特点是简单明了，协议应用广泛（zbus设计上可以替换JSON）

针对问题2、问题3，zbus默认采用两套模式，MQ-RPC与DirectRPC， MQ-RPC基于MQ消息队列集中接入模式，DirectRPC则通过交叉直连模式

zbus的RPC方案除了解决上面三个问题之外，还有两个重要的工程目标：

4. 极其轻量、方便二次开发
    5. RPC业务本身与zbus解耦（无侵入，方便直接替换掉zbus）

zbus的RPC设计非常简单，模型上对请求和应答做了基本的抽象

public static class Request{ 
        private String module = ""; //模块标识
        private String method;      //远程方法
        private Object[] params;    //参数列表
        private String[] paramTypes;
        private String encoding = "UTF-8";
    }
    
    public static class Response {  
        private Object result;  
        private Throwable error;
        private String stackTrace; //异常时候一定保证stackTrace设定，判断的逻辑以此为依据
        private String encoding = "UTF-8";
    }

非常直观的抽象设计，就是对method+params 与 结果result/error 的JAVA表达而已。

RpcCodec的一个JSON协议实现---JsonRpcCodec完成将上述对象序列化成JSON格式放入到HTTP消息体中在网络上传输

### RPC调用方 ###

RpcInvoker API核心

public class RpcInvoker{ 
        private MessageInvoker messageInvoker; 
        private RpcCodec codec; //RPC对象序列化协议
    
        public Response invokeSync(Request request){
            .....
        } 
    }

完成将上述请求序列化并发送至网络，等待结果返回，序列化回result/error。

//调用示例
    RpcInvoker rpc = new RpcInvoker(...); //构造出RpcInvoker
    
    //利用RpcInvoker 调用方法echo(String msg), 给定参数值 "test"
    
    //1) 调用动态底层API
    Request request = new Request();
    request.setMethod("echo");
    request.setParams(new Object[]{"test"});
    Response response = rpc.invokeSync(request);
    
    //2）强类型返回结果
    String echoString = rpc.invokeSync(String.class, "echo", "test");

RpcInvoker同时适配MQ-RPC与DirectRPC，只需要给RpcInvoker指定不同的底层消息MessageInvoker，比如

1.  点对点DirectRPC (MessageClient/Broker)
2.  高可用DirectRPC (HaInvoker)
3.  MQ-RPC (MqInvoker)

点对点DirectRPC

//1） MessageClient是一种MessageInvoker，物理连接点对点
    MessageInvoker client = new MessageClient("127.0.0.1:15555", ....);
    RpcInvoker rpc = new RpcInvoker(client); //构造出RpcInvoker 
    
    //2) Broker也是一种MessageInvoker, 因为Broker管理了连接池，这样构造的RpcInvoker具有连接池能力
    MessageInvoker broker = new ZbusBroker("127.0.0.1:15555"); 
    RpcInvoker rpc = new RpcInvoker(broker); //构造出RpcInvoker 
    
    //1)与2）本质上都是点对点的直连模式

高可用DirectRPC

//1） 接入到Trackserver的ZbusBroker，具备高可用选择能力
    MessageInvoker messageInvoker = new ZbusBroker("127.0.0.1:16666;127.0.0.1:16667");
    //指定高可用服务器上的选择标识，注册为相同标识的服务提供方之间高可用
    HaInvoker haInvoker = new HaInvoker(messageInvoker, "HaDirectRpc"); 
    RpcInvoker rpc = new RpcInvoker(haInvoker); //构造出RpcInvoker

MQ-RPC

//step 1 生成一个到zbus服务器的MessageInvoker
    Broker broker = new ZbusBroker(); 
    //step 2 类似Java IoStream封装，在点对点基础上可以适配出MQ能力的MessageInvoker
    MessageInvoker mqInvoker = new MqInvoker(broker, "MyRpc"); //使用某个队列实现的RPC，调用适配
    RpcInvoker rpc = new RpcInvoker(mqInvoker); //构造出RpcInvoker

以上三种RPC结构优缺点如下：

*  点对点DirectRPC简单单机性能高，但存在单点问题
 *  高可用DirectRPC解决点对点的单点问题，但是网络连接是蜘蛛网状
 *  MQ-RPC集中式管理，多机负载均衡，但是因为所有消息都走了中间节点，性能有所下降

为了解决问题5，使得zbus在RPC业务解耦，zbus增加了动态代理类

RpcFactory API完成业务interface经过zbus的RPC动态代理类实现

public class RpcFactory {
        private final MessageInvoker messageInvoker; //底层支持的消息Invoker，完成动态代理    
        public <T> T getService(Class<T> api) throws Exception{
            ....
        }
    }

通过RpcFactory则完成了业务代码与zbus的解耦（通过spring等IOC容器更加彻底的把zbus完全隔离掉）

MessageInvoker invoker = new ... //DirectRPC或者MqRPC 选择， 同上
    //RpcFactory根据底层invoker来决定消息流
    RpcFactory factory = new RpcFactory(invoker);   
    //动态生成出InterfaceExample的实现类，RPC调用方不需要真正的实现类，客户端与服务端都通interface解耦
    InterfaceExample hello = factory.getService(InterfaceExample.class);

Spring的配置完全是上述代码的XML翻译，在此不做例子，具体参考examples下spring配置示例。

### RPC服务方 ###

RPC数据流图中分布式服务提供方需要的两件事情是

1.  如何拿到请求RPC数据包
2.  解释好包如何调动本地对应的方法

对于问题1.如何拿到数据包，分两大类处理方案：DirectRPC与MQ-RPC

DirectRPC则需要启动网络侦听服务，被动处理请求RPC包；MQ-RPC则是使用Consumer从zbus的MQ队列中主动取RPC请求包。

DirectRPC的服务zbus采用JAVA NIO服务器完成，对应org.zbus.rpc.direct.Service服务器完成NIO网络伺服；MQ-RPC对应org.zbus.rpc.mq.Service，多Consumer线程从zbus的某个MQ队列中并发取RPC请求包。

对于问题2，不管哪种模式的RPC都采用相同的处理方式--RpcProcessor

public class RpcProcessor implements MessageProcessor{ 
        private RpcCodec codec = new JsonRpcCodec(); //序列反序列化Request/Response
        private Map<String, MethodInstance> methods = new HashMap<String, MethodInstance>();  //业务方法映射表
    
        public void addModule(String module, Object... services){
            .....
        }
        public Message process(Message msg){ 
            .....
        }
    }

RpcProcessor本质上是通过反射将业务逻辑对象中的方法组织成 method==>(Method对象,Instance)映射

RpcProcessor.addModule(module, BizObject...)完成这个映射的管理

process的过程如下：

1. 处理RPC的请求包,RpcCodec反序列化出Request对象
    2. 根据Request对象找到合适的Method并尝试调用
    3. 调用结果组装成合适的Response对象
    4. RpcCodec反序列化Response对象返回RPC响应包

启动RPC服务在zbus中变得非常简单，分两步完成

//1)构造RpcProcessor--准备好服务映射表 
    RpcProcessor processor = new RpcProcessor();  
    processor.addModule(new InterfaceExampleImpl()); //动态增加业务对象，提供真正的业务逻辑
    
    
    //2)MQ-RPC或者DirectRPC的Service--容器运行上面的RpcProcessor
    ServiceConfig config = new ServiceConfig();
    config.setMessageProcessor(processor);  
    //更多的配置
    Service svc = new Service(config);
    svc.start();

Spring的配置完全是上述代码的XML翻译，在此不做例子，具体参考examples下spring配置示例。

## zbus实现异构服务代理--服务总线 ##

ZBUS = MQ+RPC

![zbus总线][zbus 8]

跨平台多语言+集中式节点控制，使得zbus适合完成服务总线适配工作。

为什么要采用总线架构适配已有服务？ 1. 集中式接入控制 2. 标准化 3. 扩展引入zbus的多语言跨平台能力

总线架构的一个核心需求是提供便捷的服务适配能力，zbus通过MQ和RPC来完成，对

1.  新服务 -- MQ-RPC模式完成，无侵入式
2.  旧服务 -- 选择旧服务支持的平台接入，通过MQ消息代理模式完成协议转换

新服务接入参考zbus实现RPC部分

旧服务MQ代理模式适配数据流描述：

zbus标准RPC客户端 <----> zbus（某个MQ队列）------->consumer线程消费消息----RPC消息包解包---->旧协议组装调用旧服务
                                  ^                                                          |
                                  |                                                          v
                                  --------------consumer.route命令返回<-----组装RPC消息包<----旧服务返回结果

代理模式一般在调用旧服务的时候采用异步模式，防止同步阻塞的场景发生 标准化RPC则采用zbus的JSON协议方式序列化消息与zbus消息交换，当然也可以私有的方式。

下面的子项目是多个语言平台实现MQ代理的案例

*  [微软MSMQ|国信交易调度][MSMQ]
 *  [金证KCXP][KCXP]
 *  [国信TC][TC]
 *  [桥接JAVA客户端][JAVA]
 *  [国泰君安GTA][GTA]

## zbus底层编程扩展 ##

接入zbus只需要遵循公开协议即可，目前已经支持的接入平台包括

*  [Java API][]
 *  [C/C++ API][C_C_ API]
 *  [Python API][]
 *  [C\# API][C_ API]
 *  [Node.JS API][]

### zbus协议说明 ###

zbus协议可以简单描述为扩展HTTP协议，协议整体格式是HTTP格式，因为HTTP协议的广泛应用，相对方便解释与理解。但同时为了降低HTTP协议头部负载与业务数据独立于zbus控制数据，zbus采用了HTTP扩展协议：

*  控制数据放在HTTP扩展头部，比如增加mq: MyMQ\\r\\n扩展控制消息目标MQ
 *  业务数据放在HTTP消息体，不参与任何zbus消息控制，业务数据底层为byte\[\]二进制

因此zbus协议描述就是HTTP扩展的KeyValue描述

命令控制 cmd

zbus接收到消息Message做何种动作，由cmd KV扩展决定，支持的赋值（Protocol.java 中定义）

public static final String Produce   = "produce";   //生产消息命令
    public static final String Consume   = "consume";   //消费消息命令
    public static final String Route     = "route";     //路由回发送者命令
    public static final String QueryMQ   = "query_mq";  //查询消息队列信息
    public static final String CreateMQ  = "create_mq"; //创建消息队列
    public static final String RemoveMQ  = "remove_mq"; //删除消息队列 
    public static final String AddKey    = "add_key";   //增加一个Key，用于判定某条消息是否重复，zbus简单的KV服务
    public static final String RemoveKey = "remove_key";//删除一个Key 
    //下面的命令是监控中使用到，test测试，data返回监控数据，jquery监控使用到的jquery.js
    public static final String Auth      = "auth";  
    public static final String Test      = "test";      
    public static final String Data      = "data"; 
    public static final String Jquery    = "jquery";

每个命令可能用到参数Key说明（Message.java）

public static final String MQ       = "mq";      //消息队列标识 
    public static final String SENDER   = "sender";  //消息发送者标识
    public static final String RECVER   = "recver";  //消息接收者标识
    public static final String ID       = "id";  //消息ID
    public static final String RAWID    = "rawid";   //原始消息ID（消费消息时交换中用到）
    public static final String SERVER   = "server";  //消息经过的broker地址
    public static final String TOPIC    = "topic";   //消息发布订阅主题， 使用,分隔 
    public static final String ACK      = "ack";      //消息ACK
    public static final String ENCODING = "encoding"; //消息body二进制编码
    public static final String KEY       = "key";      //消息的KEY
    public static final String KEY_GROUP = "key_group"; //消息的KEY分组
    public static final String MASTER_MQ  = "master_mq";   //消息队列主从复制的主队列标识
    public static final String MASTER_TOKEN  = "master_token";  //主队列访问控制码

具体每个命令对应使用到的参数，请参考MqAdaptor中对应每个命令的Handler

public class MqAdaptor extends IoAdaptor implements Closeable {
        public MqAdaptor(MqServer mqServer){ 
            ....
            registerHandler(Protocol.Produce, produceHandler); 
            registerHandler(Protocol.Consume, consumeHandler);  
            registerHandler(Protocol.Route, routeHandler); 
    
            registerHandler(Protocol.CreateMQ, createMqHandler);
            registerHandler(Protocol.QueryMQ, queryMqHandler);
            registerHandler(Protocol.RemoveMQ, removeMqHandler);
    
            registerHandler(Protocol.AddKey, addKeyHandler); 
            registerHandler(Protocol.RemoveKey, removeKeyHandler); 
    
            registerHandler("", homeHandler);  
            registerHandler(Protocol.Data, dataHandler); 
            registerHandler(Protocol.Jquery, jqueryHandler);
            registerHandler(Protocol.Test, testHandler);
    
            registerHandler(Message.HEARTBEAT, heartbeatHandler);   
        } 
    }

### zbus网络编程模型 ###

zbus底层通信基础并没有采用netty这样的NIO框架，而是基于JAVA NIO做了一个简单的封装，尽管没有使用到netty的大量开箱即用的功能，但是zbus也在通信基础上获取了些我们认为更加重要的东西： 1. 完全自主个性化的网络事件模型 2. 轻量级通信底层

zbus的网络通讯部分核心在org.zbus.net.core包中，org.zbus.net.http 提供了一个轻量级的HTTP扩展实现。

zbus的NIO通信模型的封装非常简单：

1. 网络事件模型是由SelectorThread来完成，核心就是run方法中的多路复用检测网络IO事件
    2. 在各个事件处理中（READ/WRITE/CONNECT/ACCEPT)中核心产生了Session处理
    3. 事件处理公开机制靠IoAdaptor完成
    4. 最外面由SelectorGroup完成多个SelectorThread的负载均衡与简单管理，提高整体性能

上面的描述也是解读代码的先后顺序

zbus在net.core包设计的基础之上，为了方便使用方构建客户端与服务器端程序，提供了Client、Server的基本封装，同步异步处理Sync方便消息的同步异步转换。

Client本质上就一个IoAdaptor应用案例，专门从连接客户端角度处理网络各项事件。 Server则提供了一个简单机制，运行可被个性化的IoAdaptor实例。

Server端示例（简洁性的体现）

//借助HTTP协议实现中的MessageAdaptor完成HTTP服务器，只需要简单的
    public static void main(String[] args) throws Exception {
        //1） SelectorGroup管理 
        final SelectorGroup group = new SelectorGroup();
        final Server server = new Server(group);
        //2)构建一个MessageAdaptor
        MessageAdaptor ioAdaptor = new MessageAdaptor();
        ioAdaptor.uri("/hello", new MessageProcessor() { 
            public Message process(Message request) {
                Message resp = new Message();
                resp.setStatus(200);
                resp.setBody("hello");
                return resp;
            }
        });
        //3)在8080端口上启动这个IoAdaptor服务
        server.start(8080, ioAdaptor);
    }

运行则直接可以统统浏览器访问 [http://localhost:8080/hello][http_localhost_8080_hello]

这个示例并不是简单的hello world，SelectorGroup使之具备高性能服务框架，在i7 CPU的box上能上10w+的QPS性能

具体请详细参考examples下面的net示例

## zbus高可用模式 ##

zbus高可用采用类似zookeeper的跟踪机制，但并没有使用zookeeper。

zbus高可用由两大节点群组成： 1. ZbusServer节点群 2. TrackServer节点群

ZbusServer节点群由单机版本的zbus组成，各个节点之间无状态关联，TrackServer节点群中各个节点也无任何状态关联，ZbusServer把节点状态（诸如MQ信息）上报给所有的TrackServer。

这里面信息的一致性zbus是做了妥协的，可以理解为zookeeper一种简化，典型配置是TrackServer全网配置两台，所有的ZbusServer都向这两台TrackServer上报各自的节点变化信息，包括某个节点MQ信息即时变化推送，定时（默认2s）重复更新。实用角度简化设计的一种折中。

客户端（生产者与消费者）仍然是直接链接到某个ZbusServer，但是选择节点由订阅TrackServer而给出的整体ZbusServer的节点拓扑信息决定，客户端同时做了容错处理，运行中所有的TrackServer失败不影响已有拓扑信息的实用（本地缓存）

上述客户端的复杂性由HaBroker封装（最终由ZbusBroker统一类型选择），API层面不受高可用选择影响与单点zbus场景保持一致，同时高可用节点选择算法也将陆续开放，方便二次开发个性化。

高可用HA环境的搭建 因为zbus HA方案中的节点无任何状态联系，因此HA环境搭建非常简单，各个节点启动无顺序依赖，一般顺序为：

1.  启动若干个（一般两个）TrackServer群。
2.  配置预先知道的TrackServer列表到ZbusServer（MqServer）的启动项中，启动若干个ZbusServer节点群。

整个HA的Broker环境就建立好了，例子可以参考zbus-dist/ha 目录下的配置启动，注意如果不按照先TrackServer启动的顺序，先启动ZbusServer会临时报无法找到某个TrackServer错误，直到TrackServer启动正常，错误不影响使用。

HA最佳实践指导：

1.  生产者端（包括RPC客户端）配置HaBroker，完全实现Failover与负载均衡
2.  消费者端（包括RPC服务端）配置SingleBroker，不使用HaBroker的容错，而是多机部署，这样能运行确定节点分布。

上述HaBroker与SingleBroker都统一使用ZbusBroker，只是BrokerAddress的地址配置差异。

## zbus性能测试数据 ##

性能测试程序在test/performance目录下，根据实际的机器测试给出。

一个参考数据，测试环境

MacBook Pro (Retina, 15-inch, Mid 2015)
    Processor 2.5 GHz Intel Core i7
    Memory 16 GB 1600 MHz DDR3

消息大小 "hello world"

*  生产消息速度 （~4万笔每秒）

测试代码： org.zbus.performance.ProducerPerf.java

2016-03-16 14:50:08 INFO  Perf:73 - QPS: 42844.4874, Failed/Total=0/2660020(0.0000)
    2016-03-16 14:50:09 INFO  Perf:73 - QPS: 42845.4515, Failed/Total=0/2670011(0.0000)
    2016-03-16 14:50:09 INFO  Perf:73 - QPS: 42842.2988, Failed/Total=0/2680012(0.0000)
    2016-03-16 14:50:09 INFO  Perf:73 - QPS: 42841.8991, Failed/Total=0/2690011(0.0000)
    2016-03-16 14:50:09 INFO  Perf:73 - QPS: 42838.7834, Failed/Total=0/2700020(0.0000)
    2016-03-16 14:50:10 INFO  Perf:73 - QPS: 42840.4312, Failed/Total=0/2710016(0.0000)
    2016-03-16 14:50:10 INFO  Perf:73 - QPS: 42840.0428, Failed/Total=0/2720007(0.0000)

*  消费消息速度（~4万笔每秒）

测试代码： org.zbus.performance.ConsumerPerf.java

2016-03-16 14:57:13 INFO  ConsumerPerf:47 - Consumed:150000, QPS: 43290.0433
    2016-03-16 14:57:13 INFO  ConsumerPerf:47 - Consumed:160000, QPS: 43859.6491
    2016-03-16 14:57:14 INFO  ConsumerPerf:47 - Consumed:170000, QPS: 43859.6491
    2016-03-16 14:57:14 INFO  ConsumerPerf:47 - Consumed:180000, QPS: 43290.0433
    2016-03-16 14:57:14 INFO  ConsumerPerf:47 - Consumed:190000, QPS: 43859.6491
    2016-03-16 14:57:14 INFO  ConsumerPerf:47 - Consumed:200000, QPS: 44247.7876
    2016-03-16 14:57:15 INFO  ConsumerPerf:47 - Consumed:210000, QPS: 43668.1223
    2016-03-16 14:57:15 INFO  ConsumerPerf:47 - Consumed:220000, QPS: 44843.0493
    2016-03-16 14:57:15 INFO  ConsumerPerf:47 - Consumed:230000, QPS: 44843.0493

*  HTTP响应速度（~6.6万笔每秒）

测试代码，服务器: org.zbus.examples.net.server.MyServer

压力程序: ab -k -c 20 -n 1000000 [http://localhost:8080/hello][http_localhost_8080_hello]

Server Hostname:        localhost
    Server Port:            8080
    
    Document Path:          /hello
    Document Length:        5 bytes
    
    Concurrency Level:      20
    Time taken for tests:   15.073 seconds
    Complete requests:      1000000
    Failed requests:        0
    Keep-Alive requests:    1000000
    Total transferred:      67000000 bytes
    HTML transferred:       5000000 bytes
    Requests per second:    66344.44 [#/sec] (mean)
    Time per request:       0.301 [ms] (mean)
    Time per request:       0.015 [ms] (mean, across all concurrent requests)
    Transfer rate:          4340.90 [Kbytes/sec] received

[zbus]: http://git.oschina.net/rushmore/zbus#zbus%E8%A7%A3%E5%86%B3%E7%9A%84%E9%97%AE%E9%A2%98%E5%9F%9F
[zbus 1]: http://git.oschina.net/rushmore/zbus#zbus%E7%89%B9%E7%82%B9
[zbus 2]: http://git.oschina.net/rushmore/zbus#zbus%E5%90%AF%E5%8A%A8
[zbus 3]: http://git.oschina.net/rushmore/zbus#zbus%E5%AE%9E%E7%8E%B0%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97
[zbus_RPC]: http://git.oschina.net/rushmore/zbus#zbus%E5%AE%9E%E7%8E%B0RPC
[zbus_--]: http://git.oschina.net/rushmore/zbus#zbus%E5%AE%9E%E7%8E%B0%E5%BC%82%E6%9E%84%E6%9C%8D%E5%8A%A1%E4%BB%A3%E7%90%86--%E6%9C%8D%E5%8A%A1%E6%80%BB%E7%BA%BF
[zbus 4]: http://git.oschina.net/rushmore/zbus#zbus%E5%BA%95%E5%B1%82%E7%BC%96%E7%A8%8B%E6%89%A9%E5%B1%95
[zbus 5]: http://git.oschina.net/rushmore/zbus#zzbus%E9%AB%98%E5%8F%AF%E7%94%A8%E6%A8%A1%E5%BC%8F
[zbus 6]: http://git.oschina.net/rushmore/zbus#zbus%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95%E6%95%B0%E6%8D%AE
[zbus 7]: https://imgconvert.csdnimg.cn/aHR0cDovL2dpdC5vc2NoaW5hLm5ldC91cGxvYWRzL2ltYWdlcy8yMDE2LzAzMTYvMTYxNzEzX2MxNWM2MDMxXzc0NTgucG5n?x-oss-process=image/format,png
[BROKER]: http://www.infoq.com/cn/articles/high-availability-broker-design
[zbus 8]: https://imgconvert.csdnimg.cn/aHR0cDovL2dpdC5vc2NoaW5hLm5ldC91cGxvYWRzL2ltYWdlcy8yMDE2LzAzMTYvMTYwMDM2XzQ4YmYzYjcyXzc0NTgucG5n?x-oss-process=image/format,png
[MSMQ]: http://git.oschina.net/rushmore/zbus-proxy-msmq
[KCXP]: http://git.oschina.net/rushmore/zbus-proxy-kcxp
[TC]: http://git.oschina.net/rushmore/zbus-proxy-tc
[JAVA]: http://git.oschina.net/rushmore/zbus-proxy-java
[GTA]: http://git.oschina.net/rushmore/zbus-proxy-gta
[Java API]: http://git.oschina.net/rushmore/zbus
[C_C_ API]: http://git.oschina.net/rushmore/zbus-api-c
[Python API]: http://git.oschina.net/rushmore/zbus-api-python
[C_ API]: http://git.oschina.net/rushmore/zbus-api-csharp
[Node.JS API]: http://git.oschina.net/rushmore/zbus-api-nodejs
[http_localhost_8080_hello]: http://localhost:8080/hello