摘要: serverStatus.pdf原文:https://docs.mongodb.com/v3.0/reference/command/serverStatus/定義serverStatusserverStatus命令用于返回數據庫進程狀態的概述文檔. 大部分監控程序都會定期運行此命令來收集實例相關的統計信息:{ serverStatus: 1 } 其值(即上面的1)不影響命令的操作。2.4版本中修...
閱讀全文
posted @
2017-06-26 21:08 胡小軍 閱讀(2557) |
評論 (0) |
編輯 收藏
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未更新數據之前:
客戶端A:
B更新數據:
客戶端B:

客戶端A:

經過上面的實驗可以得出結論,已提交讀隔離級別解決了臟讀的問題,但是出現了不可重復讀的問題,即事務A在兩次查詢的數據不一致,因為在兩次查詢之間事務B更新了一條數據。已提交讀只允許讀取已提交的記錄,但不要求可重復讀。
(三)、將A的隔離級別設置為repeatable read(可重復讀)
在B未更新數據之前:
客戶端A:
B更新數據:
客戶端B:

客戶端A:

B插入數據:
客戶端B:

客戶端A:

由以上的實驗可以得出結論,可重復讀隔離級別只允許讀取已提交記錄,而且在一個事務兩次讀取一個記錄期間,其他事務部的更新該記錄。但該事務不要求與其他事務可串行化。例如,當一個事務可以找到由一個已提交事務更新的記錄,但是可能產生幻讀問題(注意是可能,因為數據庫對隔離級別的實現有所差別)。像以上的實驗,就沒有出現數據幻讀的問題。
(四)、將A的隔離級別設置為 可串行化 (Serializable)
A端打開事務,B端插入一條記錄
事務A端:

事務B端:

因為此時事務A的隔離級別設置為serializable,開始事務后,并沒有提交,所以事務B只能等待。
事務A提交事務:
事務A端

事務B端

