最全技術面試180題:阿里11面試+網(wǎng)易+百度+美團!

網(wǎng)絡編程

ISO模型與協(xié)議

http1.0:需要使用keep-alive參數(shù)來告知服務器端要建立一個長連接

http1.1:默認長連接钉跷。支持只發(fā)送header信息该编,可以用作權限請求。支持Host域认境。

http2.0:多路復用的技術胚委,做到同一個連接并發(fā)處理多個請求。HTTP2.0使用HPACK算法對header的數(shù)據(jù)進行壓縮叉信。支持HTTP2.0的web server請求數(shù)據(jù)的時候庞萍,服務器會順便把一些客戶端需要的資源一起推送到客戶端燎悍,免得客戶端再次創(chuàng)建連接發(fā)送請求到服務器端獲取。這種方式非常合適加載靜態(tài)資源。

會話層:負責管理主機之間的會話進程裙盾,負責建立伙窃、管理择膝、終止進程之間的會話奢米。

傳輸層:將上層數(shù)據(jù)分段并提供端到端的、可靠的或不可靠的傳輸讶迁,還要處理端到端的差錯控制和流量控制問題连茧。協(xié)議TCP、UDP巍糯、SPX

網(wǎng)絡層:對子網(wǎng)間的數(shù)據(jù)包進行路由選擇啸驯。此外,網(wǎng)絡層還可以實現(xiàn)擁塞控制祟峦、網(wǎng)際互連等功能罚斗。協(xié)議IP、IPX宅楞、RIP针姿、OSPF

數(shù)據(jù)鏈路層:在不可靠的物理介質上提供可靠的傳輸袱吆。該層的作用包括:物理地址尋址、數(shù)據(jù)的成幀距淫、流量控制绞绒、數(shù)據(jù)的檢錯、重發(fā)等榕暇。協(xié)議SDLC蓬衡、HDLC、PPP彤枢、STP狰晚、幀中繼

TCPIP模型與協(xié)議

應用層:單位是數(shù)據(jù)段,協(xié)議有FTP堂污、TELNET家肯、HTTP龄砰、SMTP盟猖、SNMP、TFTP换棚、NTP式镐、DNS

運輸層:單位是數(shù)據(jù)包,協(xié)議有TCP固蚤、UDP

網(wǎng)絡層:單位是數(shù)據(jù)幀娘汞,協(xié)議有IP

網(wǎng)絡接口層:單位是比特,ARP夕玩、RARP

三次握手與四次揮手

BIO NIO AIO

BIO:同步阻塞IO你弦,每個請求都要一個線程來處理。

NIO:同步非阻塞IO燎孟,一個線程可以處理多個請求禽作,適用于短連接、小數(shù)據(jù)揩页。

AIO:異步非阻塞IO旷偿,一個線程處理多個請求,使用回調函數(shù)實現(xiàn)爆侣,適用于長連接萍程、大數(shù)據(jù)。

DDOS攻擊原理與防御方式

HTTP Get Flood:發(fā)送大量會產生sql查詢的連接兔仰,使得數(shù)據(jù)庫負載很高茫负。

CSRF跨站請求偽造原理攻擊者盜用了你的身份,以你的名義發(fā)送惡意請求乎赴。

CSRF攻擊是源于WEB的隱式身份驗證機制忍法!WEB的身份驗證機制雖然可以保證一個請求是來自于某個用戶的瀏覽器置吓,但卻無法保證該請求是用戶批準發(fā)送的!

防御方式:1.驗證碼缔赠;2. 后臺生成token衍锚,讓前端請求攜帶。3.使用對稱加密嗤堰,后端隨機給前端一個密鑰戴质,前端進行加密,后端解密踢匣。

會話劫持通過暴力破解告匠、 預測、竊壤牖!(通過XSS攻擊)等方式獲取到用戶session

