在分布式系统中，网络服务依赖常常因为下游不稳定而引发连锁故障。熔断器模式通过切断不可用依赖来保护主流程，但如果没有正确的状态转换超时控制，熔断器可能卡在打开状态无法恢复，或者在下游尚未真正就绪时就贸然放行流量。使用Ruby语言实现一套带有状态转换超时的熔断器，需要明确closed、open、half_open三种状态的生命周期，以及在什么条件下允许状态迁移。
熔断器状态模型与超时原理
熔断器的核心是一个有限状态机。closed状态下请求正常放行，当失败次数超过阈值时进入open状态，此时所有请求被快速失败。open状态不能无限持续，也不能立刻回到closed，因此需要引入超时：在open状态停留超过设定时间后，转为half_open状态，放行少量探针请求。如果探针成功，回到closed；如果失败，重新回到open并重置超时计时。
状态转换超时的本质是为每一次状态变更记录时间戳，并在后续决策中比对当前时间与上次变更时间的差值。Ruby中可以用Time.now或Process.clock_gettime获取时间。需要注意系统时钟回拨可能导致超时判断失效，因此对精度要求高的场景应使用单调时钟。下面代码展示了基础状态结构与超时判断逻辑。
class CircuitBreaker
STATE_CLOSED = :closed
STATE_OPEN = :open
STATE_HALF_OPEN = :half_open
def initialize(open_timeout: 5, half_open_timeout: 2)
@state = STATE_CLOSED
@state_since = Process.clock_gettime(Process::CLOCK_MONOTONIC)
@open_timeout = open_timeout
@half_open_timeout = half_open_timeout
end
def allow_request?
now = Process.clock_gettime(Process::CLOCK_MONOTONIC)
case @state
when STATE_OPEN
# 超过open超时则进入半开
if now - @state_since >= @open_timeout
transition_to(STATE_HALF_OPEN)
true
else
false
end
when STATE_HALF_OPEN
# 半开状态超时仍未确认则回到打开
if now - @state_since >= @half_open_timeout
transition_to(STATE_OPEN)
false
else
true
end
else
true
end
end
private
def transition_to(new_state)
@state = new_state
@state_since = Process.clock_gettime(Process::CLOCK_MONOTONIC)
end
end
上面的实现把超时判断直接写在allow_request?方法中，逻辑清晰但耦合较高。实际项目中建议将状态转换规则抽离为独立方法，便于单元测试。另外，半开状态的探针数量通常需要单独计数，而不是仅靠超时控制，否则可能在大流量下瞬间打垮下游。
Ruby中的线程安全与并发控制
在Web服务如Rails或Sinatra中，熔断器对象往往被多个线程同时访问。如果状态和时间戳的读写没有同步保护，可能出现一个线程刚将状态改为half_open，另一个线程读到旧open状态并重复切换。Ruby的全局锁（GVL）能缓解部分CPU竞争，但无法保证复合操作的原子性，因此必须使用Mutex或原子变量。
使用Mutex是最直接的方案。我们把状态相关操作全部放在锁内执行，虽然会带来微小性能损耗，但能彻底避免竞态。下面的例子在之前基础上增加了互斥锁，并支持失败计数与成功重置。
require 'mutex'
class SafeCircuitBreaker
def initialize(failure_threshold: 3, open_timeout: 5)
@mutex = Mutex.new
@state = :closed
@state_since = Process.clock_gettime(Process::CLOCK_MONOTONIC)
@failures = 0
@failure_threshold = failure_threshold
@open_timeout = open_timeout
end
def record_failure
@mutex.synchronize do
@failures += 1
if @state == :closed && @failures >= @failure_threshold
transition_to(:open)
elsif @state == :half_open
transition_to(:open)
end
end
end
def record_success
@mutex.synchronize do
if @state == :half_open
transition_to(:closed)
@failures = 0
end
end
end
def allow?
@mutex.synchronize do
now = Process.clock_gettime(Process::CLOCK_MONOTONIC)
if @state == :open && now - @state_since >= @open_timeout
transition_to(:half_open)
end
@state != :open
end
end
private
def transition_to(state)
@state = state
@state_since = Process.clock_gettime(Process::CLOCK_MONOTONIC)
end
end
如果熔断器需要在多进程（如Puma集群）间共享状态，单机的Mutex就不够了。此时可借助Redis的原子命令，例如用SET配合NX和过期时间存储状态与时间戳，利用Redis#eval执行Lua脚本保证判断与写入的原子性。这种方案牺牲了一定延迟，但能跨进程协调超时转换。
选择线程安全方案时要权衡粒度。锁范围过大时会成为吞吐瓶颈，过小则无法保护复合状态。经验做法是将状态读取、超时判断、状态写入放在同一个临界区，业务调用方在锁外执行真实网络请求，这样锁占用时间仅几微秒。
基于Redis的分布式状态转换超时实现
当Ruby服务部署在多个节点，依赖同一个外部API时，每个节点独立熔断会导致整体仍向下游发送大量请求。用Redis集中管理熔断器状态，可以让所有节点共享open超时与half_open探测结果。核心思路是将状态、时间戳、失败计数序列化为字符串或Hash，通过Lua脚本原子更新。
下面示例用Redis Hash保存熔断器，脚本先读取状态与updated_at，若当前为open且超时则改为half_open并返回允许；若half_open超时则维持open。由于Lua在Redis中单线程执行，不存在并发竞争。Ruby侧只需调用eval即可。
require 'redis'
class RedisCircuitBreaker
def initialize(redis:, key: 'cb:api', open_timeout: 5)
@redis = redis
@key = key
@open_timeout = open_timeout
end
def allow?
script = <<-LUA
local data = redis.call('HMGET', KEYS[1], 'state', 'updated_at')
local state = data[1]
local updated = tonumber(data[2] or '0')
local now = tonumber(ARGV[1])
if state == 'open' and (now - updated) >= tonumber(ARGV[2]) then
redis.call('HMSET', KEYS[1], 'state', 'half_open', 'updated_at', now)
return 1
end
if state == 'half_open' then
return 1
end
if state == 'open' then
return 0
end
return 1
LUA
now = Process.clock_gettime(Process::CLOCK_MONOTONIC).to_i
@redis.eval(script, keys: [@key], argv: [now, @open_timeout])
end
def on_failure
@redis.multi do |pipe|
pipe.hincrby(@key, 'failures', 1)
pipe.hset(@key, 'state', 'open')
pipe.hset(@key, 'updated_at', Process.clock_gettime(Process::CLOCK_MONOTONIC).to_i)
end
end
end
这种实现把超时判断下沉到Redis，Ruby进程崩溃也不会破坏状态机。但要注意时钟基准：Lua里ARGV[1]应传入Redis服务器时间或统一单调时间，避免各节点时钟不一致。此外，网络抖动可能造成Redis调用本身变慢，因此Ruby客户端需设置合理连接超时，防止熔断器检查成为新瓶颈。
对比内存方案，Redis方案在状态转换超时精度上依赖外部存储的可用性与延迟。若Redis短暂不可用，可降级为本地允许请求并打日志，而不是全盘阻断。生产环境中建议将open超时设置为下游平均恢复时间的零点几倍，并配合监控告警，才能既防雪崩又不过度敏感。