AMD|OpenResty 究竟解决了什么痛点?

AMD|OpenResty 究竟解决了什么痛点?

文章图片

AMD|OpenResty 究竟解决了什么痛点?

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

OpenResty解决的是高并发的痛点 。 现在服务的后台大部分是java写的 , 但是用java写出稳定的高并发服务是很复杂的一件事 , 首先是服务器的选择 , web服务器有几个选型 , tomcat , apacheweblogic还有商用webphere. 1、tomcat官方宣称的并发量是1000 , 厉害点地做点参数调优 , 也不过3000并发如果要开发一个并发百万的服务 , 1000000/3000需要1000台服务器 , 想想都不可能 。2、apache的并发比tomcat更不堪 , 200-300 3、weblogic的并发稍好 , 平均能达到3000左右 , 但是也没有达到好一个数量级
lvs -> nginx -> server -> database , 后端哪一个环节慢 , 都不是反向代理应该解决的事情 , 你没搞懂痛点在哪里 。
但是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就搞不定了 。
【AMD|OpenResty 究竟解决了什么痛点?】不同的并发量要应对的东西不一样 , 比如1000并发 , 用tomcat , springmvc框架加缓存就可以应对 , 1万的并发在关键节点使用内存处理也很容易 , 百万并发就需要linux内核调优 , socket缓冲区 , 文件句柄数 , 内存池 , RPS/RFS SMP等优化也可以达到 。 千万并发就需要考虑用户态协议dpdk了