（摘自知乎）
精简自 耿小扭
OpenResty解决的是高并发的痛点。
现在服务的后台大部分是java写的，但是用java写出稳定的高并发服务是很复杂的一件事。首先是web服务器的选型：tomcat/apache/weblogic,还有商用webphere
- tomcat官方宣称的并发量是1000，厉害点的做点参数调优，也不过3000并发,如果要开发一个并发百万的服务，1000000/3000,需要1000台服务器，想想都不可能。
- apache的并发比tomcat更不堪，200-300左右
- weblogic的并发稍好，平均能达到3000左右，但是也没有达到好一个数量级
nginx就不一样了，处理几万的请求很轻松，内存占用也不高。之前我们把它用作负载均衡，没想过当做一个web服务器。OpenResty的出现解决了享受nginx高并发优势的拦路虎，因为nginx是使用异步事件模型，跟传统的编程思想不一样，而lua是用c解释执行的脚本语言（执行效率很高），可以用传统的同步编程思想上，在nginx请求接进来后处理稍复杂的逻辑。
对于高并发的系统来说，都是基于内存的，或者说是基于缓存的。用mysql支撑高并发是不现实的，mysql的并发量在4000-8000 （补充：mysql的并发量要具体到具体服务器配置吧，比如带宽、内存以及cpu，脱离这些因素不太准确，业内推荐的mysql的并发量是2000，最好控制在2000以下），超过这个量mysql性能就会急剧下降。一次内存读取的时间是几十纳秒，一次缓存读取是几毫秒，大家可能对纳秒比较陌生，一纳秒等于1秒的1000000000分之一，一毫秒等于1秒的1000分之一，请求过来之后直接走内存读取，在需要和数据库交互的时候把数据写入内存，然后再批量入库，快速响应。
web流量也符合二八原则，百分之八十的流量集中在百分之二十的页面，比如电商的首页，产品详情页，使用openResty支撑产品详情页的高并发访问，在处理订购单，购物车等环节用其他的高并发框架处理，比如java的NIO网络框架netty。
java的netty也是处理高并发的利器，不过我做过测试，整体性能可以达到nginx的80%，所以，脏活累活都让nginx做吧，关键业务用netty。
当然，每个人对高并发的理解可能不太一样，有人说1000并发就是高并发了，有人说1万的并发才是高并发，有人说并发百万才是高并发，OpenResty是可以做到百万并发的（当然需要各种调优）现在大部分业务OpenResty都可以胜任，但是像腾讯10亿用户，1亿的并发，OpenResty就搞不定了。
不同的并发量要应对的东西不一样，比如1000并发，用tomcat，springmvc框架加缓存就可以应对，1万的并发在关键节点使用内存处理也很容易，百万并发就需要linux内核调优，socket缓冲区，文件句柄数，内存池，RPS/RFS SMP等优化也可以达到。千万并发就需要考虑用户态协议dpdk
精简自 babayetu liu
openresty本身是集成了lua组件的nginx，等于是把一部分后端服务的功能用lua集成到反向代理里面了。
- 数据库慢，需要加缓存，拆分，看哪个业务逻辑拖慢了整体的返回速度。
- 业务逻辑复杂，拆域，中间层聚合。
- 超时还可以用nginx上的静态持久化页面返回。
lvs -> nginx -> server -> database，后端哪一个环节慢，都不是反向代理应该解决的事情。
精简自 匿名用户
当初解决了nginx不可编程的问题，所以给nginx加了个lua jit，而且前人基于openRsety做了不少的库，所以能在nginx更方便方便编程。
虽然nginx官方后来也推出nginScript，但是官方推动不好，或者说它的库还远远不够用，导致nginScript的基础设施建设就没赶上openResty。
