企业官网建设流程全解析

国外html5网站源码,如何做建材网站的线下推广,网站怎么能被百度收录,如何免费创建app前言#xff1a;从“静止”到“流动” 在 Hadoop 的世界里#xff0c;我们习惯处理 T1 的数据#xff08;今天算昨天的数据#xff09;。这叫离线批处理。但在双十一大屏、股市交易、实时推荐等场景下#xff0c;每一秒都有亿万条数据产生#xff0c;我们需要实时处理它们…前言从“静止”到“流动”在 Hadoop 的世界里我们习惯处理 T1 的数据今天算昨天的数据。这叫离线批处理。但在双十一大屏、股市交易、实时推荐等场景下每一秒都有亿万条数据产生我们需要实时处理它们。这时候系统面临两个巨大的挑战耦合之痛生产数据的系统如订单服务和消费数据的系统如大数据分析、风控系统如果直接连接一旦下游挂了上游也会被拖垮。洪峰之灾流量高峰期数据量暴增如果直接写入数据库或 Hadoop数据库会瞬间崩塌。Apache Kafka就是为了解决这两个问题而诞生的。它不仅仅是一个消息队列更是一个分布式的流处理平台。第一部分Kafka 的核心设计哲学很多人把 Kafka 当作 RabbitMQ 的替代品这其实低估了它。Kafka 的设计核心在于一个极其简单的概念分布式提交日志 (Distributed Commit Log)。1. 什么是“日志”这里的日志不是指程序里打印的Log.info(xxx)而是计算机科学中的Commit Log。它是一个**只追加Append-Only**的序列。数据一旦写进去就不能改也不能插队只能按时间顺序往后排。2. 为什么要这么设计传统的数据库如 MySQL为了支持随机读写UPDATE/DELETE使用了复杂的 B 树索引导致写入性能在数据量大时急剧下降。而 Kafka 放弃了修改功能只允许追加写入。这种**顺序写Sequential Write**的机制让它在普通的机械硬盘上也能跑出接近内存的速度下文会详细解释。第二部分解剖 Kafka 的架构肌理Kafka 的架构非常精妙它引入了几个核心概念来支撑高吞吐和高扩展。1. Topic (主题) 与 Partition (分区) —— 并行的秘密Topic逻辑上的概念比如“订单数据”就是一个 Topic。Partition物理上的概念。这是 Kafka 吞吐量无限扩展的关键。假如一个 Topic 的数据量太大一台机器存不下怎么办Kafka 把一个 Topic 切分成多个Partition分布在不同的机器Broker上。并行读写生产者可以同时向 10 个 Partition 写数据消费者也可以同时从 10 个 Partition 读数据。并发能力直接乘以 10。2. Broker (代理/服务器)Kafka 集群中的一台服务器就是一个 Broker。一个 Topic 的多个 Partition 会均匀地分散在多个 Broker 上以实现负载均衡。3. Producer (生产者) 与 Consumer Group (消费者组)Producer发消息的人。它决定把消息发给哪个 Partition通常使用轮询或 Hash 算法。Consumer Group核心创新在传统的队列Queue模型中消息被读走就没了。在发布/订阅Pub/Sub模型中每个消费者都能收到全量消息。Kafka 结合了两者的优点一个 Partition 只能被同一个消费者组里的某一个消费者消费。效果如果你的消费速度跟不上生产速度你只需要往“消费者组”里加人增加机器Kafka 就会自动把 Partition 分配给新加入的机器实现消费能力的水平扩容。4. Offset (偏移量)因为 Kafka 的数据是“持久化”存储在磁盘上的消费了不会删除。所以每个消费者需要记住自己读到哪里了。这个“书签”就是Offset。这使得 Kafka 支持重播 (Replay)我想重新分析昨天的数据只需要把 Offset 重置到昨天的位置即可。第三部分为什么 Kafka 快得像跑车Kafka 每秒可以处理百万级的消息它的高性能主要源于以下三个底层技术面试必考点1. 磁盘顺序写 (Sequential I/O)你可能不信顺序写的磁盘比随机写的内存还要快。现代操作系统的磁盘预读机制加上 Kafka 极简的“只追加不修改”设计使得它在写入时几乎没有磁头寻道时间Seek Time。这是 Kafka 高吞吐的基石。2. Page Cache (页缓存)Kafka 并没有自己管理内存缓存而是完全依赖 Linux 内核的Page Cache。当你写入数据时直接写到操作系统的内存缓存里就返回成功了由操作系统异步刷盘。当你读取数据时如果数据刚好在缓存里热数据直接从内存读。优势即使 Kafka 进程崩溃只要机器没重启Page Cache 里的数据还在重启后瞬间热加载。3. Zero Copy (零拷贝)传统的数据传输从磁盘读文件 - 发送给网卡需要经过 4 次数据拷贝磁盘-内核态-用户态-内核态-网卡。Kafka 利用了 Linux 的sendfile系统调用实现了零拷贝。数据直接从Page Cache内核态复制到网卡缓冲区内核态完全不需要经过 Kafka 应用程序用户态。这极大降低了 CPU 的消耗。第四部分可靠性 —— 数据不丢的保障跑得快还不够还得稳。Kafka 借鉴了 HDFS 的副本机制来保证高可用。1. Replica (副本)每个 Partition 都有多个副本分为Leader老大。负责所有的读写操作。Follower小弟。只负责从 Leader 那里复制数据不与客户端交互。机制如果 Leader 所在的 Broker 挂了Kafka 会自动从 Follower 中选举出新的 Leader。2. ISR (In-Sync Replicas) —— 同步副本集合不是所有的 Follower 都有资格当 Leader。只有那些“跟得上 Leader 脚步”的 Follower 才能进入ISR 列表。如果一个 Follower 网络卡了滞后太多它就会被踢出 ISR。选举时只能从 ISR 里选这保证了数据不丢失。3. ACK 机制 (确认机制)生产者发消息时可以设置可靠性级别request.required.acksacks0发出去就不管了。最快但可能丢数据。acks1Leader 收到并落盘就返回 OK。默认模式比较稳。acksall (-1)Leader 加上所有 ISR 里的 Follower 都收到了才返回 OK。最慢但最安全。第五部分Kafka 与 ZooKeeper 的爱恨情仇回到我们上篇博文的话题Kafka 也是一个典型的分布式系统所以它也曾重度依赖 ZooKeeper。1. 过去重度依赖在早期的 Kafka 版本中Broker 管理Broker 上线、下线都往 ZK 注册。Controller 选举Kafka 集群里有一个 Broker 是总指挥Controller它的选举完全靠 ZK。消费进度 (Offset)早期的消费者把 Offset 存在 ZK 里。这是个大坑因为 ZK 不适合高频写入导致以前 Kafka 消费性能起不来。后来 Kafka 把 Offset 移回了自己的一个内部 Topic 存储。2. 现在与未来去 ZooKeeper 化 (KRaft 模式)虽然 ZK 很强但维护两套集群Kafka ZK增加了运维复杂度。而且 ZK 的元数据存储能力限制了 Kafka 集群支持的 Partition 数量上限百万级瓶颈。从 Kafka 2.8 版本开始引入了KRaft (Kafka Raft)模式。Kafka 内部实现了一个 Raft 共识算法自己选 Leader自己存元数据。这意味着未来的 Kafka 将不再需要 ZooKeeper它可以像一个独立的应用一样部署架构更加简洁。第六部分总结如果把 Hadoop 比作一个巨大的仓库存得多那 Kafka 就是这个数据中心的高速物流传输带运得快。Kafka 的核心价值总结削峰填谷在流量洪峰时充当缓冲池Buffer保护后端数据库。解耦生产者只管发消费者只管收互不影响。高性能通过顺序写、零拷贝、页缓存压榨硬件极限。从学习路线的角度看学会了Linux你就懂了 Kafka 为什么快IO模型。学会了ZooKeeper你就懂了 Kafka 是怎么组建集群的。学会了Kafka下一步你就可以进军Flink或Spark Streaming去探索实时计算的领域了。希望这一篇关于 Kafka 的深度解析能帮你打通大数据架构中的“任督二脉”。