SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。
Read Uncommitted（读取未提交内容）

       在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
Read Committed（读取提交内容）

       这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
Repeatable Read（可重读）

       这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（可串行化） 
       这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

         这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：

         脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

         不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。

         幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

         在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：

下面，将利用MySQL的客户端程序，分别测试几种隔离级别。测试数据库为test，表为tx；表结构：

两个命令行客户端分别为A，B；不断改变A的隔离级别，在B端修改数据。

（一）、将A的隔离级别设置为read uncommitted(未提交读)

 在B未更新数据之前：

客户端A：

B更新数据：

客户端B：

客户端A：

        经过上面的实验可以得出结论，事务B更新了一条记录，但是没有提交，此时事务A可以查询出未提交记录。造成脏读现象。未提交读是最低的隔离级别。

（二）、将客户端A的事务隔离级别设置为read committed(已提交读)

 在B未更新数据之前：

B更新数据：

客户端B：

客户端A：

       经过上面的实验可以得出结论，已提交读隔离级别解决了脏读的问题，但是出现了不可重复读的问题，即事务A在两次查询的数据不一致，因为在两次查询之间事务B更新了一条数据。已提交读只允许读取已提交的记录，但不要求可重复读。

(三)、将A的隔离级别设置为repeatable read(可重复读)

 在B未更新数据之前：

B更新数据：

客户端B：

客户端A：

B插入数据：

客户端B：

客户端A：

       由以上的实验可以得出结论，可重复读隔离级别只允许读取已提交记录，而且在一个事务两次读取一个记录期间，其他事务部的更新该记录。但该事务不要求与其他事务可串行化。例如，当一个事务可以找到由一个已提交事务更新的记录，但是可能产生幻读问题(注意是可能，因为数据库对隔离级别的实现有所差别)。像以上的实验，就没有出现数据幻读的问题。

(四)、将A的隔离级别设置为 可串行化 (Serializable)

A端打开事务，B端插入一条记录

事务A端：

事务B端：

因为此时事务A的隔离级别设置为serializable，开始事务后，并没有提交，所以事务B只能等待。

事务A提交事务：

事务A端

事务B端

      
 serializable完全锁定字段，若一个事务来查询同一份数据就必须等待，直到前一个事务完成并解除锁定为止 。是完整的隔离级别，会锁定对应的数据表格，因而会有效率的问题。

一、rsync的概述

rsync是类unix系统下的数据镜像备份工具，从软件的命名上就可以看出来了——remote sync。rsync是Linux系统下的文件同步和数据传输工具，它采用“rsync”算法，可以将一个客户机和远程文件服务器之间的文件同步，也可以 在本地系统中将数据从一个分区备份到另一个分区上。如果rsync在备份过程中出现了数据传输中断，恢复后可以继续传输不一致的部分。rsync可以执行 完整备份或增量备份。它的主要特点有：

1.可以镜像保存整个目录树和文件系统；

2.可以很容易做到保持原来文件的权限、时间、软硬链接；无须特殊权限即可安装；

3.可以增量同步数据，文件传输效率高，因而同步时间短；

4.可以使用rcp、ssh等方式来传输文件，当然也可以通过直接的socket连接；

5.支持匿名传输，以方便进行网站镜象等；

6.加密传输数据，保证了数据的安全性；

二、镜像目录与内容

rsync -av duying  /tmp/test

查看/tmp/test目录，我们可以看到此命令是把duying这个文件夹目录连同内容全部考到当前目录下了

rsync  -av duying/ /tmp/test         注意：比上一条命令多了符号“/” 

再次查看/tmp/test目录，我们发现没有duying这个目录，只是看到了目录中的内容

三、增量备份本地文件

rsync -avzrtopgL  --progress /src /dst

-v是“--verbose”,即详细模式输出； -z表示“--compress”，即传输时对数据进行压缩处理；

-r表示“--recursive”，即对子目录以递归的模式处理；-t是“--time”，即保持文件时间信息；

-o表示“owner”，用来保持文件属主信息；-p是“perms”，用来保持文件权限；

-g是“group”，用来保持文件的属组信息；

--progress用于显示数据镜像同步的过程；

四、镜像同步备份文件

rsync -avzrtopg --progress --delete /src  /dst

--delete选项指定以rsync服务器端为基础进行数据镜像同步，也就是要保持rsync服务器端目录与客户端目录的完全一致；

--exclude选项用于排除不需要传输的文件类型；

五、设置定时备份策略

crontab -e

30 3 * * * rsync -avzrtopg  --progress  --delete  --exclude "*access*"

--exclude "*debug*"  /src /dst

