1 設(shè)計一個系統(tǒng)統(tǒng)計當前時刻北京用戶在線人數(shù)

【Redis】位圖以及位圖的使用場景(統(tǒng)計在線人數(shù)和用戶在線狀態(tài))

1.1 方案一：

• 在用戶登錄時，使用 Redis SET 將用戶 ID 添加到一個特定的鍵（例如 “online:beijing”）。
• 用戶退出時，從 SET 中移除用戶 ID。
• 為了統(tǒng)計在線人數(shù)，直接獲取 SET 的元素數(shù)量。

1.2 方案二：為什么不能用一個 count 字段

如果使用單一的 count 字段，當多個進程或線程同時更新該字段時，可能會出現(xiàn)競爭條件，導(dǎo)致不準確的計數(shù)。此外，你無法知道哪些用戶是在線的。

1.3 方案三：方案一在計數(shù)方面不方便，所以我是不是可以把這兩個方案結(jié)合起來，要查總在線人數(shù)的時候使用count字段一次性查出，想要看哪些活躍的人數(shù)的時候就按照方案一查（其實redis的set集合中應(yīng)該也提供了計算元素數(shù)量的api）

確實，你可以將兩個方案結(jié)合起來以便根據(jù)不同的需求靈活地查詢。

結(jié)合方案：

1. 處理登錄：

   • 當用戶登錄時，執(zhí)行以下操作：
     1. 使用 Redis SET 將用戶 ID 添加到一個特定的鍵（例如 “online:beijing”）。
     2. 使用 Redis 的 INCR 命令增加一個 “online:count:beijing” 字段的值。

2. 處理退出：

   • 當用戶退出時，執(zhí)行以下操作：
     1. 從 SET “online:beijing” 中移除用戶 ID。
     2. 使用 Redis 的 DECR 命令減少 “online:count:beijing” 字段的值。

3. 查詢在線人數(shù)：

   • 直接獲取 “online:count:beijing” 字段的值。

4. 查詢在線的具體用戶：

   • 直接獲取 SET “online:beijing” 的所有成員。

這種方法結(jié)合了兩種方案的優(yōu)點：INCR 和 DECR 命令都是原子的，這意味著即使有多個進程或線程同時操作，“online:count:beijing” 的值也會被準確地更新。而 SET “online:beijing” 則提供了查詢特定在線用戶的能力。

需要注意的是，這種方法會稍微增加存儲和操作的開銷，因為每次登錄或退出都需要操作兩個 Redis 鍵。但從實用性和靈活性的角度來看，這是一個很好的折中方案。

1.4 方案四：使用bitMap

前幾個方案的缺點：如果使用set，會存儲每一個用戶的id，在1億用戶量的情況下，每一個用戶id占用4B，總的內(nèi)存使用量就是10^9*4B=4GB，內(nèi)存會撐爆

答：所以這個時候會使用位圖，將每一個在線用戶放入到一個編碼函數(shù)生成一串數(shù)字，根據(jù)對應(yīng)的數(shù)字將其在bitMap中對應(yīng)位置的值置為1，用戶下線時就將對應(yīng)位置的值置換為0，此時內(nèi)存使用量為100000000/8b/1024B/1024MB 約等于 12MB；

本方案不足：當需要查找在線人數(shù)的時候，就是用bitcount()獲取，但是這個方法會遍歷bitMap，復(fù)雜度是O(n)的

1.5 方案五：使用bitMap+count字段

新設(shè)置一個count字段，用于統(tǒng)計在線人數(shù)，然后每次上線一個用戶，就使用原子化操作將bitMap和count自增操作打包在一起更新。這樣在查詢總?cè)藬?shù)的時間復(fù)雜度也是O(1)

2 讓你設(shè)計一個mysql優(yōu)化器，怎么設(shè)計

2.1 收集統(tǒng)計信息：

掃描數(shù)據(jù)表和索引來估計行數(shù)、數(shù)據(jù)分布和存儲大小。
**定期更新這些統(tǒng)計信息，**以保持查詢優(yōu)化器的信息是最新的。

2.2 SQL 重寫：

解析輸入的 SQL 查詢并形成一個初始的執(zhí)行計劃。
對計劃進行轉(zhuǎn)化，例如合并相鄰的表掃描，簡化 WHERE 子句等。

2.3 索引建議：

分析查詢以確定哪些列經(jīng)常被用作過濾條件。
基于這些信息提供索引創(chuàng)建的建議，以加速查詢。

2.4 緩存：

為經(jīng)常運行的查詢結(jié)果提供緩存，避免重復(fù)的計算。
考慮緩存的失效策略，如 LRU。

2.5 分析查詢：

對查詢的執(zhí)行計劃進行深入的分析，找出可能的性能瓶頸。
提供關(guān)于查詢?nèi)绾涡薷幕蛑貙懸愿纳菩阅艿慕ㄗh。

