使用S3条件写入进行领导者选举
内容提要
在分布式系统中，领导者选举是防止任务重复执行的重要机制。AWS在S3中引入了条件写入功能，通过If-None-Match头实现分布式锁定。节点竞争创建锁文件，成功者成为领导者，锁文件包含过期属性以确保任务完成后释放锁。为避免领导者崩溃导致系统停滞，可以设置锁的有效期。尽管时钟漂移可能影响系统吞吐量，领导选举最终会正确。
延伸解读
S3条件写入的局限与适用场景
S3新支持的If-None-Match条件写入仅能防止创建已存在的对象，无法阻止对现有文件的更新丢失。因此，它适合实现领导者选举中的锁文件创建，但不适用于需要CAS更新现有对象的场景。与GCP和Azure的完整CAS操作相比，S3的功能较为有限，但对于仅使用对象存储的应用，它避免了引入ZooKeeper等外部服务的运维和成本开销。
锁过期机制与活性保障
领导者崩溃时若未释放锁，系统将无法选举新领导者。通过为锁文件添加validity_ms属性（如60秒），并利用S3提供的最后修改时间戳，其他节点可以判断锁是否过期。领导者也可定期更新文件以延长租约。这种机制确保了系统的活性，但需注意只有创建锁的进程才能将其标记为过期，否则可能引发混乱。
时钟漂移的影响与应对
节点间时钟不一致可能导致领导者过早停止工作或非领导者延迟获取领导权，影响吞吐量，但不会破坏正确性。然而，若领导者因时钟落后而继续工作，或非领导者因时钟超前而提前夺权，则会出现双领导者。根本原因在于检查锁有效性与执行工作非原子。因此，领导者选举只能最终正确，必须使用 fencing token（如递增的epoch）来识别并拒绝旧领导者的请求。
实践中的 fencing 与时钟同步
为减少时钟漂移带来的吞吐量影响，可尽力保持时钟同步，例如通过S3临时文件比较创建时间，或使用Amazon Time Sync Service。对于不支持fencing token的远程API，可传递epoch作为请求头，由API维护最高epoch并丢弃僵尸请求。针对S3，SlateDB通过按序上传文件并检测冲突来实现类似效果。这些措施有助于在最终一致的前提下提升系统安全性。
Q&A
什么是领导者选举，它在分布式系统中有什么作用？
领导者选举是在分布式系统中选择一个节点作为领导者，以防止任务重复执行的重要机制。
AWS S3的条件写入功能如何支持领导者选举？
AWS S3的条件写入功能通过If-None-Match头实现分布式锁定，允许节点竞争创建锁文件，成功者成为领导者。
如何设置锁的有效期以避免领导者崩溃导致系统停滞？
可以在锁文件中添加有效期属性，定义锁的有效时间，以确保在领导者崩溃时能够选举新的领导者。
时钟漂移对领导者选举有什么影响？
时钟漂移可能影响系统吞吐量，但不会影响领导者选举的正确性，领导选举最终会正确。
在领导者选举中，如何处理领导者崩溃的情况？
可以通过设置锁文件的过期属性来处理领导者崩溃，确保其他节点能够检测到并选举新的领导者。
如何使用AWS Java SDK实现锁的创建？
使用AWS Java SDK时，可以通过PutObjectRequest设置If-None-Match头来尝试创建锁文件，并处理412响应。