如果文件比较大，可使用nohup将进程放到后台执行。

nohup rsync -avzrtopgL  --progress /data/opt /data2/  >/var/log/$(date +%Y%m%d).mail.log & 

六、rsync的优点与不足

与传统的cp、tar备份方式对比，rsync具有安全性高、备份迅速、支持增量备份等优点，通过rsync可以解决对实时性要求不高的数据备份需求，例如，定期地备份文件服务器数据到远端服务器，对本地磁盘定期进行数据镜像等。

但是随着系统规模的不断扩大，rsync的缺点逐渐被暴露了出来。首先，rsync做数据同步时，需要扫描所有文件后进行对比，然后进行差量传输。如果文 件很大，扫面文件是非常耗时的，而且发生变化的文件往往是很少一部分，因此rsync是非常低效的方式。其次，rsync不能实时监测、同步数据，虽然它 可以通过Linux守护进程的方式触发同步，但是两次触发动作一定会有时间差，可能导致服务器端和客户端数据出现不一致。

转自：http://blog.sina.com.cn/s/blog_6954b9a901011esn.html

     Linux下如何查看版本信息， 包括位数、版本信息以及CPU内核信息、CPU具体型号等等，整个CPU信息一目了然。

1. 在项目上右键进入Properties,选择Deployment Assembly，再点击Add...,如下图所示：
   
   ２.然后在弹出的窗口中，选择Java Build Path Entries，点击Next,如下图所示：
   
   
   
   3.选择你要你引入的UserLibrary，点击Finish即可
   
   注意：如果在Java Web Project引入了其它Java Project,默认引用的Java　Project的编译后字节码是不会部署到WEB-INF/class下的，此时需要使用上面的Project进行导出．

原文：http://hg.rabbitmq.com/rabbitmq-management/raw-file/3646dee55e02/priv/www-api/help.html

介绍

除了帮助页面，所有URIs只会服务application/json类型的资源，并且需要HTTP基础认证(使用标准RabbitMQ用户数据库). 默认用户是guest/guest.

大多数URIs需要虚拟主机名称作为其路径的一部分, 因为名称是虚拟主机的唯一标识符对象. 默认虚拟主机称为"/", 它需要编码为"%2f".

PUT一个资源会对其进行创建. 你上传的JSON对象必须有某个键keys (下面文档有描述)，其它的键会被忽略. 缺失键会引发错误.

在AMQP中，由于绑定没有名称或IDs，因此我们基于其所有属性人工合成了一个. 

由于一般情况下很难预测这个名字, 你可以通过POST一个工厂URI来创建绑定.查看下面的例子.

注意事项

• arguments 字段会被忽略.你不创建一个队列,交换器或使用参数进行绑定. 带有参数的队列，交换器或绑定也不会显示这些参数．
• 权限偶尔才需要强制执行.如果一个用户能用HTTP API进行认证，那么它们可以做任何事情.
• 从GET请求中返回的对象中包含许多与监控相关的信息. 它们是无证实的，并且将来可能要发生变化.

示例

下面有几个快速例子,它们使用了Unix命令行工具curl:

• 获取虚拟主机列表:

  $ curl -i -u guest:guest http://localhost:55672/api/vhosts 
  HTTP/1.1 200 OK 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Tue, 31 Aug 2010 15:46:59 GMT 
  Content-Type: application/json 
  Content-Length: 5  
  ["/"]

• 创建一个新虚拟主机:

  $ curl -i -u guest:guest -H "content-type:application/json" \   -XPUT http://localhost:55672/api/vhosts/foo 
  HTTP/1.1 204 No Content 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Fri, 27 Aug 2010 16:56:00 GMT 
  Content-Type: application/json 
  Content-Length: 0

  注意: 你必须将mime类型指定为application/json.

  Note: 在上传的JSON对象中，对象名称是不需要的，因为它已经包含在了URI中. 由于一个虚拟主机除了名称外没有其它属性，这意味着你完全不需要指定一个body.

• 在默认虚拟主机中创建一个新的交换器:

  $ curl -i -u guest:guest -H "content-type:application/json" \   -XPUT -d'{"type":"direct","auto_delete":false,"durable":true,"arguments":[]}' \   http://localhost:55672/api/exchanges/%2f/my-new-exchange 
  HTTP/1.1 204 No Content 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Fri, 27 Aug 2010 17:04:29 GMT 
  Content-Type: application/json 
  Content-Length: 0

  注意: 在PUT或DELETE的响应中， 除非失败了，否则我们绝不会返回一个body.

