业务场景需求
很久以前:
在项目的运营和维护过程中,SEO团队曾说过,如果一个网页的URL中能够包含关键词,那么该网页在被各大搜索引擎收录和排名方面将具有非常重要且明显的优势(~~就是。 SEO团队专业不?~,这里不评论)所以公司决定在项目的CMS系统中添加更改页面URL的功能(这没什么大不了的,甲方爸爸只是要求的)。
添加该功能后,业务人员相信内容的有效性,每天都会多次添加、删除、修改内容,之后还要修改搜索引擎收录的页面URL,添加301、302。塔。点击跳转以确保它对搜索引擎友好。 (我一天改好多次,但不知道是什么善意,所以就不评论了)
由于项目结构包括多级CDN分发、网站内容的静态管理、流量资源的控制等,因此配置文件中包含了修改后的URL的301映射,以保证系统的稳定性。每日更新。
现在:
外部运维团队寻求这种解决方案,因为他们对实时情况的要求不断提高,并且需要立即生效。
为了解决这个业务场景的挑战,我们在Mac 上本地验证和测试了流程,以组织我们的想法和流程。在其他平台上也可以找到相应的方法。 (我将省略详细信息,因为它们在官方文档和教程中进行了描述)
OpenResty = Nginx+Lua
该解决方案选择OpenResty 是因为Web 服务器始终使用Nginx,并且还需要更改项目中的Nginx 源代码。
https://openresty.org/
OpenResty 是一个可扩展的Web 平台,通过Lua 扩展Nginx 实现。可以看到,Web服务的核心是Nginx,但是Lua添加了很多扩展,还是很不错的。
Nginx很早就发布了njs模块。虽然NJS支持使用JavaScript的某些子集进行扩展,但在很多Nginx场景下,NJS的扩展使用生态不如Lua。在解决问题和可扩展性方面,它不像Lua 那么容易,但它的社区和开源使它变得容易。
MacOS 上的安装:
brew 安装openresty/brew/openresty
需要谨慎
brew install openresty #无法使用此命令安装。出现一条消息,指出找不到该文件。
安装完成后,需要添加环境变量,以便Nginx启动时可以找到命令。
post-brew 安装地址(macOS)可能位于/usr/local/openresty (这是默认地址)。
路径=/opt/homebrew/Cellar/openresty/1.25.3.1_1/nginx/sbin:$PATH
导出路径
接下来,创建Web 服务所需的工作区。
mkdir www 日志conf
创建工作区的步骤需要在新环境中完成验证过程,因此后续命令在nginx-lua-redis 目录中运行。如果移动到其他目录,请注意某些命令所需的文件路径更改。
在conf文件夹中创建一个新的示例配置Nginx.conf。
工作进程1;
error_log 日志/error.log;
事件{
工人连接1024;
}
http{
服务器{
听8080。
位置/{
默认类型text/html;
content_by_lua_block {
ngx.say(\’你好,世界/p\’)
}
}
}
}
接下来,启动Nginx 服务。
nginx -p `pwd`/-c conf/nginx.conf
如果您收到找不到文件的消息,请检查路径是否正确。
测试:
卷曲http://本地主机:8080/
结果:
你好世界/p
此时,其他Web服务所需的相关文件将在nginx-lua-redis目录中自动生成,因此您可以放心地忽略它们。
至此,通过OpenResty项目集成就可以使用Nginx + Lua环境了。事实证明,安装Nginx + Lua 模块和其他扩展变得有点痛苦。我从来没听说过。要学习和理解. OpenResty 本身已经集成了扩展所需的大部分内容。很好+1。
Redis 支持
这个方案为什么要用Redis?官网说速度快……
Redis 在Mac 上安装相对容易
酿造安装Redis
酿造服务启动Redis
Redis服务器
好的,我们已经准备好了一个简单的Redis 示例。
通过打开新的终端窗口来测试链接。
redis-cli -h 127.0.0.1 -p 6379
由于我是在验证和测试流程,所以不想为Redis编写任何代码,所以我直接从官网下载了一个支持Mac的免费客户端。
RedisInsight https://redis.io/insight/
完全万无一失的操作性和非常漂亮的界面
这里,我尝试创建两组页面跳转实例,最终在内置终端中选择HASH模式,并创建百度和知乎跳转键值对用于后续测试。
Redis 中不同的数据类型以不同的方式工作。如果调用Lua脚本时选择不同的数据类型,则需要进行调整。
当Lua调用Redis中的数据匹配跳转规则时,传入的URL数据以“/”开头。这就是为什么截图中有两个数据集(第一组我忘记了这个,所以失败了。然后我想起来了)
配置文件案例
一旦理解了语法,实现Nginx + Lua 脚本就相对容易了。这个例子的关键在于,Nginx在匹配URL规则时,通过Lua脚本调用后端Redis中存储的301跳转规则,而不是之前写在配置文件中的固定规则。由于Redis的运行,规则内容是实时更新的。
工作进程1;
error_log 日志/error.log;
事件{
工人连接1024;
}
http{
lua_shared_dict redirects_cache 3m; # 分配1MB共享内存用于缓存
服务器{
听8080。
位置/{
access_by_lua_block {
需要本地redis=\’resty.redis\’
本地红=redis:new()
red:set_timeout(1000) — 设置超时
本地没问题,error=red:connect(\’127.0.0.1\’, 6379)
如果不行的话
ngx.log(ngx.ERR,“无法连接到redis:”,错误)
返回ngx.exit (ngx.HTTP_INTERNAL_SERVER_ERROR)
结尾
— 尝试从缓存中检索跳转规则。
本地缓存重定向=ngx.shared.redirects_cache:get(ngx.var.uri)
对于缓存的重定向
ngx.redirect(cached_redirect, 301)
返回
结尾
— Redis 查询
本地new_url=red:hget(\’重定向\’, ngx.var.uri)
如果类型(new_url)==\’字符串\’
— 缓存结果以加速后续请求
ngx.shared.redirects_cache:set(ngx.var.uri, new_url, 600) — 缓存600 秒
red:close() — 关闭连接
ngx.redirect(new_url, 301)
返回
结尾
红色:关闭()
}
默认类型text/html;
content_by_lua_block {
ngx.say(\’你好,world.nginx-lua-Redis/p\’)
}
}
}
}
redirects_cache:每次都检查Redis来设置缓存区域,成本很高。缓存的大小取决于您的项目所需的301 规则的数量。
您可以像往常一样通过访问预设地址进行跳转。
localhost:8080/test1.shtml – 成功访问百度
localhost:8080/test2.shtml – 正确导航到知乎
Redis中的数据更新后,跳转效果也会实时启用。
后记:
关于Nginx热加载重载:
Nginx本身就提供了热加载功能。
nginx -s 重新加载
这也是我之前使用自动化的方式。在实际使用中,当流量较大或维持长链路时,重载方式常常会导致服务中断、重载失败等意外情况。因此,早期的解决方案实际上是通过高可用集群切换来保证自动更新的有效性。然而,现在业务利益相关者热衷于频繁更改URL跳转规则,并要求在短时间内立即生效。使用Reload给平台业务服务的稳定性增加了更多隐患。也许这次集群Reload还没有完成,考虑到系统消耗和稳定性,我决定测试Nginx+Lua+Redis。计划。
解决方案的局限性:
该解决方案的所有生成和测试都是基于当前项目的业务条件和环境要求。这并不是说这只能解决我的情况的问题。在真实的项目中,你只需根据自己的情况来整理和验证你的想法即可。如果大家有更好的方法或者意见,欢迎批评指正。
#Nginx301 以上关于Nginx+Lua+Redis实现跳转配置管理源网络的相关内容仅供参考。相关信息请参见官方公告。
原创文章,作者:CSDN,如若转载,请注明出处:https://www.sudun.com/ask/91847.html