Nginx Lua编程实战案例

本节介绍如下3个Nginx Lua编程实战案例：

（1）一个基于Nginx+Redis分布式架构的访问统计实战案例。

（2）一个基于Nginx+Redis+Java容器架构的高并发访问实战案例。

（3）一个基于Nginx+Redis架构的黑名单拦截实战案例。

Nginx+Redis进行分布式访问统计

接口（或者页面）的访问统计是网站运营和优化的一个重要参考数据，对于分布式接口可以通过Nginx+Redis架构来简单实现分布式受访统计。

得益于Nginx的高并发性能和Redis的高速缓存，基于Nginx+Redis的受访统计的架构设计比纯Java实现受访统计的架构设计在性能上高出很多。

作为参考案例，这里使用前面定义的RedisOperator基础操作类编写了一个简单的受访统计类，具体的代码如下：

---启动调试，正式环境请注释
local mobdebug = require("luaScript.initial.mobdebug");
mobdebug.start();
--导入自定义的RedisOperator模块
local redisOp = require("luaScript.redis.RedisOperator");
--创建自定义的redis操作对象
local red = redisOp:new();
--打开连接
red:open();
--获取访问次数
local visitCount = red:incrValue("demo:visitCount");
if visitCount == 1 then
 --10秒内过期
 red:expire("demo:visitCount", 10);
end
--将访问次数设置到Nginx变量
ngx.var.count = visitCount;
--归还连接到连接池
red:close();

在nginx-redis-demo.conf配置文件中编写一个location配置块来使用该脚本，建议将该脚本执行于access阶段而不是content阶段，具体代码如下：

#点击次数统计的演示
 location /visitcount {
 #定义一个Nginx变量，用于在Lua脚本中保存访问次数
 set $count 0;
 access_by_lua_file luaScript/redis/RedisVisitCount.lua;
 echo "10s内总的访问次数为: " $count;
 }

修改nginx-redis-demo.conf文件后重启Openrestry，然后使用浏览器访问其地址/visitcount，并且在浏览器中不断刷新，发现每刷新一次，页面的统计次数会加一，其结果如图8-23所示。

Nginx+Redis+Java容器实现高并发访问

在不需要高速访问的场景下，运行在Java后端的容器（如Tomcat）会直接从DB数据库（如MySQL）查询数据，然后返回给客户端。

由于数据库的连接数限制、网络传输延迟、数据库的IO频繁等多方面的原因，Java后端容器直接查询DB的性能会很低，这时会进行架构的调整，采用“Java容器+Redis+DB”的查询架构。针对数据一致性要求不是特别高但是访问频繁的API接口（实际上大部分都是），可以将DB数据放入Redis缓存，Java API可以优先查询Redis，如果缓存未命中，就回源到DB查询，从DB查询成功后再将数据更新到Redis缓存。

“Java容器+Redis+DB”的查询架构既起到Redis分流大量查询请求的作用，又大大提升了API接口的处理性能，可谓一举两得。该架构的请求处理流程如图8-24所示。

大家知道，常用的后端Java容器（如Tomcat、Jetty等）的性能其实不是太高，QPS性能指标一般会在1000以内。从笔者经历过的很多次性能攻关的数据来看，Nginx的性能是Java容器的10倍左右（甚至以上），并且稳定性更强，还不存在FullGC卡顿。

为了应对高并发，可以将“Java容器+Redis+DB”架构优化为“Nginx+Redis+Java容器”查询架构。新架构将后端Java容器的缓存判断、缓存查询前移到反向代理Nginx，通过Nginx直接进行Redis缓存判断、缓存查询。

“Nginx+Redis+Java容器”的查询架构不仅为Java容器减少了很多请求，而且能够充分发挥Nginx的高并发优势和稳定性优势。该架构的请求处理流程如图8-25所示。

这里以秒杀系统的商品数据查询为例提供一个“Nginx+Redis+Java容器”查询架构的参考实现。首先定义两个接口：一个模拟Java容器的商品查询接口；另一个模拟供外部调用的商品查询接口：

