大家周四快樂，今天分享粉絲投稿的面經。

內容整理如下：

go

go singleflight 的底層實現

singleflight 是 Go 語言標準庫中的一個很有用的包，它主要用來處理并發請求時的重復問題。比如在高并發場景下，如果多個請求同時訪問同一個資源，singleflight 可以確保這些請求中只有一個實際執行，其他請求則等待這個結果。

具體來說，singleflight 里有一個核心結構叫做 Group。當你調用 Do 方法時，它接收一個鍵（key）和一個函數（fn）。這個鍵是用來標識請求的唯一性，而函數則是實際要執行的操作。Do 方法首先會檢查是否已經有相同的請求正在處理中。如果有，那么當前請求就會被放入一個等待隊列，直到第一個請求完成并返回結果。這時，所有等待的請求都會收到相同的結果。

內部實現上，singleflight 使用了一個互斥鎖（mutex）來保護其狀態，并且有一個映射表（map）來存儲正在進行的請求。對于每個請求，它會創建一個 call 對象，這個對象包含了實際的執行函數以及一個通道（channel），用于在請求完成后發送結果。當有多個請求使用相同的鍵時，它們會被添加到同一個 call 對象的等待隊列中，等到第一個請求完成后，所有的請求都會被喚醒并返回相同的結果。

這種方式特別適用于緩存穿透或者需要避免重復計算的場景，因為它可以大大減少對后端服務的壓力，提高系統的性能和效率。

mysql

使用數據庫樂觀鎖cas操作判斷的時候，受不受數據庫隔離級別的影響？

樂觀鎖（CAS操作）和數據庫的隔離級別確實有一定的關系，但它們的作用方式不同。

樂觀鎖通常通過版本號或時間戳來實現。當一個事務嘗試更新數據時，它會檢查數據的版本號或時間戳是否與讀取時一致。如果不一致，說明在這期間數據已經被其他事務修改了，那么當前事務就會失敗并可能需要重試。

數據庫的隔離級別則決定了事務之間可見性的規則。常見的隔離級別包括讀未提交、讀已提交、可重復讀和序列化。不同的隔離級別對并發事務的可見性和一致性有不同的保證。

樂觀鎖的操作本身并不依賴于特定的隔離級別，但它可能會受到隔離級別選擇的影響。例如：

• 讀未提交：在這種隔離級別下，事務可以看到其他事務未提交的數據。這可能會導致樂觀鎖的版本檢查出現問題，因為一個事務可能會看到另一個事務尚未提交的數據。
• 讀已提交：在這種隔離級別下，事務只能看到已經提交的數據。這是最常見的隔離級別之一，適合使用樂觀鎖，因為它可以避免臟讀。
• 可重復讀：在這種隔離級別下，事務在執行過程中多次讀取同一數據時，結果是一致的。這有助于確保樂觀鎖的版本檢查是基于一致的數據視圖。
• 序列化：這是最高的隔離級別，它提供了最嚴格的事務隔離。在這種隔離級別下，樂觀鎖通常也能很好地工作，但由于序列化的高開銷，實際應用中不常用。

redis

介紹一下redis中常用數據結構的底層實現

1. String

• 用途：用于存儲簡單的鍵值對，可以是字符串、整數或浮點數。
• 底層實現：
  • Redis 的 String 類型內部使用 sds (簡單動態字符串) 結構來存儲數據。sds 是 Redis 自己實現的一種字符串結構，它在 C 字符串的基礎上增加了長度信息，并且提供了高效的內存管理和擴展能力。

2. Hash

• 用途：用于存儲字段和值之間的映射關系，類似于 Java 中的 HashMap。
• 底層實現：
  • 當哈希表中的元素較少時，Redis 使用壓縮列表（ziplist）來存儲數據。壓縮列表是一種特殊的雙向鏈表，它可以高效地存儲小數量的數據，并且占用更少的內存。
  • 當哈希表中的元素較多時，Redis 會將壓縮列表轉換為字典（Dictionary）。字典是一個由多個桶（bucket）組成的數組，每個桶中包含一個鏈表，用于處理哈希沖突。
• 轉換閾值：
  • 每個字段的最大長度：hash-max-ziplist-value（默認 64 字節）
  • 哈希表的最大字段數量：hash-max-ziplist-entries（默認 512 個字段）

3. List

• 用途：有序的字符串列表，可以在列表的兩端進行插入和刪除操作。
• 底層實現：
  • 當列表中的元素較少時，Redis 使用壓縮列表（ziplist）來存儲數據。壓縮列表可以高效地存儲小數量的數據，并且占用更少的內存。
  • 當列表中的元素較多時，Redis 會將壓縮列表轉換為雙端鏈表（linked list）。雙端鏈表允許在列表的兩端進行高效的插入和刪除操作，但訪問中間元素的效率較低。
