ImageVerifierCode 换一换
格式:DOCX , 页数:15 ,大小:898.66KB ,
资源ID:25695801      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/25695801.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(Nginx Lua编程实战案例.docx)为本站会员(b****9)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

Nginx Lua编程实战案例.docx

1、Nginx Lua编程实战案例3个Nginx Lua编程实战案例本节介绍如下3个Nginx Lua编程实战案例:(1)一个基于Nginx+Redis分布式架构的访问统计实战案例。(2)一个基于Nginx+Redis+Java容器架构的高并发访问实战案例。(3)一个基于Nginx+Redis架构的黑名单拦截实战案例。Nginx+Redis进行分布式访问统计接口(或者页面)的访问统计是网站运营和优化的一个重要参考数据,对于分布式接口可以通过Nginx+Redis架构来简单实现分布式受访统计。得益于Nginx的高并发性能和Redis的高速缓存,基于Nginx+Redis的受访统计的架构设计比纯Jav

2、a实现受访统计的架构设计在性能上高出很多。作为参考案例,这里使用前面定义的RedisOperator基础操作类编写了一个简单的受访统计类,具体的代码如下:-启动调试,正式环境请注释local mobdebug = require(luaScript.initial.mobdebug);mobdebug.start();-导入自定义的RedisOperator模块local redisOp = require(luaScript.redis.RedisOperator);-创建自定义的redis操作对象local red = redisOp:new();-打开连接red:open();-获取访问

3、次数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

4、 #定义一个Nginx变量,用于在Lua脚本中保存访问次数 set $count 0; access_by_lua_file luaScript/redis/RedisVisitCount.lua; echo 10s内总的访问次数为: $count; 修改nginx-redis-demo.conf文件后重启Openrestry,然后使用浏览器访问其地址/visitcount,并且在浏览器中不断刷新,发现每刷新一次,页面的统计次数会加一,其结果如图1所示。图1 访问统计效果图Nginx+Redis+Java容器实现高并发访问在不需要高速访问的场景下,运行在Java后端的容器(如Tomcat)会直

5、接从DB数据库(如MySQL)查询数据,然后返回给客户端。由于数据库的连接数限制、网络传输延迟、数据库的IO频繁等多方面的原因,Java后端容器直接查询DB的性能会很低,这时会进行架构的调整,采用“Java容器+Redis+DB”的查询架构。针对数据一致性要求不是特别高但是访问频繁的API接口(实际上大部分都是),可以将DB数据放入Redis缓存,Java API可以优先查询Redis,如果缓存未命中,就回源到DB查询,从DB查询成功后再将数据更新到Redis缓存。“Java容器+Redis+DB”的查询架构既起到Redis分流大量查询请求的作用,又大大提升了API接口的处理性能,可谓一举两得

6、。该架构的请求处理流程如图8-24所示。图2 “Java容器+Redis+DB”查询架构的请求处理流程大家知道,常用的后端Java容器(如Tomcat、Jetty等)的性能其实不是太高,QPS性能指标一般会在1000以内。从笔者经历过的很多次性能攻关的数据来看,Nginx的性能是Java容器的10倍左右(甚至以上),并且稳定性更强,还不存在FullGC卡顿。为了应对高并发,可以将“Java容器+Redis+DB”架构优化为“Nginx+Redis+Java容器”查询架构。新架构将后端Java容器的缓存判断、缓存查询前移到反向代理Nginx,通过Nginx直接进行Redis缓存判断、缓存查询。“

7、Nginx+Redis+Java容器”的查询架构不仅为Java容器减少了很多请求,而且能够充分发挥Nginx的高并发优势和稳定性优势。该架构的请求处理流程如图8-25所示。图3 “Nginx+Redis+Java容器”查询架构的请求处理流程这里以秒杀系统的商品数据查询为例提供一个“Nginx+Redis+Java容器”查询架构的参考实现。首先定义两个接口:一个模拟Java容器的商品查询接口;另一个模拟供外部调用的商品查询接口:模拟Java容器的商品查询接口:/java/good/detail。模拟供外部调用的商品查询接口:/good/detail。然后提供一个Lua操作缓存的类RedisCac

8、heDemo,主要定义如下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 =

9、 require(luaSmon.basic);-导入自定义的RedisOperator模块local redisOp = require(luaScript.redis.RedisOperator);local PREFIX = GOOD_CACHE:-RedisCacheDemo类local _RedisCacheDemo = _RedisCacheDemo._index = _RedisCacheDemo-类的方法newfunction _RedisCacheDemo.new(self) local object = setmetatable(object, self) return o

10、bject;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 . 的缓

11、存没有命中); 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.r

12、ead_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

13、 ,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;endreturn _RedisCac

14、heDemo;在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查询商

15、品 local RedisCacheDemo = require luaScript.redis.RedisCacheDemo; local redisCacheDemo = RedisCacheDemo:new(); local json = redisCacheDemo:getCache(goodId); -判断缓存是否被命中 if not json then ngx.say(缓存是否被命中,回源到上游接口); -若没有命中缓存,则回源到上游接口 json = redisCacheDemo:goUpstream(); else ngx.say(缓存已经被命中); end ngx.say(商

16、品信息:,json); 出于调试方便,在nginx-redis-demo.conf配置文件中再编写一个location配置块来模拟Java容器的后台商品查询接口/java/good/detail。理论上,后台接口的业务逻辑是从数据库查询商品信息并缓存到Redis,然后返回商品信息。这里为了方便演示对其进行简化,具体的代码如下: #模拟Java后台接口查询商品,然后设置缓存 location = /java/good/detail #指定规则为internal内部规则,防止外部请求命中此规则 internal; content_by_lua_block local RedisCacheDemo