·模拟Java容器的商品查询接口：/java/good/detail。·模拟供外部调用的商品查询接口：/good/detail。

然后提供一个Lua操作缓存的类RedisCacheDemo，主要定义如下3个方法：

（1）getCache（self，goodId）：根据商品id取得Redis商品缓存。

（2）goUpstream（self）：通过capture内部请求访问上游接口获取商品数据。

（3）setCache（self，goodId，goodString）：设置商品缓存，此方法用于模拟后台Java代码。

缓存操作类RedisCacheDemo的核心代码如下：

---启动调试，正式环境请注释
local mobdebug = require("luaScript.initial.mobdebug");
mobdebug.start();
--导入自定义的基础模块
local basic = require("luaScript.module.common.basic");
--导入自定义的RedisOperator模块
local redisOp = require("luaScript.redis.RedisOperator");
local PREFIX = "GOOD_CACHE:"
--RedisCacheDemo类
local _RedisCacheDemo = { }
_RedisCacheDemo.__index = _RedisCacheDemo
--类的方法new
function _RedisCacheDemo.new(self)
 local object = {}
 setmetatable(object, self)
 return object;
end
--根据商品id取得缓存
function _RedisCacheDemo.getCache(self,goodId)
 --创建自定义的redis操作对象
 local red = redisOp:new();
 --打开连接
 if not red:open() then
 basic:error("redis连接失败");
 return nil;
 end
 --获取缓存数据 local json = red:getValue(PREFIX .. goodId);
 red:close();
 if not json or json==ngx.null then
 basic:log(goodId .. "的缓存没有命中");
 return nil;
 end
 basic:log(goodId .. "缓存成功命中");
 return json;
end
--通过capture方法回源上游接口
function _RedisCacheDemo.goUpstream(self)
 local request_method = ngx.var.request_method
 local args = nil
 --获取参数的值
 if "GET" == request_method then
 args = ngx.req.get_uri_args()
 elseif "POST" == request_method then
 ngx.req.read_body()
 args = ngx.req.get_post_args()
 end
 --回源上游接口,比如Java后端rest接口
 local res = ngx.location.capture("/java/good/detail",{
 method = ngx.HTTP_GET,
 args = args --重要：将请求参数原样向上游传递
 })
 basic:log("上游数据获取成功");
 --返回上游接口的响应体body
 return res.body;
end
--设置缓存，此方法主要用于模拟Java后台代码
function _RedisCacheDemo.setCache(self, goodId ,goodString)
 --创建自定义的redis操作对象
local red = redisOp:new();
 --打开连接
 if not red:open() then
 basic:error("redis连接失败");
 return nil;
 end
 --set缓存数据
 red:setValue(PREFIX .. goodId,goodString);
 --60秒内过期
 red:expire(PREFIX .. goodId, 60);
 basic:log(goodId .. "缓存设置成功");
 --归还连接到连接池
 red:close();
 return json;
end
return _RedisCacheDemo;

在nginx-redis-demo.conf配置文件中编写一个location配置块来使用该脚本，该配置块是提供给外部调用的商品查询接口/good/detail，具体代码如下：

首先从缓存中查询商品
未命中再回源到
后台 #首先从缓存中查询商品，未命中再回源到Java后台
 location = /good/detail {
 content_by_lua_block {
 local goodId=ngx.var.arg_goodid;
 --判断goodId参数是否存在
 if not goodId then
 ngx.say("请输入goodId");
 return;
 end
 --首先从缓存中根据id查询商品
 local RedisCacheDemo = require "luaScript.redis.RedisCacheDemo";
 local redisCacheDemo = RedisCacheDemo:new();
 local json = redisCacheDemo:getCache(goodId);
 --判断缓存是否被命中
 if not json then
 ngx.say("缓存是否被命中，回源到上游接口<br>");
 --若没有命中缓存，则回源到上游接口
 json = redisCacheDemo:goUpstream();
 else
 ngx.say("缓存已经被命中<br>");
 end
 ngx.say("商品信息：",json);
 }
 }

出于调试方便，在nginx-redis-demo.conf配置文件中再编写一个location配置块来模拟Java容器的后台商品查询接口/java/good/detail。

