配置隊列需要配置哪些參數

A. 線程池-參數篇：2.隊列

多線程環境中，通過隊列可以很容易實現線程間數據共享，比如經典的「生產者」和「消費者」模型中，通過隊列可以很便利地實現兩者之間的數據共享；同時作為BlockingQueue的使用者，我們不需要關心什麼時候需要阻塞線程，什麼時候需要喚醒線程，因為這一切BlockingQueue的實現者都給一手包辦了。

基於數組的阻塞隊列實現，在ArrayBlockingQueue內部，維護了一個定長數組，以便緩存隊列中的數據對象，另外還保存著兩個整形變數，分別標識著隊列的頭部和尾部在數組中的位置。

ArrayBlockingQueue在生產者放入數據和消費者獲取數據，都是共用同一個鎖對象，由此也意味著兩者無法真正並行運行，而在創建ArrayBlockingQueue時，我們還可以控制對象的內部鎖是否採用公平鎖，默認採用非公平鎖。

按照實現原理來分析，ArrayBlockingQueue完全可以採用分離鎖，從而實現生產者和消費者操作的完全並行運行。

基於鏈表的阻塞隊列，其內部也維持著一個數據緩沖隊列（由一個鏈表構成），當生產者往隊列中放入一個數據時，隊列會從生產者手中獲取數據，並緩存在隊列內部，而生產者立即返回；只有當隊列緩沖區達到最大值緩存容量時（LinkedBlockingQueue可以通過構造函數指定該值），才會阻塞生產者隊列，直到消費者從隊列中消費掉一份數據，生產者線程會被喚醒，反之對於消費者這端的處理也基於同樣的原理。

對於生產者端和消費者端分別採用了獨立的鎖來控制數據同步，這也意味著在高並發的情況下生產者和消費者可以並行地操作隊列中的數據，以此來提高整個隊列的並發性能。

ArrayBlockingQueue和LinkedBlockingQueue間還有一個明顯的不同之處在於，前者在插入或刪除元素時不會產生或銷毀任何額外的對象實例，而後者則會生成一個額外的Node對象。這在長時間內需要高效並發地處理大批量數據的系統中，其對於GC的影響還是存在一定的區別。如果沒有指定其容量大小，LinkedBlockingQueue會默認一個類似無限大小的容量（Integer.MAX_VALUE），這樣的話，如果生產者的速度一旦大於罩伍消費者的速度，也許還沒有等到隊列滿阻塞產生，系統內存就有可能已被消耗殆盡了。

ArrayBlockingQueue和LinkedBlockingQueue是兩個最普通也是最常用的阻塞隊列，一般情況下，在處理多線程間的生產者消費者問題，使用這兩個類足以。

DelayQueue中的元素只有當其指定的延遲時間到了，才能夠從隊列中獲取到該元素。DelayQueue是一個沒有大小限制的隊列，因此往隊列中插入數據的操作（生產者）永遠不會被阻塞，而只有獲取數據的操作（消費者）才會被阻塞。

DelayQueue用於放置實現了Delayed介面的對象，其中的對象只能在其到期時才能從隊列中取走。這種隊列是有序的，即隊頭對象的延遲到期時間最長。注意：不能將null元素放置到這種隊列中。

Delayed 是一種混合風格的介面，用來標記那些應該在給定延遲時間之後執行的對象。Delayed擴展了Comparable介面，比較的基準為延時的時間值，Delayed介面的實現類getDelay的返回值應為固定宴悶沖值（final）。DelayQueue內部是使用PriorityQueue實現的。

考慮以下場景：

一種笨笨的辦法就是，使用一個後台線程，遍歷所有對象，挨個檢查。這種笨笨的辦法簡單好用，但是對象數量過多時，可能存在性能問題，檢查間隔時間不好設置，間隔時間過大，影響精確度，多小則存在效率問題。而且做不到按超時的時間順序處理。

這場景，使用DelayQueue最適合了，詳情查看 DelayedQueue學習筆記 ; 精巧好用的DelayQueue

