webworker应用场景_典型应用场景 · OpenResty最佳实践-最新版 · 看云

# 典型应用场景

可以这样说，任何一个开发语言、开发框架，都有它存在的明确目的，重心是为了解决什么问题。没有说我们学习一门语言或技术，就可以解决所有的问题。同样的，`OpenResty`的存在也有其自身适用的应用场景。

其实官网 wiki 已经列了出来：

- 在lua中混合处理不同nginx模块输出(proxy, drizzle, postgres, redis, memcached等)。

- 在请求真正到达上游服务之前，lua中处理复杂的准入控制和安全检查。

- 比较随意的控制应答头(通过Lua)。

- 从外部存储中获取后端信息，并用这些信息来实时选择哪一个后端来完成业务访问。

- 在内容handler中随意编写复杂的web应用，同步编写异步访问后端数据库和其他存储。

- 在rewrite阶段，通过Lua完成非常复杂的处理。

- 在Nginx子查询、location调用中，通过Lua实现高级缓存机制。

- 对外暴露强劲的Lua语言，允许使用各种Nginx模块，自由拼合没有任何限制。该模块的脚本有充分的灵活性，同时提供的性能水平与本地C语言程序无论是在CPU时间方面以及内存占用差距非常小。所有这些都要求LuaJIT 2.x是启用的。其他脚本语言实现通常很难满足这一性能水平。

#### 不擅长的应用场景

前面的章节，我们是从它适合的场景出发，`OpenResty`不适合的场景又有哪些？以及我们在使用中如何规避这些问题呢？

这里官网并没有给出答案，我根据我们的应用场景给大家列举，并简单描述一下原因：

- 有长时间阻塞调用的过程

- 例如通过 `Lua` 完成系统命令行调用

- 使用阻塞的`Lua API`完成相应操作

- 单个会话处理逻辑复杂，尤其是需要和请求方多次交互的长连接场景

- `Nginx`的内存池 pool 是每次新申请内存存放数据

- 所有的内存释放都是在会话退出的时候统一释放

- 如果单个会话处理过于复杂，将会有过多内存无法及时释放

- 内存占用高的处理

- 受制于`Lua VM`的最大使用内存 1G 的限制

- 这个限制是单个`Lua VM`，也就是单个`Nginx worker`

- 两个会话之间有交流的场景

- 例如你做个在线聊天，要完成两个用户之间信息的传递

- 当前`OpenResty`还不具备这个通讯能力(后面可能会有所完善)

- 与行业专用的组件对接

- 最好是 TCP 协议对接，不要是 API 方式对接，防止里面有阻塞 TCP 处理

- 由于`OpenResty`必须要使用非阻塞 API ，所以传统的阻塞 API ，我们是没法直接使用的

- 获取 TCP 协议，使用 cosocket 重写(重写后的效率还是很赞的)

- 每请求开启的 `light thread` 过多的场景

- 虽然已经是`light thread`，但它对系统资源的占用相对是比较大的

这些适合、不适合信息可能在后面随着 `OpenResty` 的发展都会有新的变化，大家拭目以待。