圖片

go

go singleflight 的底層實現(xiàn)

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

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

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

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

mysql

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

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

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

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

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

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

redis

介紹一下redis中常用數(shù)據(jù)結(jié)構(gòu)的底層實現(xiàn)

1. String

• 用途：用于存儲簡單的鍵值對，可以是字符串、整數(shù)或浮點數(shù)。
• 底層實現(xiàn)：

Redis 的 String 類型內(nèi)部使用 sds (簡單動態(tài)字符串) 結(jié)構(gòu)來存儲數(shù)據(jù)。sds 是 Redis 自己實現(xiàn)的一種字符串結(jié)構(gòu)，它在 C 字符串的基礎(chǔ)上增加了長度信息，并且提供了高效的內(nèi)存管理和擴展能力。

2. Hash

• 用途：用于存儲字段和值之間的映射關(guān)系，類似于 Java 中的 HashMap。
• 底層實現(xiàn)：

當哈希表中的元素較少時，Redis 使用壓縮列表（ziplist）來存儲數(shù)據(jù)。壓縮列表是一種特殊的雙向鏈表，它可以高效地存儲小數(shù)量的數(shù)據(jù)，并且占用更少的內(nèi)存。

當哈希表中的元素較多時，Redis 會將壓縮列表轉(zhuǎn)換為字典（Dictionary）。字典是一個由多個桶（bucket）組成的數(shù)組，每個桶中包含一個鏈表，用于處理哈希沖突。

• 轉(zhuǎn)換閾值：

• 每個字段的最大長度：hash-max-ziplist-value（默認 64 字節(jié)）

• 哈希表的最大字段數(shù)量：hash-max-ziplist-entries（默認 512 個字段）

3. List

• 用途：有序的字符串列表，可以在列表的兩端進行插入和刪除操作。
• 底層實現(xiàn)：

當列表中的元素較少時，Redis 使用壓縮列表（ziplist）來存儲數(shù)據(jù)。壓縮列表可以高效地存儲小數(shù)量的數(shù)據(jù)，并且占用更少的內(nèi)存。

當列表中的元素較多時，Redis 會將壓縮列表轉(zhuǎn)換為雙端鏈表（linked list）。雙端鏈表允許在列表的兩端進行高效的插入和刪除操作，但訪問中間元素的效率較低。

• 轉(zhuǎn)換閾值：

• 每個元素的最大長度：list-max-ziplist-value（默認 64 字節(jié)）

• 列表的最大元素數(shù)量：list-max-ziplist-entries（默認 512 個元素）

4. Set

• 用途：無序的字符串集合，不允許重復(fù)元素。
• 底層實現(xiàn)：

當集合中的元素較少時，Redis 使用整數(shù)集合（intset）來存儲數(shù)據(jù)。整數(shù)集合是一個有序的整數(shù)數(shù)組，支持快速查找和插入操作。

當集合中的元素較多時，Redis 會將整數(shù)集合轉(zhuǎn)換為字典（Dictionary）。字典提供高效的查找和插入操作，適用于大量數(shù)據(jù)的情況。

• 轉(zhuǎn)換閾值：

• 整數(shù)集合中的最大元素數(shù)量：沒有明確的配置項，但當集合中的元素不再是整數(shù)或元素數(shù)量超過一定閾值時，會自動轉(zhuǎn)換為字典。

5. Zset (Sorted Set)

• 用途：有序的字符串集合，每個元素關(guān)聯(lián)一個分數(shù)，通過分數(shù)進行排序。
• 底層實現(xiàn)：

跳躍表（skiplist）：跳躍表是一種概率數(shù)據(jù)結(jié)構(gòu)，提供高效的范圍查詢和插入操作。跳躍表通過多層索引來加速查找過程。

字典（Dictionary）：字典用于存儲成員到分數(shù)的映射，以便快速查找成員的分數(shù)。

Zset 內(nèi)部使用兩種數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)：

