TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Improve your beta-testing with Nginx, Lua and Redis

72 点作者 transmit101将近 13 年前

8 条评论

runningdogx将近 13 年前
With a modern pcre library version and nginx, instead of<p><pre><code> location ~ ^/([a-zA-Z0-9_]+)/ { set $username $1; </code></pre> you can use named captures<p><pre><code> location ~ ^/(?&#60;username&#62;[a-zA-Z0-9_]+)/ {</code></pre>
评论 #4166964 未加载
评论 #4166947 未加载
richardv将近 13 年前
This is a fantastic explanation. We have started to do something similar but your LUA rewrites is a lot more effective. I wasn't even aware that you could do something like that.
eli将近 13 年前
I've done very similar things with Varnish reverse caching proxy. And as a bonus, Varnish is crazy fast if your pages or assets are cacheable.<p>Its scripting language is very simple (not quite as nice as Lua, IMHO), but it supports multiple backends and rewriting arbitrary headers: <a href="https://www.varnish-cache.org/trac/wiki/VCLExamples" rel="nofollow">https://www.varnish-cache.org/trac/wiki/VCLExamples</a>
评论 #4168372 未加载
jperras将近 13 年前
We've done this before, but by adding an additional load-balancer that forwards requests to a different port (e.g. 81 instead of 80) depending on the subdomain that was accessed. The request is processed by nginx, which has separate server blocks and associated upstreams for processing requests that come in over the configured ports. The only application logic that was necessary to accommodate the changes was a check to determine if the user should be part of the beta, and redirect them to the appropriate subodmain if necessary.<p>While it's not as clean as having the check done in nginx itself via Lua script + Redis, it's relatively low friction. That said, the Lua script embedded in the nginx config is very slick, and I had been contemplating writing something similar using the nginx memcache module. Nice work.
评论 #4167430 未加载
grogs将近 13 年前
Good write up for a sensible solution to a problem which should effect lots of sites.<p>Personally, I would probably take the approach of settings a cookie per user. This would be very suitable when beta testing is enabled/decided by users, rather than a subset being chosen A/B style based on a value in the database. This would have the advantage that nginx would not have to make any database requests; just check a cookie on the request, likely speeding up the speed at which nginx handles requests. However, it would require some changes to the application (versus [small] changes to the database which the slug approach) to set the cookie etc.<p>I wonder how easy this is to do in apache.
评论 #4167001 未加载
projct将近 13 年前
Couldn't you use a cookie and map, rather than URLs? Sounds like users could end up on different rails back ends unintentionally based on what URL they use, with your method...<p><a href="http://serverfault.com/questions/268633/controlling-nginx-proxy-target-using-a-cookie" rel="nofollow">http://serverfault.com/questions/268633/controlling-nginx-pr...</a>
评论 #4167417 未加载
davnola将近 13 年前
Lovely. We do something very similar in front of EC2 clusters with <a href="http://openresty.org/" rel="nofollow">http://openresty.org/</a>
Androsynth将近 13 年前
rather than: if (-f $request_filename)... you should use try_files<p><a href="http://wiki.nginx.org/IfIsEvil" rel="nofollow">http://wiki.nginx.org/IfIsEvil</a><p><a href="http://wiki.nginx.org/Pitfalls#Using_If" rel="nofollow">http://wiki.nginx.org/Pitfalls#Using_If</a>
评论 #4168086 未加载