GuuJiang 最近的时间轴更新
GuuJiang

GuuJiang

V2EX 第 58186 号会员,加入于 2014-03-14 16:18:47 +08:00
今日活跃度排名 2833
根据 GuuJiang 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
GuuJiang 最近回复了
更正一下,甚至我自己说的“自旋锁只是其中一种手段”这句话都是不准确的,自旋并不是锁的必要条件,锁也不是靠自旋实现的,有没有自旋,自旋多少次都不影响锁行为的正确性,自旋的存在仅仅是作为“预期能够很快得到锁,自旋的代价小于 wait 的代价”这一前提下的一种优化手段而已,既然是优化,那自然是可以调整其参数甚至去掉的
如果“预期能很快得到锁”这个条件满足,那么自旋带来的收益就是正的,如果条件不满足,那还不如不自旋,而在单核条件下这个条件显然是不可能满足的,那关掉自旋(其实就是把自旋次数改为 0)也是一种很自然的选择
@raysonx 这就是你和其他所有人分歧的出发点,没有人说过去掉锁啊,锁是目的,自旋锁只是其中一种手段,去掉自旋 != 去掉锁,不管怎么说,也改变不了在单核环境中自旋就是被优化掉了这个事实
这篇帖子生动地展示了什么叫作“你在第二层,你以为我在第一层,实际我在第五层”
按照“是不是只能等 A 执行完毕”这样的表述,提问者应该在第一层,估计还没有形成时间片这个概念,于是第二层的人敏锐地意识到了这一点,指出了不管是不是单核,实际都有并发,但是这个帖子好巧不巧提到了自旋,于是引来了第五层的人,指出了在单核环境下自旋是无意义的,但是第二层的人无法区分第一层和第五层,把所有第五层的对手都当第一层的来辩论
其实跟各种软件自带一大堆重复的 dll 同样的理由,站在开发者的角度,肯定是统一的依赖管理更合理,然而站在小白用户的角度,更看重的是开箱即用,最终形成了这个恶性循环的局面
9 天前
回复了 zhoudaiyu 创建的主题 Linux 今天遇到了一个 curl 的问题,感觉有点坑
@zhoudaiyu 你执行下 fg 命令还会有新的惊喜
10 天前
回复了 James369 创建的主题 数学 概率中的 P(Ω)=1 应该怎么理解?
数学问题要从定义出发,不要从直觉出发,“独立”在概率论里只有一个明确的定义,那就是 P(A)P(B)=P(AB) ⇔ A 和 B 独立,因此把 P(Ω)=1 代进去,显然成立
14 天前
回复了 Joker123456789 创建的主题 Java 问几个有关 NIO 的问题
我补充一下,确实存在同一个端口同时支持多种协议的情况,但这个和提问者想象的那个不是一回事,可以认为这个分发工作仍然是处在协议处理层,相当于一个复合的协议,具体实现时类似状态机,总之只需要记住一点,IO 部分是不关心上层协议的
14 天前
回复了 Joker123456789 创建的主题 Java 问几个有关 NIO 的问题
恭喜你终于开始有点要逐步转到正确方向的迹象了,我来依次回答下你的每个问题,希望你哪天能正确认识到你在原来那个帖子里犯的错误是多么的基础和低级,并且向所有指出你问题的人一一道个歉
1. 不保证
2. 会
随时记住一点:TCP 是流式协议

关于分片的问题,任何分法都是有可能的,随时记住一点:TCP 是流式协议、TCP 是流式协议、TCP 是流式协议,对上层协议一无所知

关于协议解析的问题,在你选择了监听某个端口之前,这个端口期望收到的协议是已经提前确定了的,换句话说你需要自己负责按照预先的期望去解析协议,并不存在你想象中的“根据收到的内容自动判断协议”这种东西
@JasonLaw 以下描述不针对负载均衡类应用,而针对广义的抽象的 IO+业务处理
想象收银台(IO 模块)和厨房(业务模块)是两个独立的部门,对彼此是黑盒,收银台收到订单后将菜单交给厨房制作(读到数据后调用业务模块),厨房制作完成后将食品让收银台交给用户(业务处理完成后结果写回客户端),针对你的问题“当咖啡处理好了之后,是收银员将咖啡拿给顾客吗”,答案是是的,只有收银台才能和顾客打交道(持有连接)
那么每个部门内部可以分别独立地作出以下选择
收银台:
1. 一个顾客首次到来(建立连接)后指派一个专门的收银员(IO 线程)全程服务这个顾客直到他离开(断开连接),这就是阻塞式 IO,在这个过程中顾客完全可以点一样东西,思考几分钟,再点下一样,他思考的时候收银员就在等待(阻塞)
2. 一个收银员服务轮流服务所有顾客,并且只服务那些已经想好了(数据就绪)的顾客,如果顾客点了一样东西然后卡壳了,需要继续思考(就绪数据已读完),那么对不起,请你马上让开给下一个想好的顾客,等你想好了再来(下一轮 select/poll/epoll),当然收银员有职责记住每个顾客已点的部分食品,下一轮继续回来点的东西能够拼接上,最终形成完整订单(即上层协议的分割和解析,当然这一步严格来说到底算 IO 模块还是算业务模块暂时存疑,具体取决于期望 IO 模块的输出是 TCP 流还是上层协议内容),这就是非阻塞 IO
厨房:
1. 收银员递交订单后需要一直等着,直到拿到做完的东西后才能转身继续服务顾客,这就是同步调用
2. 收银员递交完订单后就转身继续服务顾客,厨房有需要的时候再把东西交给收银台,这就是异步调用

