在上一篇中，我们在linux上部署了OpenRestry单个节点简单实现了hello word功能，使用OpenRestry的强大之处在于使用它和其他模块比如http等，使用它的lua脚本实现一些接口的转发，利用这个特性我们可以设想一下，假如我们使用OpenRestry来实现nginx集群的负载均衡该如何做呢？

可以分两步，假如有多台机器，每台机器上都部署了nginx，那么只需要其中的一台作为转发请求的节点，其他的作为负载均衡的节点不就可以了吗？事实上，也是这样做的，作为流量或者接口转发的节点，我们称之为流量分发服务器，所有需要通过nginx作为代理的请求首先需要走OpenRestry分发，又这个分发服务器统一将流量按照特定的负载均衡算法转到其他nginx服务器，这个也是作为三级缓存架构中的常用做法。

按照上一篇的搭建OpenRestry的流程，我们在另外两台机器上都部署一份OpenRestry,搭建过程都相同，另外的两台节点IP分别为，192.168.111.133 和 192.168.111.134 ，这两个节点作为应用层的nginx,而之前的192.168.9.140 作为分发层nginx服务器，我们编写lua脚本实现流量定向转发也是在这台节点上做。

这里为了使得后期的运维更加方便，我们重新规划一下OpenRestry的相关配置文件的目录，这里我在servers下面新建了一个叫做hello的文件夹，用于存放lua脚本文件和lua的其他依赖组件，如下，

这样假如以后你的业务越来越多，就可以通过不同的目录进行区分，这里命名比较随意，主要是为了测试，我们分别看看各自的内容，
hello.conf:基本上和上一篇的内容一模一样，只是整理了一下文件的位置，

而lualib是直接从安装完毕的OpenRestry主目录下拷贝过来的，里面放的是lua脚本的依赖文件，可以理解为jar包，

这里面配置了以后我们需要去nginx目录下重新配置一下nginx.conf的文件，这里面只需要替换一下上一篇的配置变成下面的即可，

在133和134节点上均使用上述的配置流程，然后我们启动一下133和134的nginx然后在浏览器访问一下，可以看到另外两个节点的nginx也可以正常使用了，

下面就是基于lua脚本实现商品ID的定向转发，直接上代码，我也是参考相关资料进行配置的编写的，可以放心使用，

local uri_args = ngx.req.get_uri_args()
local productId = uri_args["productId"]

local host = {"192.168.31.19", "192.168.31.187"}
local hash = ngx.crc32_long(productId)
hash = (hash % 2) + 1  
backend = "http://"..host[hash]

local method = uri_args["method"]
local requestBody = "/"..method.."?productId="..productId

local http = require("resty.http")  
local httpc = http.new()  

local resp, err = httpc:request_uri(backend, {  
    method = "GET",  
    path = requestBody
})

if not resp then  
    ngx.say("request error :", err)  
    return  
end

ngx.say(resp.body)  
  
httpc:close() 

相信有一点编程基础的同学应该能够看懂上面的代码的意思，只是lua脚本的语法可能不太一样，大体意思都差不多，无非就是实现了一个按照请求的商品productId根据我们自定义的crc36的算法实现不同商品ID转发到不同的应用层nginx上面进行处理，从而达到负载均衡合理使用nginx服务器的功能，然后我们在浏览器请求一下下面的地址，当结果展示出来了，再把productId的值分别编程1或其他的数，看看结果会有何不同，留给各位伙伴自己探索了，

http://192.168.9.140/hello?requestPath=hello&productId=5

本篇的整合到此结束，感谢观看！后续将会基于此思路实现相关的java层逻辑，从而真正实现三级缓存的架构设想。