跳躍表和字典共同工作，確保 Zset 既能高效地進行范圍查詢，又能快速地進行成員查找。

• 轉(zhuǎn)換閾值：

• 每個成員的最大長度：zset-max-ziplist-value（默認 64 字節(jié)）

• 有序集合的最大成員數(shù)量：zset-max-ziplist-entries（默認 128 個成員）

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

一、監(jiān)控和分析內(nèi)存使用情況

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

二、調(diào)整數(shù)據(jù)存儲和過期策略

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

優(yōu)化數(shù)據(jù)結(jié)構(gòu)，避免存儲不必要的大字符串等占用大量內(nèi)存的數(shù)據(jù)結(jié)構(gòu)。

三、啟用內(nèi)存淘汰策略

選擇合適的內(nèi)存淘汰策略，如 allkeys-lru（淘汰最近最少使用的鍵）、volatile-lru（淘汰已設(shè)置過期時間且最近最少使用的鍵）等?？梢酝ㄟ^ CONFIG SET maxmemory-policy 命令來設(shè)置淘汰策略。

四、數(shù)據(jù)持久化和清理

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

根據(jù)業(yè)務(wù)需求，手動清理一些不再需要的數(shù)據(jù)，可以使用 DEL 命令刪除單個鍵。

五、擴展 Redis 實例

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

使用 Redis 集群或哨兵模式，將數(shù)據(jù)分片存儲到多個 Redis 實例中，分散內(nèi)存壓力。

kafka

如何保證kafka消息順序 （包括業(yè)務(wù)內(nèi)有序和全局有序）

要保證 Kafka 消息的業(yè)務(wù)內(nèi)有序，需確保相關(guān)業(yè)務(wù)消息被發(fā)送至同一個分區(qū)，這是因為同一分區(qū)內(nèi)的消息處理是有序的。

而實現(xiàn)全局有序，通常需嚴格限制并發(fā)度，僅使用一個分區(qū)，但這會在一定程度上降低系統(tǒng)的性能和消息的吞吐量。

在實際應(yīng)用中，要綜合考慮業(yè)務(wù)需求、性能要求和資源配置等多方面因素來權(quán)衡消息順序和系統(tǒng)效率之間的關(guān)系。

kafka的可用性怎么保證的？

可以通過多種機制來保證高可用性，確保在出現(xiàn)故障時系統(tǒng)能夠繼續(xù)正常運行：

1. 多副本：

Kafka 的每個 topic 可以劃分為多個 partition，每個 partition 可以有多個副本（replica）。這些副本分布在不同的 broker 上。

其中一個副本被選為 leader，負責處理所有的讀寫請求；其他副本是 follower，它們從 leader 復(fù)制數(shù)據(jù)。

如果 leader 副本所在的 broker 宕機，Kafka 會自動從 follower 中選舉一個新的 leader 繼續(xù)提供服務(wù)。

2. ISR：

ISR 是一組與 leader 保持同步的副本集合。只有當 follower 副本的數(shù)據(jù)與 leader 一致時，才會被加入 ISR。

Kafka 通過維護 ISR 來確保數(shù)據(jù)的一致性和可靠性。如果某個 follower 落后太多或無法與 leader 通信，它會被移出 ISR。

3. ACK 機制：

acks=0：生產(chǎn)者不等待任何確認。

acks=1：生產(chǎn)者等待 leader 副本確認。

acks=all：生產(chǎn)者等待所有 ISR 中的副本確認。

生產(chǎn)者在發(fā)送消息時可以設(shè)置 acks 參數(shù)來控制消息的確認級別：

設(shè)置 acks=all 可以確保消息被所有副本確認，從而提高數(shù)據(jù)的可靠性。

4. ZooKeeper 用于元數(shù)據(jù)管理：

Kafka 使用 ZooKeeper 來管理和協(xié)調(diào)集群中的 broker、topic 和 partition 的狀態(tài)。