• 轉換閾值：
  • 每個元素的最大長度：list-max-ziplist-value（默認 64 字節）
  • 列表的最大元素數量：list-max-ziplist-entries（默認 512 個元素）

4. Set

• 用途：無序的字符串集合，不允許重復元素。
• 底層實現：
  • 當集合中的元素較少時，Redis 使用整數集合（intset）來存儲數據。整數集合是一個有序的整數數組，支持快速查找和插入操作。
  • 當集合中的元素較多時，Redis 會將整數集合轉換為字典（Dictionary）。字典提供高效的查找和插入操作，適用于大量數據的情況。
• 轉換閾值：
  • 整數集合中的最大元素數量：沒有明確的配置項，但當集合中的元素不再是整數或元素數量超過一定閾值時，會自動轉換為字典。

5. Zset (Sorted Set)

• 用途：有序的字符串集合，每個元素關聯一個分數，通過分數進行排序。
• 底層實現：
  • 跳躍表（skiplist）：跳躍表是一種概率數據結構，提供高效的范圍查詢和插入操作。跳躍表通過多層索引來加速查找過程。
  • 字典（Dictionary）：字典用于存儲成員到分數的映射，以便快速查找成員的分數。
  • Zset 內部使用兩種數據結構來實現：
  • 跳躍表和字典共同工作，確保 Zset 既能高效地進行范圍查詢，又能快速地進行成員查找。
• 轉換閾值：
  • 每個成員的最大長度：zset-max-ziplist-value（默認 64 字節）
  • 有序集合的最大成員數量：zset-max-ziplist-entries（默認 128 個成員）

redis內存快把一臺機器的內存占滿了，例如一共16g，現在用了15.5g這時候你該怎么辦？

一、監控和分析內存使用情況

使用 Redis 的監控工具（如 RedisInsight）或者命令（如 INFO memory）來確定哪些數據占用了大量內存，以便后續采取針對性措施。

二、調整數據存儲和過期策略

檢查是否有一些數據可以設置過期時間，對于臨時數據或者不經常使用的數據，設置合理的過期時間，讓 Redis 自動清理這些數據。例如，使用 EXPIRE 或 PEXPIRE 命令設置鍵的過期時間。

優化數據結構，避免存儲不必要的大字符串等占用大量內存的數據結構。

三、啟用內存淘汰策略

選擇合適的內存淘汰策略，如 allkeys-lru（淘汰最近最少使用的鍵）、volatile-lru（淘汰已設置過期時間且最近最少使用的鍵）等。可以通過 CONFIG SET maxmemory-policy 命令來設置淘汰策略。

四、數據持久化和清理

利用 Redis 的持久化機制（如 RDB 或 AOF），將數據定期持久化到磁盤上，這樣可以在內存不足時，從磁盤恢復數據，釋放內存空間。

根據業務需求，手動清理一些不再需要的數據，可以使用 DEL 命令刪除單個鍵。

五、擴展 Redis 實例

如果條件允許，可以考慮為當前機器增加內存。

使用 Redis 集群或哨兵模式，將數據分片存儲到多個 Redis 實例中，分散內存壓力。

kafka

如何保證kafka消息順序 （包括業務內有序和全局有序）

要保證 Kafka 消息的業務內有序，需確保相關業務消息被發送至同一個分區，這是因為同一分區內的消息處理是有序的。

而實現全局有序，通常需嚴格限制并發度，僅使用一個分區，但這會在一定程度上降低系統的性能和消息的吞吐量。

在實際應用中，要綜合考慮業務需求、性能要求和資源配置等多方面因素來權衡消息順序和系統效率之間的關系。

kafka的可用性怎么保證的？

可以通過多種機制來保證高可用性，確保在出現故障時系統能夠繼續正常運行：

1. 多副本：
   • Kafka 的每個 topic 可以劃分為多個 partition，每個 partition 可以有多個副本（replica）。這些副本分布在不同的 broker 上。
   • 其中一個副本被選為 leader，負責處理所有的讀寫請求；其他副本是 follower，它們從 leader 復制數據。
   • 如果 leader 副本所在的 broker 宕機，Kafka 會自動從 follower 中選舉一個新的 leader 繼續提供服務。
