前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >什么是消息系统?

什么是消息系统?

作者头像
哒呵呵
发布2018-08-06 11:28:14
1K0
发布2018-08-06 11:28:14
举报
文章被收录于专栏:鸿的学习笔记

首先来看什么是消息系统?简单来讲就是生产者发送包含事件的消息给消息系统,然后将消息推送给消费者。消息系统有很多种,最简单的就是TCP连接这种的直接信道,之后出现的消息系统大多都是在这个模型上构建的,只不过TCP是生产者和消费者一对一,更完善的消息系统是多对多的形式。

如果让你来设计消息系统

  1. 生产者发送消息的速度比消费者快,消息系统该怎么处理?
  2. 消息系统布置的节点崩溃,消息要怎么处理?
  3. 当消息发送失败或者重复时,重试机制要怎么处理?

带着这些问题继续下去

1.生产者直接将消息发送给消费者

这个算是最简单粗暴的处理方式,消息不经过中间节点。但是这个需要生产者和消费者考虑消息丢失的可能性,在消息处理的过程种需要生产者和消费者长期保持在线,一旦有一方不在线,消息便会丢失无法找回。所以这个时候需要消息代理使得消费者和生产者解耦。

代表系统:UDP,ZeroMQ

2.消息代理的方式(JMS/AMQP)

消息代理实质上是一种针对处理消息流而优化的数据库。 它作为服务器运行,生产者和消费者作为客户端连接到服务器。生产者将消息写入代理,消费者通过从代理那里读取来接收消息,使得生产者和消费者可以顺利解耦。消息的持久性以及消费消息速度过缓的问题也交给了消息代理去解决。这样的后果就是生产者和消费者不再是同步处理数据,而是异步,生产者产生完消息后可以不用再管消费者是否消费。

当有多个消费者时,消息的发送方式
  1. load balance 让多个客户端共享同一队列以分担队列的消费压力
  2. fan-out 同一个消息会发给订阅此队列的所有的消费者

两者的区别在于load balance当一个客户端消费完一条消息后,这条消息不会再被其它客户端消费,但是fan-out则是一个消息可以让多个客户端同时消费到。

消息确认机制

为了防止消费者消费过程种出现问题,一般的消费代理都会有确认机制,只有当消费者发回确认消息后,消息才会被删除,否则就有可能等待另一个消费消费。这里会出现一个问题,当使用load balanc时,会出现消息乱序的情况。

代表系统:RabbitMQ

3.基于日志的消息代理

前面的文章提过日志是只增不减的有序序列,在消息系统里,日志也可以成为消息的存储媒介,最新的消息永远是日志的最后,消费者只要记住自己的读取的位移,不断往后移就可以读到最新的消息,而日志也带给了消息系统真正的消息持久化,消费者可以持续的从某个时间段抽取数据。为了提高吞吐量,日志也可以做分区,每一个主题包含一定数量的分区,分区也可以分布在各个不同的机器上。

因为日志的读取方式,所以天然支持fan-out的发送方式,为了支持load balance,可以将整个分区丢给消费者组。但是这要求消费者必须以单线程消费数据,从而降低了性能。

代表系统:Kafka

小总结

因此在消息处理代价高昂,希望逐条并行处理,以及消息的顺序并没有那么重要的情况下, 可以使用JMS/AMQP风格的消息代理。另一方面,在消息吞吐量很高,需要处理迅速,顺序很重要的情况下,基于日志的方法值得选择。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2018-07-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 鸿的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1.生产者直接将消息发送给消费者
  • 2.消息代理的方式(JMS/AMQP)
    • 当有多个消费者时,消息的发送方式
      • 消息确认机制
      • 3.基于日志的消息代理
        • 小总结
        相关产品与服务
        数据库
        云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档