如何动态地并行请求外部多个URL？

delong2py · 2015-08-19T15:45:58+00:00

明白了!重建数据的必须过程. 2015-08-21 22:48 GMT+08:00 Yichun Zhang (agentzh) <age...

如何动态地并行请求外部多个URL？

delong2py

我的程序中会请求到多个外部的URL，我想并行去请求这些外部的URL，当前的实现方式是配置了多个location，将这些URL写死到location内配置中，然后使用capture_multi并行调用。这样的带来的问题就是一旦需要添加或修改这些URL，就要修改对应的配置文件。有想过将location写成动态匹配的样子，但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

doujiang24

hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：

有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

delong2py

hi,

sorry, 没表达清楚，我先描述下情景：

现在有10个外部的URL地址，程序每次会从redis中读取到其中的几个，然后去请求他们。

我想并行地进行请求，使用的方法就是配置这个10个外部地址的location，读取到本次需要的几个URL后，就使用capture_multi实现并行请求。

但是这种方法的局限在于，一旦这些外部地址需要添加或者改动的时候，我就需要去修改location的配置。

因此在想有没有其他更好的方式？

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：

hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

lancelijade

location 里用 proxy_pass， proxy_pass 访问的地址用参数送过去

Lance

2015-08-19 17:42 GMT+08:00 delong li <delo...@gmail.com>:

hi,

sorry, 没表达清楚，我先描述下情景：

现在有10个外部的URL地址，程序每次会从redis中读取到其中的几个，然后去请求他们。

我想并行地进行请求，使用的方法就是配置这个10个外部地址的location，读取到本次需要的几个URL后，就使用capture_multi实现并行请求。

但是这种方法的局限在于，一旦这些外部地址需要添加或者改动的时候，我就需要去修改location的配置。

因此在想有没有其他更好的方式？

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

delong2py

hi,

准备改成这种方式，不过这样就没法配置对应的upstream，无法使用keepalive功能。

在 2015年8月19日星期三 UTC+8下午5:48:54，Lance Li写道：

location 里用 proxy_pass， proxy_pass 访问的地址用参数送过去

Lance

2015-08-19 17:42 GMT+08:00 delong li <delo...@gmail.com>:
hi,

sorry, 没表达清楚，我先描述下情景：

现在有10个外部的URL地址，程序每次会从redis中读取到其中的几个，然后去请求他们。

我想并行地进行请求，使用的方法就是配置这个10个外部地址的location，读取到本次需要的几个URL后，就使用capture_multi实现并行请求。

但是这种方法的局限在于，一旦这些外部地址需要添加或者改动的时候，我就需要去修改location的配置。

因此在想有没有其他更好的方式？

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

doujiang24

hi,

抱歉，貌似我还是没 get 到你的要点

在 2015年8月19日下午6:06，delong li <delo...@gmail.com>写道：

hi,

准备改成这种方式，不过这样就没法配置对应的upstream，无法使用keepalive功能。

一个 upstream 对应一个的外部上游，只要上游（域名）没增加，配置文件就不需要变更

proxy_pass 和 upstream 可以一起使用的

upstream backend_domain1 {

server XXXX;

}

location /domain1 {

proxy_pass http://backend_domain1;

}

在 2015年8月19日星期三 UTC+8下午5:48:54，Lance Li写道：
location 里用 proxy_pass， proxy_pass 访问的地址用参数送过去

Lance

2015-08-19 17:42 GMT+08:00 delong li <delo...@gmail.com>:
hi,

sorry, 没表达清楚，我先描述下情景：

现在有10个外部的URL地址，程序每次会从redis中读取到其中的几个，然后去请求他们。

我想并行地进行请求，使用的方法就是配置这个10个外部地址的location，读取到本次需要的几个URL后，就使用capture_multi实现并行请求。

但是这种方法的局限在于，一旦这些外部地址需要添加或者改动的时候，我就需要去修改location的配置。

因此在想有没有其他更好的方式？

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

--

doujiang24

hi，

抱歉，最好能给段示例哈，个人感觉这种场景代码的表现力比文字要强，哈哈

在 2015年8月19日下午5:42，delong li <delo...@gmail.com>写道：

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

这里指的性能差很多，是指资源利用多了，还是相应时间慢了呢

这两种方式不应该有太大的性能上的差距，或许是你没有正确的把链接放入连接池

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

noisywolf

是不是用协程的时候写成了串行，capture_multi是并行的

2015年8月19日星期三，DeJiang Zhu <douj...@gmail.com> 写道：

hi，

抱歉，最好能给段示例哈，个人感觉这种场景代码的表现力比文字要强，哈哈

在 2015年8月19日下午5:42，delong li <delo...@gmail.com>写道：

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

这里指的性能差很多，是指资源利用多了，还是相应时间慢了呢

这两种方式不应该有太大的性能上的差距，或许是你没有正确的把链接放入连接池

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

--

doujiang24

hi，

这个得看你代码怎么写的了

实际上是可以做到并行的

在 2015年8月19日下午9:56，Josh <nois...@gmail.com>写道：

是不是用协程的时候写成了串行，capture_multi是并行的

2015年8月19日星期三，DeJiang Zhu <douj...@gmail.com> 写道：
hi，

抱歉，最好能给段示例哈，个人感觉这种场景代码的表现力比文字要强，哈哈

在 2015年8月19日下午5:42，delong li <delo...@gmail.com>写道：

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