• 再删除它:

  $ curl -i -u guest:guest -H "content-type:application/json" \   -XDELETE http://localhost:55672/api/exchanges/%2f/my-new-exchange 
  HTTP/1.1 204 No Content 
  Server: MochiWeb/1.1 WebMachine/1.7 (participate in the frantic) 
  Date: Fri, 27 Aug 2010 17:05:30 GMT 
  Content-Type: application/json 
  Content-Length: 0

参考

{"type":"direct","auto_delete":false,"durable":true,"arguments":[]}

{"auto_delete":false,"durable":true,"arguments":[]}

{"routing_key":"my_routing_key","arguments":[]}

{"password":"secret"}

{"scope":"client","configure":".*","write":".*","read":".*"}

rabbitmqctl list_exchanges -p /myvhost name type

rabbitmqctl list_bindings -p /myvhost exchange_name queue_name

rabbitmqctl list_connections send_pend port

rabbitmqctl list_channels connection messages_unacknowledged

rabbitmqctl status

rabbitmqctl report > server_report.txt

rabbitmqctl eval 'node().'

• 使 client 连接与程序相关联
• 使用细粒度的权限
• 凭据翻滚(如. 周期性地或遭到破坏的情况下)

• 至少有128 MB
• 当RAM达到4GB时，可配置为75%的RAM限制
• 当RAM达到4GB－8GB时，可配置为80%的RAM限制
• 当RAM达到8GB－16GB时，可配置为85%的RAM限制
• 当RAM大于16GB时，可配置为90%的RAM限制

• 至少有2 GB
• 当限制为1到8GB的RAM时，可配置为RAM限制的50％
• 当限制为8到32GB的RAM时，可配置为RAM限制的40%
• 当限制超过32GB的RAM时，可配置为RAM限制的30%

• 希望的吞吐量
• 希望的复制( mirrors的数目)
• 数据局部性

原文：http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html

学习如何在你的应用程序中集成WebSockets.

Published April 2013

对于许多基于客户端－服务器程序来说，老的HTTP 请求-响应模型已经有它的局限性. 信息必须通过多次请求才能将其从服务端传送到客户端.

过去许多的黑客使用某些技术来绕过这个问题，例如：长轮询(long polling)、基于 HTTP 长连接的服务器推技术(Comet). 

在2011年, IETF发布了标准WebSocket协议－RFC 6455. 从那时起，大多数Web浏览器都实现了支持WebSocket协议的客户端APIs.同时，许多Java 包也开始实现了WebSocket协议.

WebSocket协议利用HTTP升级技术来将HTTP连接升级到WebSocket. 一旦升级后，连接就有了在两个方向上相互独立(全双式)发送消息(数据桢)的能力. 

不需要headers 或cookies,这大大降低了所需的带宽. 通常，WebSockets来周期性地发送小消息 (例如，几个字节). 

JSR 356

JSR 356, WebSocket的Java API, 明确规定了API，当Java开发者需要在应用程序中集成WebSocket时，就可以使用此API—服务端和客户端均可. 每个声明兼容JSR 356的WebSocket协议，都必须实现这个API. 

因此，开发人员可以自己编写独立于底层WebSocket实现的WebSocket应用。这是一个巨大的好处，因为它可以防止供应商锁定，并允许更多的选择、自由的库、应用程序服务器。

JSR 356是即将到来的java EE 7标准的一部分，因此，所有与Java EE 7兼容的应用服务器都有JSR 365标准WebSocket的实现.一旦建立，WebSocket客户端和服务器节点已经是对称的了。客户端API与服务器端API的区别是很小的，JSR 356定义的Java client API只是Java EE7完整API的子集.

客户段－服务器端程序使用WebSockets，通常会包含一个服务器组件和多个客户端组件, 如图１所示:

图1

在这个例子中，server application 是通过Java编写的,WebSocket 协议细节是由包含在Java EE 7容器中JSR 356 实现来处理的.

JavaFX 客户端可依赖任何与JSR 356兼容的客户端实现来处理WebSocket协议问题. 

其它客户端(如,iOS 客户端和HTML5客户端)可使用其它 (非Java)与RFC6455兼容的实现来与server application通信.

编程模型

JSR 356定义的专家小组,希望支持Java EE开发人员常用的模式和技术。因此,JSR 356使用了注释和注入。

一般来说，支持两种编程模型:

• 注解驱动(annotation-driven). 通过使用注解POJOs, 开发者可与WebSocket生命周期事件交互.
• 接口驱动(interface-driven). 开发者可实现Endpoint接口和与生命周期交互的方法.

生命周期事件

典型的WebSocket 交互生命周期如下:

• 一端 (客户端) 通过发送HTTP握手请求来初始化连接.
• 其它端(服务端) 回复握手响应.
• 建立连接.从现在开始，连接是完全对称的.
• 两端都可发送和接收消息.
• 其中一端关闭连接.

大部分WebSocket生命周期事件都与Java方法对应，不管是 annotation-driven 还是interface-driven.

Annotation-Driven 方式

接受WebSocket请求的端点可以是以 @ServerEndpoint 注解的POJO. 

此注解告知容器，此类应该被认为是WebSocket端点. 

必须的value 元素指定了WebSocket端点的路径.

考虑下面的代码片断:

@ServerEndpoint("/hello")  public class MyEndpoint { } 

此代码将会以相对路径hello来发布一个端点.在后续方法调用中，此路径可携带路径参数，如： /hello/{userid}是一个有效路径，在这里{userid} 的值，可在生命周期方法使用@PathParam 注解获取.

在GlassFish中，如果你的应用程序是用上下文mycontextroot 部署的，且在localhost的8080端口上监听, WebSocket可通过使用ws://localhost:8080/mycontextroot/hello来访问.

初始化WebSocket连接的端点可以是以 @ClientEndpoint 注解的POJO.@ClientEndpoint 和 @ServerEndpoint的主要区别是ClientEndpoint 不接受路径路值元素，因为它监听进来的请求。

@ClientEndpoint  public class MyClientEndpoint {} 

Java中使用注解驱动POJO方式来初始化WebSocket连接，可通过如下代码来完成:

javax.websocket.WebSocketContainer container = javax.websocket.ContainerProvider.getWebSocketContainer();  container.conntectToServer(MyClientEndpoint.class, new URI("ws://localhost:8080/tictactoeserver/endpoint")); 

此后，以 @ServerEndpoint 或@ClientEndpoint 注解的类都称为注解端点.

一旦建立了WebSocket连接 ，就会创建 Session，并且会调用注解端点中以@OnOpen注解的方法. 

此方法包含了几个参数:

• javax.websocket.Session 参数, 代表创建的Session
• EndpointConfig 实例包含了关于端点配置的信息
• ０个或多个以 @PathParam注解的字符串参数,指的是端点路径的path参数

下面的方法实现了当打开WebSocket时，将会打印session的标识符:

@OnOpen public void myOnOpen (Session session) {    System.out.println ("WebSocket opened: "+session.getId()); } 

Session实例只要WebSocket未关闭就会一直有效. Session类中包含了许多有意思的方法，以允许开发者获取更多关于的信息。

同时,Session 也包含了应用程序特有的数据钩子,即通过getUserProperties() 方法来返回 Map<String, Object>. 

这允许开发者可以使用session-和需要在多个方法调用间共享的应用程序特定信息来填充Session实例.

i当WebSocket端收到消息时，将会调用以@OnMessage注解的方法.以@OnMessage 注解的方法可包含下面的参数:

• javax.websocket.Session 参数.
• ０个或多个以 @PathParam注解的字符串参数,指的是端点路径的path参数
• 消息本身. 下面有可能消息类型描述.

当其它端发送了文本消息时，下面的代码片断会打印消息内容:

@OnMessage public void myOnMessage (String txt) {    System.out.println ("WebSocket received message: "+txt); }  

如果以@OnMessage i注解的方法返回值不是void, WebSocket实现会将返回值发送给其它端点.下面的代码片断会将收到的文本消息以首字母大写的形式发回给发送者:

@OnMessage public String myOnMessage (String txt) {    return txt.toUpperCase(); }  

另一种通过WebSocket连接来发送消息的代码如下:

RemoteEndpoint.Basic other = session.getBasicRemote(); other.sendText ("Hello, world"); 

在这种方式中，我们从Session 对象开始，它可以从生命周期回调方法中获取(例如,以 @OnOpen注解的方法).session实例上getBasicRemote() 方法返回的是WebSocket其它部分的代表RemoteEndpoint. RemoteEndpoint 实例可用于发送文本或其它类型的消息，后面有描述.

当关闭WebSocket连接时,将会调用@OnClose 注解的方法。此方法接受下面的参数:

• javax.websocket.Session 参数. 注意，一旦WebSocket真正关闭了，此参数就不能被使用了，这通常发生在@OnClose 注解方法返回之后.
• A javax.websocket.CloseReason 参数，用于描述关闭WebSocket的原因,如：正常关闭，协议错误,服务过载等等.
• ０个或多个以 @PathParam注解的字符串参数,指的是端点路径的path参数

下面的代码片段打印了WebSocket关闭的原因:

@OnClose public void myOnClose (CloseReason reason) {    System.out.prinlnt ("Closing a WebSocket due to "+reason.getReasonPhrase()); } 

完整情况下，这里还有一个生命周期注解:如果收到了错误，将会调用 @OnError 注解的方法。

Interface-Driven 方式

annotation-driven 方式允许我们注解一个Java类，以及使用生命周期注解来注解方法. 

使用interface-driven方式,开发者可继承javax.websocket.Endpoint 并覆盖其中的onOpen, onClose, 以及onError 方法:

public class myOwnEndpoint extends javax.websocket.Endpoint {    public void onOpen(Session session, EndpointConfig config) {...}    public void onClose(Session session, CloseReason closeReason) {...}    public void onError (Session session, Throwable throwable) {...} } 

为了拦截消息，需要在onOpen实现中注册一个javax.websocket.MessageHandler:

public void onOpen (Session session, EndpointConfig config) {    session.addMessageHandler (new MessageHandler() {...}); } 

MessageHandler 接口有两个子接口: MessageHandler.Partial和 MessageHandler.Whole. 

MessageHandler.Partial 接口应该用于当开发者想要收到部分消息通知的时候,MessageHandler.Whole的实现应该用于整个消息到达通知。

下面的代码片断会监听进来的文件消息，并将文本信息转换为大小版本后发回给其它端点：

