lua-resty-lock在分布式缓存中的应用

分布式缓存

下图是分布式缓存应用设计中常见的架构，该架构采用redis集群作分布式缓存。

1. 接入层nginx+lua读取本地缓存；
2. 如果缓存没有命中，则接入层会接着读取分布式redis集群的缓存；
3. 如果还是没有命中，则会回溯到服务集群中应用的本地缓存；
4. 如果还是没有命中，则会调用依赖服务获取数据，同时异步写入到redis集群中；

场景

是不是所有项目的分布式缓存都是这样设计的呢？答案当然不是，这只是设计的雏形，在项目使用的时候需要根据实际使用的业务场景决定。比如在业务数据量不大的情况下，可以首先选择应用local redis cache的策略，这种架构是最优秀的。为什么呢？通过在nginx本机部署redis服务,然后通过redis的主从同步机制实现数据的一致性。这样在请求获取数据的时候可以避免网络请求带来的消耗，同时也可以保证数据的一致性。 

值得注意的是在上面的2、3步骤，在缓存没有命中的时候回溯到我们的应用服务。如果我们回溯的并发量过大，将会导致我们应用服务流量大量涌入，可能导致我们的服务不可用或者出现服务延时等情况。那么怎么才能解决这种状况呢？可以采用lua-resty-lock非阻塞式锁来减少回溯应用服务器的量。不过这种策略也需要看具体使用的场景，请求过来获取数据维度过于细分，那么这种策略将会失效。另外4步骤中的异步写入redis集群数据时，我们也需要使用分布式锁来避免多次数据的无效更新。

应用

lua-resty-lock是什么？

lua-resty-lock是一个基于Nginx共享内存（ngx.shared.DICT）的非阻塞锁（基于Nginx的时间事件实现），说它是非阻塞的是因为它不会阻塞Nginx的worker进程，当某个key（请求）获取到该锁后，后续试图对该key再一次获取锁时都会『阻塞』在这里，但不会阻塞其它的key。当第一个获取锁的key将获取到的数据更新到缓存后，后续的key就不会再回源后端应用了，从而可以起到保护后端应用的作用。

lua-resty-lock是干什么的呢？

它是解决缓存失效风暴的利器。缓存失效风暴是指缓存因为时间过期而失效时，会导致所有的请求都去访问 后台的redis或者mysql，而导致CPU性能即刻增长的现象。所以关键是当缓存失效时，用lock保证只有一个线程去访问后台的redis或者mysql，然后更新缓存。需要使用到 lua-resty-lock 模块的加锁、解锁功能。

lua-resty-lock怎么应用呢？

这是lua-resty-lock 官方文档：https://github.com/openresty/lua-resty-lock

这里假设我们使用ngx_lua共享内存字典来缓存Redis查询结果，我们在使用中有如下配置nginx.conf：

设置10m的缓存空间和1m存储锁的空间 

    # you may want to change the dictionary size for your cases.
    lua_shared_dict my_cache 10m;
    lua_shared_dict my_locks 1m;

1.  从本地缓存my_cache中获取数据；
2. 若果存在值直接返回，如果缓存中不存在值就获取resty_lock锁；
3. 再次检查缓存是否有值，因为可能有人把值放入到缓存中；
4. 如果还是没有获取到数据，就从redis集群中获取数据.。如果rereis中也没有获取到数据，就会回溯到服务器获取数据；
5. 更新分布式缓存redis，再更新本地缓存my_cache。

    local resty_lock = require "resty.lock"
    local cache = ngx.shared.my_cache

    -- step 1:
    local val, err = cache:get(key)
    if val then
        ngx.say("result: ", val)
        return
    end

    if err then
        return fail("failed to get key from shm: ", err)
    end

    -- cache miss!
    -- step 2:
    local lock, err = resty_lock:new("my_locks")
    if not lock then
        return fail("failed to create lock: ", err)
    end

    local elapsed, err = lock:lock(key)
    if not elapsed then
        return fail("failed to acquire the lock: ", err)
    end

    -- lock successfully acquired!

    -- step 3:
    -- someone might have already put the value into the cache
    -- so we check it here again:
    val, err = cache:get(key)
    if val then
        local ok, err = lock:unlock()
        if not ok then
            return fail("failed to unlock: ", err)
        end

        ngx.say("result: ", val)
        return
    end    --- step 4:
    local val = fetch_redis(key)
    if not val then
        local ok, err = lock:unlock()
        if not ok then
            return fail("failed to unlock: ", err)
        end
       -- get data from backend

       local val =  get_from_backend(key)

       ngx.say("result: ", val)

       local ok,err = update_redis(val);

       if not ok then

       return fail("failed to upadte redis: ", err)

       end
    end

    -- update the shm cache with the newly fetched value
    local ok, err = cache:set(key, val, 1)
    if not ok then
        local ok, err = lock:unlock()
        if not ok then
            return fail("failed to unlock: ", err)
        end

        return fail("failed to update shm cache: ", err)
    end

    local ok, err = lock:unlock()
    if not ok then
        return fail("failed to unlock: ", err)
    end

    ngx.say("result: ", val)