基於優先順序的阻塞隊列（優先順序的判斷通過構造函數傳入的Compator對象來決定），需要注意PriorityBlockingQueue並不會阻塞數據生產者晌殲，而只會在沒有可消費的數據時，阻塞數據的消費者。

使用時，若生產者生產數據的速度快於消費者消費數據的速度，隨著長時間的運行，可能會耗盡所有的可用堆內存空間。在實現PriorityBlockingQueue時，內部控制線程同步的鎖採用的是公平鎖。

SynchronousQueue是一個內部只能包含零個元素的隊列。插入元素到隊列的線程被阻塞，直到另一個線程從隊列中獲取元素。同樣，如果線程嘗試獲取元素並且當前沒有線程在插入元素，則該線程將被阻塞，直到有線程將元素插入隊列

聲明一個SynchronousQueue有公平模式和非公平模式，區別如下:

參考： java多線程-工具篇-BlockingQueue
12. SynchronousQueue

B. CDH中yarn的動態資源池的相關配置

CDH Yarn資源隊列劃分管理
場景：根據不同項目或不同用戶，對yarn資源隊列進行劃分，達到資源管控，任務管控的目的
CDH版本：5.x
配置：
1 yarn資源隊列參數設置：
(1)yarn.scheler.fair.user-as-default-queue false

解釋：當設置為 true 時，如果未指定池名稱，Fair Scheler 將會使用用戶名作為默認的池名稱。當設置為 false 時，所有應用程序都在一個名為 default 的共享池中運行。設置成false是為了不根據用戶名而自動分配資源池。

Fair Scheler：yarn的公平調度器，對全局資源和對所有的應用作業都均勻分配的資源分配方法。默認情況下，它是基於內存來安排公平調度策略，也可以配置成為同時基於內存和CPU來進行調度。總的來說，它是一種基於內存，給集群中所提交的應用程序分配資源的調度器。

(2)yarn.scheler.fair.allow-undeclared-pools false

解釋：設置為 true 時，將使用默認設置創建在應用程序中指定但未明確配置的池。設置為 false 時，將在名為 default 的池中運行應用程序指定的未明確配置的池。此設置適用於應用程序明確指定某個池時以及應用程序運行所在的池的名稱為與該應用程序關聯的用戶名的情況。

默認是true，允許創建未定義的資源池。當用戶提交了一個作業，指定的隊列不存在的時候，會自動創建出這個不存在的隊列。設置成false，如果任務中指定了一個未定義的資源池，那麼這個資源池將不會被創建，該任務會被分配到默認的資源池中，default。

修改完配置重啟服務
2 CDH 動態資源隊列配置

如圖，第一步我們劃分了2個資源池：、
(1)root.default:默認池，沒有劃分資源池的用戶會提交到default資源池

權重定義了資源池之間分配資源的比例，目前集群中的default資源池和users資源池的權重各為1,那麼集群中的資源會將50%分配給default，50%分配給users，但是這里的資源分配不是一個靜態的概念，假如users中沒有任務在運行，那麼default資源池是允許使用超過50%的資源的，且資源池配置允許在線修改，修改後不需要重啟yarn，因為RM會周期性的讀取資源池的配置信息

設置default資源池的調度演算法：使用DRF，即根據內存和CPU進行資源調度

yarn.scheler.fair.preemption解釋：啟用後，如果在某些時間段圓戚未達到池的最小共享，Fair Scheler 可以優先選取其他池中的應用程序。優先權可保證生產應用程序不缺乏資源，同時還可使群集用棗鍵於實驗和研究應用程序。為盡量減少計算資源浪費，Fair Scheler 會優先選取最近啟動的應用程序。

該項不建議開啟。
Yarn的資源搶占本身就具有一定的資源開銷，並且如果開啟了資源搶占，對於長時間運行的任務容易出現延遲的情況。所以在此也建議配置隊列時，要將長時間運行任務和執行時間較短的任務放在不同的隊列中。同時對於隊列的maxResource，可以適當的配置大些，這樣即使不打開搶占，RM也是可以將一個隊列的已經運行完成的資源回收分配給別的隊列。凳腔巧從而達到提高資源的利用率。

