ZeroMQ消息模式分析：通讯结构、缓冲队列及PUSH/PULL模式详解

有一个被很多人天天使用，却讲不清楚究竟如何运作的东西，它是分布式系统里的核心组件，也就是消息队列。今天不讲那些空洞的内容，而是直接去剖析它的基础结构，还有它的通讯机制，以及它的缓冲策略，以此让你弄清楚消息是怎样于节点之间进行流转的，并且明白那些会导致阻塞以及丢消息的场景究竟是如何出现的。

端口缓冲与队列设计

消息队列系统借助绑定端口开展通讯，每个端口内部都有自带的缓冲区，该缓冲区用于暂存来不及进行处理的消息。这个缓冲区，其本质实际上是一块内存区域，当网络数据到达的速度超出应用处理速度之时，数据会先落到此处，以免直接丢失。缓冲区的大小，会对系统的抗压能力产生直接影响。

除去端口缓冲区，系统自身另外实现了一个缓冲队列，其默认长度为1000。这个队列是消息进入业务逻辑之前的最后一道关卡。要是系统处理能力跟不上，队列就会被填满。在这种情况下系统会依据通讯模式做出不一样的反应：要么使发送端阻塞等待，要么直接丢弃新到的消息。这样的设计确保了系统在高压环境下不会崩溃，不过代价就是部分消息或许会丢失或者发送端会被卡住。

调整缓冲队列长度

缓冲队列的长度并非处于固定状态，开发者得以依据实际的业务场景进行灵活的调整。就拿ZeroMQ的Python绑定来说，在创建一个PUSH套接字之后，借助setsockopt方法便能够对队列长度予以修改。举例来讲，将其设置为2000，这所代表的是系统能够暂时存放2000条有待处理的消息，而这便给予了下游更多的缓冲空间。

队列长度之外，端口缓冲区大小也是能够进行调整的。依旧采用setsockopt方式，传入200与1024相乘的结果，便能够将缓冲区设置为200K。此参数对网络层能够缓存的数据量起着决定作用。要是你的消息体积较大然而频率较低，适度调大缓冲区能够减少丢包情况发生；倘若消息体非常小但并发程度极高，调小缓冲区反倒有助于快速触发背压机制，防止内存占用过高。

PUSH/PULL模式的阻塞机制

PUSH与PULL，是特别典型的那种一对多的推送模式，PULL端绑定着一个端口，此端口专门负责接收消息，存在多个PUSH端，这些PUSH端能够同时朝着那个端口推送数据，在这种模式情况之下，所有的PUSH端彼此之间都是对等的，PULL端依照公平队列的方式，从各个PUSH端轮流去取消息，如此便保障做到了负载均衡。

当PULL端处理存在困难，无法及时处理时，它的接收缓冲队列会慢慢地逐渐被填满。一旦该队列满了，那么PULL端就会暂时没办法接收新消息。就在这个时候，如果PUSH端的发送缓冲队列同样也被填满了，PUSH端就会进入到阻塞状态。在阻塞期间，程序会停留在那里，一直到PULL端处理完一部分消息，队列出现空闲状况，PUSH端才能够继续进行发送。这种机制借助压住发送端的方式来保护接收端，以此防止系统产生雪崩。

PUB/SUB模式的丢弃策略

广播订阅模式是PUB/SUB，PUB端绑定端口，此端口用于向外广播消息，存在多个SUB端，这些SUB端借助订阅来接收自身感兴趣的内容，在这种模式当中，对于PUB端而言不存在队列长度限制，它会持续朝着缓冲区写入数据，当缓冲区处于满了的状态时，新来的消息会直接将旧数据覆盖。这所表明的是，要是订阅者处理速度过慢，那么有可能会错过中间状态，最终只能获取到最新的消息。

SUB端此处存在供自身使用的缓冲队列，这个缓冲队列是用于临时存放从网络那里接收而来的消息的。当SUB端处理消息的速度跟不上，致使缓冲队列被填满之际，新的消息便不会再进入队列，而是会被直接丢弃掉。一直到队列当中出现有空闲的位置，SUB端才会再次开始进行接收。这样的设计是以牺牲掉一部分消息的完整性作为代价，从而换取了发布端的无阻塞性能以及订阅端的稳定性。

两种模式的实际应用场景

若将PUSH/PULL模式应用于任务分发场景，比如在视频转码系统中，多个生产者负责推送视频文件路径，下游的转码服务器会逐个对其进行处理。倘若所有转码服务器均处于忙碌、无法及时处理的状态，那么PUSH端便会出现阻塞情况，新任务也不会继续被提交。这种情况能够避免因任务大量堆积从而导致系统资源耗尽。此模式确保了消息不会丢失，不过其代价在于发送端有可能会被阻塞。

PUB/SUB模式适宜于实时数据广播，像股票行情推送这种情况，多个客户端会订阅不同股票的实时价格，要是某个客户端出现网络波动，或者处理速度慢，那它有可能丢失几条价格变动，不过只要恢复之后能够跟上最新价格，对于交易决策产生的影响就不大，发布端永远不会因为某个订阅者速度慢而受到拖累，从而保证了系统的整体吞吐量。

参数调优的注意事项

在对缓冲队列长度予以调整之际，绝不能够仅仅着眼于数字的大小。一旦队列偏长，便会大量占用内存，要是每条消息的体积较大，那么纵使仅有几千条消息堆积于队列之中，也极有可能引发内存溢出的状况。而倘若队列太短的话，又极易诱发阻塞或者丢消息的情形，进而对业务的稳定性造成影响。通常来讲，建议依据消息的平均大小以及期望的积压容忍度来展开计算一番，比如每条消息为1KB，所需容忍积压5000条，如此一来，队列长度便设定为5000。

缓冲区大小在端口方面同样是需要进行权衡的，要是设置得过大，在网络出现突发流量之际能够进行平滑处理，然而却会长时间占用内存，要是设置得过小，就容易频繁触发阻塞，进而降低吞吐量，在实际进行调优的时候能够运用压测工具去模拟真实流量，来观察消息延迟以及丢包率，从而逐步找寻到最为合适的参数，要记住一点，调参并非能够一劳永逸，随着业务的增长是需要定期进行评估的。

在平常使用消息队列之际，所碰到的最为棘手的难题，究竟是为了防止丢消息而进行调参，还是去排查阻塞方面的问题呢？欢迎于评论区当中分享你自身的实战经历。