分布式锁

起因 之前遇到一些场景,使用了分布式锁,目前来做一个总结 redis 1. 单点redis 单点redis场景,主要容易存在单点故障。(分布式高可用的手段:1.单点故障转移 2.数据冗余) // 获取锁 SET key value NX PX xmilliseconds // 删除锁 if redis.call("get" »

关于锁的总结(三)信号量

难点 个人感觉信号量主要难在应用场景上; 同等对比,互斥量主要用来上锁,条件变量来优化多任务等待 其中互斥量正常场景下,都应该(最好都是遵从这样方式)保持上锁、解锁是同一个task; 在《评论迁移》里面,分布式锁redis的set NX 过程中,参数是key、requireId、expiration,其中requireId(多task环境下唯一ID)就是为了保证上锁、解锁是同一个task 综合来看,好像不需要信号量这类东西的存在 《UNIX »

关于锁的总结(一)互斥量

锁 我们语境下的锁是一种同步机制,用于计算机在多任务环境下访问公共资源达到互斥作用。 临界资源 临界资源(Critical Resource)是一次仅允许一个进程(任务)使用的共享资源 临界区 每个进程(任务)中访问临界资源的代码块。每次只允许一个进程进入临界区(Critical Section) 互斥量 互斥量(mutex),用于保护临界区的。下面举个例子,三个task,其中两个生产者,一个消费者 以下代码有如下假定: »