Robins Tharakan：LISTEN/NOTIFY性能提升40倍
内容提要
Postgres最近优化了NOTIFY命令的处理方式，修复了通知队列的性能瓶颈。新实现使用共享哈希表跟踪监听者，避免了线性搜索的高成本，显著提高了吞吐量，增强了在高负载场景下的可扩展性，并减少了CPU上下文切换。
关键要点
-
Postgres最近修复了通知队列的性能瓶颈，显著提高了吞吐量。
-
新实现使用共享哈希表跟踪监听者，避免了线性搜索的高成本。
-
优化后的NOTIFY命令在高负载场景下增强了可扩展性，减少了CPU上下文切换。
-
新实现允许并发的LISTEN/UNLISTEN命令，避免了全局锁争用。
-
测试显示，优化前后在发送通知时性能差异明显，优化后性能保持平稳。
延伸解读
性能提升的背景
Postgres在处理NOTIFY命令时，之前的实现存在性能瓶颈，尤其是在有大量独特频道的情况下，通知的发送成本呈现平方级增长。此次优化通过引入共享哈希表，显著提升了吞吐量，解决了这一问题，使得在高负载场景下的性能表现更加稳定。
优化的技术细节
新实现采用了分区哈希锁定技术，允许并发的LISTEN和UNLISTEN命令，避免了全局锁争用。这种设计不仅提高了系统的并发能力，还减少了CPU上下文切换，提升了整体效率，尤其适合需要高并发的实时通知系统。
实际应用中的注意事项
尽管此次优化显著提升了Postgres的通知系统性能，但仍需注意，创建过多的频道（如100,000个）可能导致其他问题。因此，在设计系统时，合理规划频道数量仍然是重要的考虑因素，以确保系统的稳定性和可扩展性。
延伸问答
Postgres的NOTIFY命令有什么性能提升？
Postgres的NOTIFY命令性能提升了40倍，显著提高了吞吐量。
新实现如何改善了通知队列的性能瓶颈？
新实现使用共享哈希表跟踪监听者，避免了线性搜索的高成本。
优化后的NOTIFY命令在高负载场景下有什么优势？
优化后的NOTIFY命令增强了可扩展性，并减少了CPU上下文切换。
新实现如何处理LISTEN和UNLISTEN命令的并发？
新实现允许并发的LISTEN/UNLISTEN命令，避免了全局锁争用。
测试结果显示了什么样的性能差异？
测试显示优化前后在发送通知时性能差异明显，优化后性能保持平稳。
Postgres的通知系统在高负载下的表现如何？
优化消除了Postgres消息系统中的显著可扩展性悬崖，使其在高负载场景下更为稳健。
