实现一个简单的服务端推方案
UPDATED: 本文已经不再适用，新版 ngx_lua 已经支持 semaphore 功能了。
客户端和服务端的交互有推和拉两种方式：如果是客户端拉的话，通常就是Polling；如果是服务端推的话，一般就是Comet(http://en.wikipedia.org/wiki/Comet_(programming%29)，目前比较流行的Comet实现方式是Long Polling。
注：如果不清楚相关名词含义，可以参考：Browser 與 Server 持續同步的作法介紹。
先来看看Polling，它其实就是我们平常所说的轮询，大致如下所示：
Polling
因为服务端不会主动告诉客户端它是否有新数据，所以Polling的实时性较差。虽然可以通过加快轮询频率的方式来缓解这个问题，但相应付出的代价也不小：一来会使负载居高不下，二来也会让带宽捉襟见肘。
再来说说Long Polling，如果使用传统的LAMP技术去实现的话，大致如下所示：
Long Polling
客户端不会频繁的轮询服务端，而是对服务端发起一个长连接，服务端通过轮询数据库来确定是否有新数据，一旦发现新数据便给客户端发出响应，这次交互便结束了。客户端处理好新数据后再重新发起一个长连接，如此周而复始。
在上面这个Long Polling方案里，我们解决了Polling中客户端轮询造成的负载和带宽的问题，但是依然存在服务端轮询，数据库的压力可想而知，此时我们虽然可以通过针对数据库使用主从复制，分片等技术来缓解问题，但那毕竟只是治标不治本。
我们的目标是实现一个简单的服务端推方案，但简单绝对不意味着简陋，轮询数据库是不可以接受的，下面我们来看看如何解决这个问题。在这里我们放弃了传统的LAMP技术，转而使用Nginx与Lua来实现。
Modified Long Polling
此方案的主要思路是这样的：使用Nginx作为服务端，通过Lua协程来创建长连接，一旦数据库里有新数据，它便主动通知Nginx，并把相应的标识（比如一个自增的整数ID）保存在Nginx共享内存中，接下来，Nginx不会再去轮询数据库，而是改为轮询本地的共享内存，通过比对标识来判断是否有新消息，如果有便给客户端发出响应。
注：服务端维持大量长连接时内核参数的调整请参考：http长连接200万尝试及调优。
首先，我们简单写一点代码实现轮询（篇幅所限省略了查询数据库的操作）：
lua_shared_dict config 1m;
server {
location /push {
content_by_lua '
local id = 0;
local ttl = 100;
local now = ngx.time();
local config = ngx.shared.config;
if not config:get("id") then
config:set("id", "0");
end
while id >= tonumber(config:get("id")) do
local random = math.random(ttl - 10, ttl + 10);
if ngx.time() - now > random then
ngx.say("NO");
ngx.exit(ngx.HTTP_OK);
end
ngx.sleep(1);
end
ngx.say("YES");
ngx.exit(ngx.HTTP_OK);
';
}
...
}注：为了处理服务端不知道客户端何时断开连接的情况，代码中引入超时机制。
其次，我们需要做一些基础工作，以便操作Nginx的共享内存：
lua_shared_dict config 1m;
server {
location /config {
content_by_lua '
local config = ngx.shared.config;
if ngx.var.request_method == "GET" then
local field = ngx.var.arg_field;
if not field then
ngx.exit(ngx.HTTP_BAD_REQUEST);
end
local content = config:get(field);
if not content then
ngx.exit(ngx.HTTP_BAD_REQUEST);
end
ngx.say(content);
ngx.exit(ngx.HTTP_OK);
end
if ngx.var.request_method == "POST" then
ngx.req.read_body();
local args = ngx.req.get_post_args();
for field, value in pairs(args) do
if type(value) ~= "table" then
config:set(field, value);
end
end
ngx.say("OK");
ngx.exit(ngx.HTTP_OK);
end
';
}
...
}如果要写Nginx共享内存的话，可以这样操作：
shell> curl -d "id=123" http://<HOST>/config如果要读Nginx共享内存的话，可以这样操作：
shell> curl http://<HOST>/config?field=id注：实际应用时，应该加上权限判断逻辑，比如只有限定的IP地址才能使用此功能。
当数据库有新数据的时候，可以通过触发器来写Nginx共享内存，当然，在应用层通过观察者模式来写Nginx共享内存通常会是一个更优雅的选择。
如此一来，数据库就彻底翻身做主人了，虽然系统仍然是轮询，但已经从轮询别人变成了轮询自己，效率不可相提并论，从强奸变成了自慰，还是有进步意义的。相应的，我们可以加快轮询的频率而不会造成太大的压力，从而在根本上提升用户体验。
突然想起另一个有趣的服务端推的做法，不妨在一起唠唠：如果DB使用Redis的话，那么可以利用其提供的BLPOP方法来实现服务端推，这样的话，连sleep都不用了，不过有一点需要注意的是，一旦使用了BLPOP方法，那么Nginx和Redis之间的连接便会一直保持下去，从Redis的角度看，Nginx是客户端，而客户端的可用端口数量是有限的，这就意味着一台Nginx至多只能建立六万多个连接（net.ipv4.ip_local_port_range），有点儿少。
…
当然，本文的描述只是沧海一粟，还有很多技术可供选择，比如Pub/Sub，WebSocket等等，篇幅所限，这里就不多说了，有兴趣的读者请自己查阅。
腾讯云开发者