解釋：
yarn.acl.enable：指定是否應檢查管理 ACL 中指定的用戶和組執行管理操作的授權。
yarn.admin.acl：確定哪些用戶和組可在任何池中提交和中止應用程序以及可以對 ResourceManager 角色發出命令的 ACL。

重啟服務

添加was用戶資源池

資源池的提交控制訪問和管理控制訪問的配置會自動繼承到子隊列中，比如在root資源池下的提交控制訪問中配置了用戶was，那麼即使root.test的提交用戶訪問中配置是空，用戶was也可以向隊列test中提交yarn應用程序。

計劃模式：可以根據不同時間段使用不同的資源池配置，合理使用集群的縱向資源

創建新的計劃規則：

配置完計劃模式，資源池會有多套配置，如下

配置完不同時間段使用的配置集後，修改各配置集的資源分配。例如streaming資源池在默認的配置集下，權重是2，使用的集群的資源佔50%,但是在night配置集下配置的權重是1，使用的集群的資源佔33%。而nigth配置集是在每天晚上8點到第二天早上六點時間段生效的。

放置規則：控制任務使用資源池的規則，即任務會根據以下的規則放到對應的資源池中執行，不需要自定義配置，在提交任務的時候顯示的指定隊列即可

用戶限制：控制用戶可以提交的最大應用程序數量，可以統一配置，也可以單獨給某個用戶配置

C. Redis怎麼配置JedisPool參數

edis之如何配置jedisPool參數

JedisPool的配置參數很大程度上依賴於實際應用需求、軟硬體能力，JedisPool的配置參數大部分是由JedisPoolConfig的對應項來賦值的。

maxActive：擾啟控制一個pool可分配多少個jedis實例，通過pool.getResource()來獲取；如果賦值為-1，則表示
不限制；如果pool已經分配了maxActive個jedis實例，則此時pool的狀態就成exhausted了，在JedisPoolConfig

maxIdle：控制一個pool最多有多少個狀態為idle的jedis實例；

whenExhaustedAction：表示當pool中的jedis實例都被allocated完時，pool要採取的操作；默認有三種
WHEN_EXHAUSTED_FAIL（表示無jedis實例時，直接拋出NoSuchElementException）、
WHEN_EXHAUSTED_BLOCK（則表示阻塞住，或者達到maxWait時拋出JedisConnectionException）、
WHEN_EXHAUSTED_GROW（則表示新建一個jedis實例，也就說設置的maxActive無用）；

maxWait：表示當borrow一個jedis實例時，最大的等待時間，如果超過等待時間，則直接拋出JedisConnectionException；

testOnBorrow：在borrow一個jedis實例時，是否提前進行alidate操作；如果為true，則昌李扮得到的jedis實例均是可用的；

testOnReturn：在return給pool時，是否提前進行validate操作；

testWhileIdle：如果為true，表示有一個idle object evitor線程對idle
object進行掃描，如果validate失敗，此object會被從pool中drop掉；這一項只有在
timeBetweenEvictionRunsMillis大於0時才有意義；

timeBetweenEvictionRunsMillis：表示idle object evitor兩次掃描之間要sleep的毫秒數；

numTestsPerEvictionRun：表示idle object evitor每次掃描的最多的對象數；

minEvictableIdleTimeMillis：表示一個對象至少停留在idle狀態的最短時間，然後才能被idle object evitor掃描並驅逐；這一項只有在timeBetweenEvictionRunsMillis大於0時才有意義；

：在minEvictableIdleTimeMillis基礎上，加入了至少
minIdle個對象已經在pool裡面了。如果為-1，evicted不會根據idle
time驅逐任何對象。如果minEvictableIdleTimeMillis>0，則此項設置無意義，且只有在
timeBetweenEvictionRunsMillis大於0時才有意義；

