事件驱动架构在实时Web应用中的地位日益重要，无论是聊天室、协同编辑还是监控面板，都需要服务器主动推送数据。Cramp框架基于EventMachine构建，使得Ruby开发者能够以非阻塞的方式处理请求，适合实现长轮询和WebSocket等服务。Cramp提供了简洁的控制器抽象，让连接的生命周期管理变得清晰可控。
Cramp的设计思路与传统Rack应用不同，它完全运行在EventMachine事件循环中。这意味着每个请求不会占有一个系统线程，I/O操作通过回调通知完成，从而支持成千上万的并发连接。理解这一底层模型，是正确使用长轮询和WebSocket的前提。
事件驱动模型与长轮询的实现原理
长轮询是一种模拟服务器推送的方式：客户端发起普通HTTP请求，服务器收到后不立即响应，而是挂起该请求，等待有新数据时再返回。这样既保持了HTTP协议兼容性，又实现了准实时效果。在Cramp中，一个Action就是一个异步控制器，默认情况下请求会一直保持连接，直到开发者显式调用finish或请求超时。
Cramp的事件循环由EventMachine驱动，开发者可以借助EM定时器或自定义回调来判断数据是否就绪。一个常见的长轮询控制器会先挂起请求，注册一个周期检查器，当条件满足时输出数据并结束连接。下面这段代码展示了用Cramp实现长轮询的基本骨架：
require 'cramp'
class LongPollingController < Cramp::Action
def start
# 每两秒检查一次数据是否就绪
@checker = EM.add_periodic_timer(2) do
if data_ready?
render "new data: #{fetch_data}"
finish
end
end
end
def finish
EM.cancel_timer(@checker) if @checker
super
end
private
def data_ready?
# 模拟数据源，正常情况下会查询数据库或消息队列
rand <= 0.5
end
def fetch_data
Time.now.to_i.to_s
end
end
注意这里的核心点是异步：控制器不会阻塞在sleep上，而是将检查逻辑交给事件循环定时执行。每个长轮询请求占用的仅仅是内存中的连接对象，而非一个线程。这种模式允许同一台服务器同时挂起大量请求，在移动端推送和消息提醒场景中非常实用。
不过长轮询也有一些固有缺陷，比如需要维护每个挂起请求的超时状态，客户端重连会带来额外的服务器负载。因此，在实际系统中要配合合理的超时时间，并尽量复用已建立的TCP连接。Cramp允许在Rack中间件中配置headers，例如设置超时或禁用缓冲，从而优化长轮询行为。
WebSocket连接生命周期与消息广播
与长轮询相比，WebSocket提供了全双工的持久连接，服务端和客户端可以随时互发消息，且握手完成后不再需要HTTP头开销。Cramp专门提供了Cramp::Websocket基类，让开发者通过重写生命周期方法来管理连接。这个类已经封装了WebSocket的握手和帧解析逻辑，程序员只需要关注业务事件。
下面是一个简单的聊天室WebSocket处理类，它使用全局连接注册表记录所有在线客户端，并在收到消息时广播给所有人：
class ChatSocket < Cramp::Websocket
def on_open
puts "客户端接入"
ClientRegistry.add(self)
end
def on_message(message)
ClientRegistry.broadcast(message)
end
def on_close
ClientRegistry.remove(self)
puts "客户端断开"
end
end
class ClientRegistry
@clients = []
class << self
def add(socket)
@clients << socket
end
def remove(socket)
@clients.delete(socket)
end
def broadcast(data)
@clients.each do |client|
client.write(data)
end
end
end
end
在on_open阶段，我们将当前连接对象加入注册表，这样后续广播时就可以遍历所有连接发送数据。on_close方法中必须清理连接，否则会形成内存泄漏。Cramp的write方法负责以WebSocket帧格式输出数据，底层由EventMachine管理发送缓冲。
连接管理是WebSocket应用的核心挑战。当连接数量上升时，注册表本身的锁竞争、广播时的遍历效率都会成为瓶颈。一个改进做法是使用EM.channel来管理连接，这是一种广播通道，每个连接注册为订阅者，发布消息时自动分发到所有订阅者。但通道对象需要自己维护订阅关系的生命周期，避免使用已关闭的连接。
连接管理的关键策略：心跳、超时与监控
无论是长轮询还是WebSocket，连接管理都必须考虑异常断开的情况。客户端可能突然断网、移动端切换网络，或者代理服务器空闲超时。如果不主动检测，服务器端会积累大量半开连接，最终耗尽文件描述符。解决这一问题的通用手段是心跳机制。
在WebSocket协议中，ping和pong帧就是为心跳设计的。Cramp底层封装了这些控制帧，但框架没有强制要求开发者使用。因此，我们需要利用EventMachine的定时器自己实现心跳。下面的代码演示了如何每30秒发送一次ping，并监听pong响应：
class HeartbeatSocket < Cramp::Websocket
PING_INTERVAL = 30
TIMEOUT = 5
def on_open
@last_beat = Time.now
@heartbeat = EM.add_periodic_timer(PING_INTERVAL) do
ping_frame = EM::WebSocket::Frame::Ping.new
@connection.send_frame(ping_frame)
EM.add_timer(TIMEOUT) do
close_connection if @last_beat < Time.now - TIMEOUT
end
end
end
def on_pong
@last_beat = Time.now
end
def on_close
EM.cancel_timer(@heartbeat) if @heartbeat
end
end
对于长轮询，超时控制更加直接。Cramp的Action可以在start方法里注册一个超时定时器，超过预设时间就返回一个空响应，让客户端立即重新发起请求。客户端也应当根据网络状态调整重试间隔，避免形成请求风暴。一个典型的配置是：超时设为30秒，客户端在收到超时响应后等待2秒再发起新的长轮询请求。
连接监控同样不可忽视。开发者可以统计当前活跃连接数、消息吞吐率和断开原因，把数据暴露给运维系统。Cramp虽然不提供内置监控，但通过Rack中间件或自定义统计模块很容易实现。例如在ClientRegistry中维护一个计数器，定期将统计信息写入日志或时间序列数据库。
长轮询与WebSocket的选型建议
两种技术在Cramp中都能实现，但适用场景明显不同。长轮询的优势在于兼容性，任何支持HTTP的客户端和服务器都能使用，不需要特殊协议支持。它适合低频、偶发的数据推送，比如新消息提醒或订单状态更新。在Cramp中实现长轮询只需要处理挂起请求和定时器，复杂度较低。
WebSocket则适合高频、双向交互的场景，比如在线白板、实时协作、股票行情订阅。它的建立需要完成HTTP Upgrade握手，但之后开销极小，且天然支持服务端主动推送。在Cramp中使用WebSocket要管理连接注册和心跳，部署环境还需要确认反向代理支持WebSocket的升级头部。
如果团队对实时性要求很高，且项目已经决定使用Cramp，那么直接采用WebSocket是更长远的选择。长轮询可以作为降级方案，在浏览器不支持WebSocket时使用。Cramp允许在同一个Rack应用中同时挂载两种控制器，提供统一的入口路由来切换，从而实现渐进增强。
总结
使用Cramp实现事件驱动Web应用时，长轮询和WebSocket都是有效的连接方案。理解EventMachine的工作方式是关键，因为它决定了请求的异步处理和资源回收方式。无论选择哪种方案，连接管理都要围绕生命周期、心跳和超时来设计，避免连接泄漏和假死。
核心代码量其实并不大，难度在于边缘条件的处理。建议开发者先从简单的WebSocket聊天开始，逐步加入心跳、注册表和监控，形成一套适合自己业务的连接管理模块。Cramp灵活的底层接口也为定制化提供了可能，只要掌握好事件循环和定时器，就能构建出稳定可靠的实时系统。
Cramp框架事件驱动WebSocket连接管理修改时间：2026-08-20 23:48:43