3 讓你設(shè)計一個延時任務(wù)系統(tǒng)怎么做？

3.1 Redis ZSET

（1）使用 Redis ZSET，score作為時間戳，任務(wù)id作為哈希表的key:
（2）分片: 為了抗高并發(fā)，可以將數(shù)據(jù)分散到多個 Redis 實例中，使用一致性哈?；蚱渌制惴?。
（3）持久化: 利用 Redis 的 RDB 或 AOF 功能，確保數(shù)據(jù)不丟失。
（4）哨兵模式: 用于故障轉(zhuǎn)移，當主節(jié)點出現(xiàn)問題時，哨兵可以自動將從節(jié)點提升為主節(jié)點。

3.2 時間片輪轉(zhuǎn)算法

時間輪是一個非常高效的延時任務(wù)調(diào)度方法，其基本概念是將時間分成多個小的時間片段，并使用一個循環(huán)隊列（輪子）來表示。每個槽代表一個時間片段。時間輪持續(xù)地旋轉(zhuǎn)，當時間推進到某個槽時，會執(zhí)行該槽中的所有任務(wù)。

• 初始化: 創(chuàng)建一個固定大小的時間輪，每個槽都有一個任務(wù)隊列。
• 添加任務(wù): 根據(jù)任務(wù)的延時時間，計算應(yīng)該放入哪個槽。將任務(wù)放入相應(yīng)槽的任務(wù)隊列中。
• 時間推進: 定期（例如每秒）檢查當前槽，執(zhí)行所有任務(wù)，然后移動到下一個槽。
• 槽溢出處理: 對于超過時間輪大小的延時，可以使用多層時間輪來處理。

4 Redis 的 ZSET 做排行榜時，如果要實現(xiàn)分數(shù)相同時按時間順序排序怎么實現(xiàn)？

4.1 方案一：拆分 score:

即將 score 拆分為高 32 位和低 32 位,高32位存儲時間戳，低32位存儲score

4.2 方案二：使用 ZSET

使用 ZSET 存儲分數(shù)，再使用一個 HASH 表存儲每個用戶的時間戳。在獲取排行榜時，首先按分數(shù)排序，分數(shù)相同的則根據(jù) HASH 表中的時間戳排序。

5 redis實現(xiàn)好友關(guān)系、粉絲數(shù)

5.1 好友關(guān)系(使用一個set存儲我關(guān)注的人)

• 對于每個用戶，使用一個 SET 來存儲他的所有好友的 ID。
• 添加好友：在兩個用戶的 SET 中互相添加對方的 ID。
• 刪除好友：在兩個用戶的 SET 中互相移除對方的 ID。
• 檢查是否為好友：查詢其中一個用戶的 SET 是否包含另一個用戶的 ID。
• 獲取好友列表：直接獲取用戶的 SET 中的所有元素。
• 共同好友：將兩個用戶的set都查出來，取得交集

5.2 粉絲數(shù)

再設(shè)置一個set，存儲關(guān)注我的人，別人關(guān)注我就需要同時在兩個set上put新值

6 給一個場景：有很多圖片，然后我們需要對圖片進行存儲，以及查找，有什么數(shù)據(jù)結(jié)構(gòu)比較適合？如果我要加速查詢的速率，你要怎么設(shè)計？

6.1 方案一

處理大量圖片的存儲和檢索通常涉及多個層次的設(shè)計。以下是針對這一場景的一些建議：

1. 存儲：

   • 分布式文件系統(tǒng)：例如 Hadoop Distributed FileSystem (HDFS) 或 Facebook 的 Haystack，它們專為存儲大量文件而設(shè)計。
   • 對象存儲：例如 Amazon S3，它可以存儲和檢索任意數(shù)量的數(shù)據(jù)。

2. 為圖片建立索引：

   當你只知道圖片的元數(shù)據(jù)（例如上傳者、時間、標簽等）并希望基于這些數(shù)據(jù)檢索圖片時：

   • 使用關(guān)系數(shù)據(jù)庫或NoSQL數(shù)據(jù)庫來存儲圖片的元數(shù)據(jù)和其在分布式文件系統(tǒng)或?qū)ο蟠鎯χ械奈恢谩?/li>

   當你希望基于圖片內(nèi)容本身進行檢索（例如查找與給定圖片相似的圖片）時：

   • 使用特征提取技術(shù)從每張圖片中提取特征，并使用這些特征為圖片建立索引。
   • 一種常見的方法是使用哈希函數(shù)將圖片特征轉(zhuǎn)化為“圖像哈希”，并將這些哈希值存儲在數(shù)據(jù)庫中。

