Oracle Advanced Queuing（AQ）是数据库内置的消息中间件，其消息持久化与去重能力是企业级可靠通信的核心。通过将队列数据映射到普通关系表并参与事务，AQ保证了消息在系统故障时不丢失。去重则依赖于消息唯一标识与消费事务的状态管理，避免重复处理。在分布式系统设计中，这种基于数据库事务的消息机制能够无缝集成现有OLTP业务，降低异构中间件运维成本。
一、Oracle AQ持久化的存储与事务原理
持久化队列的底层的本质是一张或多张队列表（queue table），这些表在创建时通过DBMS_AQADM.CREATE_QUEUE_TABLE过程定义，底层使用对象类型或LOB列来存储消息载荷。与普通表无异，队列表的数据变更完全遵循Oracle的事务模型：当生产者调用DBMS_AQ.ENQUEUE时，消息行被插入队列表，但只有在会话提交后，该插入才会通过重做日志（redo log）永久写入数据文件。如果事务回滚，消息行对所有其他会话不可见，从而实现了原子性投递。
对比非持久化队列（memory-based queue），持久化队列在数据库实例重启、崩溃恢复后依然能够保留未消费消息，因为它依赖表空间和归档日志进行介质恢复。在创建队列表时可以指定STORAGE_CLAUSE和TABLESPACE参数，将队列数据隔离在高性能磁盘上。例如将队列表空间放置于 C:\oracle\data\aqts.dbf 这样的独立文件，可以减少与业务表的IO争用。这种机制的优点是可靠性极高，缺点则是每次入队出队都产生redo记录，写入吞吐受限于日志磁盘带宽。
从数据字典角度看，队列表上会自动建立若干索引来加速按消息状态、延迟时间的检索。数据库后台的清理进程会定期将已消费且超过保留期的消息移至历史表或直接删除。运维时需监控队列表的空间增长，避免因为消费者滞后导致海量堆积。合理设置RETENTION参数（如保留一天）能在故障排查与存储成本间取得平衡。
二、消息去重的技术实现与消费模型
许多初次接触AQ的工程师以为去重是基于消息内容哈希或业务主键的自动判重，其实Oracle AQ的去重严格依赖消息标识（msgid）与事务锁。系统在入队时可为消息显式指定msgid，若两次入队使用相同的msgid且前一次事务仍未提交，后一次会抛出重复标识错误；若前一次已提交且消息未被消费，再次入队相同msgid同样被拒绝。这种机制保证了生产端在重试时不会产生副本。
在消费端，AQ通过出队选项如DEQUEUE_MODE => 'LOCKED'或'REMOVE'来变更消息状态。当某个会话以LOCKED模式读取消息，该消息行被事务锁持有，其他消费者无法再次读取，直到提交或回滚。对于多订阅者队列，每个接收者维护独立的消费状态，去重逻辑通过队列表中的recipient视图实现。在RAC环境中，全局入队服务（GES）协调跨实例锁，确保集群内不会有两个节点同时处理同一条消息。
应用层若想实现业务级去重，必须自行生成确定性msgid，例如将订单号拼接时间戳哈希后转为RAW赋值给消息属性。下面代码片段展示在PL/SQL中如何指定msgid进行幂等入队，以及捕获重复异常。需要注意的是，代码中的比较符号若出现在注释里应当转义，但此处我们避免即可。
DECLARE
v_msgid RAW(16);
v_props DBMS_AQ.MESSAGE_PROPERTIES_T;
v_payload ORDER_TYPE;
BEGIN
v_payload := ORDER_TYPE(1001, 'NEW');
v_props.MSGID := HEXTORAW('1A2B3C4D5E6F708192AABBCC');
BEGIN
DBMS_AQ.ENQUEUE('ORDER_QUEUE', v_props, v_payload);
COMMIT;
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -25228 THEN
-- 重复消息标识，视为已发送
ROLLBACK;
ELSE
RAISE;
END IF;
END;
END;
三、PL/SQL实战：构建具备持久化与去重的订单队列
假设电商订单服务需将创建事件发送给库存服务，要求不丢失且不重复处理。我们首先创建持久化队列表与队列，指定消息类型为自定义对象，并开启RETENTION以保留一天用于审计。创建语句通过DBMS_AQADM完成，其中QUEUE_TABLE参数使用专属表空间，确保故障恢复能力。
BEGIN
DBMS_AQADM.CREATE_QUEUE_TABLE(
QUEUE_TABLE => 'ORDER_QT',
QUEUE_PAYLOAD_TYPE => 'ORDER_TYPE',
STORAGE_CLAUSE => 'TABLESPACE AQ_TS',
RETENTION => 86400
);
DBMS_AQADM.CREATE_QUEUE(
QUEUE_NAME => 'ORDER_QUEUE',
QUEUE_TABLE => 'ORDER_QT'
);
DBMS_AQADM.START_QUEUE('ORDER_QUEUE');
END;
入队过程在订单事务中内联执行，这样订单写入与消息发送同时提交，满足事务性投递。若指定了基于订单号的msgid，网络超时重试将安全幂等。出队端采用守护存储过程循环拉取，使用FOR UPDATE风格的事务隔离，处理成功后提交移除消息。如下示例演示出队并捕获锁冲突，避免并发重复消费。
DECLARE
v_msgid RAW(16);
v_props DBMS_AQ.MESSAGE_PROPERTIES_T;
v_payload ORDER_TYPE;
v_opt DBMS_AQ.DEQUEUE_OPTIONS_T;
BEGIN
v_opt.DEQUEUE_MODE := DBMS_AQ.REMOVE;
v_opt.WAIT := DBMS_AQ.NO_WAIT;
DBMS_AQ.DEQUEUE('ORDER_QUEUE', v_opt, v_props, v_payload);
-- 业务处理库存扣减
COMMIT;
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -25228 THEN
ROLLBACK; -- 无消息或已被锁定
ELSE
RAISE;
END IF;
END;
在实际部署中，应当为队列表空间配置自动扩展，并监控积压。如果消费者处理缓慢，消息堆积在 C:\oracle\data\aqts.dbf 文件中，可能引发空间告警。此时可增加并行消费者或优化业务逻辑。此外，去重仅保证传输层不重复，若业务处理本身非幂等，仍需在库存服务内做唯一约束。
四、性能调优与常见误区
持久化队列的IO开销主要来自重做日志与队列表索引维护。在高吞吐场景，可将队列表置于异步提交或批量入队模式中，利用AQ的数组入队接口减少网络往返。去重检查虽在内存中进行msgid比对，但高并发指定相同msgid的异常重试会带来锁等待，因此建议业务层使用雪花算法生成全局唯一msgid，而非依赖数据库序列导致热点。
常见误区之一是认为AQ能像Kafka那样按业务主键自动去重。实际上若不显式设置msgid，系统会自动分配随机值，重试时产生的网络超时若未捕获便重新入队，就会生成两条不同msgid的相同内容消息。另一个误区是忽略保留期设置，导致历史消息无限堆积。应定期运行DBMS_AQADM.PURGE_QUEUE_TABLE清理已处理数据。
综合来看，Oracle AQ的持久化与去重是一套基于数据库事务的严谨方案，适合已深度使用Oracle且要求强一致性的系统。通过合理设计队列表空间路径（如 C:\oracle\product\19c\aq\ 独立挂载点）、msgid生成策略与消费并发度，可构建出媲美专业消息中间件的可靠管道，同时免去额外组件运维负担。