詳解Kafka重平衡機制詳解

????????Kafka 的重平衡機制（Rebalance）是確保消費者組內成員動態變化（如新成員加入、現有成員退出或崩潰、訂閱主題分區數變化）時，分區所有權能合理、公平地重新分配的核心機制。其目標是保證所有分區都有消費者處理，且負載相對均衡。

一、重平衡的觸發條件

1. 消費者加入組：

  • 新消費者啟動并加入已存在的消費者組。

  • 消費者崩潰后重新恢復并重新加入組。

2. 消費者離開組：

  • 消費者主動關閉（發送 LeaveGroup 請求）。

  • 消費者崩潰（長時間未發送心跳，被 Broker 判定為失效）。

  • 消費者處理消息時間過長（超過?max.poll.interval.ms），被 Broker 判定為失敗。

3.?訂閱主題變化：

  • 消費者組訂閱的主題列表發生變更（增加或減少主題）。

4.?主題分區數變化：

  • 消費者組訂閱的某個主題的分區數量發生變更（增加分區）。

二、重平衡的核心角色與協議（Consumer Group Protocol）

????????Kafka 使用基于?Group Coordinator?和?Consumer Group Leader?的協議來管理重平衡。協議的核心是?Group Membership?和?Partition Assignment。

1. Group Coordinator：

  • 每個消費者組在創建時，會被分配一個特定的 Broker 作為其?組協調器。

  • 負責管理消費者組的元數據（成員列表、當前狀態、分配方案、消費位移等）。

  • 處理消費者的加入/離開請求。

  • 監控消費者的心跳。

  • 觸發并管理重平衡過程。

  • 消費者通過向集群發送?FindCoordinator?請求來查找其組的協調器。

2.?消費者組狀態機：

  • Empty：?組內沒有任何成員。當最后一個成員離開且位移保留策略到期后進入此狀態。

  • PreparingRebalance：?組正在準備進行重平衡（有成員加入或離開）。

  • CompletingRebalance：?組內成員已穩定，等待 Leader 消費者提交分區分配方案。

  • Stable：?重平衡完成，組處于穩定工作狀態，成員按分配方案消費。

3.?重平衡流程詳解（以 JoinGroup/SyncGroup 協議為主）：

階段 1：消費者加入組（JoinGroup?請求）

  • 當觸發條件發生時（如新消費者啟動），所有存活的組成員（包括新成員）?都需要向 Coordinator 發送?JoinGroup?請求。

  • 第一個成功發送?JoinGroup?的消費者（或 Coordinator 選定的）成為?Consumer Group Leader。其他成員成為 Follower。

  • Leader 的職責：?收集所有成員通過?JoinGroup?請求上報的訂閱信息（訂閱的主題列表、用戶自定義數據?userData）。

  • Coordinator 等待一段時間（session.timeout.ms?或?rebalance.timeout.ms），收集所有成員的?JoinGroup?請求。

  • Coordinator 向?所有成員?發送?JoinGroup?響應：

    • 包含：generationId（代次，每次重平衡遞增，用于防止處理過期消息）、memberId（由 Coordinator 分配的唯一成員ID）、leaderId、協議列表、Leader 成員列表和訂閱信息（僅 Leader 收到完整的訂閱信息）。

階段 2：Leader 計算分配方案 & Follower 等待

  • Leader 消費者：?收到?JoinGroup?響應后，根據所有成員的訂閱信息和預配置的?分區分配策略（partition.assignment.strategy），計算出一個分區分配方案（哪個分區分配給哪個消費者）。

  • Follower 消費者：?在?JoinGroup?響應后，等待 Leader 的下一步指示。

