3.10. 分布式锁使用

var balance = db.account.getBalance(id)
if(balance < amount){
  return error("余额少于扣款金额")
}
db.account.updateBalance(id,-amount)

synchronized {
    var balance = db.account.getBalance(id)
    if(balance < amount){
      return error("余额少于扣款金额")
    }
    db.account.updateBalance(id,-amount)
}

• Set化后的MQ替代分布式锁，比如上面的例子，我们可以按用户ID做Set（用户ID % Set数）进而分成多个组，为不同的组创建不同的MQ队列，这样一个用户同一时间只在一个队列中，一个队列的处理是串行化的，实现了锁的功能，同时又有多个Set来完成并行化，在性能上会好于分布式锁，并且代码上没有太多改动
• 使用乐观锁，再如上面的例子，为account创建一个更新版本字段（update_version）,每次更新时版本加1，更新的条件是版本号要等于传入版本号：

  var (balance,currentVersion) = db.account.getBalanceAndVersion(id)
  if(balance < amount){
    return error("余额少于扣款金额")
  }
  // 此操作对应的SQL: UPDATE account SET balance = balance  - <amount> , update_verison = update_verison + 1 WHERE id = <id> AND update_version = <currentVersion>
  if(db.account.updateBalance(id,-amount, currentVersion) == 0){
  return error("扣款失败") // 或递归执行此代码进行重试
  }
  

• 锁释放与超时 正常情况下，只要我们在使用完锁后在finally中加上锁释放的代码就可以了，比如下面的代码：

  val lock=new Lock()
  if(lock.tryLock()){
      try{
          // 业务处理
      }catch(Exception ex){
          // 业务异常处理
      }finally{
          //释放锁
          lock.unlock();
      }
  }
  

  这是单机版锁上我们常用的逻辑，unlock在finally确保每次加锁都会解锁，即使在执行业务处理或业务异常处理时OOM了也不会死锁（因为此时锁也没了），但在分布式环境下网络是不可靠的，节点是可能宕机的，这种情况下就很可能出现锁无法释放，比如上述情况下的OOM就可能导致死锁，再比如正常执行了unlock代码，但网络传输时丢失了unlock信号也可能导致死锁，所以我们必须要加上超时时间，如（tryLock(<等待锁的时长>,<锁占用的最大时长>)），超时时间设置过长会导致服务异常后无法及时获取新的锁，过短又有可能在业务没有执行完锁提前释放了。更优雅但偏复杂的方法是使用心跳超时设置，即与占有锁的服务保持心跳，在心跳超时后再释放锁
• 性能及高可用 出于性能考虑，一般分布式锁都是非公平锁，如果要保证加锁顺序而选用公平锁时要注意对性能的影响，加解锁操作本身要保证性能及可用性，避免单点，锁信息要持久化，慎用自旋避免CPU浪费
• 数据一致性 分布式锁要合理设置锁标记以区分是哪个实例、哪个线程的操作，可重入锁要做好计数及相应的unlock次数，同时必须保证数据的一致，这要求我们只能选择CP特性（见下文）的服务作为分布式锁的中间件

• 关系型数据库 由关系型数据库的某些特性来实现，比如使用主键唯一性约束及数据一致来确保同一时间只有一个请求能获得锁，这一方案实现简单，但对高并发场景或可重入时存在比较大的性能瓶颈
• Redis 可使用Redis单线程、原子化操作（setnx）来实现，这一方案也很简单，但因为没有原子化的值比较方法，无法原子化确认占用锁的是否是当前实例的当前线程导致比较难实现重入锁，另外Redis单节点有高可用问题，多节点引入RedLock也存在比较大的争议。当然在绝大多数情况下大家还是可以放心使用的
• Zookeeper 可使用Zookeeper的持久节点（PERSISTENT）、临时节点（EPHEMERAL），时序节点（SEQUENTIAL ）的特性组合及watcher接口实现，这一方案可保证最为严格的数据一致性、在性能及高可用也有着比较好的表现，推荐对一致性高要求极高、并发量大的场景使用