Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

组队吃饭问题的纠结点

  经常和同事组队去吃饭,可是大家一般仅仅是「组队去」而已,到了餐厅又开始各自单点。而且公司楼下的餐厅上菜也挺烦,第一份可能很快就上了,而后续的可能拖好久。然而大家一起来的通常也会一起走,最后造成的结果是先吃完的人得等大家吃完。
  也许有人会问,既然这么纠结干嘛还要组队去吃饭?叫外卖多好?其实叫外卖也会遇到同样的问题。餐厅通常不会逐份送,都是同一区域有一定量的订单后一起送,这样才能让配送成本降到最低。然而这时候可能第一份餐早就做好了,而最后一份很久之后才做好。最终会变成所有外卖的送餐速度以最慢的那个为准。总之吃饭是件很纠结的问题,所以最近我也逐渐变成早上在家里做好便当带到公司了。
  无论是组队出去吃还是一起叫外卖,只要是存在「批量处理」的问题就总会带来一些不尽人意的结果。之前我也让公司的后端提供一个 API 合并的接口,虽然解决了请求数过多的问题,但请求打包后就会造成如果其中一个子请求很慢就会拖慢所有请求的问题。于是就会遇到和上面吃饭相同的问题。
  也许现实中的这些问题要真正解决非常困难,但就程序而言确实是可以解决的。由于一开始我们的合并请求接口设计是基于有序数组的,所以解决这个问题会踩坑。如果合并请求是先给每个请求添加一个唯一标识符再以无序的形式发给服务器的话,服务器响应也不需要照顾发送的顺序,可以完全按照子请求的处理速度来,这样就可以先返回处理较快的部分。客户端收到响应后可以根据发起请求时给的唯一标识符来选择处理函数。
  这个实现需要用到的技术大概有 HTTP Chunked(让服务器可以先响应处理完的数据)、XHR progress(XHR 对象加载过程中的数据收集)、JSON Stream(用于让客户端解析传输过程中的 JSON)。如果是组队去吃饭,那就意味着大家不要等到所有人吃完后才一起走,先吃完的先走(谁买单啊混蛋 >_<)。虽然感觉有点不太礼貌吧,不过这确实是效率最高的实践了。
  有时候我真觉得人类那纠结的感情是社会进步的障碍。
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^