階段 3：同步分配方案（SyncGroup?請求）

  • Leader 消費者：?向 Coordinator 發送?SyncGroup?請求，其中包含計算好的分區分配方案。

  • Follower 消費者：?向 Coordinator 發送空的?SyncGroup?請求（表示等待分配結果）。

  • Coordinator 等待 Leader 的?SyncGroup?請求。收到后，將 Leader 提交的分區分配方案保存下來。

  • Coordinator 向?所有成員?發送?SyncGroup?響應：

    • 包含：分配給該消費者的具體分區列表（以及 Leader 可能放入?userData?中的任何信息）。

階段 4：穩定狀態（Stable）

  • 所有消費者收到?SyncGroup?響應后，知道了自己負責消費哪些分區。

  • 消費者開始從分配到的分區的最后提交的位移（committed offset）處開始拉取消息并進行消費。

  • 消費者定期向 Coordinator 發送心跳（Heartbeat?請求）以表明自己存活。

  • 組狀態變為?Stable。

三、重要的分區分配策略

消費者端的配置?partition.assignment.strategy?決定了 Leader 如何計算分配方案。常用策略：

1.?RangeAssignor?(默認)：

  • 原理：?按主題維度分配。對每個訂閱的主題，將分區排序，消費者排序，然后計算每個消費者應分配的分區范圍。

  • 優點：?簡單。

  • 缺點：?可能導致訂閱相同主題數量不同的消費者間負載不均衡（尤其訂閱主題多時，前面消費者可能分配到更多分區）。

2.?RoundRobinAssignor：

  • 原理：?將所有消費者訂閱的所有主題的所有分區打散排序，然后按消費者順序輪詢分配。

  • 優點：?在消費者訂閱主題完全相同時，分配最均衡。

  • 缺點：?如果消費者訂閱的主題不同，分配可能不均衡（訂閱主題少的消費者可能分不到某些主題的分區）。

3.?StickyAssignor?(粘性分配器)：

  • 原理：?目標是盡量保持與上一次分配結果一致，僅在必要時（如成員變化、分區數變化）進行最小變動。同時盡量保證負載均衡。

  • 優點：

    • 減少重平衡影響：?大部分分區不換主人，減少了狀態（如本地緩存、處理上下文）遷移的開銷和重復消費/漏消費的風險。

    • 平衡性：?在穩定性基礎上追求負載均衡。

  • 主要缺點：

    • Stop-The-World:?在重平衡期間，整個消費者組的所有消費者都會停止處理數據。這個過程可能相當長，尤其是在大型消費者組或分區數很多的情況下，導致應用程序處理中斷。

    • 單點計算壓力：?Leader 消費者需要收集所有成員信息并執行復雜的分配計算，對于大型組來說負擔很重。

    • 協議限制：?它依賴于舊的、需要一次性完成全量分配的 Eager Rebalance 協議。

  • 強烈推薦使用！?顯著提升重平衡的平滑度。

  • 工作機制:

    • 所有消費者實例都使用?StickyAssignor。

    • 當觸發重平衡時（例如，一個新消費者加入），整個消費者組的所有消費者都會停止拉取數據并提交偏移量。

    • 所有消費者都向協調者（Group Coordinator）發送加入組的請求。

    • 協調者選出 Leader 消費者。

    • Leader 消費者執行分配邏輯：?Leader 消費者收集所有成員的訂閱信息和上一次的分配結果，然后運行?StickyAssignor?的分配算法，計算出一個新的、盡可能保留上次分配的分區方案。

    • Leader 消費者將分配方案發送給協調者。

    • 協調者將分配方案發送給所有消費者。

    • 所有消費者同時開始消費它們新分配到的分區。