XSS攻擊XSS攻擊是Web攻擊中最常見的攻擊方法之一后专,它是通過對網(wǎng)頁注入可執(zhí)行代碼且成功地被瀏覽器執(zhí)行,達到攻擊的目的输莺,形成了一次有效XSS攻擊戚哎,一旦攻擊成功,它可以獲取用戶的聯(lián)系人列表嫂用,然后向聯(lián)系人發(fā)送虛假詐騙信息型凳,可以刪除用戶的日志等等,有時候還和其他攻擊方式同時實施比如SQL注入攻擊服務器和數(shù)據(jù)庫嘱函、Click劫持甘畅、相對鏈接劫持等實施釣魚,它帶來的危害是巨大的往弓,是web安全的頭號大敵疏唾。

XSS反射型攻擊,惡意代碼并沒有保存在目標網(wǎng)站函似,通過引誘用戶點擊一個鏈接到目標網(wǎng)站的惡意鏈接來實施攻擊的槐脏。

XSS存儲型攻擊,惡意代碼被保存到目標網(wǎng)站的服務器中缴淋,這種攻擊具有較強的穩(wěn)定性和持久性准给,比較常見場景是在博客,論壇等社交網(wǎng)站上重抖,但OA系統(tǒng)露氮,和CRM系統(tǒng)上也能看到它身影,比如:某CRM系統(tǒng)的客戶投訴功能上存在XSS存儲型漏洞钟沛,黑客提交了惡意攻擊代碼畔规,當系統(tǒng)管理員查看投訴信息時惡意代碼執(zhí)行,竊取了客戶的資料恨统,然而管理員毫不知情叁扫,這就是典型的XSS存儲型攻擊三妈。

解決方法

在表單提交或者url參數(shù)傳遞前,對需要的參數(shù)進行過濾

過濾用戶輸入莫绣。檢查用戶輸入的內容中是否有非法內容畴蒲。如<>(尖括號)、”(引號)对室、 ‘(單引號)模燥、%(百分比符號)、;(分號)掩宜、()(括號)蔫骂、&(& 符號)、+(加號)等

28.RPC與HTTP服務的區(qū)別

數(shù)據(jù)庫原理

MYISAM與innodb搜索引擎原理MyISAM引擎使用B+Tree作為索引結構牺汤,葉節(jié)點的data域存放的是數(shù)據(jù)記錄的地址辽旋。其采用索引文件與數(shù)據(jù)文件,索引文件只存放索引檐迟,葉子節(jié)點存放數(shù)據(jù)的物理地址补胚。數(shù)據(jù)文件存放數(shù)據(jù)。其索引方式是非聚集的锅减。

InnoDB也使用B+Tree作為索引結構糖儡。但是它的主索引與數(shù)據(jù)都放在一個文件中。這種索引叫做聚集索引怔匣,因為InnoDB的數(shù)據(jù)文件本身要按主鍵聚集,所以InnoDB要求表必須有主鍵(MyISAM可以沒有)桦沉,如果沒有顯式指定每瞒,則MySQL系統(tǒng)會自動選擇一個可以唯一標識數(shù)據(jù)記錄的列作為主鍵,如果不存在這種列纯露,則MySQL自動為InnoDB表生成一個隱含字段作為主鍵剿骨,這個字段長度為6個字節(jié),類型為長整形埠褪。

區(qū)別一:InnoDB的主索引與數(shù)據(jù)都放在一個文件中浓利。而MYISAM是分開存放的。

區(qū)別二:InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是地址钞速。

區(qū)別三:InnoDB的主鍵索引是聚集索引贷掖,而MYISAM不是聚集索引。

3.索引渴语,聚簇索引和二級索引的加鎖區(qū)別

聚集(clustered)索引苹威,也叫聚簇索引。數(shù)據(jù)行的物理順序與列值(一般是主鍵的那一列)的邏輯順序相同驾凶,一個表中只能擁有一個聚集索引牙甫。

非聚集(unclustered)索引掷酗。該索引中索引的邏輯順序與磁盤上行的物理存儲順序不同,一個表中可以擁有多個非聚集索引窟哺。會發(fā)生二次查詢泻轰。

稠密索引:稠密索引文件中的索引塊保持鍵的順序與文件中的排序順序一致。

稀疏索引:稀疏索引沒有為每個數(shù)據(jù)都創(chuàng)建一個索引,它比稠密索引節(jié)省了更多的存儲空間且轨,但查找給定值的記錄需更多的時間糕殉。只有當數(shù)據(jù)文件是按照某個查找鍵排序時,在該查找鍵上建立的稀疏索引才能被使用殖告,而稠密索引則可以應用在任何的查找鍵阿蝶。

