1 設計一個系統(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)競爭條件，導致不準確的計數(shù)。此外，你無法知道哪些用戶是在線的。

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

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

結合方案：

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” 的所有成員。

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

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

1.4 方案四：使用bitMap

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

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

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

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

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

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

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

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

2.2 SQL 重寫：

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

2.3 索引建議：

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

2.4 緩存：

為經常運行的查詢結果提供緩存，避免重復的計算。
考慮緩存的失效策略，如 LRU。

2.5 分析查詢：

對查詢的執(zhí)行計劃進行深入的分析，找出可能的性能瓶頸。
提供關于查詢如何修改或重寫以改善性能的建議。

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

3.1 Redis ZSET

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

3.2 時間片輪轉算法

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

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

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ù)相同的則根據 HASH 表中的時間戳排序。

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

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

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

5.2 粉絲數(shù)

再設置一個set，存儲關注我的人，別人關注我就需要同時在兩個set上put新值

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

6.1 方案一

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

1. 存儲：

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

2. 為圖片建立索引：

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

   • 使用關系數(shù)據庫或NoSQL數(shù)據庫來存儲圖片的元數(shù)據和其在分布式文件系統(tǒng)或對象存儲中的位置。

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

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

3. 加速查詢：

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

4. 其他加速技術：

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

5. 搜索擴展性：

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

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

方案二

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

1. 上傳到云存儲：

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

2. 存儲URL：

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

3. 查詢與檢索：

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

4. 加速查詢：

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

5. 安全與權限：

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

這種設計方案不僅可以擴展存儲，還可以通過利用云服務的全球網絡來提高訪問速度，同時，通過將存儲與處理解耦，還可以簡化應用的架構和維護。

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

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

1. 輪詢 (Round Robin)

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

2. 加權輪詢 (Weighted Round Robin)

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

3. 最少連接 (Least Connections)

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

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

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

5. IP哈希 (IP Hash)

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

6. URL哈希 (URL Hash)

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

7. 最短延遲 (Least Latency)

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

8. 健康檢查

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

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

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

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

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

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

為了處理這些容災情況，可以采取以下策略：

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

具體的容災策略會根據所使用的注冊中心軟件（如Eureka、Consul、Zookeeper等）和組織的需求有所不同?？傊?#xff0c;設計一個高可用和容錯的注冊中心是確保微服務系統(tǒng)穩(wěn)定運行的關鍵。