4.?CooperativeStickyAssignor?(協作粘性分配器 - KIP-429)：

  • 原理：?StickyAssignor?的協作式（增量式）版本，是實現?增量式重平衡?的關鍵。在重平衡時，允許消費者在完成同步SyncGroup之前，保留其之前分配到的部分分區?并繼續消費這些分區（稱為"延遲撤銷"），直到新分配方案生效。新舊分配方案之間的差異分區才需要停止消費或開始消費。

  • 優點：

    • 顯著減少"停止世界"時間：?消費者在重平衡的大部分時間內仍在消費部分數據，大大降低了應用程序停頓時間，提高了可用性。

    • 平滑遷移：?分區所有權的轉移是漸進的。

  • 要求：?消費者組內所有成員必須使用相同的?CooperativeStickyAssignor?策略。

  • 工作機制:

    • 所有消費者實例都使用?CooperativeStickyAssignor。

    • 當觸發重平衡時（例如，一個新消費者加入）：

      • 第一階段：

        • 協調者通知所有消費者需要進行重平衡。

        • 消費者不需要立即停止消費！?它們繼續處理當前分配到的分區。

        • 消費者向協調者發送加入組請求，并攜帶它們當前持有的分區信息。

        • 協調者選出 Leader 消費者。

        • Leader 消費者執行第一輪分配邏輯：?Leader 收集所有成員的訂閱信息和當前持有的分區信息，運行?CooperativeStickyAssignor?算法。算法會：

          • 標記那些不再需要由當前消費者持有的分區（例如，因為消費者離開，或者訂閱主題變化）。

          • 生成一個臨時分配方案，這個方案只包含消費者可以安全繼續持有的分區。那些需要移動的分區在這個階段不會被分配出去。

        • Leader 將臨時分配方案發送給協調者。

        • 協調者將臨時分配方案發送給所有消費者。

        • 消費者收到臨時分配方案：

          • 它們釋放那些在臨時方案中不再分配給自己的分區（停止消費）。

          • 它們繼續消費臨時方案中仍然分配給自己的分區。應用程序處理在這些分區上不會中斷！

      • 第二階段：

        • 消費者完成釋放分區后，再次向協調者發送加入組請求（攜帶它們當前的狀態）。

        • 協調者（可能再次選出 Leader，也可能復用）收集請求。

        • Leader 消費者執行第二輪分配邏輯：這次它知道哪些分區已經被釋放（處于未分配狀態）。它再次運行分配算法，將第一階段未分配的分區（需要移動的）以及任何新發現需要調整的分區，重新分配給合適的消費者。

        • Leader 將最終分配方案發送給協調者。

        • 協調者將最終分配方案發送給所有消費者。

        • 消費者開始消費最終分配方案中全部分區（包括它們在第一階段保留的分區和第二階段新分配的分區）。

特性StickyAssignor (傳統)CooperativeStickyAssignor (協作式 - KIP-429)
核心目標最小化分區移動最小化分區移動?+?最小化重平衡期間應用程序停頓
重平衡協議Eager Rebalance (急切重平衡)Cooperative Rebalance?(協作重平衡/增量重平衡)
消費者行為全局停頓：?所有消費者在重平衡期間完全停止消費增量協作：?消費者分階段釋放和獲取分區，部分消費可在重平衡期間繼續
分配階段單階段：?一次計算完成全量分配多階段：?至少兩個階段（臨時分配 & 最終分配）
主要缺點重平衡期間整個消費者組完全停止處理數據實現更復雜，需要 Kafka Broker 和 Client 端支持新協議
Kafka 版本要求老版本 Kafka 均支持需要 Broker 和 Client 端均為 Kafka 2.4+
配置名partition.assignment.strategy: org.apache.kafka.clients.consumer.StickyAssignorpartition.assignment.strategy: org.apache.kafka.clients.consumer.CooperativeStickyAssignor?(通常與?RangeAssignor?或?RoundRobinAssignor?一起配置，如?[RangeAssignor, CooperativeStickyAssignor]?以兼容舊版協議)

四、重平衡的痛點與優化

傳統 Eager Rebalance（Range,?RoundRobin,?Sticky的非協作模式）的主要痛點：

  • "Stop-The-World" 效應：?重平衡期間，整個消費者組停止消費（所有消費者在收到新分配方案前必須撤銷當前持有的所有分區并停止消費）。

  • 處理延遲與重復消費：?撤銷分區可能導致處理到一半的消息需要回滾，新消費者接手后可能重復消費；長時間的重平衡增加端到端延遲。

  • 資源浪費：?頻繁重平衡消耗 Broker 和消費者的 CPU/網絡資源。

