企业官网建设流程全解析

句容网站建设开发,网站推广营销策略,建立网站就是制作网页吗,做界面网站用什么语言好01.理解消息系统 ​ 可理解为它将应用程序解耦成独立的生产者#xff08;寄信人#xff09;和消费者#xff08;收信人#xff09;#xff0c;通过消息队列#xff08;邮箱#xff09;实现同步/异步通信。消息系统实现了应用程序间的解耦通信#xff0c;既支持异步…01.理解消息系统​ 可理解为它将应用程序解耦成独立的生产者寄信人和消费者收信人通过消息队列邮箱实现同步/异步通信。消息系统实现了应用程序间的解耦通信既支持异步的发后即忘模式提高吞吐量也支持同步的确认机制保证可靠性。1.1同步处理​ 同步模式下系统必须先确认商品有库存才能允许下单此后每个后续步骤都必须阻塞等待前一个步骤完全处理完毕后才能开始。只有当请求顺利通过所有流程、到达最后一个环节时才能计算出整个订单处理所耗费的总时间。1.2异步处理​ 异步模式下系统在检查库存时可快速获取结果有则返回无则生产并放入队列中被消费无需长时间阻塞等待各处理步骤能够并发执行从而显著减少整体等待时间提升系统吞吐量与性能。那这样处理的时间可以被压缩到50ms处理一个事件。1.2.1点对点模式​ 生产者将消息发送到队列中消费者从中取出消息。消息只能被一个消费者读取读取成功后即被移除(消息不能被重复处理)例如线程池中的reactor模式。1.2.2发布-订阅​ 举个简单的例子比如游戏里面跨服并广播今天整体还剩多少把屠龙刀可以暴然后广播用户暴的屠龙刀的消息。​ 在发布/订阅模式中生产者把消息发送到一个主题Topic所有订阅该主题的活跃消费者都会收到并处理该消息(广播给订阅者)超过设定时间后被删除。该模式适用于一对多场景消息广播分发、消费者相互独立。Kafka 将消息持久化存储在 Topic 的 Partition 中每个消费者通过维护自己的偏移量来记录消费位置不会因被消费而删除。02.消息队列2.1流量消峰​ 当系统短时间内收到大量请求如秒杀、抢购直接处理可能导致服务崩溃。消息队列作为缓冲层将突发的请求暂存到队列中后端服务按自身处理能力(最大限制数量)匀速消费从而平滑流量高峰避免系统过载。2.2服务解藕​ 在传统调用中服务 A 直接调用服务 B、C、D导致高度耦合。引入消息队列后服务 A 只需将消息发到队列无需关心谁来消费后续新增或修改消费者如加一个日志服务不需要改动 A 的代码降低系统间依赖提升可维护性和扩展性。2.3高并发缓冲Kafka 通过将消息持久化到磁盘日志天然具备高并发能力。当上游生产速率达到 15,000 条/秒而下游消费者最大处理能力仅为 10,000 条/秒时Kafka 会将超出消费能力的消息暂存于磁盘中形成消费积压lag。随后当生产速率回落至 4,000 条/秒消费者可逐步追平积压最终完成全部消息的处理。整个过程无需丢弃数据实现了对突发流量的削峰填谷。03.kafkaKafka 本质上是一个分布式消息队列Message Queue使用消息队列的主要优势包括解耦生产者和消费者无需彼此感知可独立扩展或修改各自的处理逻辑降低系统间依赖。可恢复性即使消费者进程宕机消息仍持久化在队列中待服务恢复后继续处理避免数据丢失。缓冲有效应对生产与消费速率不匹配的问题平滑流量波动。灵活性与峰值处理能力在突发高负载下消息队列作为缓冲层防止核心服务被压垮提升系统稳定性。异步通信生产者发送消息后无需等待处理完成可立即返回实现非阻塞、高吞吐的异步处理。3.1消息顺序性​ 基于Queue消息模型利用FIFO先进先出的特性可以保证消息的顺序性。3.2消息ACK机制​ 即消息的Ackownledge确认机制为了保证消息不丢失消息队列提供了消息Acknowledge机制即ACK机制当Consumer确认消息已经被消费处理发送一个ACK给消息队列此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭没有发送ACK消息队列将认为这个消息没有被处理会将这个消息重新发送给其他的Consumer重新消费处理。ACK保证了实时性 但是牺牲吞吐量。Kafka 通过消费组实现了灵活的消息分发语义同消费组内多个消费者 表现为点对点Queue模型每条消息仅被组内一个消费者处理不同消费组间表现为发布/订阅模型每条消息被每个消费组独立消费一次3.3消息持久化​消息持久化(副本)对于一些关键的核心业务来说是非常重要的启用消息持久化后消息队列宕机重启后消息可以从持久化存储恢复消息不丢失可以继续消费处理。其中可以根据消息的重要程度设置不一样的处理方式。3.4消息同步/异步收发同步:支持“一问一答”式的同步通信生产者发送消息后需等待消费者的响应形成双向应答机制。例如张三发信至邮局中转站并注明回信地址李四取信处理后将回执信放回中转站张三再从中转站取回——整个过程需双方协调完成。若采用同步拉取Pull方式接收消息当队列为空时消费者将阻塞等待直至消息到达或超时。类似 TCP 的可靠传输机制若在指定时间内未收到应答可触发消息重传以保证可靠性。异步异步发生产者发出消息后无需等待确认可立即继续执行后续操作提升吞吐效率。异步接通常采用Push 模式由消息队列主动将消息推送给消费者通过回调或事件驱动触发处理逻辑避免轮询开销。04.kafka架构Kafka 由Producer发消息、Broker存消息、Consumer消费消息和旧版ZooKeeper协调组成。消息按Topic分类每个 Topic 分为多个Partition物理日志。每个 Partition 有 1 个Leader处理读写和多个Follower仅同步不服务。Consumer Group内消费者分摊 Partition组间独立消费实现 Pub/Sub。消费位置由Offset记录支持断点续消费。副本保障高可用但Follower 不提供读服务。Kafka ≥3.0 支持去 ZooKeeperKRaft 模式。消息的生产者、消费者消息生产者Producer:发送消息到消息队列。消息消费者Consumer:从消息队列接收消息。被动接受消息S--C主动拉取消息S--C通过pull​ 在处理队列的数据的时候我们采用从队列里面pull拉取数据的方式而不是队列主动push推送数据考虑每个消费者自身消费情况进行处理更能保证一个健康的不阻塞的流程。考虑到消费者的处理能力。4.1工作流程在 Kafka 中消息以Topic为单位进行逻辑分类。生产者Producer将消息发送到指定的 Topic消费者Consumer从该 Topic 订阅并消费消息——双方面向的是同一个 Topic。Topic 是逻辑概念而Partition分区是物理存储单元。每个 Partition 对应一个日志文件Log SegmentProducer 发送的消息被顺序追加到该日志文件的末尾。每条消息在 Partition 内都有一个唯一的Offset偏移量用于标识其位置。每个消费者会独立记录自己消费到的 Offset以便在发生故障或重启后能够从上次消费的位置继续处理实现精确或至少一次的消费语义。Kafka 的日志文件默认存储在本地磁盘路径/tmp/kafka-logs可通过log.dirs配置项修改。4.2副本原理Kafka 中每个分区的副本分为Leader和Follower创建时选举一个 Leader其余为 Follower。Follower 不对外提供读写服务仅用于数据同步不同于 FastDFS、MongoDB 等支持从副本读取的系统。当 Leader 所在 Broker 宕机Kafka 通过 ZooKeeper或 KRaft感知故障并立即从 Follower 中选举新 Leader原 Leader 恢复后自动转为 Follower。基于leader的副本机制​ Kafka 中每个分区有一个 Leader 副本负责处理所有读写请求其余副本为 Follower仅从 Leader 同步数据不对外提供服务。当 Leader 所在 Broker 宕机时Kafka 会自动从 Follower 中选举新的 Leader旧版本依赖 ZooKeeper新版本Kafka 3.0使用内置的 KRaft 协议。原 Leader 恢复后会自动降级为 Follower 并同步最新数据。这种设计保障了高可用与数据持久性但不支持从 Follower 读取因此无法通过副本扩展读吞吐。4.3分区与主题的关系一个分区只能属于一个主题一个主题可以有多个分区同一主题的不同分区内容不一样每个分区有自己独立的2ffset同一主题不同的分区能够被放置到不同节点的broker分区规则设置得当可以使得同一主题的消息均匀落在不同的分区05.生产者5.1topic partion​ Kafka中的消息以主题为单位进行归类生产者负责将消息发送到特定的主题(发送到Kafka集群中的每一条消息都要指定一个主题)而消费者负责订阅主题并进行消费。可以将topic类比为高速公路partion类比为多个车道分区数越多并行度越高。topic​主题Topic是 Kafka 中对消息进行逻辑分类的单位可理解为消息的类别。一个主题含多个分区(多车道)生产者将消息发送到指定topic消费者订阅感兴趣的topic来接收消息。数据存储在分区而不在主题内部。partion​分区Partition是 Kafka 中 Topic 的物理分片单元提供负载均衡可以理解为kafka把一个大“队列”拆成多个小“队列”分散到集群中处理。分区可在不同broker上同一分区内消息有序整个topic的全局顺序不保证。​每条消息在写入 Kafka 时只会被分配到 Topic 的某一个 Partition分区中且仅存储一次不会重复出现在多个分区里。eg:主题中有4个分区消息被顺序追加到每个分区日志文件的尾部。Kafka中的分区可以分布在不同的**服务器(broker)**上也就是说一个主题可以横跨多个broker。​ 每条消息在发送到 Broker 前会根据分区策略如 Key 哈希被路由到某个具体分区。合理的分区策略可使消息均匀分布避免单点 I/O 瓶颈——若一个 Topic 只有一个分区即一个日志文件其所在机器将成为性能瓶颈。Kafka 支持在创建 Topic 时指定分区数也可后续增加但不能减少通过扩容分区实现水平扩展。​ 为了提升容灾能力Kafka 为每个分区引入多副本机制同一分区的所有副本保存相同数据Follower 可能略有滞后采用“一主多从”架构——只有 Leader 副本处理读写请求Follower 副本仅同步数据备份。所有副本分布在不同 Broker 上当 Leader 所在 Broker 故障时系统会从 Follower 中自动选举新 Leader实现故障转移保障服务高可用。​ eg:在一个 4 节点 Kafka 集群中若某 Topic 有 3 个分区、副本因子为 3则每个分区包含 1 个 Leader 和 2 个 Follower生产者和消费者始终只与 Leader 交互。5.2分区策略​ 所谓分区策略是决定生产者将消息发送到哪个分区的算法。Kafka为我们提供了默认的分区策略同时它也支持你自定义分区策略。轮询策略随机策略按消息键默认分区5.2.1轮训策略​ 当Producer 发送消息未指定分区partition也未提供 Key时Kafka 使用轮询策略Round-Robin将消息均匀分配到 Topic 的各个分区。eg:一个 Topic 有 3 个分区P0、P1、P2则消息依次被分配为​ 第1条 → P0第2条 → P1第3条 → P2第4条 → P0第5条 → P1……以此循环。5.2.2随机策略5.2.3按消息键​ Kafka 允许为消息指定Key如用户ID、订单号等。相同 Key 的消息会被路由到同一个分区而每个分区内消息是严格有序的从而保证相同 Key 的消息全局有序。5.2.4默认分区消息分配到分区的优先级如下指定了 Partition→ 直接使用未指定 Partition 但有 Key→hash(Key) % 分区数既无 Partition 也无 Key→ 采用轮询Round-Robin策略均匀分配到各分区实现负载均衡。06.消费者​ 传统消息队列有个特点消息一旦被消费就会从队列里删掉而且只能被一个消费者处理。这在某些场景下没问题但扩展性不好——多个消费者得“抢”同一条消息没法高效协作。发布/订阅模型虽然允许多个消费者都收到同一条消息但它也有局限每个订阅者必须接收主题的全部数据不能只挑一部分。​ 这也造成了当要处理多个主题时这种“全量订阅”的方式既不灵活也容易造成资源浪费。所以Kafka引入Consumer Group消费者组巧妙地解决了这些问题。一个 Consumer Group 内的多个消费者会自动分摊主题下的不同分区每人只处理一部分实现负载均衡不同 Consumer Group 之间完全独立哪怕订阅的是同一个主题彼此也不会干扰加上 Kafka 本身会把消息在 Broker 上保留一段时间消费者可以随时重读历史数据。更妙的是只靠 Consumer Group 这一个机制Kafka 就同时支持了两种经典模型 这样既灵活又可扩展还避免了传统模型的短板。如果所有消费者都在同一个 Group里就相当于点对点队列一条消息只被处理一次如果每个消费者都在不同的 Group里就变成了发布/订阅每条消息广播给所有组。6.1消费方式​ Kafka 的消费者采用Pull 模式主动从 Broker 拉取消息这样可以根据自身处理能力控制消费速度比如忙时少拉闲时多拉。为了避免在无消息时空转消费者会设置一个timeout参数当队列为空时会等待一段时间再返回而不是立刻轮询既省资源又及时。6.2分区分配策略​ 当消费者组Consumer Group内有多个消费者而 Topic 有多个分区时Kafka 需要决定“哪个分区由哪个消费者负责”。如果组内消费者数量变化如扩容/缩容还会触发“再平衡”重新分配。Kafka 提供四种分配策略通过partition.assignment.strategy配置默认是Range CooperativeSticky6.2.1RangeAssignor 分配策略​ 按主题独立分配分区对每个主题单独处理将分区和消费者按名称排序用分区数 ÷ 消费者数计算基础分配量余数部分优先分给字典序靠前的消费者。假设n 分区数/消费者数m 分区数%消费者数前 m 个消费者各分 n1 个分区其余分 n 个。​ 就是计算得到n,m其中前面m个消费者分配得到n1个分区(partion)剩余的消费者分配得到n个分区。6.2.2RoundRobin分配策略​ 将所有主题的分区打散和所有消费者一起按哈希值排序再轮询分配更均衡但失去主题局部性。6.2.3StickyAssignor分配策略​ 优先保证分配均衡且在再平衡时尽量保留原有分配减少数据迁移。这样初看上去似乎与采用RoundRobinAssignor分配策略所分配的结果相同但事实是否真的如此呢?再假设此时消费者C1脱离了消费组那么消费组就会执行再均衡操作进而消费分区会重新分配。如果采用RoundRobinAssignor分配策略那么此时的分配结果如下:RB..会重新轮训分配。​ 而StickyAssignor的方式会尽量减少变动在原来的基础上先给消费者消息较少的一方先分配。07.数据可靠性保证​ 为保证 Producer 发送的数据能可靠发送到指定的topic,topic 的每个 Partition收到Producer发送的数据后都需要向Producer发送ACK(ACKnowledge确认收到)。ACK 是由Leader 副本返回的Follower 同步是后台异步进行的。7.1副本数据同步策略​ 如果要求全部 Follower 同步完成后才发 ACK即acksall 等所有副本虽然能保证强一致性但是延迟高若某个 Follower 宕机或网络卡顿Leader 会无限等待导致 Producer 阻塞。​ 在 Kafka 中ACK 并非等“所有 Follower”同步完成才发送而是基于一个动态维护的ISRIn-Sync Replicas集合来决定。7.1.1ISR 是什么​ ISR 是与 Leader 保持同步的副本集合包括 Leader 自身。Follower 只要能在replica.lag.time.max.ms默认 30 秒内跟上 Leader 的日志进度就留在 ISR 中否则被踢出。7.1.2何时发送 ACK​ 当 Producer 设置acksall时Leader 只需等待 ISR 中的所有副本都写入成功即可返回 ACK——不是所有配置的副本而是当前“健康”的 ISR 副本。7.1.3故障容错与选举Leader 宕机后新 Leader 必须从 ISR 中选举确保不丢失已确认的消息因此只要 ISR 中有至少一个 Follower就能安全切换若 ISR 缩减为仅 Leader如其他副本全掉线则默认unclean.leader.election.enablefalse拒绝选举非 ISR 副本为 Leader宁可不可用也不丢数据若开启 unclean 选举则可能丢数据但提升可用性。策略描述优点缺点半数以上同步如 Raft多数派确认即ACK延迟低容忍 n 故障需 2n1 节点Kafka未采用ISR 全部同步Kafka 方案ISR 内所有副本同步才ACK强一致性 自动剔除慢节点若 ISR 缩小可用性下降 Kafka 没有采用“半数以上”模型而是通过动态 ISR acksall实现让 Leader 只等待“健康且同步及时”的 Follower 完成写入后才发送 ACK既避免因个别副本故障导致系统阻塞又确保故障切换时不丢失已确认数据。7.2ACK应答机制​ 对于某些不太重要的数据对数据的可靠性要求不是很高能够容忍数据的少量丢失所以没必要等ISR中的Follower全部接受成功。所以Kafka为用户提供了三种可靠性级别用户根据可靠性和延迟的要求进行权衡选择以下的配置。当acks1默认Leader 副本写入成功即返回 ACKProducer 收到后继续发送下一条若未收到 ACK如超时或失败Producer 会自动重试发送需开启重试机制更高可靠性可设acksall要求Leader 所有 ISR Follower 均写入成功才返回 ACK。tipsACK 是由Leader 副本返回的不是每个 Partition 主动“向 Producer 发送 ACK”Follower 同步是后台异步进行的。7.3可靠性指标当然可以。以下是对您提供内容的精炼、准确、语言自然的整理去除冗余突出 Kafka 可靠性设计的关键点2.6.3 可靠性指标​ 没有任何系统能做到 100% 可靠Kafka 的可靠性目标是通过合理配置无限接近“五个 9”99.999%。Kafka 从生产、存储、消费三个环节保障高可靠副本机制每个分区可配置多个副本通常3 副本即可满足大多数高可靠场景副本分布在不同 Broker 上避免单点故障注意增加分区数不等于提升可靠性副本数才是关键过多分区反而带来调度和管理开销。ACKS设置acksall或-1确保消息被Leader 和所有 ISR 副本成功写入后才确认配合重试机制retries 0和幂等性enable.idempotencetrue避免丢失或重复。消费者 Offset 提交策略默认enable.auto.committrue会定期自动提交 offset存在消息丢失或重复风险高可靠场景应关闭自动提交在消息处理成功后再手动提交 offset宁可重复消费也不因提前提交 offset 导致消息丢失。