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":".*"}