Kafka 的優化方案

1. 增量式協作重平衡（Incremental Cooperative Rebalance - KIP-429）：

  • 核心思想：?將分區所有權變更從"一次性全部撤銷"改為"多次小批量撤銷/分配"，允許消費者在重平衡過程中保留部分分區并繼續消費。

  • 協議變更：

    • 消費者在?JoinGroup?請求中包含當前持有的分區（owned_partitions）。

    • Coordinator 和 Leader 在計算新方案時，知道當前每個消費者持有哪些分區。

    • 新方案中，如果一個消費者不再擁有某個分區，該分區會被標記為"待撤銷"（revoked），但不會立即停止消費。

    • 消費者收到?SyncGroup?響應后：

      • 保留?新方案中仍然分配給它的分區（且之前就持有的），繼續消費。

      • 開始消費?新方案中分配給它的、但之前不持有的分區（assigned）。

      • 標記待撤銷?不再持有的分區（revoked），但繼續消費直到顯式要求停止。

    • 消費者處理完?revoked?分區的最后一批消息后，主動向 Coordinator 發送?ACK?表示已準備好釋放這些分區。

    • 當所有消費者都?ACK?了其所有待釋放分區后，Coordinator 觸發第二輪（增量）重平衡。

    • 在第二輪重平衡中，之前被?ACK?釋放的分區可以被安全地重新分配給其他消費者。

  • 效果：?顯著縮短了消費者組整體不可用的時間窗口。應用程序在大部分重平衡過程中仍在處理消息。

2.?靜態成員資格（Static Membership - KIP-345）：

  • 痛點：?消費者短暫下線（如滾動重啟、短暫網絡抖動）會立即觸發重平衡，即使它很快會回來。

  • 方案：?為消費者配置持久化的?group.instance.id。

  • 原理：

    • Coordinator 將?group.instance.id?視為消費者的"永久身份"。

    • 消費者在重啟后使用相同的?group.instance.id?加入組。

    • Coordinator 不會立即移除短暫消失的成員，而是等待?session.timeout.ms。如果在超時前該成員重新加入，則不觸發重平衡，它將繼續持有之前的分配。

  • 效果：?大大減少了因滾動重啟或計劃內維護觸發的重平衡次數。

五、最佳實踐與配置建議

  • 使用?CooperativeStickyAssignor：?這是減少重平衡影響最關鍵的一步。確保所有消費者配置一致。

  • 啟用靜態成員資格：?為需要穩定性的消費者（特別是生產環境）配置?group.instance.id，尤其是在滾動部署場景下。

  • 合理配置超時參數：

    • session.timeout.ms?(Broker 端：group.min.session.timeout.ms/group.max.session.timeout.ms)：心跳超時時間。增大?可以容忍更長的 GC 暫停或網絡延遲，避免誤判死亡觸發重平衡，但延長了故障檢測時間。典型值：5s - 30s。

    • heartbeat.interval.ms：心跳發送間隔。應遠小于?session.timeout.ms?(通常為 1/3)。典型值：1s - 10s。

    • max.poll.interval.ms：兩次?poll()?調用的最大間隔。如果消費者處理消息太慢超過此時間，會被認為失敗觸發重平衡。根據業務邏輯處理最慢情況設定，避免過小導致誤判。典型值：根據處理耗時設置，如 1min - 5min。

  • 優化消息處理邏輯：?確保?poll()?返回的消息能在?max.poll.interval.ms?內處理完。避免在消息處理中執行耗時操作（如同步 DB 調用、復雜計算）。考慮異步處理、批量處理優化。

  • 避免頻繁重啟消費者：?規劃好部署和維護策略，減少不必要的消費者啟停。

  • 監控：

    • 監控消費者組狀態 (kafka-consumer-groups.sh)。

    • 監控重平衡速率 (kafka.server:type=group-coordinator-metrics,name=rebalance-rate-per-group,?rebalance-latency-avg?等 JMX 指標)。

    • 監控消費者滯后量 (consumer_lag)。

    • 監控心跳和?poll?間隔。

