配置队列需要配置哪些参数
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