聯(lián)合索引:將一張表中多個列組成聯(lián)合索引(col1,col2,col3),其生效方式滿足最左前綴原則黄绩。

覆蓋索引:對于二級索引而言羡洁,在innodb中一般是需要先根據(jù)二級索引查詢到主鍵,然后在根據(jù)一級索引查詢到數(shù)據(jù)爽丹。但是如果select的列都在索引中筑煮,就避免進行一級查詢。

4.主鍵選擇

在使用InnoDB存儲引擎時粤蝎,如果沒有特別的需要真仲,請永遠使用一個與業(yè)務無關的自增字段作為主鍵。

where 1 = 1:能夠方便我們拼sql初澎,但是使用了之后就無法使用索引優(yōu)化策略秸应,因此會進行全表掃描,影響效率碑宴。

5.分表分庫

水平拆分:依據(jù)表中的數(shù)據(jù)的邏輯關系软啼,將同一個表中的數(shù)據(jù)依照某種條件拆分到多臺數(shù)據(jù)庫(主機)上面。按照1個或多個字段以及相應的規(guī)則延柠,將一張表重的數(shù)據(jù)分到多張表中去祸挪。比如按照id%5的規(guī)則,將一張大表拆分成5張小表贞间。適合具有超大表的系統(tǒng)贿条。

垂直拆分:依照不同的表(或者Schema)來切分到不同的數(shù)據(jù)庫(主機)之上。一般按照模塊來分庫增热。適合各業(yè)務之間耦合度非常低的系統(tǒng)整以。

6.隔離級別

read uncommit:讀不加鎖,寫加共享鎖钓葫。會產生臟讀悄蕾、幻讀。

read commit:讀加共享鎖,寫加排它鎖帆调,但不加間隙鎖奠骄。間隙鎖的主要作用是防止不可重復讀,但會加大鎖的范圍番刊。

repeatable read(innodb默認):讀加共享鎖含鳞,寫加間隙排它鎖。注意芹务,Innodb對這個級別進行了特殊處理蝉绷,使得這個級別能夠避免幻讀,但不是所有引擎都能夠防止幻讀枣抱!(網(wǎng)易面試官問)

serialization:會給整張表加鎖熔吗,強一致,但是效率低佳晶。

7.innodb中的鎖

MVCC(multi-Version Concurrency Control):讀不加鎖桅狠,讀寫不沖突。適合寫少讀多的場景轿秧。讀操作分為:快照讀(返回記錄的可見版本中跌,不加鎖)、當前讀(記錄的最新版本菇篡,加鎖漩符,保證其它記錄不修改)。

LBCC(Lock-Based Concurrency Control):

join原理Simple Nested-Loop Join:效率最低驱还,按照join的次序嗜暴,在join的屬性上一個個掃描,并合并結果铝侵。

Index Nested-Loop Join:效率最高灼伤,join的屬性上面有索引,根據(jù)索引來匹配咪鲜。

Block Nested-Loop Join:用于沒有索引的列。它會采用join buffer撞鹉,將外表的值緩存到join buffer中疟丙,然后與內表進行批量比較,這樣可以降低對外表的訪問頻率

8.galera

多主架構:真正的多點讀寫的集群鸟雏,在任何時候讀寫數(shù)據(jù)享郊,都是最新的。

同步復制孝鹊,各節(jié)點間無延遲且節(jié)點宕機不會導致數(shù)據(jù)丟失炊琉。

緊密耦合,所有節(jié)點均保持相同狀態(tài),節(jié)點間無不同數(shù)據(jù)苔咪。

無需主從切換操作锰悼。

無需進行讀寫分離。

并發(fā)復制:從節(jié)點在APPLY數(shù)據(jù)時团赏,支持并行執(zhí)行箕般,有更好的性能表現(xiàn)。

故障切換:在出現(xiàn)數(shù)據(jù)庫故障時舔清,因為支持多點寫入丝里,切的非常容易。