ZooKeeper 監(jiān)控 broker 的狀態(tài)，并在 broker 宕機時觸發(fā) leader 選舉和重新分配。

5. 負載均衡：

Kafka 通過將 partition 分散到不同的 broker 上，實現(xiàn)負載均衡，避免單點壓力過大。

這種分散存儲的方式也提高了系統(tǒng)的整體吞吐量和可用性。

6. 配置參數(shù)：

通過調(diào)整 Kafka 的配置參數(shù)，如 replication.factor（副本數(shù)）、min.insync.replicas（最小同步副本數(shù)）等，可以進一步優(yōu)化高可用性。

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

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

1. 自動切換到備份：

每個 topic 的 partition 都有多個副本（復(fù)制的數(shù)據(jù)），其中一個副本是 leader，負責處理讀寫請求。其他副本是 follower，它們從 leader 復(fù)制數(shù)據(jù)。

如果 leader 所在的 broker 宕機了，Kafka 會自動選擇一個健康的 follower 副本作為新的 leader。這個過程對消費者是透明的，消費者可以繼續(xù)從新的 leader 讀取消息。

2. 消費者重新分配：

當 broker 宕機后，消費者的消費組會進行一次重新平衡（rebalance）。這意味著 Kafka 會重新分配 partition 給消費者，確保每個 partition 只有一個消費者在讀取。

重新平衡后，消費者可以從上次提交的位置繼續(xù)消費消息。如果消費者之前已經(jīng)提交了偏移量（offset），那么它可以從提交的位置開始繼續(xù)消費，而不會丟失或重復(fù)消息。

3. 偏移量管理：

消費者可以配置為自動提交偏移量，也就是每隔一段時間自動告訴 Kafka 已經(jīng)消費到哪個位置了。這樣即使消費者宕機，重啟后也可以從上次提交的位置繼續(xù)消費。

如果需要更精確的控制，消費者可以選擇手動提交偏移量，在處理完一條消息后再提交偏移量，這樣可以避免消息丟失或重復(fù)。

4. 客戶端自動重連：

Kafka 客戶端（比如消費者）通常會有自動重連機制。如果連接斷開了，客戶端會嘗試重新連接到 Kafka 集群。

客戶端和 broker 之間還有心跳檢測機制，如果發(fā)現(xiàn)連接中斷，客戶端會嘗試重新建立連接。

kafka重復(fù)消費問題怎么解決？

1. 冪等性處理

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

2. 事務(wù)支持

• 使用 Kafka 事務(wù)：Kafka 支持事務(wù)，可以在同一個事務(wù)中同時處理消息和提交偏移量。這樣即使在處理過程中出現(xiàn)故障，也不會導(dǎo)致重復(fù)消費。

生產(chǎn)者和消費者都可以參與事務(wù)，確保數(shù)據(jù)的一致性和完整性。

3. 手動提交偏移量

• 關(guān)閉自動提交：將 enable.auto.commit 設(shè)置為 false，然后在消息成功處理后再手動提交偏移量。

同步提交：consumer.commitSync()，這種方式會阻塞直到提交完成。

異步提交：consumer.commitAsync()，這種方式是非阻塞的，但需要處理提交失敗的情況。

4. 去重機制

• 使用外部存儲去重：利用外部存儲（如 Redis、數(shù)據(jù)庫）來記錄已經(jīng)處理過的消息 ID 或其他唯一標識符。每次處理消息前，先檢查該消息是否已經(jīng)被處理過。

這種方法適用于對消息去重有嚴格要求的場景，但會增加額外的復(fù)雜性和開銷。

5. 布隆過濾器

• 使用布隆過濾器：對于大量數(shù)據(jù)，可以使用布隆過濾器來高效地檢測消息是否已經(jīng)被處理過。布隆過濾器是一種空間效率很高的概率型數(shù)據(jù)結(jié)構(gòu)，適合用于大規(guī)模數(shù)據(jù)的去重。