代码改变世界

OpenResty 究竟解决了什么痛点?

2020-04-13 10:06  Tanwheey  阅读(1023)  评论(0编辑  收藏  举报
转~
作者:耿小扭
链接:https://www.zhihu.com/question/266535644/answer/705067582
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

比如 MySQL 卡,就算 OpenResty 极其快,对打开浏览器的用户来说,迟迟看不到从数据库获取的信息,页面一片空白,他们认为也是卡,跟没有用 OpenResty 不是一样吗?

所以它到底解决了什么痛点?


OpenResty解决的是高并发的痛点。现在服务的后台大部分是java写的,但是用java写出稳定的高并发服务是很复杂的一件事,首先是服务器的选择,web服务器有几个选型,tomcat,apache,weblogic,还有商用webphere. 1、tomcat官方宣称的并发量是1000,厉害点的做点参数调优,也不过3000并发,如果要开发一个并发百万的服务,1000000/3000,需要1000台服务器,想想都不可能。 2、apache的并发比tomcat更不堪,200-300 3、weblogic的并发稍好,平均能达到3000左右,但是也没有达到好一个数量级

但是nginx就不一样了,处理几万的请求很轻松,内存占用也不高,之前我们只是把它用作负载均衡,没想过当做一个web服务器,OpenResty的出现解决了享受nginx高并发优势的拦路虎,因为nginx是使用异步 事件模型,跟传统的编程思想不一样,而lua是用c解释执行的脚本语言(执行效率很高),可以用传统的同步编程思想上,在nginx请求接进来后处理稍复杂的逻辑。

对于高并发的系统来说,都是基于内存的,或者说是基于缓存的,题主说的用mysql支撑高并发是不现实的,mysql的并发量在4000-8000,超过这个量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了

 

作者:Horan
链接:https://www.zhihu.com/question/266535644/answer/311914648
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

OpenResty 是快,但是MySQL卡了,你换什么都是卡的,这和你用哪个技术栈没有关系,我个人认为好的几点的是:

  1. 做网关,比如说 ngx-waf,从较高的位置处理了安全问题
  2. 高并发,异步非阻塞的项目需求(甚至说你的MySQL卡,如果你用 ngx.timer.at 来实现异步写库,用户的请求完全可以不受 MySQL 卡的影响,当然 mysql 响应慢,积累太多连接不释放导致系统出问题就是另一回事了 )
  3. 对其他语言的兼容,可以直接在 lua 中嵌入 C 来写,又或者 lua 结合 redis 使用

 

----------------- 3月6日 面试被问了类似的问题,想起这个问题重写一下答案-------------

 

从深入角度来说,这里的 openresty 是基于 nginx 增加了模块,我们说的其实也就是 nginx 的性能,而 nginx 是异步非阻塞的,基于事件驱动的 server,相比其他的 server 在卡主的时候他为什么不卡?

就拿你的问题来说,mysql 卡了,这条请求的上下文会被卡在这里,不管是 nginx 还是 apache,都会卡住这条请求,但是问题关键还在于后续的请求进来后会怎么办

apache 的做法是开启一个新的进程来处理后续的请求,但系统进程资源是有限的,所以面对大量请求时,进程耗尽,apache 就会把所有后续的请求都卡住了。

nginx 只有一个master进程和已配置个数的 worker进程,master 进程把请求交给 worker 去处理,一个worker 在可能出现阻塞的地方会注册一个事件就放过去了(epoll模型),而不是干巴巴的等待阻塞被处理完,他会继续处理后续的请求(非阻塞),当这个事件处理完之后会通过callback来通知worker继续处理那条请求后续的事情(事件驱动)因此单个worker可以处理大量请求而不会轻易让整个系统卡住。

作者:王然
链接:https://www.zhihu.com/question/266535644/answer/328593385
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

异步提高了服务器整体负载能力,而不是提高某个请求的速度。

而openresty可以用写同步的方式写异步,简化开发。

 

 

更新下这个答案:

多任务程序分成两种:

一种是并行,指的是把一个大型任务拆分成N个小任务,把这些小任务分派个N个WORKER(线程,服务器)来执行,最后再组合起来,输出结果,这种是为了提升单次任务的执行时间。

 

另一种是并发,主要目标是在同一个CPU上执行几个松耦合合的任务,充分利用CPU的核,让其足够忙碌,从而最大化程序的吞吐量,那么真正要做的是避免因为等待远程服务的返回,或者对数据库的查询,而阻塞线程的执行, 浪费宝贵的计算资源,因为这种等待的时间很可能相当长(摘自JAVA8实战)。

 

异步是第二种并发的一种实现方案,OpenResty通过把nginx的事件驱动机制与lua的协程相结合,实现了cosocket这种东西,把异步实现做了一个封装。使用cosocket,开发者就不需要考虑异步如何实现,同样用同步的编程方式,就可以完成异步请求MySQL,Redis以及各种网络服务,从而达到增大服务器吞吐量的目的。

当然,lua语言本身比较小巧,相对来讲处理单次请求的效率也会更高,但这个我认为不算是OpenResty一个非常重要的优势,毕竟对于网络服务来讲单次请求的延时,瓶颈往往还是在数据库

 作者:babayetu liu
链接:https://www.zhihu.com/question/266535644/answer/309840098
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

openresty本身是集成了lua组件的nginx,等于是把一部分后端服务的功能用lua集成到反向代理里面了。和mysql慢有个毛关系啊。数据库慢,你需要加缓存,拆分,看你哪个业务逻辑拖慢了整体的返回速度。业务逻辑复杂,拆域,中间层聚合,很多手段可以用。超时还可以用nginx上的静态持久化页面返回。

lvs -> nginx -> server -> database,后端哪一个环节慢,都不是反向代理应该解决的事情,你没搞懂痛点在哪里。

实名反对圆胖肿的答案。一点常识,永远不要觉得你比数据库厂家更懂文件系统。直接写文件系统,灾备,数据丢失,回滚都自己做吗?Linux上次爆出的ext4数据丢失的bug忘了?

作者:「已注销」
链接:https://www.zhihu.com/question/266535644/answer/548599844
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

首先就单个请求而言,

单次请求响应时间是网络 + http服务器 + http到后端通信 + 后端 + 后端到数据库通信 + 数据库

那么现在openresty直接消除了第三项,第四项明显减少,整个响应时间是改善的,正因为有这个改善你才能问得出来这个问题。

 

不然,

“比如mysql卡,就算fastcgi极其快,跟cgi不是一样的吗?”

 

就多个请求而言,openresty降低了整个服务器和单次请求的footprint,使得服务器能承载更多的请求(直到把数据库撑死)。

 

你总不能说“反正数据库是瓶颈,我前面的东西放着快的不用用慢的也没有关系”吧。

 

另外某个人说“换成postgre以提高性能”,不好意思,postgre的优势在于功能和灵活性,论性能,mysql是稍好的。

“用文件系统代替数据库”,不好意思,你读写文件是自己实现缓存吗?下mysql自己测性能去谢谢。

 

 

OpenResty搭建高性能服务端:https://www.jianshu.com/p/09c17230e1ae