熱插拔:在服務期間体谒,如果數(shù)據(jù)庫掛了杯聚,只要監(jiān)控程序發(fā)現(xiàn)的夠快,不可服務時間就會非常少抒痒。在節(jié)點故障期間幌绍,節(jié)點本身對集群的影響非常小。

自動節(jié)點克缕捞:在新增節(jié)點纷捞,或者停機維護時,增量數(shù)據(jù)或者基礎數(shù)據(jù)不需要人工手動備份提供被去,Galera Cluster會自動拉取在線節(jié)點數(shù)據(jù)主儡,最終集群會變?yōu)橐恢隆?/p>

對應用透明:集群的維護,對應用程序是透明的惨缆,幾乎感覺不到糜值。

9.LSM Tree,主要應用于nessDB坯墨、leveldb寂汇、hbase

核心思想的核心就是放棄部分讀能力,換取寫入的最大化能力捣染。它假設假定內存足夠大骄瓣,因此不需要每次有數(shù)據(jù)更新就必須將數(shù)據(jù)寫入到磁盤中,而可以先將最新的數(shù)據(jù)駐留在內存中耍攘,等到積累到最后多之后榕栏,再使用歸并排序的方式將內存內的數(shù)據(jù)合并追加到磁盤隊尾。(使用歸并排序是要因為帶排序樹都是有序樹)

LSM具有批量特性蕾各,存儲延遲扒磁。B樹在insert的時候可能會造成分裂,可能會造成隨機讀寫式曲。而LSM將多次單頁隨機寫妨托,變成一次多頁隨機寫,復用了磁盤尋道時間,極大提升效率。

LSM Tree放棄磁盤讀性能來換取寫的順序性兰伤。

一般會使用Bloom Filter來優(yōu)化LSM内颗。當將內存中的數(shù)據(jù)與磁盤數(shù)據(jù)合并的時候,先要判斷數(shù)據(jù)是否有重復医清,如果不用Bloom Filter就需要在磁盤上一層層地找起暮,而使用了之后就會降低搜索代價。

多線程

synchronized会烙、CAS

Collections

支持高并發(fā)的數(shù)據(jù)結構负懦,如ConcurrentHashMap

基于AQS實現(xiàn)的鎖、信號量柏腻、計數(shù)器原理

Runnable與Callable的區(qū)別

線程池

作用

減少在創(chuàng)建和銷毀線程上所花的時間以及系統(tǒng)資源的開銷 纸厉。

當前任務與主線程隔離,能實現(xiàn)和主線程的異步執(zhí)行五嫂,特別是很多可以分開重復執(zhí)行的任務颗品。

8.阻塞隊列

9.threadlocal

Spring框架

IOC/DI

Core、Beans沃缘、Context躯枢、Expression Language

JDBC、ORM槐臀、OXM锄蹂、JMS、Transaction

AOP

Web

Test

@Autowired原理

工廠模式

反射

自動配置@ConfigurationProperties(prefix = "hello"):讀取以hello為開頭的配置水慨,屬性類使用

@Configuration:指名當前類為配置類

@EnableConfigurationProperties(Properties):指名配置屬性類

@ConditionalOnClass(Condition.class):條件類得糜,只有Condition.class存在,當前配置類才生效

Spring Boot在spring.factories配置了很多全限定名的配置類晰洒。

Redis

核心原理

常用數(shù)據(jù)類型String:二進制安全朝抖,可以存任何數(shù)據(jù),比如序列化的圖片谍珊。最大長度位512M.

Hash:是KV對集合治宣,本質是String類型的KV映射,適合存儲對象砌滞。

List:簡單字符串鏈表炼七,可以在left、right兩邊插入布持,本質是雙向鏈表。緩沖區(qū)也是用這個實現(xiàn)陕悬。

Set:String類型的無序集合,內部實現(xiàn)是一個 value永遠為null的HashMap题暖,實際就是通過計算hash的方式來快速排重的,這也是set能提供判斷一個成員是否在集合內的原因。