3. 加速查詢：

   • 緩存：對于經(jīng)常被查詢的圖片，可以使用像 Redis 這樣的內(nèi)存數(shù)據(jù)庫進行緩存，以減少對主存儲的訪問。
   • 數(shù)據(jù)庫索引：確保數(shù)據(jù)庫表中用于查詢的字段都已經(jīng)建立了索引。
   • 減少數(shù)據(jù)量：通過數(shù)據(jù)分片或選擇性地只查詢某些數(shù)據(jù)，可以加速查詢速度。
   • 內(nèi)容檢索優(yōu)化：對于基于內(nèi)容的檢索，可以使用近似最近鄰搜索（ANNS）庫，如 FAISS，以加速相似度搜索。

4. 其他加速技術(shù)：

   • CDN：使用內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）可以將圖片緩存到全球各地，從而加速對圖片的訪問速度。
   • 預(yù)加載技術(shù)：根據(jù)用戶的使用模式和行為，預(yù)先加載他們可能會訪問的圖片。
   • 圖片壓縮：通過減少圖片的大小，可以加速加載速度和減少存儲需求。

5. 搜索擴展性：

   如果搜索請求量非常大，可以考慮使用分布式搜索引擎，如 Elasticsearch 或 Solr，它們提供了分布式搜索能力，易于擴展，并支持復(fù)雜的查詢。

總之，選擇哪種方法取決于具體的使用場景，例如查詢的頻率、數(shù)據(jù)量、預(yù)算等。

方案二

是的，使用云存儲來存放圖片是現(xiàn)代應(yīng)用中的常見做法，尤其是當應(yīng)用需要可擴展的存儲和全球分布時。以下是這種方法的詳細步驟：

1. 上傳到云存儲：

   • 用戶或應(yīng)用將圖片上傳到云存儲服務(wù)，如 Amazon S3、Google Cloud Storage 或 Azure Blob Storage。
   • 這些服務(wù)通常會為每個上傳的文件提供一個唯一的URL。

2. 存儲URL：

   • 上傳成功后，將從云服務(wù)獲得的URL存儲在本地數(shù)據(jù)庫中。這個數(shù)據(jù)庫可以是關(guān)系型數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫等。
   • 可以存儲與圖片相關(guān)的其他元數(shù)據(jù)，如上傳日期、標簽和描述等。

3. 查詢與檢索：

   • 當用戶或應(yīng)用需要查詢圖片時，你可以查詢本地數(shù)據(jù)庫并返回相關(guān)的URL。
   • 用戶或應(yīng)用可以直接使用這些URL從云存儲服務(wù)下載圖片。

4. 加速查詢：

   • 數(shù)據(jù)庫緩存：像 Redis 這樣的內(nèi)存數(shù)據(jù)庫可以用來緩存熱門的圖片URL。
   • CDN：考慮使用內(nèi)容分發(fā)網(wǎng)絡(luò)服務(wù)，這樣熱門的圖片可以緩存在全球各地的邊緣位置，從而減少加載時間。

5. 安全與權(quán)限：

   • 云存儲服務(wù)通常提供詳細的權(quán)限和安全設(shè)置。確保只有授權(quán)的用戶可以上傳或訪問圖片。
   • 如果需要，可以為URL設(shè)置過期時間，這樣它們在某段時間后就不能再訪問了。

這種設(shè)計方案不僅可以擴展存儲，還可以通過利用云服務(wù)的全球網(wǎng)絡(luò)來提高訪問速度，同時，通過將存儲與處理解耦，還可以簡化應(yīng)用的架構(gòu)和維護。

7 講解了我怎么設(shè)計負載均衡算法的，以及每種策略的適用場景

負載均衡的目的是將網(wǎng)絡(luò)流量分散到多個服務(wù)器，以確保每個服務(wù)器都不會因超載而宕機，并且可以最大化吞吐量、最小化響應(yīng)時間并避免任何單一點的故障。以下是一些常用的負載均衡策略，以及各自的適用場景：

1. 輪詢 (Round Robin)

   • 策略：這是最簡單的負載均衡算法，請求按順序分配到服務(wù)器。如果服務(wù)器列表到達末尾，則重新開始。
   • 適用場景：當所有服務(wù)器都具有相似的規(guī)格并且預(yù)期的請求處理時間相似時，輪詢是一個好選擇。

2. 加權(quán)輪詢 (Weighted Round Robin)

   • 策略：與輪詢相似，但給每個服務(wù)器一個權(quán)重，權(quán)重較高的服務(wù)器會接收到更多的請求。
   • 適用場景：當你有不同能力的服務(wù)器并希望每臺服務(wù)器都接收到與其能力相稱的流量時。

3. 最少連接 (Least Connections)

   • 策略：將請求路由到連接數(shù)最少的服務(wù)器。
   • 適用場景：適用于服務(wù)器處理速度大致相同，但處理請求的時間可以變化的場景。例如，如果有一個長輪詢或Websockets服務(wù)。

