大多数情况, 人们搞混了 请求连接数 和 并发的概念
并发有两个前提:
1:处理同类事物
2:事务处理的时间窗口发生重叠
3:请求完成时间重叠并不意味着并发, 只是连接数上升。
由于大多请求处理时间很短, 只在请求连接到断开的时间窗口发生重叠, 所以内部事务处理并不发生重叠, 体现就是连接数上升。实际操作当中,就是nginx前置连接数量比较多。
后端无论 java(servlet线程池), php(fpm进程池)都只和 事务处理窗口重叠数量相关。
实际上, 很少的并发事务就能为大量的连接进行服务。
大多“牛”们谈论的都是连接数很多
当事务被阻塞, 比如mysql 无法处理写并发的时候, 就会发生堆积 ,这个时候, 并发, 连接同时上升, 死循环
事务不阻塞的情况, 吞吐量是唯一需要关心的指标,可以将并发连接数串行化到比较少的并发事务, 通过提高单个事务处理时间窗口, 减少事务并发量, 这个才是解决之道。
从外部来看, 能够处理大量连接, 及时响应, 也就是客户所需要的, 至于,内部多少并发, 没有人关心。
动则谈论 上百万的并发, 那都是扯淡。
UP############又在放屁了######真牛######对,社区还有说过亿的并发的呢######这个要顶,说的非常正确###### 不用扣字眼吧
的确你说的没错,操作系统里的“并发”(宏哥擅长的领域)应该是谈的临界资源的一些问题
大家都习惯性的将并发和“连接数”混为一谈的话,也没什么不可以的啊。“并发”,现在不单单是谈的某一小块代码里面(java里的synchronized里)的东西了,而是一整套。
就像你说的,如果你解决了高连接数,那宏观上的扎堆访问的情况就保证能解决了么?也不一定吧,那是不是每次谈“高并发”都要将这三个字扩展成几十几百个字的词语了...
倒是没见过大家专门谈“高连接数”,招聘要求里我想你也会写“高并发”而不是高连接数
我觉得也可以这样理解。对于用户端来看,“抢票”这个事情本身就是一个原子的,不管他后面怎么怎么怎么,他就是一个临界资源。 ######
我觉得也可以这样理解。对于用户端来看,“抢票”这个事情本身就是一个原子的,不管他后面怎么怎么怎么,他就是一个临界资源。
前向表现, 连接数和并发没有什么区别,用户视角
从技术角度, 前向的连接数无所谓, 随便都能支持
要解决的是后向的并发问题, 主要就是解决吞吐量的问题,就是真实的并发量
我招聘从来不写并发。 ###### 。。。
宏哥这次说了一个十分正确的事情 ######请宏哥谈谈秒杀 ######
做一个池子, 把鱼放进去
秒杀无外乎到池子里捞鱼, 有啥难的 ######精辟
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。