17、= 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,然后使用浏览器访问商品查询外部接口/

18、good/detail,并且多次刷新,发现从二次请求开始就能成功命中缓存,其结果如图8-26所示。图4使用浏览器访问商品查询外部接口/good/detail的结果Nginx+Redis实现黑名单拦截我们在日常维护网站时经常会遇到这样一个需求,对于黑名单之内的IP需要拒绝提供服务。实现IP黑名单拦截有很多途径,比如以下方式:(1)在操作系统层面配置iptables防火墙规则,拒绝黑名单中IP的网络请求。(2)使用Nginx网关的deny配置指令拒绝黑名单中IP的网络请求。(3)在Nginx网关的access处理阶段,通过Lua脚本检查客户端IP是否在黑名单中。(4)在Spring Cloud内部

19、网关(如Zuul)的过滤器中检查客户端IP是否在黑名单中。以上检查方式都是基于一个静态的、提前备好的黑名单进行的。在系统实际运行过程中,黑名单往往需要动态计算,系统需要动态识别出大量发起请求的恶意爬虫或者恶意用户,并且将这些恶意请求的IP放入一个动态的IP黑名单中。Nginx网关可以依据动态黑名单内的IP进行请求拦截并拒绝提供服务。这里结合Nginx和Redis提供一个基于动态IP黑名单进行请求拦截的实现。首先是黑名单的组成,黑名单应该包括静态部分和动态部分。静态部分为系统管理员通过控制台设置的黑名单。动态部分主要通过流计算框架完成,具体的方法为:将Nginx的访问日志通过Kafka消息中间件

20、发送到流计算框架,然后通过滑动窗口机制计算出窗口内相同IP的访问计数,将超出阈值的IP动态加入黑名单中,流计算框架可以选用ApacheFlink或者Apache Storm。当然,除了使用流计算框架外,也可以使用RxJava滑动窗口进行访问计数的统计。这里对黑名单的计算和生成不做研究,假定IP黑名单已经生成并且定期更新在Redis中。Nginx网关可以直接从Redis获取计算好的IP黑名单,但是为了提升黑名单的读取速度,并不是每一次请求过滤都从Redis读取IP黑名单,而是从本地的共享内存black_ip_list中获取,同时定期更新到本地共享内存中的IP黑名单。Nginx+Redis实现黑名

21、单拦截的系统架构如图8-27所示。图5Nginx+Redis实现黑名单拦截的系统架构这里提供一个“Nginx+Redis”实现黑名单拦截的参考实现,具体的Lua脚本如下:-启动调试,正式环境请注释local mobdebug = require(luaScript.initial.mobdebug);mobdebug.start();-导入自定义的基础模块local basic = require(luaSmon.basic);-导入自定义的RedisOperator模块local redisOp = require(luaScript.redis.RedisOperator);local i

22、p = 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() -

23、 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 endendlocal KEY = limit:ip:blacklist;-创建自定义的redis操作对象local red = redisOp:new();-打开连接red:open();-获取缓存的黑名单local ip_blacklist = red:getSmembers(KEY);-归还连接到连接池red:close

24、();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();endif black_ip_list:get(ip) the

25、n return ngx.exit(ngx.HTTP_FORBIDDEN) -直接返回403end该脚本名称为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_l

26、ist的共享内存区进行黑名单本地缓存,所以需要在配置文件中进行共享内存空间的定义,具体如下: #定义存储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所示。图6第一次访问时客户端IP没有加入黑名单在Redis服务器上新建S

27、et类型的键limit:ip:blacklist,并加入最新的当前客户端IP。然后再一次访问/black_ip_demo,发现请求已经被拦截,结果如图8-29所示。图7 客户端IP加入黑名单后请求被拦截使用Nginx Lua共享内存Nginx Lua共享内存就是在内存块中分配出一个内存空间,该共享内存是一种字典结构,类似于Java Map的键-值(Key-Value)映射结构。同一个Nginx下的Worker进程都能访问存储在这里面的变量数据。在Lua中定义共享内存非常简单,具体的指令如下:语法:lua_shared_dict上下文:http配置块。例子:lua_shared_dict bla

28、ck_ip_list 1m; #定义存储IP黑名单的共享内存变量lua_shared_dict指令用于定义一块名为DICT的共享内存空间,其内存大小为size。通过该命令定义的共享内存对于Nginx中所有Worker进程都是可见的。对于共享内存的引用可以使用以下两种形式来完成:方式一:ngx.shared.DICT。方式二:ngx.sharedDICT。ngx_lua提供了一系列API来操作共享内存,如表8-7所示。表8 ngx_lua字典API及其方法如果读者熟悉Redis字符串的操作命令和参数,就会发现以上操作Niginx共享内存的API方法和Redis字符串的操作命令和参数有惊人的相似之处。共享内存的API方法都是原子操作,也就是说,lua_shared_dict定义的是同一个共享内存区自带锁的功能,能够避免来自多个Worker工作进程的并发访问。有关数据项的过期时间可以在新增数据项的时候进行设置。在新增数据项时,如果字典的内存区域不够,ngx.shared.DICT.set方法就会根据LRU算法淘汰一部分内容。当Nginx退出时,共享内存中的数据项都会丢失。

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1