zset:有序集合胧卤,每個元素會關聯(lián)一個double類型的score唯绍,然后根據(jù)score進行排序。注意:元素不能重復枝誊,但是score是可以重復的况芒。使用HashMap和跳躍表(SkipList)來保證數(shù)據(jù)的存儲和有序,HashMap里放的是成員到score的映射叶撒,而跳躍表里存放的是所有的成員绝骚,排序依據(jù)是HashMap里存的score.

pub/sub:在Redis中,你可以設定對某一個key值進行消息發(fā)布及消息訂閱祠够,當一個key值上進行了消息發(fā)布后压汪,所有訂閱它的客戶端都會收到相應的消息。

持久化

RDB:一種是手動執(zhí)行持久化命令來持久化快照古瓤;另一種是在配置文件中配置策略止剖,來自動持久化。持久化命令有save落君、bgsave兩種穿香,bgsave會調用fork命令,產生子進程來進行持久化绎速,而父進程繼續(xù)處理數(shù)據(jù)皮获,但是持久化的快照是fork那一刻的快照,因此這種策略可能會丟失一部分數(shù)據(jù)朝氓。特點:每次都記錄所有數(shù)據(jù)魔市,恢復快,子進程不影響父進程性能赵哲。

AOF:append only file待德,將每條操作命令都記錄到appendonly.aof文件中,但是不會立馬寫入硬盤枫夺,我們可以配置always(每有一個命令将宪,都同步)、everysec(每秒同步一次)橡庞、no(沒30秒同步一次)较坛。往往everysec就夠了。aof數(shù)據(jù)損失要比RDB小扒最。特點:有序記錄所有操作丑勤,數(shù)據(jù)丟失更少,會對操作做壓縮優(yōu)化吧趣,bgrewriteaof也會fork子進程法竞,不影響父進程性能

事務

Transactions:不是嚴格的ACID的事務耙厚,但是這個Transactions還是提供了基本的命令打包執(zhí)行的功能(在服務器不出問題的情況下,可以保證一連串的命令是順序在一起執(zhí)行的岔霸,中間有會有其它客戶端命令插進來執(zhí)行)薛躬。

Redis還提供了一個Watch功能,你可以對一個key進行Watch呆细,然后再執(zhí)行Transactions型宝,在這過程中,如果這個Watched的值進行了修改絮爷,那么這個Transactions會發(fā)現(xiàn)并拒絕執(zhí)行趴酣。

KafKA

topic

broker

partition

consumer

producer

stream

存儲機制

網(wǎng)絡模型

注意:partition之間是無序的

消息隊列的生產者消費者中消費者沒有收到消息怎么辦,消息有順序比如1.2.3但是收到的卻是1.3.2怎么辦略水?消息發(fā)過來的過程中損壞或者出錯怎么辦

Spring security

攔截器棧

@PreAuthorize

@PostAuthorize

支持Expression Language

jvm原理

內存模型价卤、垃圾收集器、CMS與G1是重點

垃圾收集算法

標記-清除(CMS)容易產生碎片渊涝,當碎片太多會提前觸發(fā)Full GC

復制(年輕代基本用這個算法)會浪費一半的可能感覺

標記-整理(serial Old慎璧、Parallel Old)

Serial:采用單線程stop-the-world的方式進行收集。當內存不足時跨释,串行GC設置停頓標識胸私,待所有線程都進入安全點(Safepoint)時,應用線程暫停鳖谈,串行GC開始工作岁疼,采用單線程方式回收空間并整理內存。串行收集器特別適合堆內存不高缆娃、單核甚至雙核CPU的場合捷绒。

ParNew

Parallel Scavenge

CMS:

初始標記(stop of world)

并行標記、預清理

重新標記(stop of world)

并行清理

G1

將堆分成很多region贯要,可以同時堆年輕代與老年代進行收集

初始標記(stop of world):初始標記(Initial Mark)負責標記所有能被直接可達的根對象(原生棧對象暖侨、全局對象、JNI對象)

并行標記:

重新標記(stop of world):

清理(stop of world):

重置

gc觸發(fā)條件

從年輕代分區(qū)拷貝存活對象時崇渗,無法找到可用的空閑分區(qū)字逗,會觸發(fā)Minor GC

從老年代分區(qū)轉移存活對象時,無法找到可用的空閑分區(qū)宅广,會觸發(fā)Major GC

