一个空间做两个网站的视频教程,免费域名注册可解析,培训报名,wordpress固定地址404目录 1. 基本概念1.1 长连接 和 短连接1.2 PUSH模式和PULL模式 2. 背景介绍2.1 理解端到端的思想 3. 方案选型3.1 技术挑战3.2 技术目标 1. 基本概念
在讲解消息可用性之前#xff0c;需要理解几个通信领域的基本概念。
1.1 长连接 和 短连接 什么是长连接#xff0c;短连接… 目录 1. 基本概念1.1 长连接 和 短连接1.2 PUSH模式和PULL模式 2. 背景介绍2.1 理解端到端的思想 3. 方案选型3.1 技术挑战3.2 技术目标 1. 基本概念
在讲解消息可用性之前需要理解几个通信领域的基本概念。
1.1 长连接 和 短连接 什么是长连接短连接 在HTTP/1.0中默认使用的是短连接。也就是说浏览器和服务器每进行一次HTTP操作就建立一次连接但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源如JavaScript文件、图像文件、CSS文件等当浏览器每遇到这样一个Web资源就会建立一个HTTP会话。 但从HTTP/1.1起默认使用长连接用以保持连接特性。使用长连接的HTTP协议会在响应头有加入这行代码 Connection:keep-alive在使用长连接的情况下当一个网页打开完成后客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭如果客户端再次访问这个服务器上的网页会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接它有一个保持时间可以在不同的服务器软件如Apache中设定这个时间。实现长连接要客户端和服务端都支持长连接。 HTTP协议的长连接和短连接实质上是TCP协议的长连接和短连接 TCP的长连接和短连接 对于TCP短连接一般由客户端发起三次握手经过一次读写操作后由客户端发起四次挥手断开连接。短连接的优点在于管理起来比较简单存在的连接都是有用的连接不需要额外的控制手段 对于TCP长连接简单来说client向server发起连接server接受client连接双方建立连接。Client与server完成一次读写之后它们之间的连接并不会主动关闭后续的读写操作会继续使用这个连接。 连接本身是一种资源连接建立后server需要保存相关的状态信息如果客户端已经关闭此时的状态信息就白白占用了server的资源因此需要保活功能的存在 保活功能主要为服务器应用提供服务器应用希望知道客户主机是否崩溃从而可以代表客户使用资源。如果客户已经消失使得服务器上保留一个半开放的连接而服务器又在等待来自客户端的数据则服务器将应远等待客户端的数据保活功能就是试图在服务 器端检测到这种半开放的连接。 如果一个给定的连接在两小时内没有任何的动作则服务器就向客户发一个探测报文段客户主机必须处于以下4个状态之一正常运行已经崩溃客户主机崩溃并已经重新启动客户机正常运行但是服务器不可达弱网环境 长短连接的选择 根据之前的介绍我们已经能感受到长短连接的优缺点。长连接通常用于收发频繁的场景尤其是点对点通信比如IM,数据库而短连接通常用于请求不频繁的情况比如一般的WEB网站对于网页资源的请求一般不会十分频繁。 简单的TCP长连接服务器DEMO TCP的保活机制保证了传输层的连接可用性但是如何保证应用层的连接需要我们做跟多的工作之后会单独讲解。 package mainimport (lognettime
)func main() {// 创建 TCP 连接conn, err : net.Dial(tcp, 127.0.0.1:80)if err ! nil {log.Fatal(Failed to connect:, err)}defer conn.Close()// 将连接转换为 TCPConn 类型tcpConn, ok : conn.(*net.TCPConn)if !ok {log.Fatal(Failed to convert to TCPConn)}// 设置 KeepAlive启用 TCP 连接的 KeepAlive 功能if err : tcpConn.SetKeepAlive(true); err ! nil {log.Fatal(Failed to set KeepAlive:, err)}// 设置 KeepAlive 周期每隔一段时间发送一个 KeepAlive 包if err : tcpConn.SetKeepAlivePeriod(10 * time.Second); err ! nil {log.Fatal(Failed to set KeepAlive period:, err)}// 在这里进行其他操作保持 TCP 连接处于活跃状态
} 1.2 PUSH模式和PULL模式
这个比较简单可以理解为GIT里的push和pull.服务器主动向客户端发数据叫做push,客户端向客户端请求数据叫做pull
2. 背景介绍
在IM场景下消息的可用性包含两个方面可靠性和一致性可以总结为可达有序不重不漏。
可靠性消息一旦显示发送成功则一定到达对端一致性任何时刻消息保证由于发送端的发送顺序一致
2.1 理解端到端的思想
在设计IM系统的时候最重要的思想是 端到端思维 端到端原则是一种分布式系统中各个模块之间功能定位的设计原理指的是从代价和性能的角度出发在网络的最核心的部分应该只去做数据的传输而不能去做一些其他的应用而数据是否正确传输则应该放到应用层去检查和判断从而保证互联网核心的简单性可维护性可拓展性。 简单的理解端到端思想可以以数据传输的可靠性为例子在网络中传输文件传输错误可能发生在端到端路线的多个节点也许我们可以通过在每一个交换节点上都加入数据校验超时重传的机制来保证数据正确但是实际上可能错误可能发生在端系统的自身比如磁盘存取错误缓存不足。这样一来即使中间节点提供了数据的可靠端系统也没有任何工作量的减少依然需要进行正确性的检测。 因此在中间节点只需要提供其能完全实现的功能即路由转发即可。
OSI七层模型也是端到端思想的产物主机网络的每一层都是一个端系统只对本层负责保证本层数据可靠不保证上层数据可靠。这样的设计使得每一层功能不重叠结构清晰
数据链路层第二层和物理层第一层 这两层负责将数据转换为比特流并通过物理介质传输。在端到端原则下这些层不应对数据进行处理而应只负责将数据从一个点传输到另一个点。网络层第三层 数据在网络中进行路由和转发以便从计算机 A 到计算机 B。在端到端原则下网络层应该提供最佳的数据传输路径但不对数据进行修改或过滤传输层第四层 数据被传输到传输层以便在计算机 A 和 B 之间进行可靠的数据传输。在端到端原则下传输层负责数据的分段、重传和错误检测以保证数据的完整性和可靠性
由此我们可以总结底层可靠性仅能保证底层可靠不对上层负责。传输层已经帮我们做到了数据的完整和可靠但是并不能说它能保证应用层的可靠了。 那么TCP到底做到了哪一步我们又需要做哪些工作呢 现在假设一个场景应用层不做可用性处理clientA发送msg1和msg2到server,两个消息通过一个长连接到达了服务端此时可能会出现下面这些情况
msg1和msg2到达应用层分别由一个线程去处理msg2先落表成功发送给clientB,造成数据乱序。msg1在server落盘失败msg2成功先发送给了clientB,造成数据丢失乱序。消息在由接入层到达业务层的时候server进程崩溃但是此时clientA认为已经送达服务端业务无法感知消息丢失。
因此对于IM这种三方通信来说TCP/UDP的保证是远远不足够。
消息的端到端可用性 上行消息可用 服务端业务可用 下行消息可用
3. 方案选型
如何设计一个保证消息端到端可用性的协议是我们的本文的最重要任务。
3.1 技术挑战
三方通信难以保证网络上的消息必达没有全局时钟那一确定唯一顺序因果顺序 时钟零点漂移问题时钟零点漂移通常指的是在计算机系统中时钟的偏移或漂移这可能会导致时钟与实际时间之间存在误差。这种情况可能由多种因素引起包括硬件时钟的不准确性、操作系统的时钟管理、系统负载等。 可行的解决方式有 使用网络时间协议NTP NTP 是一种用于同步计算机时钟的协议可以从互联网上的时间服务器获取准确的时间信息并调整本地时钟以匹配其时间。在大多数操作系统中可以配置系统以自动与 NTP 服务器同步时间。定期同步时间 即使已启用自动同步时间功能也建议定期手动同步一次时间以确保时钟的准确性减少系统负载 高负载的系统可能会影响时钟同步的准确性。尽量减少系统的负载特别是在进行时钟同步时 消息顺序性在多客户端多服务端多线程/协程下那一保持 3.2 技术目标
对消息可用性的进一步细化
消息及时实时接收发送 响应时间200ms高峰期 1s消息可达超时重试ACK确认消息幂等每条消息只处理一次:分配seqId,服务端存储seqId消息有序seqId可比较接收端可以按照发送端的顺序进行消息排序 一个会话内保证消息有序即可 在下一篇文章中我们将探讨更加具体的实现方案。
