go语言体系课视频配套文档

Chatok.cn go语言聊天
Chatok.cn go语言聊天
文章作者: 全栈编程@luboke.com
版权声明: 本文章为全栈编程go语言体系课视频教程配套电子书,版权归 全栈编程@luboke.com所有,欢迎免费学习,转载必须注明出处!但禁止任何商业用途,否则将受到法律制裁!

以目前微商城小程序电商系统【以下简称“微商城”】为例,假如有千万级别的用户同时在线,目前有新品发布上线,如何高效的推送给这数千万的用户?

一、消息推送模式(属于JMS发布/订阅的细分)

  1. 推模式
  2. 拉模式

二、JMS

  1. 点对点
  2. 发布/订阅

参考:https://blog.csdn.net/heyutao007/article/details/50131089

三、消息推送常见问题

一、消息推送模式

在讨论这个问题之前,我们一起来看一看消息推送的两种模式,推模式与拉模式:

这两种模式最明显的区别是,是由服务端主动向客户端发送数据,还是有客户端主动向服务端拉取数据

消息队列比较核心的应用场合有三个:解耦、异步和削峰。

  • 推模式:消息中间件主动将消息推送给消费者
  • 拉模式:消费者主动从消息中间件拉取消息

1.Push模式(推模式)

  • 推模式是服务器端根据用户需要,有目的的、按时将用户感兴趣的信息主动发送到用户的客户端
  • 这种模式下,客户器端服务器发送一个申请,并把自己的地址(如IP、port)告知服务器,然后服务器就源源不断地把信息推送到指定地址。在多媒体信息广播中也采用了推模式。另外,如手机*、qq广播。
  • Push模式的主要优点是
    • (1)由于服务器把信息推送给客户端之前,并没有明显的客户请求。所以对用户的要求低,方便用户获取需要的信息。
    • (2)由于推模式(push模式)可以让信息主动、快速地寻找用户/客户器,当消息到达后,就会立即被投递给匹配的消费者,所以实时性非常好,消费者能及时得到最新的消息。 
    • (3)推模式将消息提前推送给消费者,消费者必须设置一个缓冲区缓存这些消息。优点是消费者总是有一堆在内存中待处理的消息,所以当真正去消费消息时效率很高。缺点就是缓冲区可能会溢出。
  • Push模式的缺点
    • (1)不能确保发送成功。Push模式采用广播方式,只有服务器端和客户端在同一个频道上,推模式才有效,用户才能接收到信息
    • (2)没有信息状态跟踪。Push模式采用开环控制技术,一个信息推送后的状态,比如客户端是否接收等,无从得知,也就是说客户端收到数据后并没有反馈信息给服务端。
    • (3)针对性较差或者说精确性较差。推送的信息可能并不能满足客户端的个性化需求,也就是说不一定满足客户的需求。

2.Pull模式

  • 拉模式是客户端主动从服务器端获取信息,服务器把自己所拥有的信息放在指定地址(如IP、port),客户器向指定地址发送请求,把自己需要的资源“拉”回来。不仅可以准确获取自己需要的资源,还可以及时把客户端的状态反馈给服务器。
  • 拉模式的主要优点是
    • 针对性强,能满足客户端的个性化需求,在消费者需要时才去消息中间件拉取消息,这段网络开销会明显增加消息延迟,降低系统吞吐量。 
    • 信息传输量较小,网络中传输的知识客户端的请求和服务器端对该请求的响应
    • 服务器端的任务轻。服务器端只是被动接收查询,对客户端的查询请求做出响应
  • 拉模式的缺点
    • 实时较差,由于拉模式需要消费者手动去消息中间件中拉取消息,所以实时性较差;消费者难以获取实时消息,具体什么时候能拿到新消息完全取决于消费者什么时候去拉取消息。针对于服务器端实时更新的信息,客户端难以获取实时信息
    • 对于客户端用户的要求较高,需要对服务器端具有一定的了解。

JMS

我们在来看一看另一种消息推送的机器,做过java的同学肯定听过JMS,Java消息服务(Java Message Service,JMS)应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。

规范目前支持两种消息模型:点对点(point to point, queue)和发布/订阅(publish/subscribe,topic)。

点对点与发布订阅最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)

点对点:Queue,不可重复消费

消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息。
消息被消费以后,queue中不再有存储,所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费。当没有消费者可用时,这个消息会被保存直到有一个可用的消费者,所以Queue实现了一个可靠的负载均衡。

 

发布/订阅:Topic,可以重复消费

消息生产者(发布)将消息发布到topic中,同时有多个消息消费者(订阅)消费该消息。和点对点方式不同,发布到topic的消息会被所有订阅者消费。只有订阅了topic的订阅者才会收到消息。topic实现了发布和订阅,当你发布一个消息,所有订阅这个topic的服务都能得到这个消息,所以从1到N个订阅者都能得到这个消息的拷贝。

 

支持订阅组的发布订阅模式:
发布订阅模式下,当发布者消息量很大时,显然单个订阅者的处理能力是不足的。实际上现实场景中是多个订阅者节点组成一个订阅组负载均衡消费topic消息即分组订阅,这样订阅者很容易实现消费能力线性扩展。可以看成是一个topic下有多个Queue,每个Queue是点对点的方式,Queue之间是发布订阅方式。

 

 

 

于推拉这两种推送模式JMS定义的规范,我们得出结论:要想实现高吞吐量,消费者需要使用推模式进行消息的处理。

基于以上推拉技术的综合技术点考虑,我们这里以websocket长连接做为基础,使用服务端主动推模式。

基本上任何一门编程语言只要涉及到web编程,都会涉及到websocket,而且都有成熟稳定的解决方案,不用重复造轮子。

 

扩展

传统企业型消息队列ActiveMQ遵循了JMS规范,实现了点对点和发布订阅模型,但其他流行的消息队列RabbitMQ、Kafka并没有遵循JMS规范。

RabbitMQ

RabbitMQ实现了AQMP协议,AQMP协议定义了消息路由规则和方式。生产端通过路由规则发送消息到不同queue,消费端根据queue名称消费消息。
RabbitMQ既支持内存队列也支持持久化队列,消费端为推模型,消费状态和订阅关系由服务端负责维护,消息消费完后立即删除,不保留历史消息。

(1)点对点
生产端发送一条消息通过路由投递到Queue,只有一个消费者能消费到。

(2)多订阅
当RabbitMQ需要支持多订阅时,发布者发送的消息通过路由同时写到多个Queue,不同订阅组消费不同的Queue。所以支持多订阅时,消息会多个拷贝。

Kafka

Kafka只支持消息持久化,消费端为拉模型,消费状态和订阅关系由客户端端负责维护,消息消费完后不会立即删除,会保留历史消息。因此支持多订阅时,消息只会存储一份就可以了。但是可能产生重复消费的情况。

(1)点对点&多订阅
发布者生产一条消息到topic中,不同订阅组消费此消息。

文章作者: 全栈编程@luboke.com
版权声明: 本文章为全栈编程go语言体系课视频教程配套电子书,版权归 全栈编程@luboke.com所有,欢迎免费学习,转载必须注明出处!但禁止任何商业用途,否则将受到法律制裁!
copyright © 2020 全栈编程@luboke.com