健康资讯 这是一个从诞生第一天起就在GitHub上开发的开源项目，也是中国第一个非Hadoop生态的Apache顶级项目。它统一了阿里集团内部所有业务线的消息中间件，伴随着中国互联网发展数次迭代。《十万亿条消息背后的故事》记录了RocketMQ从诞生、开源、发展至今创始团队成员背后的故事。一起来了解开源消息中间件Apache RocketMQ背后的人和事！
开源人说第一期——《十万亿条消息背后的故事》-云视频-阿里云开发者社区
《开源人说》为阿里云开发者社区与InfoQ 联合出品的一档精品开源视频栏目。栏目围绕阿里四大开源领域：操作系统、数据库、大数据&AI、云原生，介绍阿里优秀的开源软件：Anolis OS（龙蜥操作系统）、Flink、PolarDB、OceanBase、Dubbo、RocketMQ等背后的故事，记录传播阿里技术追求极致和开放共享的精神。
开源人说：属于开源人的时光博物馆
数仓通常是分为三层：ODS（原始数据），DW（数据仓库层），ADS（应用数据层）。
ODS是从消息中间件中拿到的最原始的数据。
DW层则是对数据进行加工后的数据，通常还是分为：DWS和DWD。DWD层中是对ODS层的数据进行清洗后提取的出来的。而DWS层是经过了一些轻度汇总后的数据。
用户可以基于DWS层直接加工出ADS层所需的数据。ADS层则是产出应用最终所需的数据。
《Apache Doris 轻松入门和快速实践》技术专栏包括Apache Doris架构介绍、环境搭建、入门操作实例和演示项目源代码。技术专栏从实战出发，通过基础知识介绍入门-环境搭建-项目实践，让初学者快速掌握Apache Doris分析型OLAP数据库开源产品。其中示例项目KFD演示通过Flink处理Kafka中的消息记录，处理之后的数据再写入到Kafka和Elasticsearch中，最后以Routine Load方式再将处理好的数据导入到Doris中。同时，还详细介绍了flink-doris-connector插件的编译和示例项目开发实践等等。
【回首开源十年，RocketMQ焕发新生】RocketMQ作为2011年诞生的消息中间件，见证了中国开源领域的十年发展。成为阿里巴巴众多开源项目中最为要耀眼的代表项目之一。这不仅仅是指 RocketMQ 是首个进入Apache顶级项目的国内互联网中间件，也包括 RocketMQ 在物联网、大数据等领域发挥着巨大作用，让数以百万的企业以及开发者真真切切的受益，推动社会经济以及互联网技术的发展。云栖掠影｜回首开源十年，RocketMQ 焕发新生-阿里云开发者社区
构件和中间件
中间件是一个软件集合的名字，这些软件位于操作系统和高层次分布式编程平台之间。中间件有时被分为面向消息的中间件( Message-Oriented Middleware,MOM)和面向对象的中间件(Object Oriented Method,OOM)。然而，现有的人多数中间件都是这两种类型的混合体。当然，现在也有一种趋势是由传统的操作系统直接支持。操作系统总是包含了对通信协议的支持。Web服务的推进和程序世界从以程序为中心到以协议为中心的转变，导致两种中间件的价值观:支持合适的协议或者提供简化本地服务构造的结构:
独立的中向件产品，如消息队列系统、事务处理监控器或者集线器，已经慢慢地消失了。取而代之的是结合了中向件功能和某个特定构件框架的特殊的服务器。应用服务器结合了应用管理、数据事务、负载平衡和其他的功能。集成服务器结合了协议转换、数据变换、路由和其他功能。工作流和复杂交互服务器结合了事件路由、决策和其他功能。
Kafka简介
1.1消息队列
1.1.1为什么要有消息队列
面对比较大的流量冲击，在网站系统中一般会有一个消息存储/缓存系统，网站就按自己的服务负载的能力，来消费这些消息——消息队列，或者叫做消息中间件
消息队列应该具备最基本的功能：
1、存储能力，所以是一个容器，一般的实现都用队列
2、消息的入队或者生产
3、消息的出队或者消费
从消息的生产与消费的角度上而言，消息队列就是一个典型的生产者-消费者模型的实现框架
1.1.2消息队列
消息 Message
网络中的两台计算机或者两个通讯设备之间传递的数据。
队列 Queue
一种特殊的线性表，特殊之处在于只允许在首部删除元素和在尾部追加元素。
消息队列 MQ
消息+队列，保存消息的队列。消息传输过程中的容器；主要提供生产、消费接口外部调用做数据的存储和获取。
1.1.3 消息队列的分类
MQ主要分为两类：点对点（p2p）、发布订阅（Pub/Sub）
Peer-to-Peer 一般基于Pull或者Polling接收数据，发送到队列的消息被一个而且仅仅一个接受者所接受，即使有多个接收者在同一个队列中侦听同一消息，即支持异步“即发即收”的消息传递方式，也支持同步请求/应答传送方式
发布订阅发布到同一个主题的消息，可被多个订阅者所接收，发布订阅即可基于Push消费数据，也可基于Pull或者Polling消费数据，解耦能力比P2P模型更强
1.1.4 p2p和发布订阅MQ的比较
共同点：
消息生产者生产消息发送到queue中，然后消息消费者读取并且消费消息
不同点：
p2p模型包括：消息队列（Queue）、发送者（Sender）、接收者（Receiver），一个生产者的消息只有一个消费者（Consumer）（即一旦被消费，消息就不存在消息队列中），比如所打电话。
pub/Sub包含：消息队列（Queue）、主题（Topic）、发布者（Publisher）、订阅者（Subsciber）
每个消息都有多个消费者，彼此之间互不影响。比如我发一个微博：关注我的人都能看到。
1.1.5 消息系统的使用场景
解耦 各系统之间通过消息系统这个统一的接口交换数据，无需了解彼此的存在
冗余 部分消息系统具有消息持久化能力，可规避消息处理前丢失的风险
扩展 消息系统是统一的数据接口，各系统可独立扩展
峰值处理能力 消息系统可顶住峰值流量，业务系统可根据处理能力从消息系统中获取并处理对应量的请求
可恢复性 系统中部分键失效并不会影响整个系统，它恢复会仍然可从消息系统中获取并处理数据
异步通信 在不需要立即处理请求的场景下，可以将请求放入消息系统，合适的时候再处理
1.2 Kafka简介
1.2.1 简介
Kafka是分布式的发布——订阅消息系统。它最初由Linked（领英）公司发布，使用Scala语言编写，于2010年12月份开源，成为Apache的顶级项目。Kafaka是一个高吞吐量的、持久性的、分布式发布订阅消息系统。它主要用于处理活跃live的数据（登录、浏览、点击、分享、喜欢等用户行为产生的数据）。
三大特点：
高吞吐量
可以满足每秒百万级别消息的生产和消费—生产消费
持久性
有一套完整的消息存储机制，确保数据高效安全的持久化——中间存储
分布式
基于分布式的扩展和容错机制；Kafka的数据都会复制到几台服务器上。当某一台服务器故障失效时，生产者和消费者转而使用其它的机器——整体
健壮性
1.2.2 设计目标
高吞吐率 在廉价的商用机器上可支持每秒100万条消息的读写
消息持久化 所有消息均被持久化到磁盘，无消息丢失，支持消息重放
完全分布式 Producer，Broker，Consumer均支持水平扩展
同时支持在线流处理和离线批处理
12.3 Kafaka核心的概念
一个MQ需要哪些部分？生产、消费、消息类别、存储等等。对于Kafka而言，Kafka服务就像是一个大的水池。不断地生产、存储、消费各种类别的消息。那么Kafka由何组成呢？
Kafka服务：
Topic：主题，Kafka处理的消息的不同分类。
Broker：消息服务器代理，Kafka集群中的一个Kafka服务器节点称为一个broker，主要存储消息数据。存在硬盘中。每个topic都是有分区的。
Partition：Topic物理上的分组，一个topic在broker中分为1个或者多个partition，分区在创建topic的时候指定。
Message：消息，是通信的基本单位，每个消息都属于一个partition
Kafka服务相关
Producer：消息和数据的生产者，向Kafka的一个topic发送消息。
Consumer：消息和数据的消费者，定于topic并处理器发布的消息。
Zookper：协调Kafka的正常运行。
对于 IT 技术，光学理论没用，要实战。
这有一定的道理，但不应该成为阻碍我们学习新技术的理由。
但有时候受到所在平台的限制，日常工作中无法接触到主流的技术，例如缺乏高并发、压根就没有接触过消息中间件和大数据技术框架等等，此时该怎么办？
在无法进行项目实战时，应该去研究主流技术的原理，为使用做好准备，不要因为没有接触到而放弃学习，机会是留给有准备的人，如果你对某一项技术研究有一定深度时，当项目中需要使用时，你可以立马施展你的才华，很容易脱颖而出。
