快手二面準備【面試準備】
- 前言
- 版權
- 快手二面準備
- 秋招一面中的問題
- 實習一面中的問題
- 計算機網絡和操作系統
- 論壇項目登錄注冊
- ThreadLocal代替session存儲用戶
- 秒殺項目登錄注冊->阿里驗證碼->rpc
- session為什么改為token實現,redis存儲用戶信息
- 由binlog的用法->緩存和數據庫的一致性
- 3種緩存更新策略是怎樣的?
- ES搜索->Mysql全文索引
- MySQL8的索引新特性
- redis的高級數據結構
- 代理模式->設計模式
- 為什么使用mq
- mq
- es的構成
- 倒排索引的理解:
- mq的消息類型
- 緩存相關的問題
- kafka的角色
- rocketmq的角色
- 最后
前言
2023-8-1 17:33:53
公開發布于
2024-5-21 13:07:32
以下內容源自《【面試準備】》
僅供學習交流使用
版權
禁止其他平臺發布時刪除以下此話
本文首次發布于CSDN平臺
作者是CSDN@日星月云
博客主頁是https://blog.csdn.net/qq_51625007
禁止其他平臺發布時刪除以上此話
快手二面準備
秋招一面中的問題
rpc
遠程過程調用
kafka為啥會丟消息
rocketmq怎么保證不丟消息
RocketMQ通過以下幾種機制來保證消息不丟失:消息持久化:RocketMQ將消息寫入磁盤中進行持久化存儲,即使在發生系統故障或重啟時,消息也能夠被恢復。內存雙寫:RocketMQ在將消息持久化到磁盤之前,先將消息寫入內存中的PageCache中。這種方式可以提高寫入速度,并且在發生宕機時,可以通過從磁盤中加載消息來進行快速恢復。同步刷盤:RocketMQ提供了同步刷盤機制,即在消息寫入磁盤之前,會等待消息被寫入磁盤后才返回發送成功的響應。這樣可以確保消息被持久化到磁盤中,避免消息丟失。主從同步:RocketMQ支持主從模式,即一個主節點和多個從節點。主節點負責將消息發送給消費者,從節點負責備份主節點的消息。當主節點宕機時,可以通過從節點快速切換來提供高可用性,并避免消息丟失。高可靠性隊列:RocketMQ提供了高可靠性的隊列機制,確保消息的可靠傳輸。通過設置消息的發送模式為同步模式,發送方在消息發送完成之前會等待Broker的確認響應,確保消息可靠傳輸。消息重試機制:RocketMQ提供了消息重試機制,當消息發送失敗時,會自動進行重試。可以通過設置重試次數和重試間隔來控制重試的策略,確保消息最終被正確處理。綜上所述,RocketMQ通過持久化、內存雙寫、同步刷盤、主從同步、高可靠性隊列和消息重試機制等多種機制來保證消息不丟失。開發人員也可以根據自己的需求和業務場景,選擇適當的配置和策略來保證消息的可靠性。
Rocketmq中Broker的刷盤策略有哪些?同步刷盤
SYNC_FLUSH(同步刷盤):生產者發送的每一條消息都在保存到磁盤成功后才返回告訴生產者成功。這種方式不會存在消息丟失的問題,但是有很大的磁盤IO開銷,性能有一定影響。
異步刷盤
ASYNC_FLUSH(異步刷盤):生產者發送的每一條消息并不是立即保存到磁盤,而是暫時緩存起來,然后就返回生產者成功。隨后再異步的將緩存數據保存到磁盤,有兩種情況:1是定期將緩存中更新的數據進行刷盤,2是當緩存中更新的數據條數達到某一設定值后進行刷盤。這種異步的方式會存在消息丟失(在還未來得及同步到磁盤的時候宕機),但是性能很好。默認是這種模式。
秒殺為什么選擇rocketmq
rocketmq支持發布事務性消息
實習一面中的問題
es與數據庫之間的同步
使用的是kafka來實現的redis是在刷新帖子分數時
點贊評論之后,記錄需要刷新的帖子id
供Quartz定時計算帖子分數,然后刷新到數據庫
動態代理
基于接口的代理:jdk
基于類的代理:cglib
了解過監聽binlog嗎
計算機網絡和操作系統
http
https
tcp和upd
dns
論壇項目登錄注冊
一個問題,驗證郵箱丟失問題
提供重新發送激活郵箱的服務
ThreadLocal代替session存儲用戶
攔截器
@preHandle
獲取登錄憑證@postHandle
前端添加loginUser@afterCompletion
清除HostHold
四種對象引用
本地線程存儲
內存泄漏問題
秒殺項目登錄注冊->阿里驗證碼->rpc
原來驗證碼輸出到控制臺里
session為什么改為token實現,redis存儲用戶信息
由binlog的用法->緩存和數據庫的一致性
數據庫和緩存如何保證一致性?
它的用法:
主從復制
數據庫恢復
還有一個,訂閱binlog解決緩存和數據庫的一致性
緩存和數據庫一致性:
先更新數據庫,后刪除緩存。
可能還會有問題
延遲雙刪
但是更新數據庫和刪除緩存是兩個操作
萬一刪除失敗了,怎么辦?
- 重試,消息隊列
- 訂閱binlog
3種緩存更新策略是怎樣的?
面試官:3種緩存更新策略是怎樣的?
Cache Aside(旁路緩存)策略是最常用的,應用程序直接與「數據庫、緩存」交互,并負責對緩存的維護,該策略又可以細分為「讀策略」和「寫策略」。
Read/Write Through(讀穿 / 寫穿)策略原則是應用程序只和緩存交互,不再和數據庫交互,而是由緩存和數據庫交互,相當于更新數據庫的操作由緩存自己代理了。
下面是 Read Through/Write Through 策略的示意圖:
Write Back(寫回)策略在更新數據的時候,只更新緩存,同時將緩存數據設置為臟的,然后立馬返回,并不會更新數據庫。對于數據庫的更新,會通過批量異步更新的方式進行。
實際上,Write Back(寫回)策略也不能應用到我們常用的數據庫和緩存的場景中,因為 Redis 并沒有異步更新數據庫的功能。
ES搜索->Mysql全文索引
MySQL全文檢索臨時代替ES實現快速搜索
模糊查詢:like '%關鍵詞'
MySQL 中使用全局變量ngram_token_size來配置ngram中n的大小,它的取值范圍是1到10,默認值是2。通常ngram_token_size設置為要查詢的單詞的最小字數。如果需要搜索單字,就要把ngram_token_size設置為1。在默認值是2的情況下,搜索單字是得不到任何結果的。因為中文單詞最少是兩個漢字,推薦使用默認值2。
CREATE FULLTEXT INDEX idx_名 ON 表(字段) WITH PARSER ngram;
select - from -
where MATCH (columnName) AGAINST ('keywords')
MySQL8的索引新特性
降序索引
隱藏索引
redis的高級數據結構
攔截器:記錄uv,dau訪問過一次判斷其為活躍
hyperLogLog
統計uv
key:uv_日期
value:ip
add()
指定日期范圍統計union()之后再size返回
bitmap
統計dau
key:dau_日期
value:userId
setBit()
統計指定日期范圍內的DAU OR運算 bitCount()
代理模式->設計模式
單例模式
工廠模式
為什么使用mq
解耦 異步 削峰
比如:論壇項目中的,關注,點贊或評論帖子,做系統通知
如果寫出一個方法的話,還需要保證事務,設置事務的傳播行為
但是別人點贊了,和你收到系統通知,其實是兩個業務
別人點贊了,系統通知的業務執行失敗,你也不能回滾
這兩個操作也是異步的
削峰,秒殺項目的
mq
【消息隊列】五個問題詳解消息中間件
【RocketMQ】原理分析:消息存儲機制
【RocketMQ】消息可靠性保證
【Kafka】原理分析:消息的文件存儲機制
【Kafka】消息可靠性保證
同步刷盤
es的構成
Elasticsearch由以下幾個主要組件構成:
-
節點(Nodes):節點是Elasticsearch的基本組成單位,每個節點代表一個運行的實例。一個Elasticsearch集群可以由多個節點組成,每個節點都有自己的名稱和唯一的ID。節點之間可以通過集群通信進行相互發現、數據同步和協作。
-
索引(Indexes):索引是一種用于組織和存儲數據的邏輯容器。它類似于數據庫中的表,可以包含多個文檔(documents)。每個索引都具有唯一的名稱,用于標識它所包含的數據類型或內容。
-
類型(Types):在早期版本的Elasticsearch(5.x及以前的版本),索引可以包含多個類型。類型是索引中的一個邏輯類別,用于區分不同類型的文檔。然而,在5.x以后的版本中,Elasticsearch不再推薦使用多個類型,建議將不同類型的數據拆分為獨立的索引。
-
文檔(Documents):文檔是Elasticsearch中的基本數據單元。它可以是任意結構的JSON對象,類似于數據庫中的記錄。每個文檔都有一個唯一的ID,用于標識它在索引中的位置。文檔可以被索引、搜索和修改。
-
分片和副本(Shards and Replicas):為了實現高可用性和擴展性,Elasticsearch將索引分割成多個分片(shards),每個分片可以在集群中的不同節點上進行分布。分片允許索引數據被并行處理和存儲。為了提高數據的冗余性和可靠性,每個分片可以有多個副本(replicas),副本是分片的精確拷貝。
以上是Elasticsearch的基本構成,它們一起工作來提供高效的分布式搜索和分析功能。
倒排索引的理解:
倒排索引(Inverted Index)是一種用于快速定位文檔的索引結構。在倒排索引中,每個關鍵詞都維護了一個包含包含該關鍵詞的文檔列表。通過倒排索引,可以快速地找到包含特定關鍵詞的文檔,而無需遍歷所有文檔。
倒排索引的構建過程包括以下幾個步驟:
文檔分詞:將每個文檔拆分為一個個的詞語(或稱為術語,terms),這通常是通過分詞器(tokenizer)來實現的。分詞器可以根據各種規則和算法將文本切分為合適的詞語。
構建倒排索引:對于每個詞語,將它出現的文檔ID記錄到倒排索引中。倒排索引的數據結構通常是一個關聯數組(Associative Array),其中詞語作為鍵,文檔ID的列表作為值。
優化倒排索引:為了提高查詢性能和減少索引的大小,通常還會對倒排索引進行優化。例如,可以使用壓縮算法對文檔ID列表進行壓縮,或者使用數據結構如跳表(Skip List)來加速查找過程。
通過倒排索引,可以在搜索時快速定位包含特定關鍵詞的文檔。比如,當用戶在搜索引擎中輸入一個關鍵詞時,搜索引擎可以通過倒排索引找到包含該關鍵詞的文檔,并返回給用戶相關的搜索結果。倒排索引是大部分搜索引擎(包括Elasticsearch)的核心組成部分,它能夠提供快速、靈活和準確的搜索功能。
mq的消息類型
緩存相關的問題
緩存和數據庫的一致性
先更新數據庫再刪除緩存
庫存的一致性是mq實現事務消息
緩存穿透
場景:
場景查詢根本不存在的數據,使得請求直達存儲層
導致其負載過大,甚至宕機。
解決方案:
1.緩存空對象存儲層未命中后,仍然將空值存入緩存層。再次訪問該數據時,緩存層會直接返回空值。
2.布隆過濾器將所有存在的key提前存入布隆過濾器,在訪問緩存層之前,先通過過濾器攔截,若請求的是不存在的key,則直接返回空值。
緩存擊穿
場景:
一份熱點數據,它的訪問量非常大。在其緩存失效瞬間,大量請求直達存儲層,導致服務崩潰。
解決方案:
1.加互斥鎖對數據的訪問加互斥鎖,當一個線程訪問該數據時,其他線程只能等待。這個線程訪問過后,緩存中的數據將被重建,屆時其他線程就可以直接從緩存取值。
2.永不過期不設置過期時間,所以不會出現上述問題,這是“物理”上的不過期。為每個value設置邏輯過期時間,當發現該值邏輯過期時,使用單獨的線程重建緩存。
緩存雪崩
場景:
由于某些原因,緩存層不能提供服務,導致所有的請求直達存儲層,造成存儲層宕機。
解決方案:
1.避免同時過期設置過期時間時,附加一個隨機數,避免大量的key同時過期。
2.構建高可用的Redis緩存部署多個Redis實例,個別節點宕機,依然可以保持服務的整體可用。
3.構建多級緩存增加本地緩存,在存儲層前面多加一級屏障,降低請求直達存儲層的幾率。
4.啟用限流和降級措施對存儲層增加限流措施,當請求超出限制時,對其提供降級服務。
kafka的角色
Kafka的角色包括以下幾個:
- 生產者(Producer):負責將消息發送到Kafka集群,并且可以選擇將消息發送到特定的主題(Topic)。
- 消費者(Consumer):從Kafka集群中讀取消息,并且可以選擇訂閱一個或多個主題。
- 主題(Topic):是消息的邏輯容器,可以理解為消息的分類或者主題。
- 分區(Partition):每個主題可以被分為一個或多個分區,每個分區對應一個日志文件。
- 消費者組(Consumer Group):消費者可以組成一個或多個消費者組,每個組可以訂閱一個或多個主題。
- Kafka集群(Kafka Cluster):由多個Kafka實例組成的集群,用于存儲和處理消息。
- Broker:Kafka集群中的每個節點就是一個Broker,負責存儲和處理消息。
- ZooKeeper:Kafka使用ZooKeeper來管理集群的元數據,包括主題、分區等信息。
- 消息(Message):Kafka中的基本單位,由鍵(Key)和值(Value)組成。
- 日志(Log):Kafka使用日志文件來存儲消息,每個分區對應一個日志文件。
以上是Kafka的主要角色,每個角色在Kafka中都扮演著不同的角色和功能。
rocketmq的角色
RocketMQ的角色包括以下幾個:
- 生產者(Producer):負責將消息發送到RocketMQ集群,并且可以選擇將消息發送到特定的主題(Topic)。
- 消費者(Consumer):從RocketMQ集群中讀取消息,并且可以選擇訂閱一個或多個主題。
- 主題(Topic):是消息的邏輯容器,可以理解為消息的分類或者主題。
消費者組(Consumer Group):消費者可以組成一個或多個消費者組,每個組可以訂閱一個或多個主題。 - Broker:RocketMQ集群中的每個節點就是一個Broker,負責存儲和處理消息。
- 消息(Message):RocketMQ中的基本單位,由鍵(Key)和值(Value)組成。
- 消息隊列(Message Queue):每個主題可以被分為一個或多個消息隊列,每個消息隊列對應一個消費者線程。
- 消息存儲(Message Store):RocketMQ使用消息存儲來存儲消息,包括內存存儲和磁盤存儲。
- NameServer:RocketMQ使用NameServer來管理集群的元數據,包括主題、消費者組等信息。
- 消息消費進度(Offset):RocketMQ可以跟蹤每個消費者組在每個主題的消費進度,以確保消息的順序性和可靠性。
以上是RocketMQ的主要角色,每個角色在RocketMQ中都扮演著不同的角色和功能。
最后
2023-8-1 21:18:19
我們都有光明的未來
祝大家考研上岸
祝大家工作順利
祝大家得償所愿
祝大家如愿以償
點贊收藏關注哦