正引领着多云技术的发展
|
需要注意的是为了避免重复去 MySQL 中拉取数据，某个 worker 从 MySQL 拉取完规则(此步需要加锁，避免所有 worker 都去拉取)或者后端集群等配置信息后要将其保存在 shared dict 中，这样之后所有的 worker 请求只要从 shared dict 中获取这些规则，然后将其映射成对应模块的函数即可，如果配置规则有变动呢，配置后台通过接口通知 OpenResty 重新加载一下即可 再比如我们不是要要上文提到网关的核心功能之一不是要监控日志吗，就可以统一在 log_by_lua 上报日志，不影响其他阶段的逻辑。 worker 间共享数据利器: shared dict worker 既然是互相独立的进程，就需要考虑其共享数据的问题， OpenResty 提供了一种高效的数据结构: shared dict ,可以实现在 worker 间共享数据，shared dict 对外提供了 20 多个 Lua API，都是原子操作的，避免了高并发下的竞争问题。 路由策略插件化实现
有了以上 OpenResty 点的铺垫，来看看上文提的网关核心功能 「路由策略插件化」,「后端集群的动态变更」如何实现 先启动的 master 进程带有 LuaJIT 的机虚拟，而 worker 进程是从 master 进程 fork 出来的，在 worker 内进程的工作主要由 Lua 协程来完成，也就是说在同一个 worker 内的所有协程，都会共享这个 LuaJIT 虚拟机，每个 worker 进程里 lua 的执行也是在这个虚拟机中完成的。
同一个时间点，worker 进程只能处理一个用户请求，也就是说只有一个 lua 协程在运行，那为啥 OpenResty 能支持百万并发请求呢，这就需要了解 Lua 协程与 Nginx 事件机制是如何配合的了。 个简单的比方，我们都有订票的经验，当我们委托酒店订票时，接待员会先把我们的电话号码和相关信息等记下来(注册事件)，挂断电话后接待员在操作期间我们就可以去做其他事了(非阻塞)，当接待员把手续搞好后会主动打电话给我们通知我们票订好了(回调)。
worker 进程是从 master fork 出来的，这意味着 worker 进程之间是互相独立的，这样不同 worker 进程之间处理并发请求几乎没有同步锁的限制，好处就是一个 worker 进程挂了，不会影响其他进程，我们一般把 worker 数量设置成和 CPU 的个数，这样可以减少不必要的 CPU 切换，提升性能 ginx 启动后，会有一个 master 进程和多个 worker 进程 ， master 进程接受管理员的信号量(如 Nginx -s reload, -s stop)来管理 worker 进程，master 本身并不接收 client 的请求，主要由 worker 进程来接收请求，不同于 apache 的每个请求会占用一个线程，且是同步IO，Nginx 是异步非阻塞的，每个 worker 可以同时处理的请求数只受限于内存大小，这里就要简单地了解一下 nginx 采用的 epoll 模型：
epoll 采用多路复用模型，即同一时间虽然可能会有多个请求进来， 但只会用一个线程去监视，然后哪个请求数据准备好了，就调用相应的线程去处理，就像图中所示，如同拨开关一样，同一时间只有一个线程在处理， Nginx 底层就是用的 epoll ，基于事件驱动模型，每个请求进来注册事件并注册 callback 回调函数，等数据准入好了，就调用回调函数进行处理，它是异步非阻塞的，所以性能很高。
（编辑：信阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
