- Socket 编程发展
- OpenResty 简介
- Lua 入门
- Nginx
- 子查询
- 不同阶段共享变量
- 防止 SQL 注入
- 如何发起新 HTTP 请求
- 访问有授权验证的 Redis
- select+set_keepalive 组合操作引起的数据读写错误
- redis 接口的二次封装(简化建连、拆连等细节)
- redis 接口的二次封装(发布订阅)
- pipeline 压缩请求数量
- script 压缩复杂请求
- 动态生成的 lua-resty-redis 模块方法
- LuaCjsonLibrary
- json解析的异常捕获
- 稀疏数组
- 空table编码为array还是object
- PostgresNginxModule
- 调用方式简介
- 不支持事务
- 超时
- 健康监测
- SQL注入
- LuaNginxModule
- 执行阶段概念
- 正确的记录日志
- 热装载代码
- 阻塞操作
- 缓存
- sleep
- 定时任务
- 禁止某些终端访问
- 请求返回后继续执行
- 调试
- 请求中断后的处理
- 我的 lua 代码需要调优么
- 变量的共享范围
- 动态限速
- shared.dict 非队列性质
- 正确使用长链接
- 如何引用第三方 resty 库
- 典型应用场景
- 怎样理解 cosocket
- 如何安全启动唯一实例的 timer
- 如何正确的解析域名
- LuaRestyDNSLibrary
- 使用动态 DNS 来完成 HTTP 请求
- LuaRestyLock
- 缓存失效风暴
- HTTPS 时代
- 动态加载证书和 OCSP stapling
- TLS session resumption
- 测试
- Web 服务
- 火焰图
- 如何定位问题
- module 是邪恶的
- FFI
- 什么是 JIT
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
LuaRestyLock
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;
- 从本地缓存 my_cache 中获取数据;
- 若果存在值直接返回,如果缓存中不存在值就获取 resty_lock 锁;
- 再次检查缓存是否有值,因为可能有人把值放入到缓存中;
- 如果还是没有获取到数据,就从 redis 集群中获取数据.。如果 rereis 中也没有获取到数据,就会回溯到服务器获取数据;
- 更新分布式缓存 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)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论