lifo：borrowObject返回對象時，是採用DEFAULT_LIFO（last in first out，即類似cache的最頻繁使用隊列），如果為False，則表示耐灶FIFO隊列；

其中JedisPoolConfig對一些參數的默認設置如下：

testWhileIdle=true

minEvictableIdleTimeMills=60000

timeBetweenEvictionRunsMillis=30000

numTestsPerEvictionRun=-1

D. YARN中設置隊列QueueA的最大使用資源量，需要配置哪個參數（）

YARN中設置隊列QueueA的最大使用資源量，需要配置哪個參明頃明數（激告）

A.yarn.scheler.capacity.root.QueueA.maximum-capacity(正乎運確答案)

B.yarn.scheler.capacity.root.QueueA.minimum-user-1imit-percent

C.yarn.scheler.capacity.root.QueueA.user-1imit-factor

D.yarn.scheler.capacity.root.QueueA.state

E. skywalking agent 本地緩存隊列參數設置

skywalking是一款優秀的apm應用性能監控軟體，屬於Apache開源平台頂級項目，以java語言開發。它以jvm虛擬機agent方式隨應用一塊啟動，通過無侵入自動代碼埋點來實現應用介面的性能監控。

由於agent代理和監控的業務應用在一塊啟動，為盡可能地減小對原有業務應用的影響(內存佔用、線程cpu資源使用等)，skywalking agent的埋點數據收集以仔扒及上報，是以隊列+非同步線程的方式實現。當skywalking server端出現故障，內存隊列被占滿，新的收集數據將直接丟棄，不會繼續往隊列里添加，以避免佔用過多內存資源對原有業務產生影響。通常情況下，保持agent默認參數配置即可，無需額外修改。針對一些需求特別的場景，用戶可以通過參數自行定義，以便最大限度降低agent對原有業務的影響。

關於skywalking agent的隊列模型-- 無鎖環狀隊列。可以參考文章：https://www.jianshu.com/p/93845a3b4b42，這里不再贅述。

skywalking agent本地緩存隊列由兩部分組成： 緩存通道*通道隊列
其中，
緩存通道大小：buffer.channel_size=${SW_BUFFER_CHANNEL_SIZE:5}
緩存隊列大小：buffer.buffer_size=${SW_BUFFER_BUFFER_SIZE:300}
上面所列參數，等號左側為k ey值，右側為value值，其中value值中銷戚畝大寫字元為環境變數，冒號：後面數字為默認值。即agent的默認緩存通道為5，默認每個通道對應隊列大小為300。

我們可以通過以下兩種方式實虧森現默認參數的覆蓋。

F. ActiveMQ之Destination

Wildcard用來支持名字分層體系，它不是JMS規范的一部分，是ActiveMQ的擴展。

ActiveMQ支持以下三種wildcard：

示例，假設有銀塵兩個Destination：PRICE.STOCK.NASDAQ.IBM 和 PRICE.STOCK.NYSE.SUNW。那麼如下配置通配符：

路徑符號替換，將「/"替換"."，添加如下插件：

組合隊列Composite Destinations 允許用一個虛擬的destination代表多個destinations,這樣就可以通過composite destinations在一個操作中同時向多個queue/topic發送消息。 有兩種實現方式：

在創建客戶端連接的Destination時，多個destination之間採用","分隔。如下：

如果希望不同的Destination的話，需要加前綴「queue://」或者「topic://」。如下

客戶端發送示例：

當客戶端向「comQueue」發送消息時，消息就會同時發送到"queue.FOO"和「topic.FOO」中。

通過配置selecter來過濾掉不需要的消息，如下：

在啟動ActiveMQ的時候如果需要創建Destination的話，可以在activemq.xml中配置:

在ActiveMQ的queue在不使用之後，可以通過web控制台或者JMX方式來刪除掉，當然，也可以通過配置，使得broker可以自動探測到無用的隊列並刪除掉，回收相應資源。

