秒杀系统 | 多级查询缓存 | OpenResty 直连 Redis
OpenResty 为什么要直连 Redis?
-
OpenResty 到 Redis 的连接只读不写; 当 OpenResty 在 Redis 中没有命中的情况下,请求打到应用服务器,应用服务器在 Redis 中应该也是没有命中的,然后请求会打到 MySQL,从 MySQL 中得到数据后,写入 Redis; OpenResty 直连 Redis 是解决 Nginx 的 Shared Dic 不能主动更新的问题,在 Nginx 的 Shared Dic 方案中,前置缓存中的数据只能被动的超时剔除;而 OpenResty 直连 Redis 的方案中,当 MySQL 中的数据更新后,可以更新 Redis 中的数据,这样请求在 OpenResty 中命中的话,得到的数据也是最新的; Nginx 的 Shared Dic 方案和 OpenResty 直连 Redis 方案一般是相互替换的关系;
OpenResty 直连 Redis 实战
-
创建 itemredis.lua 脚本,该脚本中实现 OpenResty 试图先去 Redis 中查询数据的逻辑:
local args = ngx.req.get_uri_args() local id = args["id"] local redis = require "resty.redis" local cache = redis:new() local ok, err = cache:connect("127.0.0.1", 6379) cache:select(10) local item_model = cache:get("item_"..id) if item_model == ngx.null or item_model == nil then local resp = ngx.location.capture("/item/get?id="..id) item_model = resp.body end ngx.say(item_model)
-
修改 nginx.conf
location /luaitem/get { default_type "application/json"; content_by_lua_file ../lua/itemredis.lua; }
-
重启 nginx
sudo sbin/nginx -s reload
文件 /home/lixinlei/application/openresty/lualib/resty/redis.lua 实现了对 Redis 的一些通用操作,OpenResty 对 Redis 的操作就基于这个文件;
压测结果
-
TPS 达到 3300,比 Nginx 的 Shared Dic 方案要慢一点,多了个访问 Redis 服务器的网络时间;
设计考量
-
热点数据当然是放的越前越好; 但有些数据不是特别的热,还有些更新的操作,那么建议使用 OpenResty 直连 Redis 的方案,可以保证数据更新后,OpenResty 可以在 Redis 中命中数据的最新值;或者直接在 Tomcat 层面完成对 Redis 的操作; 缓存推的越靠前,性能表现越好,占用分布式资源越多,更新越困难; 根据跟新策略、数据热的程度、业务上对脏读的忍受程度;
上一篇:
IDEA上Java项目控制台中文乱码