分配巨型對象時在老年代無法找到足夠的連續(xù)分區(qū)葫掉,會觸發(fā)Major GC

可達性分析:通過檢查一塊內存空間能否被root達到,來判斷是否對其進行回收跟狱。

jdk不同版本新增的部分特性

jvm調優(yōu)

VisualVM:JDK自帶JVM可視化工具俭厚,能過對內存、gc驶臊、cpu套腹、thread绪抛、class、變量等等信息進行可視化电禀。

設計模式

單例雙重檢查

觀察者模式

裝飾者模式:jdk中輸入輸出流用到了該模式

適配器模式:jdk中Reader、writer用到了該模式

代理模式

靜態(tài)代理

JDK動態(tài)代理

Cglib到動態(tài)代理

生產者消費者模式

工廠模式

項目管理與運維工具

git+Jenkins

maven

K8Spod:Pod是所有業(yè)務類型的基礎笤休,所有的容器均在Pod中運行,它是一個或多個容器的組合尖飞。每一個Pod都會被指派一個唯一的Ip地址,在Pod中的每一個容器共享網(wǎng)絡命名空間店雅,包括Ip地址和網(wǎng)絡端口政基。Pod能夠被指定共享存儲卷的集合,在Pod中所有的容器能夠訪問共享存儲卷闹啦,允許這些容器共享數(shù)據(jù)沮明。

kubelet:kubelet負責管理pods和它們上面的容器,images鏡像窍奋、volumes荐健、etc。

ingress琳袄,用于負載均衡

docker

docker與虛擬機的區(qū)別

數(shù)據(jù)結構

平衡二叉樹AVL

高度log(n)

插入時間復雜度log(n)

紅黑樹

插入時間復雜度log(n)

查找時間復雜度log(n)

在查找是江场,紅黑樹雖然復雜度也是log(n),但是從效率上比要略低于AVL。但是其優(yōu)勢在于插入元素的時候窖逗,不會像AVL那樣頻繁地旋轉址否。

B+Tree:只有葉子節(jié)點存值,非葉子節(jié)點只存key和child碎紊,因此同樣大小的物理頁上能存放更多的節(jié)點佑附。每一層的節(jié)點數(shù)量越多,意味著層次越少仗考,也就意味著IO次數(shù)越少音同,因此非常適合數(shù)據(jù)庫以及文件系統(tǒng)。

大根堆:采用數(shù)組存儲樹痴鳄,是一個完全樹瘟斜。先插入到數(shù)組最后的位置上,然后采用上浮的思想痪寻,將該元素與比它小的父元素調換螺句,直到parent>target,浮到root;然后將root與未排序的最后一個元素交換位置橡类;重復以上步驟蛇尚,直到所有元素都有序。插入如查找的復雜度都是log(n)顾画。

優(yōu)先隊列PriorityQueue取劫,Java中使用小根堆實現(xiàn)匆笤,非線程安全。

優(yōu)先阻塞隊列PriorityBlockQueue谱邪,線程安全炮捧。

算法

快排

時間復雜度O(nlog(n))

空間復雜度O(log(n))

堆排序

時間復雜度O(nlog(n))

空間復雜度O(1)

歸并排序

時間復雜度O(nlog(n))

空間復雜度O(n)

跳表時間復雜度O(log(n))

空間復雜度O(2n)

高度O(log(n))

分布式

cap理論

可用性

一致性

分區(qū)容忍性:對網(wǎng)絡斷開的容忍度,有點像魯棒性

拜占庭將軍問題

Raft 算法

有l(wèi)eader惦银、follower咆课、candidate

同步流程

由客戶端提交數(shù)據(jù)到Leader節(jié)點。

由Leader節(jié)點把數(shù)據(jù)復制到集群內所有的Follower節(jié)點扯俱。如果一次復制失敗书蚪,會不斷進行重試。

Follower節(jié)點們接收到復制的數(shù)據(jù)迅栅,會反饋給Leader節(jié)點殊校。

如果Leader節(jié)點接收到超過半數(shù)的Follower反饋,表明復制成功读存。于是提交自己的數(shù)據(jù)为流,并通知客戶端數(shù)據(jù)提交成功。

