@doveshelly #7 http long polling 就是用于服务端主动给前端应用推送消息的，流程显示二维码的时候请求一个后端接口，但是这个接口不立刻返回，而且等着另外一个用户扫码之后请求已扫描接口请求来触发这个接口的返回，所以这个也是实时的，之所以这个流程依然是无状态的，是因为服务端会缓存已扫码状态一小段时间，所以无所谓先扫码还是先请求 http long polling ，而且如果请求 http long polling 超时就再次重试就行，知道关闭二维码页面，实现起来也简单，和轮询实现逻辑差不多，但是再次重试不延时所以是实时的

其实 websocket 状态管理确实挺复杂的，你这个需要展码前就完成 websocket 建立吧，安全性加 TLS 就行但是服务端还是要用 token 做下校验

其实这种短时通知其实用 http long polling 更方便，可重入实时性也有保证，展码和 http long polling 请求无关前后，spring boot 可以用 DeferredResult 就可以在等待期间释放工作线程了，其它框架估计也有类似支持，如果有多节点的话可以考虑这种

https://gist.github.com/snower/f8ef25e57c72f9b41fb31ee8b164193b

http long polling 的好处就是依然是无状态的，实现和维护都简单，而实时性和 websocket 一样

验证不通过其实就是输入错误难道不是 error 不应该走 error handling 么？谈 try catch 会增加性能开销那更是扯淡，不是说没有性能开销而是实际业务中纠结这个毫无意义

想多了，蜂窝网和宽带网组网过程就不是一样的，比如手机在基站间切换是不断网的吧，而且似乎相同基站和相同子网的蜂窝网并不能互通吧

更无语的是哪种不能说不熟，发个在吗，回了在，过半小时他又给你发了个在吗，然后就这么来来回回的折腾，感觉血压都升高了

@xiaocongcong 这种难道不是应该说，你好，现在是否有空，云云之类的，在吗这个其实更不礼貌了有没有😂😂

不 join 单表读有啥压力。。别过度优化啊，复杂查询大多也能接受延时，还是异步同步好吧

@vislins 矫情，迫害妄想症，好像苹果谷歌就不限区似的，没件事情都是有成本的，都是要考虑成本的，只有成本没有收益的事情谁愿意干啊，不影响他人谁 TM 想理你

工信部发的是政策要求，其实并没有任何技术实现要求，也不可能有技术实现要求，实现是各厂商自己怎么选择的事情，最终落实估计也就是不备案的不允许上应用商店的事情，这早 8 年的不就已经是这个样子了，一个事实标准变成一个政策要求，搞不懂大家为这事激动个啥

https://mp.weixin.qq.com/s?__biz=MzIyNDU2NTc5Mw==&mid=2247510019&idx=1&sn=5a79379d068139523fbd346402cae893&chksm=e80fe74ddf786e5bcaf73ba2194bc11889a33a544ed12c650be7d177472417b423c7ffbd5524&from=industrynews&version=4.1.8.6020&platform=win#rd

人家刚还发了文章详细介绍了怎么优化内存的

长期的话边际收益太低，工资涨 3 倍估计才能覆盖边际成本吧，但是对于公司来说，增加两天工作日产出增加估计都不到 20%，所以显然员工和公司都不合算，所以不接受，也没啥意义

高带宽内存，现在大火的，AI 也很需要

把常用的不需要代理的应用比如微信支付宝什么选按应用分流，其它的不怎么用其实就不怎么耗电了，按应用分流是安卓系统提供的功能，底层走的是策略路由表，所以性能和能耗是可以得到保证的，不用担心太耗电

304 不是未修改可以用缓存。然后浏览器就读缓存成功了，最后给你返回 200 没问题啊，毕竟已经有正确的内容了，是你理解的有问题吧

如果只是某中 pod 简单用下，倒是弄个 pod 配置里添加下 hosts 把需要出口的域名指向需要出口的地址，然后在需要出口的地址挂个端口转发程序 pod 就好了，如果有出口 node 端口占用的问题，那么还可以把 hosts 指向本机然后在当前 pod 再配置个容器再端口转发一次，这样出口 node 节点就可以使用其它端口了

当然如果大部分 pod 和大部分流量都需要转发那还是 route+nat 或是 istio egress 比较好

哥啊滴滴被罚已经是很久以前的事了，你这延迟有点高了，再说大佬都说过知错就改还是好同志，而且吧红绿灯倒计时也不是啥敏感数据，有啥不能开放的，也确实是个好事也可以为未来智驾做铺垫，管方确实在开放接口了

调用链最短化和代码复用最大化考虑实际情况取最优就可以，不要太纠结，有时一开始就想各种复用就是瞎搞，然后一层调一层各种子包子项目的，其实也是乱的一塌糊涂，最后一看毛复用的情况都没出现，纯属一开始瞎想

如果是微服务体系下，单项目应该尽量单一职责，服务规划合理的情况下，项目内本来就应该缩短调用链，再一层调一层其实很多余才是更坑死

@huangya #16 其实你只要理解硬件的中断优先级是手动管理的，硬件编程和软件编程不一样，如何调度何时调度都是固定的，所以每秒留给按钮处理程序多少时间一般就是提前设计好的，几乎不会有明显波动，所以一般来说就人的反应来说并不会出现来不及处理的情况，而且吧就算是嵌入式程序，设计合理严谨的程序也不会直接在中断里直接完成逻辑处理，一般都只是获取完状态然后创建任务交给主程序完成业务逻辑，那么这种情况下，每个中断的处理时间是完全精确到了具体的时钟周期，提前就可以完全精确的算出了每个中断耗时和冲突情况，既然如此按钮能否正常处理提前就能知道啊

而对于有操作系统的像树莓派这种，一般来说应用程序层面接收到的都是内核给的软中断，一般不是驱动程序的话并不能直接接收到硬件中断吧，否则岂不是应用程序处理异常就会导致内核直接崩溃，换句话说内核负责管理了中断优先级和调度延时，同样一般内核也能保证硬件中断能得到及时处理，毕竟硬件中断并不会受到系统负载的影响，而对于网卡、USB 之类需要处理大量数据的这种设备，其实硬件已经通过 DMA 把数据直接存到内存了，硬件中断只是告诉操作系统有新数据已经保存到内存，之后同样转有软中断处理，所以硬件中断所做的事情是非常少的，不能及时处理的可能性很小，软中断自然收到操作系统调度影响但是此时程序设计本身就能支持不确定延时了吧