參數說明：

：設置多長時間檢查一次，單位是毫秒。
inactiveTimoutBeforeGC ： 設置當Destination為空後，多長時間被刪除，鋒指禪單位是毫秒。
gcInactiveDestinations ：設置刪除掉不活動的隊列，默認為false。

Destination Options是一種無需擴展JMS API即可向JMS消費者提供擴展配置選項的方法。這些選項使用URL查詢語法在創建消費者的目標名稱中進行編碼。

消費者選項如下：

虛擬destination用來創建邏輯destination,客戶端可以通過它來生產和消費消息，它會把消息映射到物理destination。

ActiveMQ支持2種方式：

ActiveMQ中，topic只有在持久訂閱下才會持久化消息。JMS持久化訂閱者 MessageConsumer 在創建時會生成一個 唯一的 JMS clientID 和一個持久化訂閱者的name。 為了符合JMS，對於一個JMSclientID，同一時間，只能有一個活躍的JMS連接，並且，對於一個clientID和訂閱者name而言，只有一個消費者可以是活躍的。也就是說，對於給定的topic訂閱者來說，只能由一個活躍的進程進行消費。這意味著我們不能實現：

如今，JMS中的隊列語義提供了通過多個消費者來實現可靠的負載均衡——允許多線程，進程和機器來處理消息。然後我們就有了成熟而復雜的負載均衡技術，就像Messge Groups一樣在維護訂單時進行負載均衡和並行化處理。如下圖所示，全量的消息先發送到隊列，然後再分發給消費者，通過隊列來解決負載均衡和故障轉移問題。

virtual topic背後的思想是生產者用正常的JMS方式把消息發送到一個topic。消費者可以繼續使用JMS標准中的Topic語義。然而，如果 topic 是虛擬的， 訂閱一個邏輯topic的消費者可以從一個真實隊列中消費，允許多個消費者分布在多個機器上且多線程的進行負載均衡。 例如，假定我們現在有一個叫做 VirtualTopic.Orders 的topic。（前綴 VirtualTopic. 表明這是一個 virtual topic）。

我們希望將orders 發送到系統A 和 系統B。於是，用逗頌通常的 rable topics ，我們需要為 clientID_A 和 "A" 創建一個JMS消費者，同時為 clientID_B 和 "B"創建一個JMS消費者。 有了virtual topics 我們可以直接從隊列 Consumer.A.VirtualTopic.Orders 中為系統A 消費，或者從隊列 Consumer.B.VirtualTopic.Orders 中為系統B 消費。

默認前綴是： VirtualTopic.>

自定義消費虛擬地址默認格式： Consumer. .VirtualTopic.>*

下面的示例演示如何使所有主題成為虛擬主題。下面的示例使用名稱「>「」表示「匹配所有主題」，「VirtualTopicConsumers」為消費隊列的前綴。

其他的配置參數：

通常情況下，使用網路連接消費者隊列。在這種情況下，不要在虛擬主題上橋接任何普通主題消費者，因為任何轉發的消息都會再次分散到網路代理上的消費者隊列，從而導致消息重復。下面示例展示了如何排除虛擬隊列：

ActiveMQ中每個queue中的消息只能被一個consumer消費。然而，有時候你可能希望能夠監視生產者和消費者之間的消息流。你可以通過使用Virtual Destinations 來建立一個virtual queue 來把消息轉發到多個queues中。但是 為系統中每個queue都進行如此的配置可能會很麻煩。 使用ActiveMQ支持Mirrored Queues。Broker會把發送到某個queue的所有消息轉發到一個名稱類似的topic，因此監控程序只需要訂閱這個mirrored queue topic。為了啟用Mirrored Queues，首先要將BrokerService的「useMirroredQueues「屬性設置成true，然後可以通過destinationInterceptors設置其它屬性，如mirror topic的前綴，預設是「VirtualTopic.Mirror.」。如下訂閱「*.qmirror」的主題就開啟了mirrored queue。

http://activemq.apache.org/features