serializable完全鎖定字段,若一個事務來查詢同一份數據就必須等待,直到前一個事務完成并解除鎖定為止 。是完整的隔離級別,會鎖定對應的數據表格,因而會有效率的問題。
轉自:http://xm-king.iteye.com/blog/770721
posted @
2016-09-24 00:06 胡小軍 閱讀(246) |
評論 (0) |
編輯 收藏
一、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
posted @
2016-09-23 22:01 胡小軍 閱讀(253) |
評論 (0) |
編輯 收藏
Linux下如何查看版本信息, 包括位數、版本信息以及CPU內核信息、CPU具體型號等等,整個CPU信息一目了然。
1、# uname -a (Linux查看版本當前操作系統內核信息)
Linux localhost.localdomain 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 athlon i386 GNU/Linux
2、# cat /proc/version (Linux查看當前操作系統版本信息)
Linux version 2.4.20-8 (bhcompile@porky.devel.redhat.com)
(gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003
3、# cat /etc/issue 或cat /etc/redhat-release(Linux查看版本當前操作系統發行版信息)
Red Hat Linux release 9 (Shrike)
4、# cat /proc/cpuinfo (Linux查看cpu相關信息,包括型號、主頻、內核信息等)
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 1
model name : AMD A4-3300M APU with Radeon(tm) HD Graphics
stepping : 0
cpu MHz : 1896.236
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr
sse sse2 syscall mmxext lm 3dnowext 3dnow
bogomips : 3774.87
5、# getconf LONG_BIT (Linux查看版本說明當前CPU運行在32bit模式下, 但不代表CPU不支持64bit)
32
6、# lsb_release -a
以上文章轉載自:http://www.cnblogs.com/lanxuezaipiao/archive/2012/10/22/2732857.html
posted @
2016-09-23 21:58 胡小軍 閱讀(241) |
評論 (0) |
編輯 收藏
摘要: 原文:http://shiro.apache.org/reference.htmlApache Shiro介紹Apache Shiro是什么?Apache Shiro 是一個可干凈處理認證,授權,企業會話管理以及加密的強大且靈活的開源安全框架.Apache Shiro的首要目標是易于使用和理解. 安全可以是非常復雜的,有時甚至是痛苦的,但它不是. 框架應該隱藏復雜的地方,暴露干凈而方便的API,以...
閱讀全文
posted @
2016-08-18 17:32 胡小軍 閱讀(2501) |
評論 (0) |
編輯 收藏
- 在項目上右鍵進入Properties,選擇Deployment Assembly,再點擊Add...,如下圖所示:

2.然后在彈出的窗口中,選擇Java Build Path Entries,點擊Next,如下圖所示:

3.選擇你要你引入的UserLibrary,點擊Finish即可
注意:如果在Java Web Project引入了其它Java Project,默認引用的Java Project的編譯后字節碼是不會部署到WEB-INF/class下的,此時需要使用上面的Project進行導出.
posted @
2016-08-17 12:53 胡小軍 閱讀(2341) |
評論 (0) |
編輯 收藏
介紹
除了幫助頁面,所有URIs只會服務application/json
類型的資源,并且需要HTTP基礎認證(使用標準RabbitMQ用戶數據庫). 默認用戶是guest/guest.
大多數URIs需要虛擬主機名稱作為其路徑的一部分, 因為名稱是虛擬主機的唯一標識符對象. 默認虛擬主機稱為"/
", 它需要編碼為"%2f
".
PUT一個資源會對其進行創建. 你上傳的JSON對象必須有某個鍵keys (下面文檔有描述),其它的鍵會被忽略. 缺失鍵會引發錯誤.
在AMQP中,由于綁定沒有名稱或IDs,因此我們基于其所有屬性人工合成了一個.
由于一般情況下很難預測這個名字, 你可以通過POST一個工廠URI來創建綁定.查看下面的例子.
注意事項
這些注意事項適用于當前管理AP的開發版本。在未來,他們將是固定的。
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
參考
GET | PUT | DELETE | POST | Path | Description |
---|
X |
|
|
| /api/overview | 描述整個系統的各種隨機信息。 |
X |
|
|
| /api/connections | 所有打開連接的列表. |
X |
| X |
| /api/connections/name | 一個單獨的連接. DELETE它會導致連接關閉. |
X |
|
|
| /api/channels | 所有打開通道的列表. |
X |
|
|
| /api/channels/channel | 單個通道的詳情. |
X |
|
|
| /api/exchanges | 所有交換器的列表. |
X |
|
|
| /api/exchanges/vhost | 指定虛擬主機中所有交換器列表. |
X | X | X |
| /api/exchanges/vhost/name | 一個單獨的交換器.要PUT一個交換器,你需要一些像下面這樣的body:{"type":"direct","auto_delete":false,"durable":true,"arguments":[]} |
X |
|
|
| /api/exchanges/vhost/name/bindings | 指定交換器中的綁定列表. |
X |
|
|
| /api/queues | 所有隊列的列表. |
X |
|
|
| /api/queues/vhost | 指定虛擬主機中所有隊列列表. |
X | X | X |
| /api/queues/vhost/name | 一個單獨隊列.要PUT一個隊列, 你需要一些像下面這樣的body:{"auto_delete":false,"durable":true,"arguments":[]} |
X |
|
|
| /api/queues/vhost/queue/bindings | 指定隊列中的所有綁定列表. |
X |
|
|
| /api/bindings | 所有綁定列表. |
X |
|
|
| /api/bindings/vhost | 指定虛擬主機上的所有綁定列表. |
X |
|
| X | /api/bindings/vhost/queue/exchange | 隊列和交換器之間的所有綁定列表. 記住,隊列和交換器可以綁定多次!要創建一個新綁定, POST 這個URI.你需要一些像下面這樣的body:{"routing_key":"my_routing_key","arguments":[]} 響應會包含一個Location header,它會告訴你新綁定的URI. |
X | X | X |
| /api/bindings/vhost/queue/exchange/props | 隊列和交換器之間的單個綁定. URI的props部分是一個名稱,用于由路由鍵和屬性組成的綁定.你可以通過PUT這個URI來創建一個綁定,它比上面POST URI更方便. |
X |
|
|
| /api/vhosts | 所有虛擬主機列表. |
X | X | X |
| /api/vhosts/name | 單個虛擬主機.由于虛擬主機只有一個名稱,因此在PUT時不需要body. |
X |
|
|
| /api/users | 所有用戶列表. |
X | X | X |
| /api/users/name | 單個用戶. 要PUT一個用戶, 你需要一些像下面這樣的body:{"password":"secret"} |
X |
|
|
| /api/users/user/permissions | 指定用戶的所有權限列表. |
X |
|
|
| /api/permissions | 所有用戶的所有權限列表. |
X | X | X |
| /api/permissions/vhost/user | 一個虛擬主機中某個用戶的個人權限. 要PUT一個權限,你需要一些像下面這樣的body:{"scope":"client","configure":".*","write":".*","read":".*"} |
posted @
2016-08-13 21:50 胡小軍 閱讀(7317) |
評論 (0) |
編輯 收藏
摘要: 3.1.15 消息監聽器容器配置有相當多的配置SimpleMessageListenerContainer 相關事務和服務質量的選項,它們之間可以互相交互.當使用命名空間來配置<rabbit:listener-container/>時,下表顯示了容器屬性名稱和它們等價的屬性名稱(在括號中).未被命名空間暴露的屬性,以`N/A`表示.Table 3.3. 消...
閱讀全文
posted @
2016-08-13 16:24 胡小軍 閱讀(6556) |
評論 (0) |
編輯 收藏
摘要: 3.1.10 配置broker介紹AMQP 規范描述了協議是如何用于broker中隊列,交換器以及綁定上的.這些操作是從0.8規范中移植的,更高的存在于org.springframework.amqp.core包中的AmqpAdmin 接口中. 那個接口的RabbitMQ 實現是RabbitAdmin,它位于org.springframework.amqp.rabbit.core 包.A...
閱讀全文
posted @
2016-08-13 16:07 胡小軍 閱讀(4968) |
評論 (0) |
編輯 收藏
摘要: 3.1.9 Request/Reply 消息介紹AmqpTemplate 也提供了各種各樣的sendAndReceive 方法,它們接受同樣的參數選項(exchange, routingKey, and Message)來執行單向發送操作. 這些方法對于request/reply 場景也是有用的,因為它們在發送前處理了必要的"reply-to"屬性配置,并能通過它在專...
閱讀全文
posted @
2016-08-13 15:59 胡小軍 閱讀(6656) |
評論 (0) |
編輯 收藏
摘要: Consumer Tags從1.4.5版本開始,你可以提供一種策略來生成consumer tags.默認情況下,consumer tag是由broker來生成的.public interface ConsumerTagStrategy { String createConsumerTag(String queue); }該隊列是可用的,所以它可以(可選)在tag中使用。參考Sectio...
閱讀全文
posted @
2016-08-13 12:48 胡小軍 閱讀(13049) |
評論 (0) |
編輯 收藏
摘要: Queue Affinity 和 LocalizedQueueConnectionFactory當在集群中使用HA隊列時,為了獲取最佳性能,可以希望連接到主隊列所在的物理broker. 雖然CachingConnectionFactory 可以配置為使用多個broker 地址; 這會失敗的,client會嘗試按順序來連接. LocalizedQueueConnectionFac...
閱讀全文
posted @
2016-08-13 12:38 胡小軍 閱讀(6251) |
評論 (0) |
編輯 收藏
摘要: 3. 參考這部分參考文檔詳細描述了組成Sring AMQP的各種組件. main chapter 涵蓋了開發AMQP應用程序的核心類. 這部分也包含了有關示例程序的章節.3.1 使用 Spring AMQP在本章中,我們將探索接口和類,它們是使用Spring AMQP來開發應用程序的必要組件 .3.1.1 AMQP 抽象介紹Spring ...
閱讀全文
posted @
2016-08-13 12:21 胡小軍 閱讀(6595) |
評論 (0) |
編輯 收藏
摘要: 原文:http://docs.spring.io/spring-amqp/docs/1.6.0.RELEASE/reference/html/1. 前言Spring AMQP項目將其核心Spring概念應用于基于AMQP消息解決方案的開發中.我們提供了一個發送和接收消息的高級抽象模板.同時,我們也提供了消息驅動POJO的支持.這些包有助于AMQP資源的管理,從而提升依賴注入和聲明式配置的使用. 在...
閱讀全文
posted @
2016-08-13 12:03 胡小軍 閱讀(5914) |
評論 (0) |
編輯 收藏
摘要: 1 概述1.1 本文檔的目標此文檔定義了一個網絡協議-高級消息隊列協議(AMQP), 它使一致的客戶端程序可以與一致的消息中間件服務器進行通信.我們面對的是這個領域有經驗的技術讀者,同時還提供了足夠的規范和指南.技術工程師可以根據這些文檔,在任何硬件平臺上使用各種編程語言來構建遵從該協議的解決方案。1.2 摘要1.2.1 為什么使用AMQP?AMQP在一致性客戶端和消息中間件(也稱為"broker...
閱讀全文
posted @
2016-08-12 18:30 胡小軍 閱讀(10848) |
評論 (0) |
編輯 收藏
摘要: 原文:http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-java7.12.1 基本概念: @Bean 和 @Configuration在Spring新的Java配置支持中,其核心構件是@Configuration注解類和@Bean注解方法.@Bean 注解用來表示方...
閱讀全文
posted @
2016-08-05 17:04 胡小軍 閱讀(2309) |
評論 (0) |
編輯 收藏
摘要: RabbitMQ內置支持TLS。自RabbitMQ 3.4.0起, 為防止 POODLE attack 攻擊,已經自動禁用了SSLv3.使用TLS時,推薦安裝的Erlang/OTP版本為17.5或以上版本. R16版本在某些證書中可以工作,但存在major limitations.必須安裝Erlang加密程序,并且保證它能工作.對于那些從源碼進行Erlang編譯的Windows...
閱讀全文
posted @
2016-08-02 22:25 胡小軍 閱讀(11907) |
評論 (0) |
編輯 收藏
摘要: 原文:http://www.rabbitmq.com/configure.htmlRabbitMQ 提供了三種方式來定制服務器:環境變量定義端口,文件位置和名稱(接受shell輸入,或者在環境配置文件(rabbitmq-env.conf)中設置)配置文件為服務器組件設置權限,限制和集群,也可以定義插件設置.運行時參數和策略可在運行時進行修改集群設置大部分設置都使用前面的兩種方法,但本指南會全部講解...
閱讀全文
posted @
2016-08-02 09:38 胡小軍 閱讀(49323) |
評論 (0) |
編輯 收藏
名稱
rabbitmqctl — 用于管理中間件的命令行工具
語法
rabbitmqctl [-n node] [-t timeout] [-q] {command} [command options...]
描述
RabbitMQ是AMQP的實現, 后者是高性能企業消息通信的新興標準. RabbitMQ server是AMQP 中間件健壯的,可擴展的實現.
rabbitmqctl 用來管理RabbitMQ中間件的命令行工具.它通過連接中間件節點來執行所有操作。
如果中間件沒有運行,將會顯示診斷信息, 不能到達,或因不匹配Erlang cookie而拒絕連接.
選項
[-n node]
默認節點是"rabbit@server",此處的server是本地主機. 在一個名為"server.example.com"的主機上, RabbitMQ Erlang node 的節點名稱通常是rabbit@server (除非RABBITMQ_NODENAME在啟動時設置了非默認值). hostname -s 的輸出通常是"@" 標志后的東西.查看rabbitmq-server(1)來了解配置RabbitMQ broker的細節.
[-q]
使用-q標志來啟用寧靜(quiet)模式,這會一致消息輸出.
[-t timeout]
操作超時時間(秒為單位). 只適用于"list" 命令. 默認是無窮大.
命令
應用程序和集群管理
stop [pid_file]
用于停止運行RabbitMQ的Erlang node.如果指定了pid_file,還將等待指定的過程結束。例如:
rabbitmqctl stop
此命令會終止RabbitMQ node的運行.
stop_app
停止RabbitMQ application,但Erlang node會繼續運行.此命令主要用于優先執行其它管理操作(這些管理操作需要先停止RabbitMQ application),如. reset.例如:
rabbitmqctl stop_app
start_app
啟動RabbitMQ application.
此命令典型用于在執行了其它管理操作之后,重新啟動停止的RabbitMQ application。如reset.例如:
rabbitmqctl start_app
此命令來指導RabbitMQ node來啟動RabbitMQ application.
wait {pid_file}
等待RabbitMQ application啟動.此命令用來等待RabbitMQ application來啟動node。它會等待創建pid文件,然后等待pid文件中的特定pid過程啟動,最后等待RabbitMQ application 來啟動node.
pid file是通過rabbitmq-server 腳本來創建的.默認情況下,它存放于Mnesia目錄中. 修改RABBITMQ_PID_FILE 環境變量可以改變此位置。如:
rabbitmqctl wait /var/run/rabbitmq/pid
此命令會在RabbitMQ node啟動后返回.
reset
將RabbitMQ node還原到最初狀態.包括從所在群集中刪除此node,從管理數據庫中刪除所有配置數據,如已配置的用戶和虛擬主機,以及刪除所有持久化消息.
執行reset和force_reset之前,必須停止RabbitMQ application ,如使用stop_app.
示例:
rabbitmqctl reset
此命令會重設RabbitMQ node.
force_reset
強制RabbitMQ node還原到最初狀態.
不同于reset , force_reset 命令會無條件地重設node,不論當前管理數據庫的狀態和集群配置是什么. 它只能在數據庫或集群配置已損壞的情況下才可使用。
執行reset和force_reset之前,必須停止RabbitMQ application ,如使用stop_app.
示例:
rabbitmqctl force_reset
此命令會重設RabbitMQnode.
rotate_logs {suffix}
指示RabbitMQ node循環日志文件.
RabbitMQ 中間件會將原來日志文件中的內容追加到原始名稱和后輟的日志文件中,然后再將原始日志文件內容復制到新創建的日志上。實際上,當前日志內容會移到以此后輟結尾的文件上。當目標文件不存在時,將會進行創建。如果不指定后輟,則不會發生循環,日志文件只是重新打開。示例:
rabbitmqctl rotate_logs .1
此命令指示RabbitMQ node將日志文件的內容追加到新日志文件(文件名由原日志文件名和.1后輟構成)中。如. rabbit@mymachine.log.1 和 rabbit@mymachine-sasl.log.1. 最后, 日志會在原始位置恢復到新文件中.
集群管理
join_cluster {clusternode} [--ram]
- clusternode
加入集群的節點.
[--ram]
如果進行了設置,節點將以RAM節點身份加入集群.
指導節點成為集群中的一員. 在加入集群之前,節點會重置,因此在使用此命令時,必須小心. 這個命令要成功,RabbitMQ應用程序必須先停止,如stop_app.
集群節點可以是兩種類型: 磁盤節點(Disc Node) 或 內存節點(RAM Node).磁盤節點會在RAM和磁盤中復制數據, 通過冗余可以防止節點失效事件,并可從斷電這種全局事件中進行恢復. RAM節點只在RAM中復制數據(除了隊列的內容外,還依賴于隊列是否是持久化的或者內容對于內存來說是否過大) ,并主要用于可伸縮性. RAM節點只有當管理資源(如,增加/刪除隊列,交換機,或綁定)的時候才具有更高的性能.一個集群必須至少有一個磁盤節點,通常來說還不止一個.
默認情況下,節點是磁盤節點.如果你想要創建內存節點,需要提供--ram 標志.
在執行cluster命令之后, 無論何時,當前節點上啟動的RabbitMQ 應用程序在節點宕機的情況下,會嘗試連接集群中的其它節點。
要脫離集群, 必須重設(reset)節點. 你也可以通過forget_cluster_node 命令來遠程刪除節點.
更多詳情,參考集群指南.
例如:
rabbitmqctl join_cluster hare@elena --ram
此命令用于指示RabbitMQ node以ram節點的形式將 hare@elena 加入集群.
cluster_status
按節點類型來分組展示集群中的所有節點,包括當前運行的節點.
例如:
rabbitmqctl cluster_status
此命令會顯示集群中的所有節點.
change_cluster_node_type {disc | ram}
修改集群節點的類型. 要成功執行此操作,必須首先停止節點,要將節點轉換為RAM節點,則此節點不能是集群中的唯一disc節點。
例如:
rabbitmqctl change_cluster_node_type disc
此命令會將一個RAM節點轉換為disc節點.
forget_cluster_node [--offline]
[--offline]
允許節點從脫機節點中刪除. 這只在所有節點都脫機且最后一個掉線節點不能再上線的情況下有用,從而防止整個集群從啟動。它不能使用在其它情況下,因為這會導致不一致.
遠程刪除一個集群節點.要刪除的節點必須是脫機的, 而在刪除節點期間節點必須是在線的,除非使用了--offline 標志.
當使用--offline 標志時,rabbitmqctl不會嘗試正常連接節點;相反,它會臨時改變節點以作修改.如果節點不能正常啟動的話,這是非常有用的.在這種情況下,節點將變成集群元數據的規范源(例如,隊列的存在),即使它不是以前的。因此,如果有可能,你應該在最新的節點上使用這個命令來關閉。
例如:
rabbitmqctl -n hare@mcnulty forget_cluster_node rabbit@stringer
此命令會從節點hare@mcnulty中刪除rabbit@stringer節點.
rename_cluster_node {oldnode1} {newnode1} [oldnode2] [newnode2 ...]
支持在本地數據庫中重命名集群節點.
此子命令會促使rabbitmqctl臨時改變節點以作出修改. 因此本地集群必須是停止的,其它節點可以是在線或離線的.
這個子命令接偶數個參數,成對表示節點的舊名稱和新名稱.你必須指定節點的舊名稱和新名稱,因為其它停止的節點也可能在同一時間重命名.
同時停止所有節點來重命名也是可以的(在這種情況下,每個節點都必須給出舊名稱和新名稱)或一次停止一個節點來重命名(在這種情況下,每個節點只需要被告知其名句是如何變化的).
例如:
rabbitmqctl rename_cluster_node rabbit@misshelpful rabbit@cordelia
此命令來將節點名稱rabbit@misshelpful 重命名為rabbit@cordelia.
update_cluster_nodes {clusternode}
- clusternode
用于咨詢具有最新消息的節點.
指示已集群的節點醒來時聯系clusternode.這不同于join_cluster ,因為它不會加入任何集群 - 它會檢查節點已經以clusternode的形式存在于集群中了.
需要這個命令的動機是當節點離線時,集群可以變化.考慮這樣的情況,節點A和節點B都在集群里邊,這里節點A掉線了,C又和B集群了,然后B又離開了集群.當A醒來的時候,它會嘗試聯系B,但這會失敗,因為B已經不在集群中了.update_cluster_nodes -n A C 可解決這種場景.
force_boot
確保節點將在下一次啟動,即使它不是最后一個關閉的。通常情況下,當你關閉整個RabbitMQ 集群時,你重啟的第一個節點應該是最后一個下線的節點,因為它可以看到其它節點所看不到的事情. 但有時這是不可能的:例如,如果整個集群是失去了電力而所有節點都在想它不是最后一個關閉的.
在這種節點掉線情況下,你可以調用rabbitmqctl force_boot .這就告訴節點下一次無條件的啟動節點.在此節點關閉后,集群的任何變化,它都會丟失.
如果最后一個掉線的節點永久丟失了,那么你需要優先使用rabbitmqctl forget_cluster_node --offline, 因為它可以確保在丟失的節點上掌握的鏡像隊列得到提升。
例如:
rabbitmqctl force_boot
這可以強制節點下次啟動時不用等待其它節點.
sync_queue [-p vhost] {queue}
- queue
同步隊列的名稱
指示未同步slaves上的鏡像隊列自行同步.同步發生時,隊列會阻塞(所有出入隊列的發布者和消費者都會阻塞).此命令成功執行后,隊列必須是鏡像的.
注意,未同步隊列中的消息被耗盡后,最終也會變成同步. 此命令主要用于未耗盡的隊列。
cancel_sync_queue [-p vhost] {queue}
- queue
取消同步的隊列名稱.
指示同步鏡像隊列停止同步.
purge_queue [-p vhost] {queue}
- queue
要清除隊列的名稱.
清除隊列(刪除其中的所有消息).
set_cluster_name {name}
設置集群名稱. 集群名稱在client連接時,會通報給client,也可用于federation和shovel插件記錄消息的來源地. 群集名稱默認是來自在群集中的第一個節點的主機名,但可以改變。
例如:
rabbitmqctl set_cluster_name london
設置集群名稱為"london".
用戶管理
注意rabbitmqctl 管理RabbitMQ 內部用戶數據庫. 任何來自其它認證后端的用戶對于rabbitmqctl來說是不可見的.
add_user {username} {password}
- username
要創建的用戶名稱.
- password
設置創建用戶登錄broker的密碼.
rabbitmqctl add_user tonyg changeit
此命令用于指示RabbitMQ broker 創建一個擁有非管理權限的用戶,其名稱為tonyg, 初始密碼為changeit.
delete_user {username}
- username
要刪除的用戶名稱.
例如:
rabbitmqctl delete_user tonyg
此命令用于指示RabbitMQ broker刪除名為tonyg的用戶
change_password {username} {newpassword}
- username
要修改密碼的用戶名稱.
- newpassword
用戶的新密碼.
例如:
rabbitmqctl change_password tonyg newpass
此命令用于指定RabbitMQ broker將tonyg 用戶的密碼修改為newpass.
clear_password {username}
- username
要清除密碼的用戶名稱.
例如:
rabbitmqctl clear_password tonyg
此命令會指示RabbitMQ broker清除名為tonyg的用戶密碼.現在,此用戶不能使用密碼登錄(但可以通過SASL EXTERNAL登錄,如果配置了的話).
authenticate_user {username} {password}
- username
用戶的名稱.
- password
用戶的密碼.
例如:
rabbitmqctl authenticate_user tonyg verifyit
此命令會指示RabbitMQ broker以名稱為tonyg, 密碼為verifyit來進行驗證.
set_user_tags {username} {tag ...}
- username
要設置tag的用戶名稱.
- tag
用于設置0個,1個或多個tags.任何現有的tags都將被刪除.
例如:
rabbitmqctl set_user_tags tonyg administrator
此命令指示RabbitMQ broker用于確保tonyg 是administrator.當通過AMQP來登錄時,這沒有什么效果,但用戶通過其它的途經來登錄時,它可用來管理用戶,虛擬主機和權限(如使用管理插件).
rabbitmqctl set_user_tags tonyg
此命令會指示RabbitMQ broker刪除tonyg上的任何現有的tag.
list_users
列出用戶. 每個結果行都包含用戶名,其后緊跟用戶的tags.
例如:
rabbitmqctl list_users
此命令指示RabbitMQ broker列出所有用戶.
訪問控制
注意rabbitmqctl 會管理RabbitMQ的內部用戶數據庫. 無權限的用戶將不能使用rabbitmqctl.
add_vhost {vhost}
- vhost
要創建虛擬主機名稱.
創建一個虛擬主機.
例如:
rabbitmqctl add_vhost test
此命令指示RabbitMQ broker來創建一個新的名為test的虛擬主機.
delete_vhost {vhost}
- vhost
要刪除的虛擬主機的名稱.
刪除一個虛擬主機.
刪除一個虛擬主機,同時也會刪除所有交換機,隊列,綁定,用戶權限,參數和策略.
例如:
rabbitmqctl delete_vhost test
此命令指示RabbitMQ broker刪除名為test的虛擬主機.
list_vhosts [vhostinfoitem ...]
列出所有虛擬主機.
vhostinfoitem 參數用于標識哪些虛擬主機應該包含在結果集中.結果集中的列順序會匹配參數的順序.vhostinfoitem 可接受下面的值:
- name
虛擬主機的名稱.
- tracing
是否對虛擬主機啟用追蹤.
如果沒有指定vhostinfoitem 參數,那么會顯示虛擬主機名稱.
例如:
rabbitmqctl list_vhosts name tracing
此命令用于指示RabbitMQ broker顯示所有虛擬主機.
set_permissions [-p vhost] {user} {conf} {write} {read}
- vhost
授予用戶可訪問的虛擬機名稱,默認是/.
- user
可訪問指定虛擬主機的用戶名稱.
- conf
一個用于匹配用戶在哪些資源名稱上擁有配置權限的正則表達式
- write
一個用于匹配用戶在哪些資源名稱上擁有寫權限的正則表達式.
- read
一個用于匹配用戶在哪些資源名稱上擁有讀權限的正則表達式.
設置用戶權限.
例如:
rabbitmqctl set_permissions -p /myvhost tonyg "^tonyg-.*" ".*" ".*"
此命令表示RabbitMQ broker授予tonyg 用戶可訪問 /myvhost虛擬主機,并在資源名稱以"tonyg-"開頭的所有資源上都具有配置權限,并在所有資源上都擁有讀寫權限。
clear_permissions [-p vhost] {username}
- vhost
用于設置禁止用戶訪問的虛擬主機名稱,默認為/.
- username
禁止訪問特定虛擬主機的用戶名稱.
設置用戶權限.
例如:
rabbitmqctl clear_permissions -p /myvhost tonyg
此命令用于指示RabbitMQ broker禁止tonyg 用戶訪問/myvhost虛擬主機.
list_permissions [-p vhost]
- vhost
用于指定虛擬主機名稱,將會列出所有可訪問此虛擬主機的所有用戶名稱和權限.默認為/.
顯示虛擬機上權限.
例如:
rabbitmqctl list_permissions -p /myvhost
此命令指示RabbitMQ broker列出所有已授權訪問/myvhost 虛擬主機的用戶,同時也會列出這些用戶能在虛擬主機資源可操作的權限.注意,空字符串表示沒有任何授予的權限。
list_user_permissions {username}
- username
要顯示權限的用戶名稱.
列出用戶權限.
例如:
rabbitmqctl list_user_permissions tonyg
此命令指示RabbitMQ broker列出tonyg可授權訪問的所有虛擬主機名稱,以及在這些虛擬主機上的操作.
參數管理
RabbitMQ的某些特性(如聯合插件)是動態控制的. 每個參數都是與特定虛擬主機相關的組件名稱, name和value構成的. 組件名稱和name都是字符串,值是Erlang term. 參數可被設置,清除和顯示.通常你可以參考文檔來了解如何設置參數.
set_parameter [-p vhost] {component_name} {name} {value}
設置一個參數.
- component_name
要設置的組件名稱.
- name
要設置的參數名稱.
- value
要設置的參數值,作不JSON項。在多數shells中,你更喜歡將其引起來.
例如:
rabbitmqctl set_parameter federation local_username '"guest"'
此命令用于在默認虛擬主機上設置federation 組件的local_username 參數值"guest".
clear_parameter [-p vhost] {component_name} {key}
清除參數.
- component_name
要清除參數的組件名稱.
- name
要清除的參數名稱.
例如:
rabbitmqctl clear_parameter federation local_username
此命令用于清除默認虛擬主機上的federation 組件的local_username 參數值.
list_parameters [-p vhost]
列出虛擬主機上的所有參數.
示例:
rabbitmqctl list_parameters
此命令用于列出默認虛擬主機上的所有參數.
策略管理
策略用于在集群范圍的基礎上用于控制和修改隊列和交換機的行為. 策略應用于虛擬主機,由name, pattern, definition或可選的priority組成. 策略可被設置,清除和列舉.
set_policy [-p vhost] [--priority priority] [--apply-to apply-to] {name} {pattern} {definition}
設置策略.
- name
策略名稱.
- pattern
正則表達式, 匹配要應用的資源
- definition
策略的定義,JSON形式.在大多數shells中,你很可能需要引用這個
- priority
策略的整數優先級. 數字越高則優先級越高.默認是0.
- apply-to
策略適用的對象類型,其值可為 "queues", "exchanges" 或 "all".默認是"all".
例如:
rabbitmqctl set_policy federate-me "^amq." '{"federation-upstream-set":"all"}'
此命令在默認虛擬主機上設置策略為federate-me,這樣內建的交換器將進行聯合.
clear_policy [-p vhost] {name}
清除策略.
- name
要清除的策略名稱.
例如:
rabbitmqctl clear_policy federate-me
此命令來清除默認虛擬主機上的federate-me 策略.
list_policies [-p vhost]
顯示虛擬主機上的所有策略.
例如:
rabbitmqctl list_policies
此命令會顯示默認虛擬主機上的所有策略.
服務器狀態
服務器狀態查詢查詢服務器返回一個結果以制表符分隔的列表. 某些查詢(list_queues, list_exchanges, list_bindings, 和 list_consumers) 接受一個可選的vhost 參數. 如果這個參數出現了,那么它必須指定在查詢的后面.
list_queues, list_exchanges and list_bindings 命令接受一個可選的虛擬主機參數以顯示其結果.默認值為"/".
list_queues [-p vhost] [queueinfoitem ...]
返回隊列的詳細信息. 如果無-p標志,將顯示/虛擬主機上的隊列詳情."-p" 標志可用來覆蓋此默認值.
queueinfoitem 參數用于指示哪些隊列信息項會包含在結果集中.結果集的列順序將匹配參數的順序.queueinfoitem 可以是下面列表中的任何值:
- name
非ASCII字符的隊列名稱.
- durable
服務器重啟后,隊列是否能幸存.
- auto_delete
不再使用時,是否需要自動刪除隊列.
- arguments
隊列參數.
- policy
應用到隊列上的策略名稱.
- pid
關聯隊列的Erlang進程ID.
- owner_pid
表示隊列專用所有者的代表連接的Erlang進程ID.如果隊列是非專用的,此值將為空.
- exclusive
True:如果隊列是專用的(即有owner_pid), 反之false
- exclusive_consumer_pid
表示此channel的專用消費者訂閱到此隊列的Erlang進程Id. 如果沒有專用消費者,則為空.
- exclusive_consumer_tag
專用消費者訂閱到此隊列的Consumer tag.如果沒有專用消費者,則為空.
- messages_ready
準備分發給客戶端的消息數目.
- messages_unacknowledged
分發到客戶端但尚未應答的消息數目.
- messages
準備分發和未應答消息的總和(隊列深度).
- messages_ready_ram
駐留在ram中messages_ready的消息數目.
- messages_unacknowledged_ram
駐留在ram中messages_unacknowledged的消息數目.
- messages_ram
駐留在ram中的消息總數.
- messages_persistent
隊列中持久化消息的數目(對于瞬時隊列總是0).
- message_bytes
隊列中所有消息體的大小總和.這不包括消息屬性(包括headers) 或任何開銷(overhead)。
- message_bytes_ready
類似于message_bytes ,但只統計準備投遞給clients的那些消息.
- message_bytes_unacknowledged
類似于message_bytes ,但只統計那些已經投遞給clients但還未應答的消息
- message_bytes_ram
類似于message_bytes ,但只統計那些在RAM中的消息
- message_bytes_persistent
類似于message_bytes ,但只統計那些持久化的消息
- head_message_timestamp
如果存在,只顯示隊列中第1個消息的timestamp屬性. 消息的時間戳只出現在分頁情況下.
- disk_reads
從隊列啟動開如,已從磁盤上讀取該隊列的消息總次數.
- disk_writes
從隊列啟動開始,已向磁盤隊列寫消息總次數.
- consumers
消費者數目.
- consumer_utilisation
時間分數(0.0與1.0之間),隊列可立即向消費者投遞消息. 它可以小于1.0,如果消費者受限于網絡堵塞或預提取數量.
- memory
與隊列相關的Erlang進程消耗的內存字節數,包括棧,堆以及內部結構.
- slave_pids
如果隊列是鏡像的,這里給出的是當前slaves的IDs.
- synchronised_slave_pids
如果隊列是鏡像的,當前slaves的IDs是master同步的- 即它們可在無消息丟失的情況下,接管master.
- state
隊列狀態.正常情況下是'running', 但如果隊列正在同步也可能是"{syncing, MsgCount}". 處于集群下的節點如果掉線了,隊列狀態交顯示'down' (大多數queueinfoitems 將不可用).
如果沒有指定queueinfoitems,那么將顯示隊列名稱和隊列深度.
例如:
rabbitmqctl list_queues -p /myvhost messages consumers
此命令顯示了/myvhost虛擬主機中每個隊列的深度和消費者數目.
list_exchanges [-p vhost] [exchangeinfoitem ...]
返回交換器細節.如果沒有指定"-p"選項,將返回 / 虛擬主機的細節. "-p" 選項可用來覆蓋默認虛擬主機.
exchangeinfoitem 參數用來表示哪些交換器信息要包含在結果中. 結果集中列的順序將與參數順序保持一致. exchangeinfoitem 可接受下面的列表中任何值:
- name
交換器名稱.
- type
交換器類型(如[direct, topic, headers, fanout]).
- durable
當服務器重啟時,交換器是否能復活.
- auto_delete
當不再使用時,交換器是否需要自動刪除.
- internal
交換器是否是內部的,即不能由client直接發布.
- arguments
交換器參數
- policy
- 應用到交換器上的策略名稱.
如果沒有指定exchangeinfoitems,那么將會顯示交換器類型和類型
例如:
rabbitmqctl list_exchanges -p /myvhost name type
此命令會顯示/myvhost中每個交換器的名稱和類型.
list_bindings [-p vhost] [bindinginfoitem ...]
返回綁定細節.默認情況下返回的是 / 虛擬主機上的綁定詳情.可使用"-p" 標記來覆蓋默認虛擬主機.
bindinginfoitem 參數用來表示結果中包含哪些綁定信息. 結果集中列的順序將匹配參數的順序.bindinginfoitem可接受下面列表的任意值:
- source_name
綁定中消息來源的名稱. C中非ASCII轉義字符.
- source_kind
綁定中消息來源的類別.當前總是exchange. C中非ASCII轉義字符.
- destination_name
綁定中消息目的地名稱.C中非ASCII轉義字符.
- destination_kind
綁定中消息目的地的種類. C中非ASCII轉義字符.
- routing_key
綁定的路由鍵,C中非ASCII轉義字符.
- arguments
綁定參數.
如果沒有指定bindinginfoitems,將會顯示所有上述條目.
例如:
rabbitmqctl list_bindings -p /myvhost exchange_name queue_name
此命令來顯示/myvhost虛擬主機上綁定的交換器名稱和隊列名稱.
list_connections [connectioninfoitem ...]
返回TCP/IP連接統計.
connectioninfoitem 參數用來表示在結果中包含哪些連接信息. 結果集中列的順序將匹配參數的順序. connectioninfoitem可接受下面列表的任意值:
- pid
與連接相關的Erlang進程ID.
- name
連接的可讀名稱.
- port
服務器端口.
- host
返回反向DNS獲取的服務器主機名稱,或 IP地址(反向DNS解析失敗) 或者未啟用.
- peer_port
Peer 端口.
- peer_host
- 返回反向DNS獲取的Peer主機名稱,或 IP地址(反向DNS解析失敗) 或者未啟用.
- ssl
用Boolean來表示連接是否是SSL的.
- ssl_protocol
SSL 協議(如. tlsv1)
- ssl_key_exchange
SSL key exchange 算法 (如 rsa)
- ssl_cipher
SSL cipher 算法 (如aes_256_cbc)
- ssl_hash
SSL hash 函數 (如 sha)
- peer_cert_subject
peer的 SSL 安全證書的主體, RFC4514形式.
- peer_cert_issuer
peer的 SSL安全證書的發行者, RFC4514 形式.
- peer_cert_validity
peer的SSL安全證書的有效期.
- state
連接狀態(可為[starting, tuning, opening, running, flow, blocking, blocked, closing, closed]其中一個).
- channels
使用連接的channel數。
- protocol
使用的AMQP協議版本(當前是{0,9,1} 或{0,8,0}). 注意,如果client請求的是AMQP 0-9 連接, 我們會視為AMQP 0-9-1.
- auth_mechanism
使用的SASL認證機制,如PLAIN.
- user
與連接相關的用戶名
- vhost
虛擬主機名稱,C中非ASCII轉義字符.
- timeout
連接超時/協商的心跳間隔,秒為單位.
- frame_max
最大 frame 大小(字節).
- channel_max
- 此連接上channel的最大數目.
- client_properties
連接建立期間由client發送的信息屬性.
- recv_oct
Octets已收到.
- recv_cnt
Packets 已收到.
- send_oct
Octets 發送.
- send_cnt
Packets 發送.
- send_pend
發送隊列大小.
- connected_at
連接建立的日期和時間,當作timestamp.
如果沒有connectioninfoitems, 那么會顯示user, peer host, peer port,流量控制和內存塊狀態的時間
例如:
rabbitmqctl list_connections send_pend port
此命令會顯示發送隊列的大小以及第個連接的服務器端口.
list_channels [channelinfoitem ...]
返回所有當前channel上的信息,邏輯容器執行大部分 AMQP命令.這將包含最初AMQP連接的部分,以及不同插件和其它擴展創建的channels.
channelinfoitem 參數用來表示在結果集中包含哪些channel信息.結果集中列的順序將匹配參數的順序. channelinfoitem 可接受下面列表中的任何一個參數:
- pid
與連接相關的Erlang進程ID.
- connection
channel所屬的連接Erlang進程ID.
- name
channel的可讀名稱.
- number
channel的數目,在一個連接中,它有唯一的標識符.
- user
與channel相關的用戶名稱.
- vhost
channel操作的虛擬主機.
- transactional
True:如果channel處于事務模式,其它情況為false.
- confirm
True:如果channel是確認模式,其它情況為false.
- consumer_count
在channel中接收消息的邏輯AMQP消費者數目.
- messages_unacknowledged
在channel中消息已投遞但還未應答的消息數目.
- messages_uncommitted
在channel中已收到消息但還沒有提交事務的消息個數.
- acks_uncommitted
確認收到一個還未提交的事務數。
- messages_unconfirmed
尚未確認已發布消息的數目。在通道不在確認模式下時,這將是0。
- prefetch_count
新消費者QoS預提取限制, 0表示無上限.
- global_prefetch_count
整個channel QoS預提取限制, 0表示無上限.
如果沒有指定channelinfoitems,那么將顯示pid, user, consumer_count,messages_unacknowledged.
例如:
rabbitmqctl list_channels connection messages_unacknowledged
此命令會顯示每個channel中連接進程和未應答消息的數目.
list_consumers [-p vhost]
列舉消費者, 即訂閱隊列的消息流. 每行將打印出由制表符分隔的已訂閱隊列的名稱,創建并管理訂閱的channel進程的標識,channel中訂閱的consumer tag唯一標識符, boolean值表示投遞到此消費者的消息是否需要應答,整數值表示表示預提取限制(為0表示無限制), 以及關于此消費者的任何其它參數.
status
顯示 broker 狀態信息,如當前Erlang節點上運行的應用程序, RabbitMQ 和 Erlang 的版本信息, OS 名稱, 內存和文件描述符統計信息. (查看cluster_status 命令來找出那些節點是集群化的以及正在運行的.)
例如:
rabbitmqctl status
此命令顯示了RabbitMQ broker的相關信息.
environment
顯示每個運行程序環境中每個變量的名稱和值.
report
為所有服務器狀態生成一個服務器狀態報告,輸出應該重定向到一個文件.
例如:
rabbitmqctl report > server_report.txt
此命令創建了一個服務器報告,可將它附著在支持請求的電子郵件中.
eval {expr}
執行任意Erlang表達式.
例如:
rabbitmqctl eval 'node().'
此命令用于返回rabbitmqctl連接的節點名稱
雜項
close_connection {connectionpid} {explanation}
- connectionpid
要關閉的與連接相關的Erlang進程ID.
- explanation
解釋字符串.
指示broker關閉與Erlang進程id相關的連接(可通過list_connections 命令查看), 通過為連接客戶端傳遞解釋字符串(作為AMQP連接關閉協議的一部分).
例如:
rabbitmqctl close_connection "<rabbit@tanto.4262.0>" "go away"
此命令指示RabbitMQ broker關閉與Erlang 進程id<rabbit@tanto.4262.0>相關聯的連接, 同時向客戶端傳遞go away字符串.
trace_on [-p vhost]
- vhost
要開啟追蹤的虛擬主機的名稱.
開啟追蹤.注意,追蹤狀態不是持久化的; 如果服務器重啟,追蹤狀態將會丟失.
trace_off [-p vhost]
- vhost
要停止追蹤的虛擬主機名稱.
停止追蹤.
set_vm_memory_high_watermark {fraction}
- fraction
當一個浮點數大于或等于0時,會觸發流量控制新內存閾值部分。
set_vm_memory_high_watermark absolute {memory_limit}
- memory_limit
流程控制觸發的新內存限制, 以字節來表示大于或等于0的整數或以字符串和內存單位來表示(如 512M或1G). 可用的單位是: k, kiB: kibibytes (2^10 bytes) M, MiB: mebibytes (2^20) G, GiB: gibibytes (2^30) kB: kilobytes (10^3) MB: megabytes (10^6) GB: gigabytes (10^9)
set_disk_free_limit {disk_limit}
- disk_limit
以整數或字符串單位的可用磁盤下限限制(查看vm_memory_high_watermark), 如 512M or 1G. 一旦可用磁盤空間達到這個限制,就會設置磁盤報警.
set_disk_free_limit mem_relative {fraction}
- fraction
相對于整個可用內存的限制,其值為非負浮點數. 當值小于1.0時是很危險的,應該謹慎使用.
posted @
2016-07-30 16:52 胡小軍 閱讀(12794) |
評論 (0) |
編輯 收藏
介紹
像RabbitMQ這樣的數據服務經常有許多的可調參數.某些配置對于開發環境來說是意義的,但卻不適合產品環境. 單個配置不能滿足每種使用情況. 因此,在進入產品環境時,評估配置是很重要的. 這就是本指南提供幫助的目的.
虛擬主機,用戶,權限
Virtual Hosts
在單租戶環境中,例如,當RabbitMQ在產品環境中只致力于為某單個系統服務時,使用默認虛擬主機 (/)是非常好的.
在多租戶環境中,為每個租戶/環境使用單獨的虛擬主機,如:project1_development, project1_production, project2_development, project2_production, 等等.
用戶
在產品環境中,刪除默認用戶(guest). 默認情況下,默認用戶只能通過本地來連接, 因為它有眾所周的憑證.為了不啟用遠程連接,可考慮使用帶有administrative權限和生成密碼的獨立用戶來代替
強烈建議在每個程序中使用單獨的用戶,例如,如果你有一個mobile app, 一個Web app, 和一個數據聚合系統, 你最好有3個獨立的用戶. 這會使許多事情變得更簡單:
- 使 client 連接與程序相關聯
- 使用細粒度的權限
- 憑據翻滾(如. 周期性地或遭到破壞的情況下)
如果有許多相同應用程序的實例,有一個更好安全性權衡(每一個實例的憑據)和方便的配置(共享一些或所有實例之間的一組憑據)。物聯網的應用涉及很多客戶執行相同或相似的功能,有固定的IP地址,它可以使用X509證書或源IP地址范圍驗證。
資源限制
內存
默認情況下, RabbitMQ會使用可用RAM的40%. 這專門針對于那些運行RabbitMQ的節點,通常情況下,提高此限制是合理的. 然而,應注意的是,操作系統和文件系統的緩存也需要內存來運行。如果不這樣做,會由于操作系統交換導致嚴重的吞吐量下降,甚至導致操作系統會終止RabbitMQ過程的運行。
- 至少有128 MB
- 當RAM達到4GB時,可配置為75%的RAM限制
- 當RAM達到4GB-8GB時,可配置為80%的RAM限制
- 當RAM達到8GB-16GB時,可配置為85%的RAM限制
- 當RAM大于16GB時,可配置為90%的RAM限制
高于0.9的值是很危險的,不推薦配置
可用磁盤空間
必要的可用磁盤空間可防止disk space alarms.(磁盤空間報警) .默認情況下,RabbitMQ始終需要 50 MiB的可用磁盤空間.在大多數Linux發行者,根據開發者的經驗,可將放置到小分區的/var 目錄下. 然而,對于產品環境來說,這不是一個推薦值, 因為它們可能明顯的更高的RAM 限制. 下面是一些基本的指導方針,如何確定有多少空閑磁盤空間是推薦的: - 至少有2 GB
- 當限制為1到8GB的RAM時,可配置為RAM限制的50%
- 當限制為8到32GB的RAM時,可配置為RAM限制的40%
- 當限制超過32GB的RAM時,可配置為RAM限制的30%
rabbit.disk_free_limit 配置可通過 {mem_relative, N}來完成,使其相對于RAM限制的百分比來計算. 例如, 使用{mem_relative, 0.5} 設為50%, {mem_relative, 0.25}設為25%等等.
打開文件句柄限制
操作系統限制了并發打開的文件句柄的最大數量,其中包括網絡套接字。確保您的限制設置得足夠高,以允許預期數量的并發連接和隊列。
對于有效RabbitMQ用戶,確保你的環境允許至少50K的打開文件描述符,包括開發環境。
作為經驗法則,并發連接數的95%乘以2再加上隊列的總數可以計算出打開文件句柄限制( multiple the 95th percentile number of concurrent connections by 2 and add total number of queues to calculate recommended open file handle limit). 值高于500K也是恰當地,它不會消耗太多的硬件資源,因此建議在生產環境中設置. 查看Networking guide 來了解更多信息. 安全注意事項
用戶和權限
查看vhosts, users, 和 證書章節.
Erlang Cookie
在Linux 和BSD 系統中, 有必要限制只有運行RabbitMQ和rabbitmqctl工具的用戶才能訪問Erlang cookie. TLS
雖然RabbitMQ試圖提供一個默認的安全TLS 配置 (如.SSLv3是禁用的), 我們推薦評估TLS 版本和密碼套件. 請參考TLS guide 了解更多信息. 網絡配置
自動連接恢復
某些client libraries, 例如 Java, .NET, 和 Ruby, 在網絡失敗后,支持自動連接恢復.如果client提供了這種功能,建議使用它來代替你自己的恢復機制. 集群化考慮
集群大小
當確定集群大小時,需要重點考慮下面的幾個因素:
- 希望的吞吐量
- 希望的復制( mirrors的數目)
- 數據局部性
因為客戶端可以連接到任何節點,RabbitMQ可能需要進行集群間消息路由和內部操作。嘗試使消費者和生產者連接到同一個節點,如果可能的話:這將減少節點間的流量。 使消費者連接到持有隊列的master上(可使用HTTP API進行推斷),也是有幫助的.當考慮到數據局部性時,總的集群吞吐量可以達到不平凡的量。 對于大多數環境中,鏡像超過一半的群集節點是足夠的。建議使用一個奇數的節點(3,5,等等)的集群。
分區處理策略
posted @
2016-07-30 16:47 胡小軍 閱讀(1658) |
評論 (0) |
編輯 收藏
原文:
http://www.rabbitmq.com/memory.html
RabbitMQ服務器在啟動時以及abbitmqctl set_vm_memory_high_watermark fraction 執行時,會檢查計算機的RAM總大小. 默認情況下下, 當 RabbitMQ server 的使用量超過RAM的40% ,它就會發出內存警報,并阻塞所有連接. 一旦內存警報清除 (如,服務器將消息轉存于磁盤,或者將消息投遞給clients),服務又地恢復.
默認內存閥值設置為已安裝RAM的40%. 注意這并不會阻止RabbitMQ server使用內存量超過40%, 它只是為了壓制發布者. Erlang的垃圾回收器最壞情況下,可使用配置內存的2倍(默認情況下t, RAMr的80%). 因此強制建議開啟OS swap或page files .
32位架構傾向于每一個進程有2GB的內存限制. 64位架構的一般實現(i.e. AMD64 和 Intel EM64T) 只允許每個進程為256TB. 64-位 Windows 限制為8TB. 但是,請注意,即使是64位操作系統下,一個32位的過程往往只有一個2GB的最大地址空間。
配置內存閥值
[{rabbit, [{vm_memory_high_watermark, 0.4}]}].
默認值0.4 代表的是已安裝RAM的 40% , 有時候還更小.如:在 32位平臺中,如果你安裝有4GB RAM , 4GB 的40% 是 1.6GB, 但是 32-位 Windows 正常情況下限制進程為2GB,因此實際閥值是2GB的40% (即820MB).
另外, 內存閥值也可以設置為絕對值. 下面的例子將閥值設為了1073741824 字節 (1024 MB):
[{rabbit, [{vm_memory_high_watermark, {absolute, 1073741824}}]}].
同例, 也可使用內存單位:
[{rabbit, [{vm_memory_high_watermark, {absolute, "1024MiB"}}]}].
如果絕對上限大于了安裝的RAM可用的虛擬地址空間, 閥值上限會略小.
當RabbitMQ服務器啟動時,內存限制將追加到RABBITMQ_NODENAME.log 文件中:
=INFO REPORT==== 29-Oct-2009::15:43:27 === Memory limit set to 2048MB.
內存限制也可以使用rabbitmqctl status命令查詢.
其閥值也可以在broker運行時,通過rabbitmqctl set_vm_memory_high_watermark fraction 命令或 rabbitmqctl set_vm_memory_high_watermark absolute memory_limit 命令修改. 內存單位也可以在命令中使用. 此命令會在broker重啟后生效. 當執行此命令時,內存限制可能會改變熱插拔RAM,而不會發生報警,這是因為需要全部數量的系統RAM.
禁止所有發布
其值為0時,會立即觸發報警并禁用所有發布 (當需要禁用全局發布時,這可能是有用的); use rabbitmqctl set_vm_memory_high_watermark 0.
限制的地址空間
當在64位操作系統中運行32位 Erlang VM時,(or a 32 bit OS with PAE), 可用地址內存是受限制的. 服務器探測到后會記錄像下邊的日志消息:
=WARNING REPORT==== 19-Dec-2013::11:27:13 === Only 2048MB of 12037MB memory usable due to limited address space. Crashes due to memory exhaustion are possible - see http://www.rabbitmq.com/memory.html#address-space
內存報警系統是不完美的.雖然停止發布通常會防止任何進一步的內存使用,但可能有其他東西繼續增加內存使用。通常情況下,當這種情況發生時,物理內存耗盡,操作系統將開始交換。但是當運行一個有限的地址空間,超過限制的運行會導致虛擬機崩潰。
因此強制建議在在64位操作系統上運行64位的Erlang VM.
配置分頁閾值
在broker達到最高水位阻塞發布者之前,它會嘗試將隊列內容分頁輸出到磁盤上來釋放內存. 持久化和瞬時消息都會分頁輸出 (已經在磁盤上的持久化消息會被趕出內存).
默認情況下,在達最高水位的50%時,就會發生這種情況. (即,默認最高水位為0.4, 這會在內存使用達到20%時就會發生). 要修改此值,可修改vm_memory_high_watermark_paging_ratio 配置的0.5默認值. 例如:
[{rabbit, [{vm_memory_high_watermark_paging_ratio, 0.75}, {vm_memory_high_watermark, 0.4}]}].
上面的配置表示在內存使用達到30%時,就會啟動,40%的時候會阻塞發布者.
也可以將vm_memory_high_watermark_paging_ratio 值設為大于1.0的值.在這種情況下,隊列不會把它的內容分頁到磁盤上.如果這引起了內存報警關閉,那么生產者會如上面預期的一樣被阻塞.
未確認的平臺
如果RabbitMQ服務器不能識別你的系統,它將在RABBITMQ_NODENAME.log 文件中追加警告.
然后它會假設安裝了超過了1GB的RAM:
=WARNING REPORT==== 29-Oct-2009::17:23:44 === Unknown total memory size for your OS {unix,magic_homebrew_os}. Assuming memory size is 1024MB.
在這種情況下,vm_memory_high_watermark 配置值假設為1GB RAM. 在 vm_memory_high_watermark 默認設為 0.4的情況下, RabbitMQ的內存閥值設為了410MB, 因此當RabbitMQ使用了多于410M內存時,它會阻塞生產者.因此當RabbitMQ不能識別你的平臺時,如果你實際有8GB RAM,并且你想讓RabbitMQ內存使用量超過3GB阻塞生產者,你可以設置vm_memory_high_watermark為3.
posted @
2016-07-30 15:05 胡小軍 閱讀(7961) |
評論 (0) |
編輯 收藏