在当今信息爆炸的时代，单台计算机已经无法负载日益增长的业务发展，虽然也有性能强大的超级计算机，但是这种高端机不仅费用高昂，也不灵活，一般的企业是负担不起的，而且也损失不起，那么将一群廉价的普通计算机组合起来，让它们协同工作就像一台超级计算机一样地对外提供服务，就成了顺其自然的设想，但是这又增加了软件的复杂度，要求开发的软件需要具备横向扩展能力，比如：Kafka、Elasticsearch、Zookeeper等就属于这一类软件，它们天生都是"分布式的"，即可以通过添加机器节点来共同地分摊数据存储和负载压力。
之前分享了一篇文章 广告倒排索引架构与优化，介绍我们的ES广告倒排索引的架构与优化，我就不介绍了，建议先去看下这篇文章，再回来看这篇，下面只放下之前的架构图
作者：anncdchen，腾讯 PCG 后台开发工程师 消息队列使用场景 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，削峰填谷等问题。实现高性能、高可用、可伸缩和最终一致性架构。 解耦：多个服务监听、处理同一条消息，避免多次 rpc 调用。 异步消息：消息发布者不用等待消息处理的的结果。 削峰填谷：较大流量、写入场景，为下游 I/O 服务抗流量。当然大流量下就需要使用其他方案了。 消息驱动框架：在事件总线中，服务通过监听事件消息驱动服务完成相应动作。 消息队列模式 点对点模
在过去的几年里，软件架构领域发生了巨大的变化。人们不再认为所有的系统都应该共享一个数据库。微服务、事件驱动架构和CQRS（命令查询的责任分离 Command Query Responsibility Segregation）是构建当代业务应用程序的主要工具。除此以外，物联网、移动设备和可穿戴设备的普及，进一步对系统的近实时能力提出了挑战。
数据中心宕机和数据丢失能导致企业损失很多收入或者完全停摆。为了将由于事故导致的宕机和数据丢失带来的损失最小化，企业需要制定业务可持续性计划和灾难恢复策略。
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，削峰填谷等问题。实现高性能、高可用、可伸缩和最终一致性架构。
在使用消息桥接时，您需要权衡这些优缺点，并根据应用程序的需求进行相应的配置和调整。
自 LinkedIn 2011 年创建了 Apache Kafka 后，这款消息系统一度成为大规模消息系统的唯一选择。为什么呢？因为这些消息系统每天需要传递数百万条消息，消息规模确实很庞大（2018 年 Twitter 推文平均每天 500 万条，用户数平均每天为 1 亿）。那时，我们没有 MOM 系统来处理基于大量订阅的流数据能力。所以，很多大牌公司，像 LinkedIn、Yahoo、Twitter、Netflix 和 Uber，只能选择 Kafka。
Redis中的订阅、发布实现了发布/订阅消息范式，发布者不是计划发送消息给特定的订阅者，而是发布消息到不同的频道，发布者不需要知道是哪些订阅者订阅了消息。订阅者对一个或多个频道感兴趣，只需接收感兴趣的消息，不需要知道是什么样的发布者发布的消息。这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑。
微信公众号：码农编程进阶笔记 关注可获得更多的视频教程及面试技巧。问题或建议，请公众号留言!
前两篇分别总结了Kafka和RocketMq相关的面试题，从今天开始，我们一起再回过头来，重新梳理一下这两个知名度超高的消息中间件的不同之处，相信本系列文章，会帮助你对消息中心以及这两个消息中心的特点有一个更深入了解！
在日常开发中，我们经常会到"有状态"服务设计与"无状态"服务设计，何谓“无状态”？
本文是SpringBoot+Kafka的实战讲解，如果对kafka的架构原理还不了解的读者，建议先看一下《大白话kafka架构原理》、《秒懂kafka HA（高可用）》两篇文章。
【1】MQ：MessageQueue，消息队列。 队列，是一种FIFO 先进先出的数据结构。消息由生产者发送到MQ进行排队，然后按原来的顺序交由消息的消费者进行处理。QQ和微信就是典型的MQ。
本文介绍了高性能消息队列CKafka的核心原理，包括设计初衷、核心概念、关键组件、工作流程、性能指标、应用场景以及消费者和生产者如何协同工作。CKafka通过集群部署、消息有序处理、可扩展的数据结构等方式实现高性能，支持大量消费者的同时维持低延迟，并通过简单的配置和API实现高效的生产和消费。
broker Kafka以集群的方式运行，可以由一个或多个服务组成，服务即broker
在之前的文章中，我们提到车联网 TSP 平台拥有很多不同业务的主题，并介绍了如何根据不同业务场景进行 MQTT 主题设计。车辆会持续不断产生海量的消息，每一条通过车联网上报的数据都是非常珍贵的，其背后蕴藏着巨大的业务价值。因此我们构建的车辆 TSP 平台也通常需要拥有千万级主题和百万级消息吞吐能力。
我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。有可能是收到消息以后发生了网络故障，也有可能是没有收到消息，又或者可能接收方的进程死了。发送方唯一的确认方法就是再次连接发送消息，并向他进行询问。这就是局部故障：根本不知道操作是否失败。因此，大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程。所以大部分应用需要开发私有的协调程序，协调程序的反复编写浪费时间，这个时候就需要一个通用的、伸缩性好的协调器。就是因为这样的场景，ZooKeeper应运而生，ZooKeeper的设计目的，就是为了减轻分布式应用程序所承担的协调任务。
消息队列作为服务解耦、异步收发消息的组件，如今已经广泛应用于各大互联网公司，具备一定规模的公司会有专门的团队负责维护消息队列。当我们需要使用消息队列时，得写专门的代码进行连接，比如若用Golang编码，当需要使用Kafka消息队列时可能会使用 sarama库。这意味着需要在业务代码中写一些与业务无关的kafka配置与连接代码。
数据流处理面临四个基本问题（Tyler Akidau, Slava Chernyak & Reuven lax. Streaming Systems: The What, Where, When and How of Large-Scale Data Processing）:
早期使用ActiveMQ作为消息中间件的项目比较多，作为Apache的一个子项目，ActiveMQ支持常用的多种语言：C++、Java、.Net、Python、PHP、Ruby等。
上一篇我们通过示范案例基本了解了一个独立交易类型的库存管理模块应该是怎样的一块业务。这篇我们讨论一些如何从技术上来实现这样的业务模块。讲确切点应该说如何借助kafka的特性来实现功能开发。
2020版中间件面试题总结（RabbitMQ+Kafka+ZooKeeper）
延迟信息处理，比如10分钟之后给下单未付款的用户发送邮件提醒。解耦系统，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，新增了给用户返积分的功能，这个时候不用在业务代码里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列即可，后面再添加任何功能只需要订阅对应的消息队列即可。
Topic 每条发布到 Kafka 集群的消息都有一个类别，这个类别被称为 Topic。（物理上不同 Topic 的消息分开存储，逻辑上一个 Topic 的消息虽然保存于一个或多个 broker 上但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处）
消息队列（Messeage Queue，MQ）是在分布式系统架构中常用的一种中间件技术，从字面表述看，是一个存储消息的队列，所以它一般用于给 MQ 中间的两个组件提供通信服务。
今天我们通过一篇文章来认识一下常见消息队列RabbitMQ、RocketMQ、Kafka。
引入消息中间件也会带来很多问题，先说说消息丢失，生产者往消息队列发送消息，消息队列往消费者发送消息，会有丢消息的可能，消息队列也有可能丢消息，通常MQ存盘时都会先写入操作系统的缓存页中，然后再由操作系统异步的将消息写入硬盘，这个中间有个时间差，就可能会造成消息丢失，如果服务挂了，缓存中还没有来得及写入硬盘的消息就会发生消息丢失。不同的消息中间件对于消息丢失也有不同的解决方案，先说说最容易丢失消息的kafka吧。生产者发消息给Kafka Broker：消息写入Leader后，Follower是主动与Leader进行同步，然后发ack告诉生产者收到消息了，这个过程kafka提供了一个参数，request.required.acks属性来确认消息的生产，0表示不进行消息接收是否成功的确认，发生网络抖动消息丢了，生产者不校验ACK自然就不知道丢了。1表示当Leader接收成功时确认，只要Leader存活就可以保证不丢失，保证了吞吐量，但是如果leader挂了，恰好选了一个没有ACK的follower，那也丢了。-1或者all表示Leader和Follower都接收成功时确认，可以最大限度保证消息不丢失，但是吞吐量低，降低了kafka的性能。一般在不涉及金额的情况下，均衡考虑可以使用1，保证消息的发送和性能的一个平衡。Kafka Broker 消息同步和持久化：Kafka通过多分区多副本机制，可以最大限度保证数据不会丢失，如果数据已经写入系统缓存中，但是还没来得及刷入磁盘，这个时候机器宕机，或者没电了，那就丢消息了，当然这种情况很极端。Kafka Broker 将消息传递给消费者：如果消费这边配置的是自动提交，万一消费到数据还没处理完，就自动提交offset了，但是此时消费者直接宕机了，未处理完的数据丢失了，下次也消费不到了。所以为了避免这种情况，需要将配置改为，先消费处理数据，然后手动提交，这样消息处理失败，也不会提交成功，没有丢消息。
应用场景，消息可靠投递，消息丢失，消息重复消费，消息的幂等性，消息的顺序性，消息队列积压，延迟队列，消息过期失效，消息队列的高可用
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
kafka代理,最近一直在搞kafka，上线前有个将kafka 集群暴露到外网的需求。那么问题来了，在内网时我们有足够的IP资源，但是在公网上时，不可能给每个broker都分配一个IP。那么就需要有一个代理用来转发。
kafka 的事务是从0.11 版本开始支持的，kafka 的事务是基于 Exactly Once 语义的，它能保证生产或消费消息在跨分区和会话的情况下要么全部成功要么全部失败
何为后端开发？以一个网站为例，通常来说，前端研发注重页面的展示，交互逻辑。而后端研发，则注重在发生在前端背后（backend）的逻辑上，例如给前端返回数据，存储数据。对于一个电商网站，一个简单的下单动作，后端可能包括商品数据查询，优惠信息计算，库存维护，用户优惠券维护，订单生成，商家通知触发等等。在很多大公司前后端的配比是1：3甚至更高，因为一个复杂的业务系统，前端的展示仅仅是冰山一角，更复杂的业务逻辑都隐藏在后端。
Sentry 是什么？这是一个用于错误上报的服务中心，使用近乎一致的 API 设计，统一了不同语言生产环境代码异常上报的难题。
Spring Cloud Stream 消息桥接（Message Bridge）是一种将消息从一个消息代理传递到另一个消息代理的高级特性。消息桥接通常用于将消息从一个环境（例如开发环境）中的消息代理传递到另一个环境（例如生产环境）中的消息代理，或者将消息从一个协议（例如 AMQP）转换为另一个协议（例如 MQTT）。本文将详细介绍 Spring Cloud Stream 中的消息桥接特性，并给出示例代码。
局部顺序：一个Topic下只需要满足同一消息key是有序的既可。例如，一个Topic下是内容变更流水，消息key值为内容ID，同一个内容ID下所有的消息是有序的；
Kafka 是 linkedin 使用 Scala 编写具有高水平扩展和高吞吐量的分布式消息系统。
原文：http://www.enmotech.com/web/detail/1/735/1.html （复制链接，打开浏览器即可查看）
多个消息生产者向消息队列发送消息，多个消费者消费消息，每个消息只会被一个消费者消费
一般来说，当在Hadoop集群上，有足够数据处理的时候，通常会有很多生产数据的服务器。这些服务器的数量上百甚至成千上万。小的数据还可以直接从应用程序写入HDFS，但庞大数量的服务器试着将海量数据直接写入HDFS或者HBase集群，会因为多种原因导致重大问题。
日志是记录系统中各种问题信息的关键，也是一种常见的海量数据。日志平台为集团所有业务系统提供日志采集、消费、分析、存储、索引和查询的一站式日志服务。主要为了解决日志分散不方便查看、日志搜索操作复杂且效率低、业务异常无法及时发现等等问题。
两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。
Kafka 是一个分布式的发布-订阅消息系统。它最初是在 LinkedIn 开发的，2011年7月成为一个 Apache 项目。今天，Kafka 被 LinkedIn、 Twitter 和 Square 用于日志聚合、队列、实时监控和事件处理等应用程序。在下面的文章中，我们将讨论下 Kafka 的 replication 设计。
Apache Pulsar是一个企业级的分布式消息系统，最初由Yahoo开发并在2016年开源，目前正在Apache基金会下孵化。Plusar已经在Yahoo的生产环境使用了三年多，主要服务于Mail、Finance、Sports、 Flickr、 the Gemini Ads platform、 Sherpa以及Yahoo的KV存储。 Pulsar之所以能够称为下一代消息队列，主要是因为以下特性:
一，流式平台介绍 1，一般来说一个通用的流平台必须具备以下三个重要的能力： 1),能够允许你订阅和发布流式消息。在这方面，它类似于消息队列或企业消息系统。 2),它允许您以容错方式存储流式消息。 3),他可以允许你实时处理流式消息。 2，Kafka常被用于两大类应用程序： 1),构建可在系统或应用程序之间可靠获取数据的实时流数据流水线 2),构建对数据流进行变换处理的实时流应用程序 3，首先介绍一些基本概念： 1),kafka是以集群的方式运行，可以有一个或者多个Broker server。 2),kafk
Raft声称是一种易于理解的分布式一致性算法。有不少工程师们翻了它的论文，参考了很多资料，最后只好怀疑自己是不是智商有问题。
Kafka中的事务可以使应用程序将消费消息、生产消息、提交消费位移当作原子操作来处理，同时成功或失败，即使该生产或消费会跨多个分区。
领取专属 10元无门槛券
手把手带您无忧上云