由Leader節(jié)點通知集群內所有的Follower節(jié)點提交數(shù)據(jù)宪萄,從而完成數(shù)據(jù)同步流程艺谆。

zookeeper

Zab(Zookeeper Atomic Broadcast)協(xié)議,有兩種模式:

它們分別是:恢復模式(選主)和廣播模式(同步)。

有兩種算法:1. basic paxos拜英;2. fast paxos(默認)

文件系統(tǒng):zookeeper的通知機制静汤、分布式鎖、隊列管理居凶、配置管理都是基于文件系統(tǒng)的虫给。

分布式鎖:有了zookeeper的一致性文件系統(tǒng),鎖的問題變得容易侠碧。鎖服務可以分為兩類抹估,一個是保持獨占,另一個是控制時序弄兜。

獨占鎖:將zookeeper上的一個znode看作是一把鎖药蜻,通過createznode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點替饿,最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖语泽。用完刪除掉自己創(chuàng)建的distribute_lock 節(jié)點就釋放出鎖。

控制時序鎖:/distribute_lock 已經(jīng)預先存在视卢,所有客戶端在它下面創(chuàng)建臨時順序編號目錄節(jié)點踱卵,和選master一樣,編號最小的獲得鎖据过,用完刪除。

隊列管理,分為同步隊列祠挫、非同步隊列

數(shù)據(jù)復制的好處

容錯:一個節(jié)點出錯,不致于讓整個系統(tǒng)停止工作酝掩,別的節(jié)點可以接管它的工作;

提高系統(tǒng)的擴展能力 :把負載分布到多個節(jié)點上罗标,或者增加節(jié)點來提高系統(tǒng)的負載能力庸队;

提高性能:讓客戶端本地訪問就近的節(jié)點,提高用戶訪問速度闯割。

5.一致性hash算法原理

微服務

Spring cloud

網(wǎng)關:zuul

分布式版本化配置 config

服務注冊和發(fā)現(xiàn):Eureka,配置時需要注意多久刷新列表一次竿拆,多久監(jiān)測心跳等宙拉。

service-to-service 調用

負載均衡:Ribbon;在生成RestTemplate的bean時丙笋,通過@LoadBalanced注解可以使得RestTemplate的調用

斷路器:Hystrix

監(jiān)控:spring admin谢澈。在啟動類上加@EnableAdminServer注解。

java web

servlet工作原理

tomcat工作原理,好文御板,強推

container

linux

系統(tǒng)結構锥忿,講得很好,強推

硬鏈接與軟連接

硬鏈接:數(shù)據(jù)節(jié)點通過引用計數(shù)的方式來對指向它的硬鏈接計數(shù)怠肋,當計數(shù)為0就刪除敬鬓。

軟連接:我們可以把它看成是快捷方式,它只是記錄了某個文件的硬鏈接的路徑笙各,如果我們把源文件刪除钉答,再重新創(chuàng)建一個相同名字的文件,那么軟連接指向的就是新創(chuàng)建的文件杈抢。

虛擬文件系統(tǒng)(VFS):文件系統(tǒng)是有很多實現(xiàn)的数尿,比如ext2、ext3惶楼、FAT等等右蹦,而VFS則是存在于應用程序與文件系統(tǒng)中間,它封裝了open歼捐、close何陆、read、write等等操作文件系統(tǒng)的接口窥岩,為應用程序屏蔽掉不同文件系統(tǒng)之間的差異甲献。

VFS數(shù)據(jù)結構

其它

bitmap,大文件交集

Elasticsearch索引原理

從內存到屏幕經(jīng)歷了啥

高并發(fā)場景的限流颂翼,你怎么來確定限流限多少晃洒,模擬場景和實際場景有區(qū)別怎么解決慨灭,

百度面試

說一下redis與kafka,redis持久化策略

git中rebase與merge區(qū)別

docker底層原理球及,依賴操作系統(tǒng)的什么

ls -l | grep xxx的執(zhí)行過程氧骤,盡可能的細,是多進程還是單進程吃引?

兩個有序數(shù)組求中位數(shù)