理论上，后台接口的业务逻辑是从数据库查询商品信息并缓存到Redis，然后返回商品信息。这里为了方便演示对其进行简化，具体的代码如下：

 #模拟Java后台接口查询商品，然后设置缓存
 location = /java/good/detail {
 #指定规则为internal内部规则，防止外部请求命中此规则
 internal;
 content_by_lua_block {
 local RedisCacheDemo = require "luaScript.redis.RedisCacheDemo";
 --Java后台将从数据库查找商品，这里简化成模拟数据
 local json='{goodId:商品id,goodName:商品名称}';
 --将商品缓存到Redis
 local redisCacheDemo = RedisCacheDemo:new();
 redisCacheDemo:setCache(ngx.var.arg_goodid, json);
 --返回商品到下游网关
 ngx.say(json);
 }
 }

 }

修改了nginx-redis-demo.conf文件后重启OpenRestry，然后使用浏览器访问商品查询外部接口/good/detail，并且多次刷新，发现从二次请求开始就能成功命中缓存，其结果如图8-26所示。

Nginx+Redis实现黑名单拦截

我们在日常维护网站时经常会遇到这样一个需求，对于黑名单之内的IP需要拒绝提供服务。实现IP黑名单拦截有很多途径，比如以下方式：

（1）在操作系统层面配置iptables防火墙规则，拒绝黑名单中IP的网络请求。

（2）使用Nginx网关的deny配置指令拒绝黑名单中IP的网络请求。

（3）在Nginx网关的access处理阶段，通过Lua脚本检查客户端IP是否在黑名单中。

（4）在Spring Cloud内部网关（如Zuul）的过滤器中检查客户端

IP是否在黑名单中。

以上检查方式都是基于一个静态的、提前备好的黑名单进行的。在系统实际运行过程中，黑名单往往需要动态计算，系统需要动态识别出大量发起请求的恶意爬虫或者恶意用户，并且将这些恶意请求的IP放入一个动态的IP黑名单中。

Nginx网关可以依据动态黑名单内的IP进行请求拦截并拒绝提供服务。这里结合Nginx和Redis提供一个基于动态IP黑名单进行请求拦截的实现。

首先是黑名单的组成，黑名单应该包括静态部分和动态部分。静态部分为系统管理员通过控制台设置的黑名单。动态部分主要通过流计算框架完成，具体的方法为：将Nginx的访问日志通过Kafka消息中间件发送到流计算框架，然后通过滑动窗口机制计算出窗口内相同IP的访问计数，将超出阈值的IP动态加入黑名单中，流计算框架可以选用ApacheFlink或者Apache Storm。当然，除了使用流计算框架外，也可以使用RxJava滑动窗口进行访问计数的统计。

这里对黑名单的计算和生成不做研究，假定IP黑名单已经生成并且定期更新在Redis中。Nginx网关可以直接从Redis获取计算好的IP黑名单，但是为了提升黑名单的读取速度，并不是每一次请求过滤都从Redis读取IP黑名单，而是从本地的共享内存black_ip_list中获取，同时定期更新到本地共享内存中的IP黑名单。

Nginx+Redis实现黑名单拦截的系统架构如图8-27所示。

这里提供一个“Nginx+Redis”实现黑名单拦截的参考实现，具体的Lua脚本如下：

---启动调试，正式环境请注释
local mobdebug = require("luaScript.initial.mobdebug");
mobdebug.start();
--导入自定义的基础模块
local basic = require("luaScript.module.common.basic");
--导入自定义的RedisOperator模块
local redisOp = require("luaScript.redis.RedisOperator");local ip = basic.getClientIP();
basic.log("ClientIP:"..ip);
--lua_shared_dict black_ip_list 1m; #配置文件定义的ip_blacklist共享内存变量
local black_ip_list = ngx.shared.black_ip_list
--获得本地缓存的刷新时间，如果没有过期，就直接使用
local last_update_time = black_ip_list:get("last_update_time");
if last_update_time ~= nil then
 local dif_time = ngx.now() - last_update_time
 if dif_time < 60 then --缓存1分钟，没有过期
 if black_ip_list:get(ip) then
 return ngx.exit(ngx.HTTP_FORBIDDEN) --直接返回403
 end
 return
 end
