为什么Redis没有实现典型的加锁功能?

在访问以写入为目的数据的时候（SOL中的SELECT FOR UPDATE),关系数据库会对被访同的数据行进行加锁，直到事务被提交（Commit）
或者被回滚（ROLLBACK）为止，如果有其他客户端试图对被加锁的数据行进行写入，那么该客户端将被阻塞、直到第一个事务执行完毕为止。加锁在实际使用中非常有效，基本上所有关系数据库都实现了这种加锁功能，它的缺点在于，持有锁的客户端运行越慢，等待解锁的客户端被阻塞的时间就越长。

因为加锁有可能会造成长时间的等待，所以Redis为了尽可能地减少客户端的等待时间，并不会在执行WATCH命令时对数据进行加锁，相反地，Redis只会在数据已经被其他客户端抢先修改了的情况下，通知执行了WATCH命令的客户端，这种做法被称为乐观镇（optimistic locking)，而关系数据库实际执行的加锁操作则被称为悲观锁（pessimistic locking).乐观锁在实际使用中同样非常有效，因为客户端水选不必花时间去等待第一个取得锁的客户端——它们只需要在自己的事务执行失败时进行重试就可以了。