算法 3Sum筹陵、中序遍歷非遞歸實現(xiàn)、循環(huán)打印矩陣

final镊尺、finally朦佩、finanize

jvm內存模型

垃圾回收器

Spring特點介紹下

Synchronize與ReentrantLock的區(qū)別、使用場景

CAS使用場景

聊了下git+jekins+K8S+docker實現(xiàn)自動化部署

innodb原理庐氮,使用場景语稠,與MYISAM在場景上的區(qū)別

weakReference、softReference等

Hbase的原理弄砍,LSM Tree

Linux中仙畦,哪種進程可以使用管道

美團

權限模型

介紹下線程池,阻塞隊列的用法音婶,無界隊列真的無界嗎慨畸?

說一下redis

kafka存儲模型與網(wǎng)絡模型

zookeeper與redis實現(xiàn)分布式鎖

樂觀鎖與悲觀鎖

算法:有n個人,給你ai與aj的身高關系衣式,如ai比aj高寸士,進行身高排序,如果條件不滿足瞳收,則輸出“不滿足”

Spring boot的特性

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末碉京,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子螟深,更是在濱河造成了極大的恐慌谐宙,老刑警劉巖,帶你破解...
    沈念sama閱讀 206,723評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件界弧,死亡現(xiàn)場離奇詭異凡蜻,居然都是意外死亡,警方通過查閱死者的電腦和手機垢箕,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,485評論 2 382
  • 文/潘曉璐 我一進店門划栓,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人条获,你說我怎么就攤上這事忠荞。” “怎么了?”我有些...
    開封第一講書人閱讀 152,998評論 0 344
  • 文/不壞的土叔 我叫張陵委煤,是天一觀的道長堂油。 經(jīng)常有香客問我,道長碧绞,這世上最難降的妖魔是什么府框? 我笑而不...
    開封第一講書人閱讀 55,323評論 1 279
  • 正文 為了忘掉前任,我火速辦了婚禮讥邻,結果婚禮上迫靖,老公的妹妹穿的比我還像新娘。我一直安慰自己兴使,他們只是感情好系宜,可當我...
    茶點故事閱讀 64,355評論 5 374
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著发魄,像睡著了一般蜈首。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上欠母,一...
    開封第一講書人閱讀 49,079評論 1 285
  • 那天,我揣著相機與錄音吆寨,去河邊找鬼赏淌。 笑死,一個胖子當著我的面吹牛啄清,可吹牛的內容都是我干的六水。 我是一名探鬼主播,決...
    沈念sama閱讀 38,389評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼辣卒,長吁一口氣:“原來是場噩夢啊……” “哼掷贾!你這毒婦竟也來了?” 一聲冷哼從身側響起荣茫,我...
    開封第一講書人閱讀 37,019評論 0 259
  • 序言:老撾萬榮一對情侶失蹤想帅,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后啡莉,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體港准,經(jīng)...
    沈念sama閱讀 43,519評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 35,971評論 2 325
  • 正文 我和宋清朗相戀三年咧欣,在試婚紗的時候發(fā)現(xiàn)自己被綠了浅缸。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,100評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡魄咕,死狀恐怖衩椒,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤毛萌,帶...
    沈念sama閱讀 33,738評論 4 324
  • 正文 年R本政府宣布苟弛,位于F島的核電站,受9級特大地震影響朝聋,放射性物質發(fā)生泄漏嗡午。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,293評論 3 307
  • 文/蒙蒙 一冀痕、第九天 我趴在偏房一處隱蔽的房頂上張望荔睹。 院中可真熱鬧,春花似錦言蛇、人聲如沸僻他。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,289評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽吨拗。三九已至,卻和暖如春婿斥,著一層夾襖步出監(jiān)牢的瞬間劝篷,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,517評論 1 262
  • 我被黑心中介騙來泰國打工民宿, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留娇妓,地道東北人。 一個月前我還...
    沈念sama閱讀 45,547評論 2 354
  • 正文 我出身青樓活鹰,卻偏偏與公主長得像哈恰,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子志群,可洞房花燭夜當晚...
    茶點故事閱讀 42,834評論 2 345

推薦閱讀更多精彩內容