4. 加權(quán)最少連接 (Weighted Least Connections)

   • 策略：與最少連接類似，但考慮到每個服務(wù)器的權(quán)重。
   • 適用場景：當服務(wù)器規(guī)格和處理速度不同時，且處理請求的時間可變。

5. IP哈希 (IP Hash)

   • 策略：基于請求者的IP地址確定應(yīng)該路由到哪個服務(wù)器。通常是通過取IP的哈希值然后對服務(wù)器數(shù)取模得到的。
   • 適用場景：當你希望來自特定IP的客戶端始終連接到同一個服務(wù)器，這在需要保持會話或某些級聯(lián)數(shù)據(jù)緩存時非常有用。

6. URL哈希 (URL Hash)

   • 策略：基于請求URL的哈希值來確定路由到哪個服務(wù)器。
   • 適用場景：特別適用于HTTP緩存服務(wù)器，因為請求的相同URL可以確保路由到包含其緩存的同一服務(wù)器。

7. 最短延遲 (Least Latency)

   • 策略：負載均衡器持續(xù)檢測每臺服務(wù)器的延遲或響應(yīng)時間，并將請求路由到響應(yīng)最快的服務(wù)器。
   • 適用場景：對于需要實時或快速響應(yīng)的應(yīng)用，如在線游戲或語音通信。

8. 健康檢查

   • 策略：定期檢查服務(wù)器的健康狀況，如果服務(wù)器未響應(yīng)或返回錯誤，它將從活動服務(wù)器池中移除，直至再次被確定為健康。
   • 適用場景：適用于任何需要高可用性的應(yīng)用。

根據(jù)你的應(yīng)用類型、服務(wù)器規(guī)格和預(yù)期的流量模式選擇合適的策略是關(guān)鍵。很多現(xiàn)代的負載均衡器都支持這些策略，并允許你基于實時流量模式動態(tài)地切換策略。

8 注冊中心能否處理容災(zāi)情況，這里的災(zāi)是指哪些

注冊中心是微服務(wù)架構(gòu)中的一個核心組件，它負責為服務(wù)提供發(fā)現(xiàn)和配置功能。如果注冊中心發(fā)生故障，可能會對整個系統(tǒng)的正常運行產(chǎn)生巨大影響。因此，確保其高可用性和對各種“災(zāi)難”情況的容錯能力是至關(guān)重要的。

以下是一些可能影響注冊中心的“災(zāi)難”情況：

1. 硬件故障：如服務(wù)器、存儲或網(wǎng)絡(luò)設(shè)備的物理故障。
2. 軟件故障：軟件缺陷、資源耗盡（例如內(nèi)存溢出）、不正確的配置等。
3. 網(wǎng)絡(luò)問題：網(wǎng)絡(luò)分區(qū)、延遲、抖動或連接中斷等。
4. 數(shù)據(jù)中心故障：如火災(zāi)、洪水、電力中斷或其他自然災(zāi)害。
5. 安全事件：如DDoS攻擊、惡意軟件感染、未經(jīng)授權(quán)的訪問或數(shù)據(jù)泄露。
6. 人為錯誤：如誤刪除數(shù)據(jù)、誤配置或發(fā)布有缺陷的代碼。

為了處理這些容災(zāi)情況，可以采取以下策略：

1. 多實例部署：在不同的物理服務(wù)器上運行多個注冊中心的實例，確保一個實例故障時，其他實例可以繼續(xù)提供服務(wù)。
2. 跨區(qū)域部署：在地理位置分散的多個數(shù)據(jù)中心部署注冊中心的實例，確保某一地區(qū)的災(zāi)難不會影響整體系統(tǒng)。
3. 數(shù)據(jù)持久化：定期將注冊中心的數(shù)據(jù)（例如服務(wù)列表、配置數(shù)據(jù)等）備份到持久存儲，以便在故障發(fā)生時進行恢復(fù)。
4. 網(wǎng)絡(luò)冗余：確保有多條網(wǎng)絡(luò)路徑可供使用，以避免單點故障。
5. 安全策略：實施防火墻、入侵檢測系統(tǒng)、流量限制和其他安全措施，以防止惡意攻擊。
6. 監(jiān)控和報警：持續(xù)監(jiān)控注冊中心的健康狀況，并在檢測到故障時立即發(fā)出報警。
7. 故障轉(zhuǎn)移和恢復(fù)：當檢測到故障時，自動將流量切換到健康的注冊中心實例，并啟動恢復(fù)過程。

具體的容災(zāi)策略會根據(jù)所使用的注冊中心軟件（如Eureka、Consul、Zookeeper等）和組織的需求有所不同。總之，設(shè)計一個高可用和容錯的注冊中心是確保微服務(wù)系統(tǒng)穩(wěn)定運行的關(guān)鍵。