uWSGI信号框架

警告

uwsgi信号的原始使用只提供给高级用户。对于一个更优雅的抽象，你应该看看 uWSGI API - Python装饰器 。

注解

uWSGI信号量与UNIX/Posix信号量毫无共同之处 (如果你找的是那些，那么 管理uWSGI服务器 才是你要看的)。

随着时间的推移，你的uWSGI堆栈越来越大，你添加spooler，更多的进程，更多的插件，等等。你添加的功能越多，你就越需要所有这些组件之间能彼此通信。

现今丰富/高级的web应用的另一个重要任务是响应不同事件。一个事件可能是一个文件修改，一个新的集群节点冒出来，另一个（黯然）死去，一个定时器时间已经到了……任何你能想象到的事件。

通信和事件管理都由相同的子系统管理 —— uWSGI信号框架。

uWSGI信号是由socket管理的，因此它们 够可靠 。当你发送一个uWSGI信号时，你可以保证它会被转发。

信号表

信号是简单的 1字节 消息，它可以由master进程路由给worker和spooler.

当一个workder接收到一个信号，它会搜索信号表，查找对应的处理程序并执行。

信号表由所有worker共享 (并通过共享锁对抗竞争条件)。

每个uWSGI进程 (虽然主要是master)可以写信号表，以设置信号处理程序和接收进程。

警告

要经常注意谁会运行信号处理程序。它必须能够访问信号处理程序本身。这意味着，如果你在 worker1 中定义一个新的函数，并将其注册为信号处理程序，那么只有 worker1 可以运行它。注册信号最好的方法是在master中定义它们，这样(多亏了 fork() )所有的worker都能看到它们。

定义信号处理程序

要管理信号表，uWSGI API提供了一个简单的函数， uwsgi.register_signal().

下面是两个简单的定义信号表项的例子，分别用Python和Lua编写。

  1. import uwsgi
  2.  
  3. def hello_signal(num):
  4.     print "i am the signal %d" % num
  5.  
  6. def hello_signal2(num):
  7.     print "Hi, i am the signal %d" % num
  8.  
  9. # define 2 signal table items (30 and 22)
  10. uwsgi.register_signal(30, "worker", hello_signal)
  11. uwsgi.register_signal(22, "workers", hello_signal2)
  1. function hello_signal(sig)
  2.     print("i am Lua, received signal " .. sig ..)
  3. end
  4.  
  5. # define a single signal table item (signal 1)
  6. uwsgi.register_signal(1, "worker", hello_signal)

信号目标

uwsgi.register_signal的第三个参数是’signal targer’。

它指示系统“谁”必须运行处理程序。默认情况下，目标是targer是表示“第一个可用worker”的’worker’。下面是可用的目标：

  • workerN (只在workder N上运行信号处理程序)
  • worker/worker0 (默认，在第一个可用的worker上运行信号处理程序)
  • workers (在所有worker上运行信号处理程序)
  • active-workers (在所有活跃的 [non-cheaped] worker上运行信号处理程序)
  • spooler (在第一个可用的spooler上运行信号处理程序)
  • mules (在所有的mule上运行信号处理程序)
  • muleN (在mule N上运行信号处理程序)
  • mule/mule0 (在第一个可用的mule上运行信号处理程序)
  • farmN/farm_XXX (在mule farm N或者指定的XXX上运行信号处理程序)

引发信号

可以使用 uwsgi.signal() 引发信号。当你发送一个信号时，它会被拷贝到master的队列中。然后，master会检查信号表并调度消息。

外部事件

uWSGI信号最有用的特性是，它们可以用于宣布外部事件。

编写可用外部事件的时机是

  • 文件系统修改
  • timer/rb_timer
  • cron

其他事件是通过插件暴露出来的，例如，每当一个postgres通知通道准备好时，https://github.com/unbit/uwsgi-pgnotifyj就会引发一个信号。

文件系统修改

要将一个特定的文件/目录修改事件映射到一个信号上，你可以使用 uwsgi.add_file_monitor() 。

一个例子：

  1. import uwsgi
  2.  
  3. def hello_file(num):
  4.         print "/tmp has been modified !!!"
  5.  
  6. uwsgi.register_signal(17, "worker", hello_file)
  7. uwsgi.add_file_monitor(17, "/tmp")

从现在开始，每次 /tmp 被修改时，将会引发信号17，然后第一个可用worker将会运行 hello_file 。

定时器

定时器是web编程中另一个有用特性 —— 例如清理会话、购物车等诸如此类。

定时器是利用内核工具实现的（BSD系统上的kqueue，以及现代Linux内核上的timerfd()）。uWSGI还包含对rb_timer的支持，这是一个在用户空间中，使用红黑树实现的定时器。

要注册一个定时器，可以使用 uwsgi.add_timer() 。要注册一个rb_timer，可以使用 uwsgi.add_rb_timer() 。

  1. import uwsgi
  2.  
  3. def hello_timer(num):
  4.         print "2 seconds elapsed, signal %d raised" % num
  5.  
  6. def oneshot_timer(num):
  7.         print "40 seconds elapsed, signal %d raised. You will never see me again." % num
  8.  
  9.  
  10. uwsgi.register_signal(26, "worker", hello_timer)
  11. uwsgi.register_signal(30, "", oneshot_timer)
  12.  
  13. uwsgi.add_timer(26, 2) # never-ending timer every 2 seconds
  14. uwsgi.add_rb_timer(30, 40, 1) # one shot rb timer after 40 seconds

每2秒钟就会引发一次信号26，并且由第一个可用worker处理。40秒过后会引发一次信号30，然后只执行一次。

signal_wait和signal_received

未注册信号（那些没有相关处理程序的）将会路由到第一个可用worker，以使用 uwsgi.signal_wait() 函数。

  1. uwsgi.signal_wait()
  2. signum = uwsgi.signal_received()

你可以将外部事件（文件监控、定时器……）和这项技术结合起来，以实现基于事件的应用。一个很好的例子是聊天服务器，其中，每个核等待用户发送的文本。

你也可以通过传递一个信号数字给 signal_wait 来等待一个特定的（甚至注册了的）信号。

待办/已知问题

  • 不能移除信号表项（这会尽快解决）
  • 迭代只适用于rb_timer
  • uwsgi.signal_wait()在异步模式下无效（将会解决）
  • 添加迭代到文件监控（以允许定时器的一次事件）