六、總結

????????Kafka 的重平衡機制是消費者組彈性和擴展性的基石，但其傳統的 "Stop-The-World" 模式帶來了顯著的性能開銷和可用性挑戰。理解其觸發條件、協議流程（JoinGroup/SyncGroup）、分配策略（尤其是?Sticky/CooperativeSticky）至關重要。通過采用?增量式協作重平衡 (CooperativeStickyAssignor)?和?靜態成員資格，并輔以合理的參數配置和消費者邏輯優化，可以極大地減少重平衡的頻率和影響范圍，顯著提升 Kafka 消費者應用程序的穩定性和吞吐量。始終監控重平衡相關指標是保障健康運行的關鍵。

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/pingmian/88129.shtml
繁體地址，請注明出處：http://hk.pswp.cn/pingmian/88129.shtml
英文地址，請注明出處：http://en.pswp.cn/pingmian/88129.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

代碼詳細注釋：文件IO在用戶管理系統中的應用實踐：C語言實現用戶名查重與密碼確認與支持日志記錄的終端用戶認證解決方案的注冊登錄系統

代碼詳細注釋：文件IO在用戶管理系統中的應用實踐：C語言實現用戶名查重與密碼確認與支持日志記錄的終端用戶認證解決方案的注冊登錄系統

代碼/* 作業增強版注冊登錄系統 - 帶日志和安全性增強功能 */ #include <stdio.h> // 標準輸入輸出函數(printf, scanf等) #include <stdlib.h> // 標準庫函數(exit, malloc等) #include <string.h> // 字符串處理函數(strcmp, strcspn等) #inc…
閱讀更多...
Go與JS無縫協作：Goja引擎實戰之錯誤處理最佳實踐

Go與JS無縫協作：Goja引擎實戰之錯誤處理最佳實踐

引言&#xff1a;當Go邂逅JavaScript 在現代軟件開發中&#xff0c;跨語言協作已成為提升效率的關鍵。想象一下&#xff1a;用Go的高性能處理核心邏輯&#xff0c;同時用JavaScript的靈活性實現動態規則——這不再是夢想。Goja&#xff0c;這個純Go語言實現的JavaScript引擎&am…
閱讀更多...
繼承與多態：面向對象編程的兩大支柱

繼承與多態：面向對象編程的兩大支柱

引言&#xff1a;為什么必須掌握繼承與多態&#xff1f; 在Java開發中&#xff0c;繼承與多態是構建可擴展、易維護系統的基石&#xff1a; 繼承&#xff1a;實現代碼復用&#xff0c;建立清晰的類層次結構多態&#xff1a;提升代碼靈活性&#xff0c;實現"編寫一次&#…
閱讀更多...
2025使用VM虛擬機安裝配置Macos蘋果系統下Flutter開發環境保姆級教程--上篇

2025使用VM虛擬機安裝配置Macos蘋果系統下Flutter開發環境保姆級教程--上篇

前言 我們在學習Flutter開發的過程中&#xff0c;永遠都跳不過去的一個問題就是如何在MAC下開發并打包Flutter工程項目&#xff0c;但MAC開發首先要解決的問題就是我們一般技術人員的電腦都是WINDOWS操作系統&#xff0c;專門配置一臺MAC的話成本又是不得不考慮的因素&#xf…
閱讀更多...
250708-Svelte項目從Debian遷移到無法聯網的RHEL全流程指南

250708-Svelte項目從Debian遷移到無法聯網的RHEL全流程指南