public void onOpen (Session session, EndpointConfig config) {    final RemoteEndpoint.Basic remote = session.getBasicRemote();    session.addMessageHandler (new MessageHandler.Whole<String>() {       public void onMessage(String text) {                  try {                      remote.sendString(text.toUpperCase());                  } catch (IOException ioe) {                      // handle send failure here                  }              }     }); } 

消息类型，编码器，解码器

WebSocket的JavaAPI非常强大，因为它允许发送任或接收任何对象作为WebSocket消息.

基本上，有三种不同类型的消息:

• 基于文本的消息
• 二进制消息
• Pong 消息,它是WebSocket连接自身

当使用interface-driven模式,每个session最多只能为这三个不同类型的消息注册一个MessageHandler.

当使用annotation-driven模式,针对不同类型的消息，只允许出现一个@onMessage 注解方法. 在注解方法中，消息内容中允许的参数依赖于消息类型。

Javadoc for the @OnMessage annotation 明确指定了消息类型上允许出现的消息参数:

• "如果方法用于处理文本消息: 
  
  
  • String 用于接收整个消息
  • Java 原型或等价的类用于接收整个消息并将其转换为此类型
  • String 和 boolean 对用于部分接收消息
  • Reader 用于以阻塞流的方式接收整个消息
  • 端点的任何对象参数存在文本解码器 (Decoder.Text 或 Decoder.TextStream).
• 如果方法用于处理二进制消息: 
  
  
  • byte[] 或 ByteBuffer 用于接收整个消息
  • byte[] 和 boolean 对, 或者 ByteBuffer 和boolean对用于部分接收消息
  • InputStream 用于按阻塞流的方式接收整个消息
  • 端点的任何对象参数存在二进制解码器(Decoder.Binary or Decoder.BinaryStream).
• 如果方法是用于处理pong消息: 
  
  
  • PongMessage 用于处理pong消息"

任何Java对象使用编码器都可以编码为基于文本或二进制的消息.这种基于文本或二进制的消息将转输到其它端点，在其它端点，它可以解码成Java对象－或者被另外的WebSocket 包解释. 

通常情况下，XML或JSON用于来传送WebSocket消息, 编码/解码然后会将Java对象编组成XML或JSON并在另一端解码为Java对象.

encoder是以javax.websocket.Encoder 接口的实现来定义,decoder是以javax.websocket.Decoder 接口的实现来定义的. 

有时，端点实例必须知道encoders和decoders是什么.使用annotation-driven方式, 可向@ClientEndpoint 和 @ServerEndpoint l注解中的encode和decoder元素传递 encoders和decoders的列表。

Listing 1 中的代码展示了如何注册一个 MessageEncoder 类(它定义了MyJavaObject实例到文本消息的转换). MessageDecoder 是以相反的转换来注册的.

@ServerEndpoint(value="/endpoint", encoders = MessageEncoder.class, decoders= MessageDecoder.class) public class MyEndpoint { ... }  class MessageEncoder implements Encoder.Text<MyJavaObject> {    @override    public String encode(MyJavaObject obj) throws EncodingException {       ...    } }  class MessageDecoder implements Decoder.Text<MyJavaObject> {    @override     public MyJavaObject decode (String src) throws DecodeException {       ...    }     @override     public boolean willDecode (String src) {       // return true if we want to decode this String into a MyJavaObject instance    } } 

Listing 1

Encoder 接口有多个子接口:

• Encoder.Text 用于将Java对象转成文本消息
• Encoder.TextStream 用于将Java对象添加到字符流中
• Encoder.Binary 用于将Java对象转换成二进制消息
• Encoder.BinaryStream 用于将Java对象添加到二进制流中

类似地,Decoder 接口有四个子接口:

• Decoder.Text 用于将文本消息转换成Java对象
• Decoder.TextStream 用于从字符流中读取Java对象
• Decoder.Binary 用于将二进制消息转换成Java对象
• Decoder.BinaryStream 用于从二进制流中读取Java对象

结论

WebSocket Java API为Java开发者提供了标准API来集成IETF WebSocket标准.通过这样做，Web 客户端或本地客户端可使用任何WebSocket实现来轻易地与Java后端通信。

也可参考

• JSR 356 on jcp.org
• JSR 356 specification work on java.net
• Tyrus (JSR 356 Reference Implementation) on java.net
• JSR 342, the Java EE 7 umbrella specification on jcp.org
• GlassFish, the Reference Implementation for Java EE

一旦它运行起来，你就可以从同一个web界面中，看到系统信息和RabbitMQ节点、队列的相关信息，如下面的截图所示：

更多

Ganglia是集群监测一种广泛的解决方案，但不是唯一的一个。其它的解决方案还包括Nagios (www.nagios.org), Zabbix (www.zabbix.com), 以及Puppet (puppetlabs.com).

通过RabbitMQ排除故障

正如前面食谱提到的, 我们可以通过一种便利的方式，即以日志文件的方式来监控RabbitMQ行为.
也可以使用RabbitMQ自身来访问同种信息, 通过向AMQP client通知broker的活动.

准备

要运行本食谱，我们需要运行RabbitMQ以及Java client library.
如何做

为了消费日志消息，你可在Consumer.java中执行主方法.你可在Chapter12/Recipe02/Java/src/rmqexample中找到源友. 下面，我们将高亮主要步骤:
1. 创建一个临时匿名队列，并将其绑定到AMQP log交换器:
String tmpQueue = channel.queueDeclare().getQueue();
channel.queueBind(tmpQueue,"amq.rabbitmq.log","#");
2. 在消费者回调(ActualConsumer.java)中,可以检索消息和每个消息的路由键，并将它们打印出来:
String routingKey = envelope.getRoutingKey();
String message = new String(body);
System.out.println(routingKey + ": " + message);
3. 此时，你可以在broker上执行任何RabbitMQ操作，并且你会看到日志输出到标准输出上。

如何工作

RabbitMQ log交换器amq.rabbitmq.log是一个topic交换器，RabbitMQ自身用来发布其日志消息.
在我们的示例代码中，我们使用#通配符来消费所有topics的消息.
例如，通过运行另一份代码，我们可运行同一个broker的两个连接，然后中断它，我们将下面的输出:
info: accepting AMQP connection <0.2737.0> (127.0.0.1:54698 ->127.0.0.1:5672)
info: accepting AMQP connection <0.2753.0> (127.0.0.1:54699 ->127.0.0.1:5672)
warning: closing AMQP connection <0.2737.0> (127.0.0.1:54698 ->127.0.0.1:5672):
connection_closed_abruptly
warning: closing AMQP connection <0.2753.0> (127.0.0.1:54699 ->127.0.0.1:5672):
connection_closed_abruptly

值得注意的是，在这里报告的信息，信息和警告不是自己的一部分，但是我们在每个开始打印的路由键消息（前一步骤的步骤2）。

TIP

如果我们只想收到警告和错误消息，我们可以订阅相应的主题.

更多

默认情况下，日志交换器－amq.rabbitmq.log被创建在虚拟主机/中。通过在RabbitMQ配置文件中定义default_vhost从而设置其位置是可能的.

追踪RabbitMQ当前活动

有时，为了分析和调试未知的应用程序行为，我们需要追踪RabbitMQ接收和分发的所有消息.
RabbitMQ提供追踪这些消息的所谓的流水追踪工具。
追踪活动可以在运行时启用和禁用,并且它应该只用于调试，因为它规定了broker活动的开销.
准备

要运行此食谱，我们需要运行此食谱，我们需要运行RabbitMQ和Java client library.
如何做

RabbitMQ使用与日志消息中同样的机制来发送追踪消息;因此，示例代码与前一个食谱中的非常相似.

为了消费追踪消息，你可以执行Consumer.java中的主方法，你可在Chapter12/Recipe02/Java/src/rmqexample目录中找到源码.这里，我们高亮了主要步骤:
1. 创建一个临时队列，并将其绑定到AMQP log交换器上:
String tmpQueue = channel.queueDeclare().getQueue();
channel.queueBind(tmpQueue,"amq.rabbitmq.trace","#");
2.在消费者回调(ActualConsumer.java)中, 可以获取每个消息，并使用下面的代码打印出来:
String routingKey = envelope.getRoutingKey();
String message = new String(body);
Map<String,Object> headers = properties.getHeaders();
LongStringexchange_name = (LongString)
headers.get("exchange_name");
LongString node = (LongString) headers.get("node");
...
3. 可从root用户(Linux)或在RabbitMQ命令控制台(Windows)来激活firehose，其激活命令如下:
rabbimqctl trace_on
4. 此时,你可以向broker启动生产和发送消息,然后你们会在标准输出中看到追踪信息.
5. 可调用下面的命令来禁用firehose:
rabbimqctl trace_off

如何工作 

默认情况下，amq.rabbit.trace topic交换器不会接收任何消息,但一旦激活firehose后(前面步骤的步骤3),所有流经broker的消息将被按下面的规则拷贝:
1.进入broker的消息,它们是通过路由键publish.exchange-name发布的, 这里的exchange-name是消息最初发布的交换器名称.
2.离开broker的消息,它们是通过路由键deliver.queuename发布的,这里的queue-name是消息最初被消费的队列名称.
3.消息的body是从原始消息中拷贝过来的.
4.原始消息的元数据会插入到拷贝消息的header属性中. 在步骤2中,我们已经看到了,如何获取最初分发消息的交换器名称,但获取所有原始信息也是可以的,即,找到所有可有字段,并将它们插到消息属性中.firehose的官方文档链接位于:http://www.rabbitmq.com/firehose.html.

调试RabbitMQ消息

有时,通过在标准输出中记录通过broker的消息是有用的.通过RabbitMQ Java客户端提供的简单应用程序来追踪消息,也是可行的.
准备

要运行此食谱,你需要运行的RabbitMQ(运行标准端口 5672),以及RabbitMQ Java client library
如何做

RabbitMQ的Java client library中包含了一个追踪工具，你可以按下面的步骤来进行实际使用.
1. 从http://www.rabbitmq.com/java-client.html页面下载最新版本的RabbitMQ Java client library.
2. 将其解压，并进入其目录.

3. 通过下面的命令来运行Java tracer:
./runjava.sh com.rabbitmq.tools.Tracer
4. 运行用于调试Java client,并将其连接到5673端口.对于本食谱,我们可以使用包含在Java client包中的另一个Java工具,其调用如下:
./runjava.sh com.rabbitmq.examples.PerfTest -h amqp://localhost:5673 -C 1 -D 1
如何工作

追踪工具是一个简单的AMQP代理;默认情况下，它监听5673端口，并会把所有的请求转发到默认监听5672端口的RabbitMQ broker.
所有生产或消费的消息，如同AMQP操作一样，都会记录到标准输出中.
运行前面步骤的步骤4,我们使用了包含在Java client包中另一个用于作RabbitMQ压力测试的工具.
在这里,我们只是限制了生产一个消息(-C 1) 并消费它(-D 1).
TIP

追踪工具只在Java client API中可用.

更多

可以使用下面的代码来为Java追踪程序传递更多的参数:
./runjava.sh com.rabbitmq.tools.Tracer listenPort connectHost connectPort
listenPort指的是追踪器监听的端口(默认为5673), connectHost/connectPort (默认为localhost/5672) 是用于连接并转发收到请求的主机和端口。

使用下面的命令，你可以找到所有PerfTest可用选项:
./runjava.sh com.rabbitmq.examples.PerfTest --help

也可参考

在http://www.rabbitmq.com/java-tools.html中，你可以找到Java追踪工具以及PerfTest的文档.

当RabbitMQ重启失败时，需要做什么

偶尔情况下， RabbitMQ 可能会重启失败。如果broker包含持久化数据时，这是一个严重的问题，否则，有足够的能力重设其持久化状态。
准备

要运行此食谱，你只需要一个测试RabbitMQ broker.
TIP

我们将销毁所有之前定义的数据—以避免使用生产实例.

如何做

要清空RabbitMQ, 可执行下面的简单步骤:
1. 如果RabbitMQ运行的话，停止它.
2. 定位到Mnesia 数据库目录.默认是/var/lib/rabbitmq/mnesia (Linux) or %APPDATA%\RabbitMQ\db (Windows).
3. 递归删除其目录和文件.
4. 重启RabbitMQ.
如何工作

Mnesia 数据库包含了所有运行时的RabbitMQ定义信息: 队列,交换器,用户等等.
通过删除Mnesia数据库 (或者通过重命名,这样可以在需要的时候恢复某些数据), RabbitMQ会重置到出厂默认状态,当RabbitMQ启动时,它会创建一个新的Mnesia数据库,并使用默认值进行初始化.

更多

如果broker无法在第一时间启动,有可能是某个系统目录存在权限问题:即要么是Mnesia数据库目录,要么是日志目录,要么是某些在配置文件中指定的临时的或自定义的目录.

你可以在RabbitMQ故障排除页页找到详尽的列表(http://www.rabbitmq.com/troubleshooting.html).

也可参考

在Mnesia API 文档页面(http://www.erlang.org/doc/man/mnesia.html),,你可以找到更多关于如何破解Mnesia数据库的信息.

使用Wireshark调试

在调试RabbitMQ消息食谱中,我们已经了解过了如何来追踪RabbitMQ的消息.

然而，以下情况并不总是可能的或可取的，即停止正在运行的客户端（或RabbitMQ服务器），修改它的连接端口，指向一个不同的broker；我们只想监控正在实时传递的消息，影响系统的活动应该尽可能的少。

TIP

但是,正如在前面食谱(追踪RabbitMQ当前活动)中看到的一样,激活firehose是可行的 .

Wireshark是一个免费的有能力解码AMQP消息的网络分析工具.
此工具既可用在客户段,也可以用在服务端,从而无缝监控AMQP交通状况.

准备

要练习这个食谱,你需要运行的RabbitMQ以及RabbitMQ Java client library.

如何做

在下面的步骤中,我们将看到如何使用Wireshark来追踪AMQP消息:
1. 如果Wireshark在你的系统中尚不可用,那么需要从http://www.wireshark.org/下载和安装Wireshark . 如果可能的话,你也可以从你的发行版中进行安装,如:
yum install wireshark-gnome
2.在Linux系统中,以root用户来启动Wireshark.
3.启动从环回接口中捕获消息.
4.切换到Java client library路径下,在终端中运行下面的命令:
./runjava.sh com.rabbitmq.examples.PerfTest -C 1 -D 1
5.停止Wireshark GUI的采集,并分析抓到的AMQP交通状况.
如何工作

使用Wireshark,可用于检测AMQP交通的退出或进行一个持有RabbitMQ服务器或客户端的服务器.
在我们的例子中,我们捕获了运行在同一台机器上服务端和客户端网络交通状况,因此连接是localhost中发生的.这也是为什么我们从环回接口中捕获交通状况的原因(前面步骤的步骤3).
反之,我们应该从网络接口中进行捕获,这种网络接口通常是eth0或其它相似的网络接口.

TIP

在Linux上,可以直接捕获localhost;但同样的操作不能应用到Windows上.在这种情况下,客户端和服务端必须位于不同的两台机器上, 并且在网络接口上(要么是物理的,要么是虚拟的)必须激活捕获, 这样它们之间才可连接.

所以，为了运行Wireshark的图形用户界面，如果RabbitMQ客户端和服务器运行在同一个节点，你需要选择环回接口，如图下面的截图所示:

TIP

在Linux上，当你安装Wireshark软件包，你通常只会有命令行界面，tshark。要安装Wireshark的GUI，你必须安装相应的软件包. 例如,在Fedora中,你需要安装wireshark-gnome包.

一旦AMQP交通已穿过环回接口，它已经被Wireshark捕获。

运行在步骤4的实验实际上在两个独立的连接中开启了一个生产者和一个消费者.

为了高亮显示,找到一个描述为Basic.PublishContent-Header的包,点击它,并选择Follow TCP stream.然后，您可以关闭显示客户端和服务器之间有效负载对话的窗口。在主窗口中，您现在可以看到在客户端和服务器之间交换的网络数据包，如下面的截图所示：



用同样的方式,你可以选择RabbitMQ server,如下面的截图所示:

在前面的两个截图中，我们已经强调了消息AMQP的有效载荷，但由于Wireshark中包括了一个非常完整的AMQP解剖器,你会发现在AMQP交通的很多细节。

更多

如果RabbitMQ配置为使用SSL,并且你想要分析加密流量,在一定条件下,通过在Wireshark配置中合理配置SSL公共/私有密钥也是可以的。

可在http://wiki.wireshark.org/SSL找到更多信息.
也可参考

在http://wiki.wireshark.org/AMQP,你可以找到一些关于Wireshark AMQP 解剖器的一些指南.