end
local KEY = "limit:ip:blacklist";
--创建自定义的redis操作对象
local red = redisOp:new();
--打开连接
red:open();
--获取缓存的黑名单
local ip_blacklist = red:getSmembers(KEY);
--归还连接到连接池
red:close();
if not ip_blacklist then
 basic.log("black ip set is null");
 return;
else
 --刷新本地缓存
 black_ip_list:flush_all();
 --同步redis黑名单到本地缓存
 for i,ip in ipairs(ip_blacklist) do
 --本地缓存redis中的黑名单
 black_ip_list:set(ip,true);
 end
 --设置本地缓存的最新更新时间
 black_ip_list:set("last_update_time",ngx.now());
end
if black_ip_list:get(ip) then
 return ngx.exit(ngx.HTTP_FORBIDDEN) --直接返回403
end

该脚本名称为black_ip_filter.lua，作为测试，在nginx-redisdemo.conf配置文件中编写一个location配置块来执行该脚本，建议将该脚本执行于access阶段而不是content阶段，具体代码如下：

 location /black_ip_demo {
 access_by_lua_ file luaScript/redis/black_ip_filter.lua;
 echo "恭喜，没有被拦截";
 }

另外，black_ip_filter.lua使用了名称为black_ip_list的共享内存区进行黑名单本地缓存，所以需要在配置文件中进行共享内存空间的定义，具体如下：

 #定义存储IP黑名单的共享内存变量
 lua_shared_dict black_ip_list 1m;

这里使用lua_shared_dict指令定义了一块1MB大小的共享内存，有关该指令的使用方法在8.8.4节详细展开。修改nginx-redis-demo.conf文件后重启Openrestry，然后使用浏览器访问/black_ip_demo的完整链接地址，第一次访问时客户端IP没有加入黑名单，所以请求没有被拦截，结果如图8-28所示。

在Redis服务器上新建Set类型的键limit：ip：blacklist，并加入最新的当前客户端IP。然后再一次访问/black_ip_demo，发现请求已经被拦截，结果如图8-29所示。

使用Nginx Lua共享内存

Nginx Lua共享内存就是在内存块中分配出一个内存空间，该共享内存是一种字典结构，类似于Java Map的键-值（Key-Value）映射结构。同一个Nginx下的Worker进程都能访问存储在这里面的变量数据。

在Lua中定义共享内存非常简单，具体的指令如下：

语法：lua_shared_dict　<DICT>　<size>
上下文：http配置块。
例子：
lua_shared_dict black_ip_list 1m; #定义存储IP黑名单的共享内存变量lua_shared_dict指令用于定义一块名为DICT的共享内存空间，其内存大小为size。通过该命令定义的共享内存对于Nginx中所有Worker进程都是可见的。对于共享内存的引用可以使用以下两种形式来完成：
方式一：ngx.shared.DICT。
方式二：ngx.shared["DICT"]。

ngx_lua提供了一系列API来操作共享内存，如表8-7所示。

如果读者熟悉Redis字符串的操作命令和参数，就会发现以上操作Niginx共享内存的API方法和Redis字符串的操作命令和参数有惊人的相似之处。

共享内存的API方法都是原子操作，也就是说，lua_shared_dict定义的是同一个共享内存区自带锁的功能，能够避免来自多个Worker工作进程的并发访问。

有关数据项的过期时间可以在新增数据项的时候进行设置。在新增数据项时，如果字典的内存区域不够，ngx.shared.DICT.set方法就会根据LRU算法淘汰一部分内容。当Nginx退出时，共享内存中的数据项都会丢失。

本文给大家讲解的内容是Nginx/OpenResty详解，Nginx Lua编程， Nginx Lua编程实战案例

1. 下篇文章给大家讲解的是 Nginx/OpenResty详解，Nginx Lua编程，限流原理与实战；
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！