关于java:消息队列面试解析-传输协议

44次阅读

共计 1865 个字符,预计需要花费 5 分钟才能阅读完成。

0 前言

应用程序之间要想相互通信,一起配合来实现业务性能,还需传输协定反对。

传输协定就是应用程序之间对话的语言。设计传输协定,并无太多标准和要求,只需通信单方的应用程序都能正确处理该协定 && 无歧义。

1 断句

1.1 分隔符

传输协定也是种语言,传输数据时,首要解决的就是断句。

对传输层,收到的数据是怎么的?

就是一段段的字节,但因网络不确定性,你收到的分段并不一定是生产者收回去的分段。

那在协定中也加上“标点符号”不就行?

而且,并不需要像自然语言中那么多种的标点符号,而只需定义一个分隔符即可。

这方法确实可行,很多传输协定就采纳这种办法,比方 HTTP 1.0 协定,它的分隔符是换行(\r\n)。但这有个问题:自然语言中,标点符号是专用的,它没有别的含意,和文字人造辨别。
但在数据传输过程,无论你定义什么字符作为分隔符,实践上都有可能会在传输的数据中呈现。

那如何辨别“数据内的分隔符”和真正的分隔符?

得在发送数据阶段,加上分隔符前,把数据内的分隔符 本义 ,收到数据后再 本义 回来。
这确实是个麻烦过程,损失了一些性能。

1.2 预置长度

更加实用的办法。

给每句话后面加一个示意这句话长度的数字,收到数据时,按长度读。

如:03 下雨天 03 留客天 02 天留 03 我不留
这里固定应用 2 位数字寄存长度,每句话最长可反对 99 个字。接管后的解决就简略了,先读取 2 位数字 03,晓得接下来 3 个字是第一句话,那就等这 3 个字都收到,即可作为第一句话,同理读第二句话、第三句话。

这很好解决断句问题,实现比分隔符办法更简略,性能也更好,是广泛采纳的分隔数据的办法。

redis 的 aof 文件如同就是前置长度哦,经典计划无处不在~

前置长度是不是也有相似问题呢,03 也可能是失常文字里的内容,也是要本义吧?

你能够想一下,最好本人实现一下接收数据进行解析的代码,你就会明确,前置长度无需本义。因为解析时,可明确晓得以后读到的这个地位应该是长度还是真正数据,它不须要依据数据流中的内容来确定。

2 双工收发

2.1 单工通信

任一时刻,数据只能单向传输,一个人说时,另一个人只能听。
HTTP 1.0 协定就是这样,客户端与服务端建设个连贯后,客户端发个申请,直到服务端返回响应或申请超时,这段时间内,这个连贯通道上不能再发其余申请。

这种单工通信,效率低,很多浏览器和 APP 为解决性能问题,只能同时在服务端和客户端间创立多条连贯。

单工通信时,一句对一句,申请和响应按序顺次收发,有个人造对应关系。就像被女朋友质问时,女朋友问一句,你才敢答一句。这沟通效率有何意义?

2.2 双工通信

而 TCP 连贯是全双工通道,可同时进行数据的双向收发,互不影响。要进步吞吐量,应用层协定必须反对双工通信。

双工通信,不论是客户端还是服务端建设好连贯后,单方都能基于该 socket 进行收发音讯,而不是服务器只能 accept 到 message 后能力做些解决。

如果说你和你对象有边听边说的本事,换成双工协定后,根本就是在和女人讲道理,你们就会凌乱到分不清到底在答复问题 or 陈说观点。
并发下,程序也无奈保障。理论设计协议时,个别不关怀程序,只需确保申请和响应可能正确对应。

解决对应问题

发送申请时,给每个申请加个序号:该序号在本次会话内保障惟一,而后在响应中带上申请的序号,这就能把申请和响应对应上。

加上序号后,即便如抢答个别凌乱,也分得清到底在说啥。

你和你对象就能对本人收回去的申请来编号,回复对方响应的时候,带上对方申请的编号即可。这就解决了双工通信的次要问题。

在一次会话过程中,结尾的先是惟一序列号吗?而后前面跟数据长度,再是内容吗?
那接到音讯的一方,如何分辨序列号的长度大小,做到区分序列号和内容前的数据长度信息?

结尾就必定是数据长度,序号也是数据的一部分!所以应该在数据长度的前面。

3 总结

设计传输协定时,只有单方应用程序可能辨认传输协定,相互交换即可,并没啥相对的标准。

首要得解决断句,有“分隔符”和“前置长度”两种断句计划。

应用 ID 来标识申请与响应对应关系的办法,是比拟通用的实现双工通信的办法,可无效晋升数据传输的吞吐量。

解决了断句,实现了双工通信,配合专用序列化办法,即可实现高性能的网络通信协定,实现高性能的过程间通信。很多 MQ、RPC 框架都是用这种形式来实现它们本人的公有应用层传输协定。

简略的高性能通信程序:你和你对象三组对话,服务端是你对象,客户端是你本人,让俩人在客厅碰见一百万次,记录下总共耗时。

https://github.com/WangYangA9…
https://sourcegraph.com/githu…

正文完
 0