建立完这个模型后再来逐一进行整体的分析
1. 收银台采用阻塞式
优点
1) 和厨房打交道时既可以选择同步方式也可以选择异步方式,当然实际情况多采用同步,因为即使使用了异步,仍然会搭配 wait 等调用,本质上还是转化成同步了
2) 在描述收集整个订单(即上层协议解析)时可以站在收银员的角度,在写一些复杂协议时比较符合人的直觉,即当读完某一部分数据后可以根据需要主动地进行读操作,如果无数据可读就进入阻塞
缺点
1) 要么保证需要的收银员数量完全等于此刻所有处在点单过程中的顾客数量(即一客户端一线程),造成了大量的资源消耗(线程的内存等资源开销),甚至耗尽资源,要么给收银员人数设上限,从而导致了某些顾客无法分配到收银员(客户端连接被阻塞)
2) 即使收银员数量是充足的,但是收银员只有在收银台才能和顾客交互,所有的收银员只能轮流使用收银台(CPU 时间片),而收银台数量是有限的,且一个收银员用完收银台换下一个收银员用时必须要进行一些交接工作(线程上下文切换),那么当收银员数量多到一定程度时可能花在交接收银台上的时间比真正使用收银台的时间还要多
2. 收银台采用非阻塞式
优点
只需要一个或少数几个收银员就可以服务大量顾客
缺点
1) 通常来说和厨房打交道时就只能选异步方式了,当然这个没有任何强制,开发者也可以自行选择同步方式,但是如果业务是耗时操作,那带来的灾难就远大于阻塞式,因为这时不单阻塞了一个顾客,而是阻塞了所有顾客,这其实是一种典型的误用,我个人觉得真出现了这种情况,需要为之负责的是开发者自己,但是却有人觉得这是非阻塞式 IO 的缺陷,我是难以认同的
2) 协议解析、业务处理等部分不能再站在收银员的角度,即收银员无权主动要求读下一块数据,只能被动地接收数据,由顾客来驱动,这有点违反直觉,在写一些复杂协议的解析时需要人工改写为状态机,这也是有的人不习惯使用非阻塞 IO 的原因,无法扭转这个视角

回到你的问题来,我没深入研究过负载均衡类系统,所以不敢妄下结论,只能说说自己的猜测,即如果我自己来实现一个负载均衡系统的话会选择怎么做
还是老话,IO 和业务独立分析,IO 部分既然它们自己说了是非阻塞那就是非阻塞了,所以重点看业务部分,作为一个负载均衡系统,假设它的业务就是选择合适的后端->透传数据,从这个角度讲其实就是把两个反向的 IO 模块背靠背连接起来,并且以无状态的方式透传数据,那么可以认为它的业务是非常轻量的,不好用厨师的例子来做类比
@JasonLaw 其实关于非阻塞 IO 有一个非常普遍非常具有迷惑性的误解,就是把 IO 和业务处理这两者混为一谈,这就会产生两种错误的理解
其一:误以为非阻塞 IO 对于业务处理也是有帮助的,觉得只要用上了非阻塞 IO 就能用单线程或者少量线程处理大量的业务
其二:虽然没有上述的误解,但是会觉得反正到了业务处理阶段还是要多线程的,那 IO 处的单线程就是无意义的,从而觉得非阻塞 IO 没用

事实上这二者是完全独立的两个问题,你可以尝试下面的思考方式
第一步:先假设最简单的一种业务,就是一个黑洞,读到数据后直接丢弃,这样抛开业务处理的影响来单独分析 IO,在这个前提下对比阻塞式和非阻塞式的区别并正确理解非阻塞 IO 的意义
第二步:此时加入业务处理,在读到数据后进行异步处理(具体的方式可能是开线程、投递到线程池、发送到消息队列、异步 RPC 等等),总之具体方式不重要,重要的是异步处理,由于是异步处理,那么对于 IO 的影响可以认为和上述的直接丢弃几乎没区别,所以上一步中得到的各种结论仍然成立

在充分理解了这一切之后,再回过头来看你在标题中的问题,答案是肯定的,是否使用非阻塞 IO 只影响收银员(即 IO 线程)与顾客之间的关系,也就是实现了用少量收银员服务大量顾客,至于能否更快提供咖啡,这已经是业务处理阶段的问题了,与是否使用非阻塞模型没有关系,非阻塞只负责用户不会卡在收银这个环节,至于后面怎么提供服务,一个厨师还是多个厨师,这些都不是收银员需要关心的问题
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1297 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 9ms · UTC 17:29 · PVG 01:29 · LAX 10:29 · JFK 13:29
♥ Do have faith in what you're doing.