PgSQL · 功能分析 · Listen/Notify 功能

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
简介: Listen 和 Notify 是PG很有意思的一个功能,可以用来进行多应用间的通信。它们可以在SQL中使用,也可以用C、JDBC里面的API调用。下面介绍一下其使用方法和内核实现。 使用方法 用一个简单的例子,来看一下Listen/Notify如何使用。假设我们有两个应用A和B,部署在不同的机

Listen 和 Notify 是PG很有意思的一个功能,可以用来进行多应用间的通信。它们可以在SQL中使用,也可以用C、JDBC里面的API调用。下面介绍一下其使用方法和内核实现。

使用方法

用一个简单的例子,来看一下Listen/Notify如何使用。假设我们有两个应用A和B,部署在不同的机器上:A机器处理前端用户请求,同时需要将一些可以异步执行的任务,分配给后台服务器B。B接收到任务并处理完成后反馈给A结果。

--分别在A和B两台机器上初始化PG连接,它们互相监听对方消息,A负责派发任务给B

--机器A初始化与PG的连接
session A:
listen workA;
commit;

--机器B初始化与PG的连接
session B:
listen workerB;
commit;

--A派发任务给B
session A:
begin;
notify workerB, 'do job 1001';
commit;

--B接受消息
session B:
begin;
Asynchronous notification "worker1" with payload "1001" received from server process with PID 29826.
commit;

--B解析消息(可用脚本或应用实现),然后完成任务,发送反馈给A
session B:
....
begin;
notify workA 'job 1001 done';
commit;

利用上面的步骤,A和B两个机器通过PG完成了通信。在上面的过程中,需要注意的是:

  1. B要想接受到消息,必须在A Notify之前运行了Listen命令;
  2. A需要使用事务commit操作来触发消息发送;
  3. 消息是异步发送到B的,即无论B的状态如何,消息都会先到达PG的消息队列(每个PG实例只有一个唯一的存放所有消息的队列);B要查看消息,如果使用的是psql客户端,则需要先发送带有事务操作的命令(如begin、commit或rollback)给PG;
  4. A 如果连续发送多个消息,B会一次性收到这些消息;
  5. 在C代码里面,你可以使用如下的调用来获取所有已到达的消息,如果没有消息到达,则进入睡眠状态。
    while (1)
    {
        sock = PQsocket(conn);

        /* Monitor socket. Sleep if there is no message */
        select(sock + 1, &input_mask, NULL, NULL, NULL) 

        /* Now check for input */
        PQconsumeInput(conn);

        /* Loop until all notifications currently received have been handled */
        while ((notify = PQnotifies(conn)) != NULL)
        {
            /* Received some message, print it out */
            fprintf(stderr,
                    "ASYNC NOTIFY of '%s' received from backend PID %d\n",
                    notify->relname, notify->be_pid);
            PQfreemem(notify);
         }
    }

内核实现

Listen/Notify的实现其实比较简单。主要的数据结构是一个消息队列(asyncQueueControl->tailasyncQueueControl->head分别指向队列尾和队列头)和一个进程状态数组(asyncQueueControl->backend),如下图所示:

消息通知机制

消息队列里面存放了所有进程的所有通知消息,而状态数组存放了所有执行了Listen命令、准备接收异步消息的进程的状态信息。状态数组中含有每个进程已经读取到的消息在队列里面的位置指针。如果有了新消息,进程就从此指针往后取,直到读取全部消息。

当一个连接的后台进程接收到Listen命令时,先将Listen的信息记录下来,然后在事务提交时,执行Listen操作,即把本进程放入状态数组(参见Exec_ListenPreCommit函数)。

执行Notify命令时,Async_Notify函数负责把通知放入pendingNotifies链表。在事务Commit操作前后,执行下面的逻辑:

  1. 调用PreCommit_Notify函数,将pendingNotifies链表中的消息,放入全局消息队列;
  2. 执行Commit操作;
  3. 利用调用链ProcessCompletedNotifies->SignalBackends->SendProcSignal->kill,向其他所有状态数组中的进程,发出通知信号。

另一方面,每个进程在接收到信号后,利用函数HandleNotifyInterrupt处理信号。如果当前进程处于事务中,则不立即处理消息,等到事务提交完毕,调用prepare_for_client_read读取下一个用户命令时,利用ProcessIncomingNotify处理消息;否则,立即调用ProcessIncomingNotify处理消息。ProcessIncomingNotify最终调用NotifyMyFrontEnd发送消息到客户端:

ProcessIncomingNotify --> asyncQueueReadAllNotifications() --> NotifyMyFrontEnd

注意,客户端收到消息后,并不立即显示出来,而是需要用API进行获取。例如,psql就是在执行下一个命令时(如begin、commit),会顺便把收到的消息显示出来的。

总结

Listen/Notify是一个轻量级的应用间通信机制,有了它,具有访问数据库能力的应用可以轻易的利用PG实现互操作。当然,由于消息队列是存放在内存里面的,在发生实例宕机等问题时,消息将丢失,对可靠性要求高的应用,需要自己进行消息持久化(如利用PG存储消息,进行持久化)。

目录
相关文章
|
存储 运维 关系型数据库
|
SQL MySQL 关系型数据库
MySQL · 引擎特性 · Group Replication内核解析之二
背景 前文已经介绍了MySQL的Group Replication的实现机制和原理,本文就Group Replication的具体实现进行详细的阐述,以更深入的理解Group Replication的机制,在实践中更好的应用Group Replication,提升应用系统的可用性,优化其性能。
1674 0
|
SQL XML 监控
MSSQL· 实现分析 · Extend Event日志文件的分析方法
背景 在前两篇月报分享中,6月份月报我们分享了SQL Server实现审计日志功能的方法探索,最终从可靠性、对象级别、可维护性、开销和对数据库系统影响五个方面得出最佳选项Extend Event;7月份月报我们量化分析了使用Extend Event实现审计日志功能对SQL Server本身的性能和吞吐量的影响,结论是对系统性能和吞吐量影响均在0.01%左右;8月份的月报分享是SQL Server审
1831 0
|
SQL Oracle 关系型数据库
PgSQL · 应用案例 · 逻辑订阅给业务架构带来了什么?
背景 逻辑订阅是PostgreSQL 10.0的新特性。 具体的原理,使用方法可以参考如下文章。 《PostgreSQL 10.0 preview 逻辑订阅 - 原理与最佳实践》 《PostgreSQL 10.0 preview 逻辑订阅 - pg_hba.conf变化,不再使用replication条目》 《PostgreSQL 10.0 preview 逻辑订阅 - 备库支持逻辑订阅,
2387 0
|
SQL 存储 缓存
SQL Server · 最佳实践 · 参数嗅探问题
摘要 MSSQL Server参数嗅探既是一个涉及知识面非常广泛,又是一个比较难于解决的课题,即使对于数据库老手也是一个比较头痛的问题。这篇文章从参数嗅探是什么,如何产生,表象是什么,会带来哪些问题,如何解决这五个方面来探讨参数嗅探的来龙去脉,期望能够将SQL Server参数嗅探问题理清楚,道明白。 什么参数嗅探 当SQL Server第一次执行查询语句或存储过程(或者查询语句与存储过程被强制
1964 0