2. ISR：
   • ISR 是一組與 leader 保持同步的副本集合。只有當 follower 副本的數據與 leader 一致時，才會被加入 ISR。
   • Kafka 通過維護 ISR 來確保數據的一致性和可靠性。如果某個 follower 落后太多或無法與 leader 通信，它會被移出 ISR。
3. ACK 機制：
   • acks=0：生產者不等待任何確認。
   • acks=1：生產者等待 leader 副本確認。
   • acks=all：生產者等待所有 ISR 中的副本確認。
   • 生產者在發送消息時可以設置 acks 參數來控制消息的確認級別：
   • 設置 acks=all 可以確保消息被所有副本確認，從而提高數據的可靠性。
4. ZooKeeper 用于元數據管理：
   • Kafka 使用 ZooKeeper 來管理和協調集群中的 broker、topic 和 partition 的狀態。
   • ZooKeeper 監控 broker 的狀態，并在 broker 宕機時觸發 leader 選舉和重新分配。
5. 負載均衡：
   • Kafka 通過將 partition 分散到不同的 broker 上，實現負載均衡，避免單點壓力過大。
   • 這種分散存儲的方式也提高了系統的整體吞吐量和可用性。
6. 配置參數：
   • 通過調整 Kafka 的配置參數，如 replication.factor（副本數）、min.insync.replicas（最小同步副本數）等，可以進一步優化高可用性。

kafka宕機后那些正在消費中的消息該怎么處理？

會通過以下方式來處理那些正在被消費的消息：

1. 自動切換到備份：
   • 每個 topic 的 partition 都有多個副本（復制的數據），其中一個副本是 leader，負責處理讀寫請求。其他副本是 follower，它們從 leader 復制數據。
   • 如果 leader 所在的 broker 宕機了，Kafka 會自動選擇一個健康的 follower 副本作為新的 leader。這個過程對消費者是透明的，消費者可以繼續從新的 leader 讀取消息。
2. 消費者重新分配：
   • 當 broker 宕機后，消費者的消費組會進行一次重新平衡（rebalance）。這意味著 Kafka 會重新分配 partition 給消費者，確保每個 partition 只有一個消費者在讀取。
   • 重新平衡后，消費者可以從上次提交的位置繼續消費消息。如果消費者之前已經提交了偏移量（offset），那么它可以從提交的位置開始繼續消費，而不會丟失或重復消息。
3. 偏移量管理：
   • 消費者可以配置為自動提交偏移量，也就是每隔一段時間自動告訴 Kafka 已經消費到哪個位置了。這樣即使消費者宕機，重啟后也可以從上次提交的位置繼續消費。
   • 如果需要更精確的控制，消費者可以選擇手動提交偏移量，在處理完一條消息后再提交偏移量，這樣可以避免消息丟失或重復。
4. 客戶端自動重連：
   • Kafka 客戶端（比如消費者）通常會有自動重連機制。如果連接斷開了，客戶端會嘗試重新連接到 Kafka 集群。
   • 客戶端和 broker 之間還有心跳檢測機制，如果發現連接中斷，客戶端會嘗試重新建立連接。

kafka重復消費問題怎么解決？

1. 冪等性處理

• 確保業務邏輯是冪等的：設計你的業務邏輯，使得多次處理同一條消息不會產生不同的結果。例如，如果消息涉及更新數據庫記錄，可以使用唯一鍵來防止重復插入。

2. 事務支持

• 使用 Kafka 事務：Kafka 支持事務，可以在同一個事務中同時處理消息和提交偏移量。這樣即使在處理過程中出現故障，也不會導致重復消費。
  • 生產者和消費者都可以參與事務，確保數據的一致性和完整性。

3. 手動提交偏移量

• 關閉自動提交：將 enable.auto.commit 設置為 false，然后在消息成功處理后再手動提交偏移量。
  • 同步提交：consumer.commitSync()，這種方式會阻塞直到提交完成。
  • 異步提交：consumer.commitAsync()，這種方式是非阻塞的，但需要處理提交失敗的情況。

4. 去重機制

• 使用外部存儲去重：利用外部存儲（如 Redis、數據庫）來記錄已經處理過的消息 ID 或其他唯一標識符。每次處理消息前，先檢查該消息是否已經被處理過。
  • 這種方法適用于對消息去重有嚴格要求的場景，但會增加額外的復雜性和開銷。

5. 布隆過濾器

• 使用布隆過濾器：對于大量數據，可以使用布隆過濾器來高效地檢測消息是否已經被處理過。布隆過濾器是一種空間效率很高的概率型數據結構，適合用于大規模數據的去重。

堅定不移，聽話照做，按部就班，早日上岸！

關注我，免費領面經，升職加薪，備注：面經。