这里指的性能差很多，是指资源利用多了，还是相应时间慢了呢

这两种方式不应该有太大的性能上的差距，或许是你没有正确的把链接放入连接池

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

--

--

noisywolf

是不是用协程的时候写成了串行，capture_multi是并行的

2015年8月19日星期三，DeJiang Zhu <douj...@gmail.com> 写道：

hi，

抱歉，最好能给段示例哈，个人感觉这种场景代码的表现力比文字要强，哈哈

在 2015年8月19日下午5:42，delong li <delo...@gmail.com>写道：

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

这里指的性能差很多，是指资源利用多了，还是相应时间慢了呢

这两种方式不应该有太大的性能上的差距，或许是你没有正确的把链接放入连接池

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

--

delong2py

是响应时间慢了，之前的代码时间太久远了，我重新考虑下lua并行请求这一块应该怎么写，多谢解答。

在 2015年8月19日星期三 UTC+8下午9:37:29，doujiang写道：

hi，

抱歉，最好能给段示例哈，个人感觉这种场景代码的表现力比文字要强，哈哈

在 2015年8月19日下午5:42，delong li <delo...@gmail.com>写道：

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

这里指的性能差很多，是指资源利用多了，还是相应时间慢了呢

这两种方式不应该有太大的性能上的差距，或许是你没有正确的把链接放入连接池

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

membphis

我们目前是通过这个方式实现的。

https://github.com/pintsized/lua-resty-http

下面是部分示例代码。调用httpc:request_uri内部直接做了keepalive。曾经做过测试，纯proxy静态文件测试执行效率还是不错的。

实现你的目的有两个玩法：

1. 可以把这段代码放到一个location中，这样外层就可以通过multy_capture完成。

2. 可以把这段代码放到一个function中，使用ngx.thread.spawn方式并发。

貌似第一个玩法性能会更好，但第二个的玩法更优雅（我没做测试）。

-- For simple singleshot requests, use the URI interface.
      local httpc = http.new()
      local res, err = httpc:request_uri("http://example.com/helloworld", {
        method = "POST",
        body = "a=1&b=2",
        headers = {
          ["Content-Type"] = "application/x-www-form-urlencoded",
        }
      })

      if not res then
        ngx.say("failed to request: ", err)
        return
      end

2015-08-19 22:33 GMT+08:00 delong li <delo...@gmail.com>:

是响应时间慢了，之前的代码时间太久远了，我重新考虑下lua并行请求这一块应该怎么写，多谢解答。

在 2015年8月19日星期三 UTC+8下午9:37:29，doujiang写道：
hi，

抱歉，最好能给段示例哈，个人感觉这种场景代码的表现力比文字要强，哈哈

在 2015年8月19日下午5:42，delong li <delo...@gmail.com>写道：

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

这里指的性能差很多，是指资源利用多了，还是相应时间慢了呢

这两种方式不应该有太大的性能上的差距，或许是你没有正确的把链接放入连接池

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

delong2py

万分感谢，我先玩下试试

在 2015年8月20日星期四 UTC+8上午10:38:06，YuanSheng Wang写道：

我们目前是通过这个方式实现的。

https://github.com/pintsized/lua-resty-http

下面是部分示例代码。调用httpc:request_uri内部直接做了keepalive。曾经做过测试，纯proxy静态文件测试执行效率还是不错的。

实现你的目的有两个玩法：
1. 可以把这段代码放到一个location中，这样外层就可以通过multy_capture完成。
2. 可以把这段代码放到一个function中，使用ngx.thread.spawn方式并发。

貌似第一个玩法性能会更好，但第二个的玩法更优雅（我没做测试）。
-- For simple singleshot requests, use the URI interface.
      local httpc = http.new()
      local res, err = httpc:request_uri("http://example.com/helloworld", {
        method = "POST",
        body = "a=1&b=2",
        headers = {
          ["Content-Type"] = "application/x-www-form-urlencoded",
        }
      })

      if not res then
        ngx.say("failed to request: ", err)
        return
      end
2015-08-19 22:33 GMT+08:00 delong li <delo...@gmail.com>:
是响应时间慢了，之前的代码时间太久远了，我重新考虑下lua并行请求这一块应该怎么写，多谢解答。

在 2015年8月19日星期三 UTC+8下午9:37:29，doujiang写道：
hi，

抱歉，最好能给段示例哈，个人感觉这种场景代码的表现力比文字要强，哈哈

在 2015年8月19日下午5:42，delong li <delo...@gmail.com>写道：

之前简单的实现了用lua协程并行发起http请求的方式，但性能相较capture_multi来说差了很多。

这里指的性能差很多，是指资源利用多了，还是相应时间慢了呢

这两种方式不应该有太大的性能上的差距，或许是你没有正确的把链接放入连接池

在 2015年8月19日星期三 UTC+8下午5:02:02，doujiang写道：
hi，

抱歉，我还不能 get 到你的意图，为了更好的方便大家帮你，提两句哈

在 2015年8月19日下午3:45，delong li <delo...@gmail.com>写道：
有想过将location写成动态匹配的样子

可以具体描述动态匹配是什么样子么

但这样好像没法使用upstream的长连接，而且也不能解决全部的问题。因此想请教下看看没有有什么更好的方法？

最好给个用例，"好像" 是不靠谱的呀，哈哈

--

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices