JMS如何监听oracleAQ队列的消息

有些网站上提供了在线聊天功能，对方发来的消息我这就回即时的显示在聊天窗口上，我现在用jms来模仿一下这个功能，接收消息是没问题的，但是我在消息反馈上出问题了，接到消息的jms监听依旧是一段服务器上的代码，服务器要怎么通知客户端的浏览器“我收到消息”了呢？再顺便调用客户端浏览器的js在对话框上显示出来接收的消息内容，是不是不可以的？ 我们都知道web应用程序是 请求-响应模式，也就是浏览器不向服务器请求数据，服务器不会理你，我是这么理解的，是不是就意味着，当服务器上jms监听收到消息了，也不可能主动的去通知某个客户的浏览器让它显示消息？因为毕竟和C/S架构应用的模式不同，那是不是意味着web页面上的聊天程序，只能通过ajax轮循访问服务器看看有没有新消息？

恢咨谅晃

1、dbwn会将数据块从buffer cache写入数据文件，对应的块仅仅会从lruw链上摘下去，oracle dbwn是按照lruw链来写脏块的这句话是不对的，dbwn进程是按照ckeckpoint链上的数据块顺序来写数据块。

2、检查点发生的时候肯定会调度dbwn来写检查点列队（checkpoint链）上的脏数据块，目前检查点又分为增量检查点和完全检查点，完全检查点会在alter system checkpoint和一致性关闭数据库的时候触发，会把checkpoint链上所有脏数据块都写入数据库。而增量检查点做了什么呢？增量检查点会把checkpoint链上第一个块的lrba地址写入控制文件，lrba对应的是checkpoint链上第一个数据块第一次修改的那个 *** 作所对应日志的位置，同时checkpoint链上从链头开始的一部分数据块写入数据文件（checkpoint链上的数据块是严格按照修改时间的顺序来排列的，并且如果对同一个块做了多次修改，checkpoint链上也只有这一个块，可以认为多次修改记录都在这一个数据块上，并不是像你说的检查点队列上挂的只是这个块的第一次被修改时的数据块，这里我也不是太理解你的意思），数据块写入数据文件自然就需要dbwn进程（这里是检查点进程触发了dbwn），而dbwn写脏数据之前lgwr会做什么呢？lgwr会先把对应的日志写入redolog。也就是dbwn会触发lgwr，oracle就是这样，写数据之前必然先写日志，有日志数据就是安全的。

3、lrba是用来干什么的呢？比如发生增量检查点，记录lrba地址到控制文件，触发dbwn，要从checkpoint链上摘掉5个块，摘掉之前dbwn触发lgwr先把这五个块对应 *** 作的日志写入redolog，有日志了，但是在这个时候（dbwn还没有将这5个脏数据块写入数据文件时侯）数据库崩溃了，buffer cache中数据都丢了，下次打开数据库的时候。smon进程会检查数据文件的end scn，如果为空就是数据库没有正常关闭（这里你可以看看实例恢复的原理，就不多说了），这个时候就要实例恢复，所以就会定位一个恢复点，lrba地址就是这个恢复的点，需要把刚刚以写日志的5个块重新在buffer cache中构造出来，lrba地址就是这个作用，但是实例恢复的具体情况还分很多，可以看看相关书籍。

希望可以帮助你。

‍测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 >

分析

下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的产生需要两方面的配合：

metric 数据

告警规则

将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：

看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。

不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：

首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。

其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：

capacity（默认值为 10000）：控制缓冲队列的大小，

maxBatchSize（默认值为 100）：控制单次发送到 AlertManager 的最大告警数

了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1 缓冲队列阶段2 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 20000s 内推送了大约 2000 次，即平均 10s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)10s = 16m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：

thanos_alert_queue_alerts_dropped_total

thanos_alert_queue_alerts_pushed_total

thanos_alert_queue_alerts_popped_total

通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。

解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、、xn，实体上的告警规则数量分别有 y1、y2、y3、、yn，那么一次能产生的告警数量最多是(x1 y2 + x2 y2 + x3 y3 + + xn yn)，最多推送（y1 + y2 + y3 + + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize >= (x1 y2 + x2 y2 + x3 y3 + + xn yn) / (y1 + y2 + y3 + + yn)，假设 x = max(x1,x2, ,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。

注意事项

上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。

‍‍

用内部索引吧，至少时间可以用内部索引。

主要是部分功能可能会很快用到插入的数据，不能做太大的延迟，延迟的时间需要控制在10分钟或者5分钟以内。

插入，有的时候会报ORA-000054错误，资源繁忙，可能是因为有查询的存在，最好可以将插入和查询的相互影响降到最低。

以上就是关于JMS如何监听oracleAQ队列的消息全部的内容，包括:JMS如何监听oracleAQ队列的消息、oracle dbwn是按照lruw链来写脏块的，检查点队列中记录的是lrba，那么CKPT发生的时候会调度dbwn来写检查点、oracle数据库的警告日志如何查看等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！