openresty lua-resty-lock数据库锁

---

openresty lua-resty-lock数据库锁

           

官网：https://github.com/openresty/lua-resty-lock

           

                

                                          

lua-resty-lock 说明

           

This library implements a simple mutex lock in a similar way to 
ngx_proxy module's proxy_cache_lock directive.
* lua-resty-lock锁为互斥锁

Under the hood, this library uses ngx_lua module's shared memory 
dictionaries. The lock waiting is nonblocking because we use 
stepwise ngx.sleep to poll the lock periodically
* 使用ngx_lua的共享模块实现锁
* 锁非阻塞，使用ngx.sleep等待，周期性地获取锁状态

        

new：创建锁

语法格式：obj, err = lock:new(dict_name, opts?)

Creates a new lock object instance by specifying the shared dictionary 
name (created by lua_shared_dict) and an optional options table opts.
* 使用共享空间实现锁，opts参数可选

In case of failure, returns nil and a string describing the error.
* 如果失败，返回nil、错误描述信息

# opts可选参数
* exptime：锁过期时间，默认30s，可精确到0.001s
* timeout：等待获取锁的超时时间，默认5s，设置为0表示如果获取不到锁，不等待直接离开
* step：锁初始等待时间，单位为秒，可精确到0.001s
* ratio：锁等待时间的放大比例，默认2，每次等待获取锁sleep时长变为上次2倍
* max_step：最大sleep时长，默认0.5s

                  

lock：加锁

语法格式：elapsed, err = obj:lock(key)

Tries to lock a key across all the Nginx worker processes in the 
current Nginx server instance. Different keys are different locks.
The length of the key string must not be larger than 65535 bytes.
* 所有的worker进程获取同一把锁
* 不同的key表示不同的锁
* key的长度不能大于65535字节

Returns the waiting time (in seconds) if the lock is successfully acquired. Otherwise returns nil and a string describing the error.
* 如果加锁成功，返回等待时间
* 加锁失败，返回nil、错误描述信息

The waiting time is not from the wallclock, but rather is from simply 
adding up all the waiting "steps". A nonzero elapsed return value indicates 
that someone else has just hold this lock. But a zero return value cannot 
gurantee that no one else has just acquired and released the lock.
* 等待时间是所有steps的和
* 非0值表示有其他worker持有锁
* 0不一定表示又其他worker持有锁，并刚刚释放锁

When this method is waiting on fetching the lock, no operating system 
threads will be blocked and the current Lua "light thread" will be 
automatically yielded behind the scene.
* 等待获取锁期间，操作系统线程不会阻塞
* 当前的lua ligth thread会自动让出cpu

It is strongly recommended to always call the unlock() method to 
actively release the lock as soon as possible.
* 建议释放锁的时候手动调用unlock

If the unlock() method is never called after this method call, the 
lock will get released when
    the current resty.lock object instance is collected automatically by the Lua GC.
    the exptime f