&#x1f4cc; 背景 在 Debian 上使用以下命令創建了一個 Svelte 項目&#xff1a; npm install -g sv npx sv create my-svelte-demo cd my-svelte-demo npm install npm run dev現在需要將該項目遷移到一臺 無法聯網的 RHEL 9.4 服務器 上運行&#xff0c;出現如下報錯&…
閱讀更多...
力扣 hot100 Day39

力扣 hot100 Day39

118. 楊輝三角 給定一個非負整數 numRows&#xff0c;生成「楊輝三角」的前 numRows 行。 class Solution { public:vector<vector<int>> generate(int numRows) {vector<vector<int>> res(numRows);for (int i 0; i < numRows; i) {res[i].resi…
閱讀更多...
HuggingFists: 無代碼處理復雜PDF

HuggingFists: 無代碼處理復雜PDF

有過使用LLM搭建RAG或其它類知識系統的朋友一定會對文檔數據的復雜多樣性有著深刻的理解。各行各業的磁盤中都沉睡了數年到數十年的各類文檔信息&#xff0c;包括&#xff1a;Doc、Docx、PPT、PDF、XLS、PNG、JPEG等各類格式。利用LLM激活這些數據價值的首要工作就是能夠正確的…
閱讀更多...
Vue 3 框架實現理念、架構與設計哲學深度解析

Vue 3 框架實現理念、架構與設計哲學深度解析

第一部分&#xff1a;Vue 3 的起源&#xff1a;架構演進與設計哲學 Vue 3 的誕生并非一次簡單的版本迭代&#xff0c;而是一場深刻的架構革命。它的出現是前端技術演進、應用規模擴張以及對更高性能和可維護性追求的必然結果。要全面理解 Vue 3 的各項實現理念&#xff0c;必須…
閱讀更多...
SQL Server使用存儲過程導出數據到Excel實現方式

SQL Server使用存儲過程導出數據到Excel實現方式

在SQL Server數據庫管理中，存儲過程作為預編譯的T-SQL語句集合，能顯著提升數據操作效率與安全性。將數據導出到Excel的需求廣泛存在于報表生成、數據遷移等場景。本文詳細解析四種通過存儲過程實現數據導出的技術方案，涵蓋代碼實現、適用場景及優化策略，為不同業務需求提供…
閱讀更多...
OpenGL 2. 著色器

OpenGL 2. 著色器

#include <glad/glad.h> #include <GLFW/glfw3.h> #include <iostream> #include <stdexcept>// 函數聲明 void framebuffer_size_callback(GLFWwindow* window, int width, int height); void processInput(GLFWwindow* window); void checkShaderCom…
閱讀更多...
【c++】容器擴容導致的類實例資源被錯誤釋放

【c++】容器擴容導致的類實例資源被錯誤釋放

BUG記錄 表現為新實例被存入前&#xff0c;容器內部的舊實例的析構被意外調用 因為 std::vector 在容量不足時&#xff0c;會自動擴容&#xff0c;把舊元素「搬」到新內存&#xff0c;然后析構舊內存上的那些對象。然后由于LKMotorController 類里沒有正確處理移動語義&#xf…
閱讀更多...
TypeScript 集成

TypeScript 集成

下面&#xff0c;我們來系統的梳理關于 Vue TypeScript 深度集成 的基本知識點&#xff1a;一、TypeScript 與 Vue 集成概述 1.1 為什么需要 TypeScript 類型安全&#xff1a;編譯時類型檢查&#xff0c;減少運行時錯誤代碼智能&#xff1a;強大的IDE智能提示和自動補全可維護…
閱讀更多...
npm proxy

npm proxy

背景 前端項目下載依賴時經常會出現timeout的情況&#xff0c;此時有三種解決方案。 切換鏡像源。 適用于對依賴版本要求不嚴格的情況。延長超時時間。設置npm proxy。一些生產環境對依賴版本有著嚴格要求&#xff0c;并且指定了依賴的下載地址&#xff08;如下圖&#xff09;&…
閱讀更多...
TVS管工作原理是什么？主要的應用場景都有哪些？

