## 串行安全网:在不损失性能的前提下实现串行化 本文介绍了一种名为串行安全网(SSN)的新方法,它可以在数据库中实现串行化事务,而不会出现传统方法(如两阶段锁定(2PL))的性能下降问题。现代系统通常优先考虑速度,采用较弱的隔离级别(读已提交或快照隔离),这可能导致数据异常,如写偏差或不可重复读。 SSN充当一个“认证器”,它构建在这些更快、较弱的方案*之上*。它跟踪事务依赖关系,并且只“批准”与其它事务可串行化的事务,从而保证执行历史无环。SSN使用时间戳来计算“水印”——本质上是检查事务的依赖关系是否在时间上形成循环。 虽然类似于乐观并发控制(OCC),但SSN避免了OCC的“重试血战”,因为它具有“安全重试”属性;冲突得以解决,因为发生冲突的事务在重试时已经提交。然而,SSN需要存储额外的时间戳,从而增加了元数据开销,并且不能原生处理幻影插入(需要额外的机制)。 本文认为,将SSN与快照隔离相结合可以提供最佳平衡,在事务执行*期间*提供应用程序一致性——避免因不一致读取而导致崩溃——而SSN则确保整体串行化。
本文详细介绍Cloudflare规则引擎中一个关键且经常被误解的方面:**规则评估顺序至关重要,因为存在“终止动作”。**
作者发现,一个旨在保护`/metrics`端点的`Block`规则,在放置在`JS Challenge`规则*之后*时会被绕过。这是因为完成挑战会设置一个`cf_clearance` cookie,从而自动终止进一步的规则评估——有效地绕过了`Block`规则。
Cloudflare将某些动作(如`Block`、`JS Challenge`等)定义为“终止动作”。如果触发了终止动作,则后续的规则将*不会*被处理。
作者建议按动作类型组织规则,将限制性动作(如`Block`)优先于挑战动作,以确保安全性。虽然未确认大规模的可利用性,但该问题凸显了Cloudflare仪表板中关于规则执行顺序的误导性信息所带来的潜在漏洞。这个问题已被用户注意到多年,正如Serverfault上的类似讨论所示。