TVS管工作原理是什么？主要的應用場景都有哪些？

什么是TVS管&#xff1f; TVS&#xff08;Transient Voltage Suppressors&#xff09;&#xff0c;即瞬態電壓抑制器&#xff0c;也被稱為雪崩擊穿二極管&#xff0c;是一種二極管形式的高效能保護器件&#xff0c;常用來防止端口瞬間的電壓沖擊造成后級電路的損壞。 TVS 有單…
閱讀更多...
分布式微服務系統架構第156集：JavaPlus技術文檔平臺日更-Java線程池使用指南

分布式微服務系統架構第156集：JavaPlus技術文檔平臺日更-Java線程池使用指南

title: java線程池使用 author: 哪吒 date: 2023-06-15點擊勘誤issues&#xff0c;哪吒感謝大家的閱讀Java線程池使用指南1. 線程池基礎使用1.1 創建線程池的方式方式一&#xff1a;使用Executors工具類&#xff08;不推薦&#xff09;// 1. 固定大小線程池 ExecutorService fi…
閱讀更多...
【最新版】點大全能版v2.6.7.1 含匯付斗拱插件+uniapp前端

【最新版】點大全能版v2.6.7.1 含匯付斗拱插件+uniapp前端

一.介紹V2全能版本、獨立版本全開源&#xff0c;含鏈動21&#xff0c;匯付斗拱?、排隊免單、推三返1 &#xff0c;扶持金&#xff0c;平級獎&#xff0c;團隊業績獎&#xff0c;酒店管理&#xff0c;約車&#xff0c;餐飲等眾多營銷功能&#xff0c;商城系統版本號為2.6.7.1&a…
閱讀更多...
Go語言高級面試必考：切片（slice）你真的掌握了嗎？

Go語言高級面試必考：切片（slice）你真的掌握了嗎？

目錄 1. 切片是個啥？從數組到切片的靈魂進化 數組與切片的愛恨情仇 切片的內存結構：三巨頭共舞 切片的初始化方式：靈活到飛起 切片的“引用”特性：福也是禍 源碼初探：切片的誕生 2. 切片三劍客：len、cap 和底層數組的三角戀 len 和 cap 的微妙關系 切片共享的秘密…
閱讀更多...
monorepo + Turborepo --- 開發應用程序

monorepo + Turborepo --- 開發應用程序

目錄 配置開發任務 在 dev 之前運行設置任務 運行特定應用程序 使用終端 UI 與任務交互 監聽模式 watch 將 turbo watch 與持久任務一起使用 依賴感知的持久任務 沒有依賴感知的持久任務 緩存 任務輸出 局限性 在 Monorepo 中開發應用程序可以解鎖強大的工作流程&…
閱讀更多...
C#字符串相關庫函數運用梳理總結 + 正則表達式詳解

C#字符串相關庫函數運用梳理總結 + 正則表達式詳解

C# 字符串常用庫函數總結 &#x1f539; 1. 字符串比較 方法說明示例string.Equals()比較兩個字符串是否相等&#xff08;可忽略大小寫&#xff09;string.Equals("abc", "ABC", StringComparison.OrdinalIgnoreCase) / !判斷兩個字符串是否相等/不等&quo…
閱讀更多...
投機采樣（Speculative Decoding）

投機采樣（Speculative Decoding）

投機采樣&#xff08;Speculative Decoding&#xff09; 是一種加速大型語言模型&#xff08;LLM&#xff09;推理的技術&#xff0c;其核心思想是通過預生成候選token序列并異步校驗&#xff0c;從而減少主模型的計算量&#xff0c;同時保持生成結果的準確性。 核心思想是通過…
閱讀更多...
最新文章

Copyright @ 2022~2023