151. RabbitMQ 對集群節(jié)點停止順序有要求嗎？
?? ?RabbitMQ 對集群的停止的順序是有要求的，應(yīng)該先關(guān)閉內(nèi)存節(jié)點，最后再關(guān)閉磁盤節(jié)點。
?? ?如果順序恰好相反的話，可能會造成消息的丟失。

Kafka
152.kafka 可以脫離 zookeeper 單獨使用嗎？為什么？
?? ?kafka 不能脫離 zookeeper 單獨使用，因為 kafka 使用 zookeeper 管理和協(xié)調(diào) kafka 的節(jié)點服務(wù)器。

153.kafka 有幾種數(shù)據(jù)保留的策略？
?? ?kafka 有兩種數(shù)據(jù)保存策略：按照過期時間保留和按照存儲的消息大小保留。

154.kafka 同時設(shè)置了 7 天和 10G 清除數(shù)據(jù)，到第五天的時候消息達(dá)到了 10G，這個時候 kafka 將如何處理？
?? ?這個時候 kafka 會執(zhí)行數(shù)據(jù)清除工作，時間和大小不論那個滿足條件，都會清空數(shù)據(jù)。

155.什么情況會導(dǎo)致 kafka 運行變慢？
?? ?cpu 性能瓶頸
?? ?磁盤讀寫瓶頸
?? ?網(wǎng)絡(luò)瓶頸

156.使用 kafka 集群需要注意什么？
?? ?集群的數(shù)量不是越多越好，最好不要超過 7 個，因為節(jié)點越多，消息復(fù)制需要的時間就越長，整個群組的吞吐量就越低。
?? ?集群數(shù)量最好是單數(shù)，因為超過一半故障集群就不能用了，設(shè)置為單數(shù)容錯率更高。
?? ?
?? ?
Zookeeper
157. zookeeper 是什么？
?? ?一.zookeeper 是什么
?? ??? ?ZooKeeper由雅虎研究院開發(fā)，是Google Chubby的開源實現(xiàn)，后來托管到Apache，于2010年11月正式成為Apache的頂級項目。
?? ??? ?ZooKeeper是一個經(jīng)典的分布式數(shù)據(jù)一致性解決方案，致力于為分布式應(yīng)用提供一個高性能、高可用，
?? ??? ?且具有嚴(yán)格順序訪問控制能力的分布式協(xié)調(diào)服務(wù)。
?? ??? ?分布式應(yīng)用程序可以基于ZooKeeper實現(xiàn)數(shù)據(jù)發(fā)布與訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)與通知、集群管理、
?? ??? ?Leader選舉、分布式鎖、分布式隊列等功能。
?? ?二.ZooKeeper目標(biāo)
?? ??? ?ZooKeeper致力于為分布式應(yīng)用提供一個高性能、高可用，且具有嚴(yán)格順序訪問控制能力的分布式協(xié)調(diào)服務(wù)
?? ??? ?2.1 高性能
?? ??? ?ZooKeeper將全量數(shù)據(jù)存儲在內(nèi)存中，并直接服務(wù)于客戶端的所有非事務(wù)請求，尤其適用于以讀為主的應(yīng)用場景
?? ??? ?2.2 高可用
?? ??? ?ZooKeeper一般以集群的方式對外提供服務(wù)，一般3 ~ 5臺機(jī)器就可以組成一個可用的Zookeeper集群了，
?? ??? ?每臺機(jī)器都會在內(nèi)存中維護(hù)當(dāng)前的服務(wù)器狀態(tài)，并且每臺機(jī)器之間都相互保持著通信。
?? ??? ?只要集群中超過一般的機(jī)器都能夠正常工作，那么整個集群就能夠正常對外服務(wù)
?? ??? ?2.3 嚴(yán)格順序訪問
?? ??? ?對于來自客戶端的每個更新請求，ZooKeeper都會分配一個全局唯一的遞增編號，這個編號反映了所有事務(wù)操作的先后順序
?? ?三.ZooKeeper五大特性
?? ??? ?ZooKeeper一般以集群的方式對外提供服務(wù)，一個集群包含多個節(jié)點，每個節(jié)點對應(yīng)一臺ZooKeeper服務(wù)器，
?? ??? ?所有的節(jié)點共同對外提供服務(wù)，整個集群環(huán)境對分布式數(shù)據(jù)一致性提供了全面的支持，具體包括以下五大特性：
?? ??? ?3.1 順序一致性
?? ??? ?從同一個客戶端發(fā)起的請求，最終將會嚴(yán)格按照其發(fā)送順序進(jìn)入ZooKeeper中
?? ??? ?3.2 原子性
?? ??? ?所有請求的響應(yīng)結(jié)果在整個分布式集群環(huán)境中具備原子性，即要么整個集群中所有機(jī)器都成功的處理了某個請求，
?? ??? ?要么就都沒有處理，絕對不會出現(xiàn)集群中一部分機(jī)器處理了某一個請求，而另一部分機(jī)器卻沒有處理的情況
?? ??? ?3.3 單一性
?? ??? ?無論客戶端連接到ZooKeeper集群中哪個服務(wù)器，每個客戶端所看到的服務(wù)端模型都是一致的，
?? ??? ?不可能出現(xiàn)兩種不同的數(shù)據(jù)狀態(tài)，因為ZooKeeper集群中每臺服務(wù)器之間會進(jìn)行數(shù)據(jù)同步
?? ??? ?3.4 可靠性
?? ??? ?一旦服務(wù)端數(shù)據(jù)的狀態(tài)發(fā)送了變化，就會立即存儲起來，除非此時有另一個請求對其進(jìn)行了變更，否則數(shù)據(jù)一定是可靠的
?? ??? ?3.5 實時性
?? ??? ?當(dāng)某個請求被成功處理后，ZooKeeper僅僅保證在一定的時間段內(nèi)，客戶端最終一定能從服務(wù)端上讀取到最新的數(shù)據(jù)狀態(tài)，
?? ??? ?即ZooKeeper保證數(shù)據(jù)的最終一致性
?? ?四.ZooKeeper集群角色
?? ??? ?在分布式系統(tǒng)中，集群中每臺機(jī)器都有自己的角色，ZooKeeper沒有沿用傳統(tǒng)的Master/Slave模式（主備模式），
?? ??? ?而是引入了Leader、Follower和Observer三種角色
?? ??? ?4.1 Leader
?? ??? ?集群通過一個Leader選舉過程從所有的機(jī)器中選舉一臺機(jī)器作為”Leader”，Leader能為客戶端提供讀和寫服務(wù)
?? ??? ?Leader服務(wù)器是整個集群工作機(jī)制的核心，主要工作：
?? ??? ??? ?1.事務(wù)請求的唯一調(diào)度者和處理者，保證集群事務(wù)處理的順序性
?? ??? ??? ?2.集群內(nèi)部各服務(wù)器的調(diào)度者
?? ??? ?4.2 Follower
?? ??? ?顧名思義，Follower是追隨者，主要工作：
?? ??? ??? ?1.參與Leader選舉投票
?? ??? ??? ?2.處理客戶端非事務(wù)請求 - 即讀服務(wù)
?? ??? ??? ?3.轉(zhuǎn)發(fā)事務(wù)請求給Leader服務(wù)器
?? ??? ??? ?4.參與事務(wù)請求Proposal的投票
?? ??? ?4.3 Observer
?? ??? ?Observer是ZooKeeper自3.3.0版本開始引入的一個全新的服務(wù)器角色，充當(dāng)一個觀察者角色，
?? ??? ?工作原理和Follower基本是一致的，和Follower唯一的區(qū)別是Observer不參與任何形式的投票
?? ??? ??? ?1.處理客戶端非事務(wù)請求 - 即讀服務(wù)
?? ??? ??? ?2.轉(zhuǎn)發(fā)事務(wù)請求給Leader服務(wù)器
?? ??? ??? ?3.不參與Leader選舉投票
?? ??? ??? ?4.參與事務(wù)請求Proposal的投票
?? ??? ?所以O(shè)bserver可以在不影響寫性能的情況下提升集群的讀性能
?? ?五. 原子廣播協(xié)議 - Zab
?? ??? ?ZooKeeper并非采用經(jīng)典的分布式一致性協(xié)議 - Paxos，
?? ??? ?而是參考了Paxos設(shè)計了一種更加輕量級的支持崩潰可恢復(fù)的原子廣播協(xié)議-Zab（ZooKeeper Atomic Broadcast）。
?? ??? ?ZAB協(xié)議分為兩個階段 - Leader Election（領(lǐng)導(dǎo)選舉）和Atomic Broadcast（原子廣播）
?? ??? ?5.1 領(lǐng)導(dǎo)選舉 - Leader Election
?? ??? ?當(dāng)集群啟動時，會選舉一臺節(jié)點為Leader，而其他節(jié)點為Follower，當(dāng)Leader節(jié)點出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況，
?? ??? ?ZAB會進(jìn)入恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器，當(dāng)集群中已有過半機(jī)器與該Leader服務(wù)器完成數(shù)據(jù)狀態(tài)同步，退出恢復(fù)模式
?? ??? ?5.2 原子廣播 - Atomic Broadcast
?? ??? ?當(dāng)領(lǐng)導(dǎo)選舉完成后，就進(jìn)入原子廣播階段。此時集群中已存在一個Leader服務(wù)器在進(jìn)行消息廣播，
?? ??? ?當(dāng)一臺同樣遵循ZAB協(xié)議的服務(wù)器啟動后加入到集群中，新加的服務(wù)器會自動進(jìn)入數(shù)據(jù)恢復(fù)階段
?? ?六. 事務(wù)請求
?? ??? ?在ZooKeeper中，事務(wù)是指能夠改變ZooKeeper服務(wù)器狀態(tài)的請求，一般指創(chuàng)建節(jié)點、更新數(shù)據(jù)、刪除節(jié)點以及創(chuàng)建會話操作
?? ??? ?6.1 事務(wù)轉(zhuǎn)發(fā)
?? ??? ?為了保證事務(wù)請求被順序執(zhí)行，從而確保ZooKeeper集群的數(shù)據(jù)一致性，所有的事務(wù)請求必須由Leader服務(wù)器處理，
?? ??? ?ZooKeeper實現(xiàn)了非常特別的事務(wù)請求轉(zhuǎn)發(fā)機(jī)制：
?? ??? ?所有非Leader服務(wù)器如果接收到來自客戶端的事務(wù)請求，必須將其轉(zhuǎn)發(fā)給Leader服務(wù)器來處理
?? ??? ?6.2 事務(wù)ID - ZXID
?? ??? ?在分布式系統(tǒng)中，事務(wù)請求可能存在依賴關(guān)系，如變更C需要依賴變更A和變更B，
?? ??? ?這樣就要求ZAB協(xié)議能夠保證如果一個狀態(tài)變更成功被處理了，那么其所有依賴的狀態(tài)變更都應(yīng)該已經(jīng)提前被處理掉了。
?? ??? ?在ZooKeeper中對每一個事務(wù)請求，都會為其分配一個全局唯一的事務(wù)ID，使用ZXID表示，通常是一個64位的數(shù)字。
?? ??? ?每一個ZXID對應(yīng)一次事務(wù)，從這些ZXID可以間接識別出ZooKeeper處理這些事務(wù)請求的全局順序
?? ?七. 數(shù)據(jù)節(jié)點 - ZNode
?? ??? ?ZooKeeper內(nèi)部擁有一個樹狀的內(nèi)存模型，類似文件系統(tǒng)，只是在ZooKeeper中將這些目錄與文件系統(tǒng)統(tǒng)稱為ZNode，
?? ??? ?ZNode是ZooKeeper中數(shù)據(jù)的最小單元，每個ZNode上可以保存數(shù)據(jù)，還可以掛載子節(jié)點，因此構(gòu)成了一個層次化的命名空間
?? ??? ?7.1 節(jié)點路徑
?? ??? ?ZooKeeper中使用斜杠（/）分割的路徑表示ZNode路徑，斜杠（/）表示根節(jié)點
?? ??? ?7.2 節(jié)點特性
?? ??? ?在ZooKeeper中，每個數(shù)據(jù)節(jié)點ZNode都是有生命周期的，其生命周期的長短取決于ZNode的節(jié)點類型
?? ??? ?7.3 權(quán)限控制 - ACL
?? ??? ?為了有效保障ZooKeeper中數(shù)據(jù)的安全，避免因誤操作而帶來數(shù)據(jù)隨意變更導(dǎo)致分布式系統(tǒng)異常，
?? ??? ?ZooKeeper提供了一套完善的ACL（Access Contro List）權(quán)限控制機(jī)制來保障數(shù)據(jù)的安全。
?? ??? ?可以從三個方面理解ACL機(jī)制，分別是：權(quán)限模式（Scheme）、授權(quán)對象（ID）和權(quán)限（Permission），
?? ??? ?通常使用”scheme:id:permission”來標(biāo)識一個有效的ACL信息
?? ??? ?7.4 節(jié)點狀態(tài)信息
?? ??? ?每個數(shù)據(jù)節(jié)點ZNode除了存儲數(shù)據(jù)內(nèi)容外，還存儲了數(shù)據(jù)節(jié)點本身的一些狀態(tài)信息
?? ??? ?7.5 節(jié)點版本
?? ??? ?ZooKeeper為數(shù)據(jù)節(jié)點引入版本的概念，對個數(shù)據(jù)節(jié)點都具有三種類型的版本信息，對數(shù)據(jù)節(jié)點的任何更新操作都會引起版本號的變化
?? ??? ?在分布式系統(tǒng)中，在運行過程中往往需要保證數(shù)據(jù)訪問的排他性。Java并發(fā)中是實現(xiàn)了對CAS的指令支持，即對于值V，
?? ??? ?每次更新前都會比對其值是否是預(yù)期值A(chǔ)，只有符合預(yù)期，才會將V原子化的更新到新值B
?? ??? ?而ZooKeeper每個節(jié)點都有數(shù)據(jù)版本的概念，在調(diào)用更新操作的時候，先從請求中獲取當(dāng)前請求的版本version，
?? ??? ?同時獲取服務(wù)器上該數(shù)據(jù)最新版本currentVersion，如果無法匹配，就無法更新成功，這樣可以有效避免一些分布式更新的并發(fā)問題
?? ?八. Watcher - 數(shù)據(jù)變更的通知
?? ??? ?在ZooKeeper中，引入Watcher機(jī)制來實現(xiàn)分布式數(shù)據(jù)的發(fā)布/訂閱功能。ZooKeeper允許客戶端向服務(wù)器注冊一個Watcher監(jiān)聽，
?? ??? ?當(dāng)服務(wù)器的一些指定事件觸發(fā)了這個Watcher，那么就會向指定客戶端發(fā)送一個事件通知來實現(xiàn)分布式的通知功能
?? ??? ?Watcher機(jī)制為以下三個過程：
?? ??? ?8.1 客戶端注冊Watcher
?? ??? ?在創(chuàng)建一個ZooKeeper客戶端對象實例時，可以向構(gòu)造方法中傳入一個Watcher，這個Watcher將作為整個ZooKeeper會話期間的默認(rèn)Watcher，
?? ??? ?一致保存在客戶端，并向ZooKeeper服務(wù)器注冊Watcher
?? ??? ?客戶端并不會把真實的Watcher對象傳遞到服務(wù)器，僅僅只是在客戶端請求中使用boolean類型屬性進(jìn)行標(biāo)記，降低網(wǎng)絡(luò)開銷和服務(wù)器內(nèi)存開銷
?? ??? ?8.2 服務(wù)端處理Watcher
?? ??? ?服務(wù)端執(zhí)行數(shù)據(jù)變更，當(dāng)Watcher監(jiān)聽的對應(yīng)數(shù)據(jù)節(jié)點的數(shù)據(jù)內(nèi)容發(fā)生變更，如果找到對應(yīng)的Watcher，會將其提取出來，
?? ??? ?同時從管理中將其刪除（說明Watcher在服務(wù)端是一次性的，即觸發(fā)一次就失效了），觸發(fā)Watcher，向客戶端發(fā)送通知
?? ??? ?8.3 客戶端回調(diào)Watcher
?? ??? ?客戶端獲取通知，識別出事件類型，從相應(yīng)的Watcher存儲中去除對應(yīng)的Watcher（說明客戶端也是一次性的，即一旦觸發(fā)就會失效）
?? ??? ?8.4 總結(jié)
?? ??? ?一致性：無論是客戶端還是服務(wù)器，一旦一個Watcher被處罰，ZooKeeper都會將其從相應(yīng)的存儲中移除，
?? ??? ?因此開發(fā)人員在Watcher使用上要反復(fù)注冊，這樣可以有效減輕服務(wù)器壓力
?? ??? ?客戶端串行執(zhí)行：客戶端Watcher回調(diào)的過程是一個串行同步的過程，這保證了順序
?? ??? ?輕量：客戶端并不會把真實的Watcher對象傳遞到服務(wù)器，僅僅只是在客戶端請求中使用boolean類型屬性進(jìn)行標(biāo)記，
?? ??? ?降低網(wǎng)絡(luò)開銷和服務(wù)器內(nèi)存開銷
?? ?九. Session - 會話
?? ??? ?Session是指客戶端連接 - 客戶端和服務(wù)器之間的一個TCP長連接
?? ??? ?9.1 會話狀態(tài)
?? ??? ?會話在整個生命周期中，會在不同的會話轉(zhuǎn)態(tài)之間進(jìn)行切換
?? ??? ?9.2 Session屬性
?? ??? ?Session是ZooKeeper中的會話實體，代表了一個客戶端會話，其包含4個屬性：
?? ??? ?9.3 心跳檢測
?? ??? ?為了保證客戶端會話的有效性，客戶端會在會話超時時間范圍內(nèi)向服務(wù)器發(fā)送PING請求來保持會話的有效性，即心跳檢測。
?? ??? ?服務(wù)器接收到客戶端的這個心跳檢測，就會重新激活對應(yīng)的客戶端會話
?? ??? ?9.4 會話清理
?? ??? ?服務(wù)器的超級檢查線程會在指定時間點進(jìn)行檢查，整理出一些已經(jīng)過期的會話后，就要開始進(jìn)行會話清理了：
?? ??? ?關(guān)閉會話
?? ??? ?清理相關(guān)的臨時節(jié)點
?? ??? ?9.5 重連
?? ??? ?當(dāng)客戶端和服務(wù)器之間網(wǎng)絡(luò)連接斷開，客戶端會自動進(jìn)行反復(fù)的重連，直到最終成功連接上ZooKeeper集群中的一臺機(jī)器
?? ??? ?在會話超時時間內(nèi)重新連接上，被視為重連成功
?? ??? ?在會話超時時間外重新連接上，此時服務(wù)器已經(jīng)進(jìn)行了會話清理，但客戶端不知道會話已經(jīng)失效，
?? ??? ?重新連接服務(wù)器會告訴客戶端會話已失效，被視為非法會話

158. zookeeper 都有哪些功能？
?? ?集群管理：監(jiān)控節(jié)點存活狀態(tài)、運行請求等。
?? ?主節(jié)點選舉：主節(jié)點掛掉之后可以從備用節(jié)點開始新一輪選舉，主節(jié)點選舉說的就是這個選舉的過程，使用zookeeper可以是協(xié)助完成這個過程。
?? ?費不是鎖：zookeeper提供兩種鎖：獨占鎖、共享鎖。獨占鎖即一次只能有一個線程使用資源，共享鎖是讀鎖共享，讀寫互斥，
?? ?既可以有多線程童師傅去一個資源，如果要使用寫鎖也只能有一個線程使用。zookeeper可以對分布式鎖進(jìn)行控制。
?? ?命名服務(wù)：在分布式系統(tǒng)中，通過使用命名服務(wù)，客戶端應(yīng)用能夠根據(jù)指定名字來獲取資源或服務(wù)的地址，提供者等信息。

159. zookeeper 有幾種部署模式？
?? ?zookeeper有三種部署模式：
?? ?單機(jī)部署：一臺集群上運行；
?? ?集群部署：多臺集群運行；
?? ?偽集群部署：一臺進(jìn)群啟動多個zookeeper實例運行；
?? ?
?? ?
160. zookeeper 怎么保證主從節(jié)點的狀態(tài)同步？
?? ?Zookeeper的核心是原子廣播，這個機(jī)制保證了各個Server之間的同步。實現(xiàn)這個機(jī)制的協(xié)議叫做Zab協(xié)議。
?? ?Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。
?? ?恢復(fù)模式：當(dāng)服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，
?? ?且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。因此，選主得到的leader保證了同步狀態(tài)的進(jìn)行，
?? ?狀態(tài)同步又保證了leader和Server具有相同的系統(tǒng)狀態(tài)，當(dāng)leader失去主權(quán)后可以在其他follower中選主新的leader。

161. 集群中為什么要有主節(jié)點？
?? ?在分布式環(huán)境中，有些業(yè)務(wù)邏輯只需要集群中的某一臺機(jī)器進(jìn)行執(zhí)行，
?? ?其他的機(jī)器可以共享這個結(jié)果，這樣可以大大減少重復(fù)計算，提高性能，所以就需要主節(jié)點

162. 集群中有 3 臺服務(wù)器，其中一個節(jié)點宕機(jī)，這個時候 zookeeper 還可以使用嗎？
?? ?可以繼續(xù)使用，單數(shù)服務(wù)器只要沒超過一半的服務(wù)器宕機(jī)就可以繼續(xù)使用。

163. 說一下 zookeeper 的通知機(jī)制？
?? ?客戶端端會對某個 znode 建立一個 watcher 事件，
?? ?當(dāng)該 znode 發(fā)生變化時，這些客戶端會收到 zookeeper 的通知，
?? ?然后客戶端可以根據(jù) znode 變化來做出業(yè)務(wù)上的改變。
?? ?
?? ?
MySQL
164. 數(shù)據(jù)庫的三范式是什么？
?? ?1、第一范式，又稱1NF，它指的是在一個應(yīng)用中的數(shù)據(jù)都可以組織成由行和列的表格形式，且表格的任意一個行列交叉點即單元格，
?? ?都不可再劃分為行和列的形式，實際上任意一張表格都滿復(fù)足1NF；?
?? ?2、第二范式，又稱2NF，它指的是在滿足1NF的基礎(chǔ)上，
?? ?一張數(shù)據(jù)表中的任何非主鍵字段都全部依賴于主鍵字段，沒有制任何非主鍵字段只依賴于主鍵字段的一部分。
?? ?即，可以由主鍵字段來唯一的確定一條記錄。比如學(xué)號+課程號的聯(lián)合主鍵，可以唯一的確定某個成績是哪個學(xué)員的哪門課的成績，
?? ?缺少學(xué)號或者缺少課程號，都不能確定成績的意義。
?? ?3、第三范式，又稱3NF，它是知指在滿足2NF的基礎(chǔ)上，
?? ?數(shù)據(jù)表的任何非主鍵字段之間都不產(chǎn)生函數(shù)依賴，即非主鍵字段之間沒有依賴關(guān)系，全部只依賴于道主鍵字段。
?? ?例如將學(xué)員姓名和所屬班級名稱放在同一張表中是不科學(xué)的，因為學(xué)員依賴于班級，可將學(xué)員信息和班級信息單獨存放，以滿足3NF。

165. 一張自增表里面總共有 7 條數(shù)據(jù)，刪除了最后 2 條數(shù)據(jù)，重啟 MySQL 數(shù)據(jù)庫，又插入了一條數(shù)據(jù)，此時 id 是幾？
?? ?一般情況下，我們創(chuàng)建的表的類型是InnoDB，如果新增一條記錄（不重啟mysql的情況下），這條記錄的id是8；
?? ?但是如果重啟（文中提到的）MySQL的話，這條記錄的ID是6。因為InnoDB表只把自增主鍵的最大ID記錄到內(nèi)存中，
?? ?所以重啟數(shù)據(jù)庫或者對表OPTIMIZE操作，都會使最大ID丟失。
?? ?但是，如果我們使用表的類型是MylSAM，那么這條記錄的ID就是8。因為MylSAM表會把自增主鍵的最大ID記錄到數(shù)據(jù)文件里面，
?? ?重啟MYSQL后，自增主鍵的最大ID也不會丟失。
?? ?注：如果在這7條記錄里面刪除的是中間的幾個記錄（比如刪除的是3,4兩條記錄），重啟MySQL數(shù)據(jù)庫后，
?? ?insert一條記錄后，ID都是8。因為內(nèi)存或者數(shù)據(jù)庫文件存儲都是自增主鍵最大ID

166. 如何獲取當(dāng)前數(shù)據(jù)庫版本？
?? ?mysql
?? ?select version();
?? ?oralce
?? ?select * from v$version;

167. 說一下 ACID 是什么？
?? ?ACID，是指在可靠數(shù)據(jù)庫管理系統(tǒng)（DBMS）中，事務(wù)(transaction)所應(yīng)該具有的四個特性：
?? ?原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）.
?? ?這是可靠數(shù)據(jù)庫所應(yīng)具備的幾個特性.所以ACID就是這四大特性的縮寫。
?? ?原子性（Atomicity）
?? ??? ?原子性意味著數(shù)據(jù)庫中的事務(wù)執(zhí)行是作為原子。即不可再分，整個語句要么執(zhí)行，要么不執(zhí)行。
?? ??? ?在SQL SERVER中，每一個單獨的語句都可以看作是默認(rèn)包含在一個事務(wù)之中，每一個語句本身具有原子性，
?? ??? ?要么全部執(zhí)行，這么全部不執(zhí)行，不會有中間狀態(tài):
?? ??? ?例如：
?? ??? ?銀行轉(zhuǎn)賬功能，從A賬戶減去100，在B賬戶增加100，如果這兩個語句不能保證原子性的話，比如從A賬戶減去100后，
?? ??? ?服務(wù)器斷電，而在B賬戶中卻沒有增加100.雖然這種情況會讓銀行很開心，但作為開發(fā)人員的你可不希望這種結(jié)果.
?? ??? ?而默認(rèn)事務(wù)中，即使出錯了也不會整個事務(wù)進(jìn)行回滾。而是失敗的語句拋出異常，而正確的語句成功執(zhí)行。
?? ??? ?這樣會破壞原子性。所以SQL SERVER給予了一些選項來保證事務(wù)的原子性。
?? ?一致性(Consistency)
?? ??? ?一致性即在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性約束沒有被破壞。
?? ??? ?一致性體現(xiàn)在兩個層面：
?? ??? ?1.數(shù)據(jù)庫機(jī)制層面
?? ??? ?數(shù)據(jù)庫層面的一致性是，在一個事務(wù)執(zhí)行之前和之后，
?? ??? ?數(shù)據(jù)會符合你設(shè)置的約束（唯一約束，外鍵約束,Check約束等)和觸發(fā)器設(shè)置.
?? ??? ?這一點是由SQL SERVER進(jìn)行保證的.
?? ??? ?2.業(yè)務(wù)層面
?? ??? ?對于業(yè)務(wù)層面來說,一致性是保持業(yè)務(wù)的一致性.這個業(yè)務(wù)一致性需要由開發(fā)人員進(jìn)行保證.
?? ??? ?很多業(yè)務(wù)方面的一致性可以通過轉(zhuǎn)移到數(shù)據(jù)庫機(jī)制層面進(jìn)行保證.比如，產(chǎn)品只有兩個型號，
?? ??? ?則可以轉(zhuǎn)移到使用CHECK約束使某一列必須只能存這兩個型號.
?? ?隔離性（Isolation)
?? ??? ?隔離性。事務(wù)的執(zhí)行是互不干擾的，一個事務(wù)不可能看到其他事務(wù)運行時，中間某一時刻的數(shù)據(jù)。
?? ??? ?在Windows中，如果多個進(jìn)程對同一個文件進(jìn)行修改是不允許的，Windows通過這種方式來保證不同進(jìn)程的隔離性，
?? ??? ?而SQL Server中，通過SQL SERVER對數(shù)據(jù)庫文件進(jìn)行管理，從而可以讓多個進(jìn)程可以同時訪問數(shù)據(jù)庫:
?? ??? ?SQL Server利用加鎖和阻塞來保證事務(wù)之間不同等級的隔離性.
?? ??? ?一般情況下，完全的隔離性是不現(xiàn)實的，完全的隔離性要求數(shù)據(jù)庫同一時間只執(zhí)行一條事務(wù)，這樣的性能可想而知.
?? ??? ?想要理解SQL Server中對于隔離性的保障，首先要了解事務(wù)之間是如何干擾的.事務(wù)之間的互相影響的情況分為幾種，
?? ??? ?分別為:臟讀(Dirty Read)，不可重復(fù)讀，幻讀。
?? ?持久性（Durability)
?? ??? ?持久性，意味著在事務(wù)完成以后，該事務(wù)所對數(shù)據(jù)庫所作的更改便持久的保存在數(shù)據(jù)庫之中，并不會被回滾。
?? ??? ?即使出現(xiàn)了任何事故比如斷電等，事務(wù)一旦提交，則持久化保存在數(shù)據(jù)庫中.

168. char 和 varchar 的區(qū)別是什么？
?? ?1. char類型的長度是固定的，varchar的長度是可變的。
?? ? ? 這就表示，存儲字符串'abc'，使用char(10)，表示存儲的字符將占10個字節(jié)（包括7個空字符）
?? ?　　使用varchar2(10),，則表示只占3個字節(jié)，10是最大值，當(dāng)存儲的字符小于10時，按照實際的長度存儲。
?? ?2.char類型的效率比varchar的效率稍高
?? ?3.varchar 與 varchar2的區(qū)別
?? ?varchar2是oracle開發(fā)的一個數(shù)據(jù)類型。
?? ?工業(yè)標(biāo)準(zhǔn)的varchar可以存儲空字符串，oracle的varchar2還可以存儲NULL值，如果想要有向后兼容的能力建議使用varchar2
?? ?4.varchar2比char節(jié)省空間，但是在效率上比char稍差些。既要獲得效率即必須犧牲一點空間，這就是設(shè)計上的"以空間換時間"
?? ?varchar2雖然比char節(jié)省空間，但是一個varchar2列經(jīng)常被修改，而且每次修改的數(shù)據(jù)長度不同，這會引起“行遷移的現(xiàn)象”，
?? ?而這造成的多余的I/O，是數(shù)據(jù)庫設(shè)計中盡量避免的，在這種情況下使用char代替varchar2會更好些。
?? ?總結(jié)：1. 如果一個字段經(jīng)常被修改，而且每次修改的數(shù)據(jù)長度不同，
?? ?為了效率應(yīng)當(dāng)考慮用char定長代替varchar2變長。（列如一個用戶的名字經(jīng)常被修改）
?? ?　　? ? 2. 設(shè)計的時候盡量考慮 ?用空間換時間。

169. float 和 double 的區(qū)別是什么？
　　01.在內(nèi)存中占有的字節(jié)數(shù)不同
　　　　單精度浮點數(shù)在機(jī)內(nèi)存占4個字節(jié)
　　　　雙精度浮點數(shù)在機(jī)內(nèi)存占8個字節(jié)
　　02.有效數(shù)字位數(shù)不同
　　　　單精度浮點數(shù)有效數(shù)字8位
　　　　雙精度浮點數(shù)有效數(shù)字16位
　　03.數(shù)值取值范圍
　　　　單精度浮點數(shù)的表示范圍：-3.40E+38~3.40E+38
　　　　雙精度浮點數(shù)的表示范圍：-1.79E+308~-1.79E+308
　　04.在程序中處理速度不同
　　　　一般來說，CPU處理單精度浮點數(shù)的速度比處理雙精度浮點數(shù)快
?? ?如果不聲明，默認(rèn)小數(shù)為double類型，所以如果要用float的話，必須進(jìn)行強(qiáng)轉(zhuǎn)
?? ?　　例如：float ?a=1.3; 會編譯報錯，正確的寫法 float a = (float)1.3;
?? ?或者float a = 1.3f;（f或F都可以不區(qū)分大小寫）
?? ?注意：float是8位有效數(shù)字，第7位數(shù)字將會四舍五入

170. MySQL 的內(nèi)連接、左連接、右連接有什么區(qū)別？
?? ?1.內(nèi)連接,顯示兩個表中有聯(lián)系的所有數(shù)據(jù);
?? ?2.左鏈接,以左表為參照,顯示所有數(shù)據(jù),右表中沒有則以null顯示
?? ?3.右鏈接,以右表為參照顯示數(shù)據(jù)，,左表中沒有則以null顯示

171. MySQL 索引是怎么實現(xiàn)的？
?? ?.B_Tree適用于：
?? ?1.全值匹配
?? ?全值匹配是指和索引中的所有列進(jìn)行匹配。
?? ?2.匹配最左前綴
?? ?匹配左左前綴即只使用索引的第4102一列
?? ?3.匹配列前綴
?? ?匹配某一列開頭部分（指的第一列）。
?? ?4.匹配范圍值
?? ?5.精確匹配某一列并范圍匹配另1653一列
?? ?6.只訪問索引的查內(nèi)詢
?? ?只需訪問索引，無需訪問數(shù)據(jù)行。
?? ?.B_Tree限制
?? ?1.如果不是按照索引的最左列開始查找，則無法使用索引。
?? ?2.不能跳過索引中的列。
?? ?3.如果查詢中有容某個列的范圍查詢，則其右邊左右列無法使用索引優(yōu)化查找。

172. 怎么驗證 MySQL 的索引是否滿足需求？
?? ?使用 explain 查看 SQL 是如何執(zhí)行查詢語句的，從而分析你的索引是否滿足需求。
?? ?explain 語法：explain select * from table where type=1。
?? ?
173. 說一下數(shù)據(jù)庫的事務(wù)隔離？
?? ?Read uncommitted (讀未提交)：最低級別，以上問題均無法解決。
?? ?Read committed (讀已提交)：讀已提交，可避免臟讀情況發(fā)生。
?? ?Repeatable Read（可重復(fù)讀）：確保事務(wù)可以多次從一個字段中讀取相同的值，
?? ?在此事務(wù)持續(xù)期間，禁止其他事務(wù)對此字段的更新，
?? ?可以避免臟讀和不可重復(fù)讀，仍會出現(xiàn)幻讀問題。
?? ?Serializable （串行化）：最嚴(yán)格的事務(wù)隔離級別，要求所有事務(wù)被串行執(zhí)行，
?? ?不能并發(fā)執(zhí)行，可避免臟讀、不可重復(fù)讀、幻讀情況的發(fā)生。
?? ?
174. 說一下 MySQL 常用的引擎？
?? ?（1）：MyISAM存儲引擎：不支持事務(wù)、也不支持外鍵，優(yōu)勢是訪問速度快，對事務(wù)完整性沒有?
?? ?要求或者以select，insert為主的應(yīng)用基本上可以用這個引擎來創(chuàng)建表
?? ?支持3種不同的存儲格式，分別是：靜態(tài)表；動態(tài)表；壓縮表
?? ?靜態(tài)表：表中的字段都是非變長字段，這樣每個記錄都是固定長度的，優(yōu)點存儲非常迅速，容易緩存，出現(xiàn)故障容易恢復(fù)；
?? ?缺點是占用的空間通常比動態(tài)表多（因為存儲時會按照列的寬度定義補(bǔ)足空格）
?? ?ps：在取數(shù)據(jù)的時候，默認(rèn)會把字段后面的空格去掉，
?? ?如果不注意會把數(shù)據(jù)本身帶的空格也會忽略。
?? ?動態(tài)表：記錄不是固定長度的，這樣存儲的優(yōu)點是占用的空間相對較少；缺點：頻繁的更新、刪除數(shù)據(jù)容易產(chǎn)生碎片，
?? ?需要定期執(zhí)行OPTIMIZE TABLE或者myisamchk-r命令來改善性能
?? ?壓縮表：因為每個記錄是被單獨壓縮的，所以只有非常小的訪問開支
?? ?（2）InnoDB存儲引擎*
?? ?該存儲引擎提供了具有提交、回滾和崩潰恢復(fù)能力的事務(wù)安全。但是對比MyISAM引擎，寫的處理效率會差一些，
?? ?并且會占用更多的磁盤空間以保留數(shù)據(jù)和索引。?
?? ?InnoDB存儲引擎的特點：支持自動增長列，支持外鍵約束
?? ?(3)：MEMORY存儲引擎
?? ?Memory存儲引擎使用存在于內(nèi)存中的內(nèi)容來創(chuàng)建表。每個memory表只實際對應(yīng)一個磁盤文件，格式是.frm。
?? ?memory類型的表訪問非常的快，因為它的數(shù)據(jù)是放在內(nèi)存中的，
?? ?并且默認(rèn)使用HASH索引，但是一旦服務(wù)關(guān)閉，表中的數(shù)據(jù)就會丟失掉。?
?? ?MEMORY存儲引擎的表可以選擇使用BTREE索引或者HASH索引，兩種不同類型的索引有其不同的使用范圍
?? ?Hash索引優(yōu)點：?
?? ?Hash 索引結(jié)構(gòu)的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像B-Tree 索引需要從根節(jié)點到枝節(jié)點，
?? ?最后才能訪問到頁節(jié)點這樣多次的IO訪問，所以 Hash 索引的查詢效率要遠(yuǎn)高于 B-Tree 索引。?
?? ?Hash索引缺點： 那么不精確查找呢，也很明顯，因為hash算法是基于等值計算的，
?? ?所以對于“l(fā)ike”等范圍查找hash索引無效，不支持；
?? ?Memory類型的存儲引擎主要用于哪些內(nèi)容變化不頻繁的代碼表，或者作為統(tǒng)計操作的中間結(jié)果表，
?? ?便于高效地對中間結(jié)果進(jìn)行分析并得到最終的統(tǒng)計結(jié)果，。
?? ?對存儲引擎為memory的表進(jìn)行更新操作要謹(jǐn)慎，因為數(shù)據(jù)并沒有實際寫入到磁盤中，
?? ?所以一定要對下次重新啟動服務(wù)后如何獲得這些修改后的數(shù)據(jù)有所考慮。
?? ?（4）MERGE存儲引擎
?? ?Merge存儲引擎是一組MyISAM表的組合，這些MyISAM表必須結(jié)構(gòu)完全相同，merge表本身并沒有數(shù)據(jù)，
?? ?對merge類型的表可以進(jìn)行查詢，更新，刪除操作，這些操作實際上是對內(nèi)部的MyISAM表進(jìn)行的。

175. 說一下 MySQL 的行鎖和表鎖？
?? ?表鎖：偏向MyISAM存儲引擎，開銷小，加鎖快，無死鎖，鎖定粒度大，發(fā)送鎖沖突的概率最高，并發(fā)度最低
?? ?結(jié)論:讀鎖會阻塞寫，寫鎖會阻塞讀和寫
?? ?對MyISAM表的讀操作，不會阻塞其它進(jìn)程對同一表的讀請求，但會阻塞對同一表的寫請求。
?? ?只有當(dāng)讀鎖釋放后，才會執(zhí)行其它進(jìn)程的寫操作。
?? ?對MyISAM表的寫操作，會阻塞其它進(jìn)程對同一表的讀和寫操作，只有當(dāng)寫鎖釋放后，才會執(zhí)行其它進(jìn)程的讀寫操作。
?? ?MyISAM不適合做寫為主表的引擎，因為寫鎖后，其它線程不能做任何操作，大量的更新會使查詢很難得到鎖，從而造成永遠(yuǎn)阻塞
?? ?
?? ?行鎖：偏向InnoDB存儲引擎，開銷大，加鎖慢，會出現(xiàn)死鎖，鎖定粒度小，發(fā)送鎖沖突的概率最低，并發(fā)度也最高
?? ?當(dāng)選中某一行時，如果是通過主鍵或者索引選中的，這個時候是行級鎖；如果是通過其它條件選中的，這個時候行級鎖會升級成表鎖，
?? ?其它事務(wù)無法對當(dāng)前表進(jìn)行更新或插入操作
?? ?適用范圍：
?? ??? ?A用戶消費，service層先查詢該用戶的賬戶余額，若余額足夠，則進(jìn)行后續(xù)的扣款操作；
?? ??? ?這種情況查詢的時候應(yīng)該對該記錄進(jìn)行加鎖
?? ??? ?否則，B用戶在A用戶查詢后消費前先一步將A用戶賬號上的錢轉(zhuǎn)走，而此時A用戶已經(jīng)進(jìn)行了用戶余額是否足夠的判斷，
?? ??? ?則可能會出現(xiàn)余額已經(jīng)不足但卻扣款成功的情況
?? ??? ?為了避免此情況，需要在A用戶操作該記錄的時候進(jìn)行for update加鎖
?? ?當(dāng)我們用范圍條件而不是相等條件檢索數(shù)據(jù)，并請求共享或排他鎖時，InnoDB會給符合條件的已有數(shù)據(jù)記錄的索引項加鎖；
?? ?對于鍵值在條件范圍內(nèi)并不存在的記錄，叫做間隙
?? ?InnoDB也會對這個"間隙"加鎖，這種鎖機(jī)制就是所謂的間隙鎖
?? ?優(yōu)化建議：
?? ??? ?盡可能讓所有數(shù)據(jù)檢索都通過索引來完成，避免無索引行鎖升級為表鎖
?? ??? ?合理設(shè)計索引，盡量縮小鎖的范圍
?? ??? ?盡可能減少索引條件，避免間隙鎖
?? ??? ?盡量控制事務(wù)大小，減少鎖定資源量和時間長度
?? ??? ?盡可能低級別事務(wù)隔離
?? ?
?? ?
176. 說一下樂觀鎖和悲觀鎖？
?? ?何謂悲觀鎖與樂觀鎖
?? ??? ?樂觀鎖對應(yīng)于生活中樂觀的人總是想著事情往好的方向發(fā)展，悲觀鎖對應(yīng)于生活中悲觀的人總是想著事情往壞的方向發(fā)展。
?? ??? ?這兩種人各有優(yōu)缺點，不能不以場景而定說一種人好于另外一種人。
?? ?悲觀鎖
?? ??? ?總是假設(shè)最壞的情況，每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改，所以每次在拿數(shù)據(jù)的時候都會上鎖，
?? ??? ?這樣別人想拿這個數(shù)據(jù)就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉(zhuǎn)讓給其它線程）。
?? ??? ?傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
?? ??? ?Java中synchronized和ReentrantLock等獨占鎖就是悲觀鎖思想的實現(xiàn)。
?? ?樂觀鎖
?? ??? ?總是假設(shè)最好的情況，每次去拿數(shù)據(jù)的時候都認(rèn)為別人不會修改，所以不會上鎖，
?? ??? ?但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)，可以使用版本號機(jī)制和CAS算法實現(xiàn)。
?? ??? ?樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量，像數(shù)據(jù)庫提供的類似于write_condition機(jī)制，其實都是提供的樂觀鎖。
?? ??? ?在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現(xiàn)方式CAS實現(xiàn)的。
?? ?兩種鎖的使用場景
?? ??? ?從上面對兩種鎖的介紹，我們知道兩種鎖各有優(yōu)缺點，不可認(rèn)為一種好于另一種，像樂觀鎖適用于寫比較少的情況下（多讀場景），
?? ??? ?即沖突真的很少發(fā)生的時候，這樣可以省去了鎖的開銷，加大了系統(tǒng)的整個吞吐量。但如果是多寫的情況，一般會經(jīng)常產(chǎn)生沖突，
?? ??? ?這就會導(dǎo)致上層應(yīng)用會不斷的進(jìn)行retry，這樣反倒是降低了性能，所以一般多寫的場景下用悲觀鎖就比較合適。
?? ?樂觀鎖常見的兩種實現(xiàn)方式
?? ??? ?樂觀鎖一般會使用版本號機(jī)制或CAS算法實現(xiàn)。
?? ??? ?1. 版本號機(jī)制
?? ??? ?一般是在數(shù)據(jù)表中加上一個數(shù)據(jù)版本號version字段，表示數(shù)據(jù)被修改的次數(shù)，當(dāng)數(shù)據(jù)被修改時，version值會加一。
?? ??? ?當(dāng)線程A要更新數(shù)據(jù)值時，在讀取數(shù)據(jù)的同時也會讀取version值，在提交更新時，
?? ??? ?若剛才讀取到的version值為當(dāng)前數(shù)據(jù)庫中的version值相等時才更新，否則重試更新操作，直到更新成功。
?? ??? ?2. CAS算法
?? ??? ?即compare and swap（比較與交換），是一種有名的無鎖算法。無鎖編程，即不使用鎖的情況下實現(xiàn)多線程之間的變量同步，
?? ??? ?也就是在沒有線程被阻塞的情況下實現(xiàn)變量的同步，
?? ??? ?所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三個操作數(shù)
?? ??? ?需要讀寫的內(nèi)存值 V
?? ??? ?進(jìn)行比較的值 A
?? ??? ?擬寫入的新值 B
?? ??? ?當(dāng)且僅當(dāng) V 的值等于 A時，CAS通過原子方式用新值B來更新V的值，否則不會執(zhí)行任何操作（比較和替換是一個原子操作）。
?? ??? ?一般情況下是一個自旋操作，即不斷的重試。
?? ?樂觀鎖的缺點：
?? ??? ?ABA 問題是樂觀鎖一個常見的問題
?? ??? ?1 ABA 問題
?? ??? ?如果一個變量V初次讀取的時候是A值，并且在準(zhǔn)備賦值的時候檢查到它仍然是A值，
?? ??? ?那我們就能說明它的值沒有被其他線程修改過了嗎？
?? ??? ?很明顯是不能的，因為在這段時間它的值可能被改為其他值，然后又改回A，那CAS操作就會誤認(rèn)為它從來沒有被修改過。
?? ??? ?這個問題被稱為CAS操作的 "ABA"問題。
?? ??? ?JDK 1.5 以后的 AtomicStampedReference 類就提供了此種能力，
?? ??? ?其中的 compareAndSet 方法就是首先檢查當(dāng)前引用是否等于預(yù)期引用，
?? ??? ?并且當(dāng)前標(biāo)志是否等于預(yù)期標(biāo)志，如果全部相等，則以原子方式將該引用和該標(biāo)志的值設(shè)置為給定的更新值。
?? ??? ?2 循環(huán)時間長開銷大
?? ??? ?自旋CAS（也就是不成功就一直循環(huán)執(zhí)行直到成功）如果長時間不成功，會給CPU帶來非常大的執(zhí)行開銷。?
?? ??? ?如果JVM能支持處理器提供的pause指令那么效率會有一定的提升，pause指令有兩個作用，
?? ??? ?第一它可以延遲流水線執(zhí)行指令（de-pipeline）,使CPU不會消耗過多的執(zhí)行資源，延遲的時間取決于具體實現(xiàn)的版本，
?? ??? ?在一些處理器上延遲時間是零。第二它可以避免在退出循環(huán)的時候因內(nèi)存順序沖突（memory order violation）
?? ??? ?而引起CPU流水線被清空（CPU pipeline flush），從而提高CPU的執(zhí)行效率。
?? ??? ?3 只能保證一個共享變量的原子操作
?? ??? ?CAS 只對單個共享變量有效，當(dāng)操作涉及跨多個共享變量時 CAS 無效。但是從 JDK 1.5開始，
?? ??? ?提供了AtomicReference類來保證引用對象之間的原子性，你可以把多個變量放在一個對象里來進(jìn)行 CAS 操作.
?? ??? ?所以我們可以使用鎖或者利用AtomicReference類把多個共享變量合并成一個共享變量來操作。
?? ?CAS與synchronized的使用情景
?? ??? ?簡單的來說CAS適用于寫比較少的情況下（多讀場景，沖突一般較少），
?? ??? ?synchronized適用于寫比較多的情況下（多寫場景，沖突一般較多）
?? ??? ?對于資源競爭較少（線程沖突較輕）的情況，
?? ??? ?使用synchronized同步鎖進(jìn)行線程阻塞和喚醒切換以及用戶態(tài)內(nèi)核態(tài)間的切換操作額外浪費消耗cpu資源；
?? ??? ?而CAS基于硬件實現(xiàn)，不需要進(jìn)入內(nèi)核，不需要切換線程，操作自旋幾率較少，因此可以獲得更高的性能。
?? ??? ?對于資源競爭嚴(yán)重（線程沖突嚴(yán)重）的情況，CAS自旋的概率會比較大，從而浪費更多的CPU資源，效率低于synchronized。
?? ?補(bǔ)充： Java并發(fā)編程這個領(lǐng)域中synchronized關(guān)鍵字一直都是元老級的角色，很久之前很多人都會稱它為 “重量級鎖” 。
?? ??? ?但是，在JavaSE 1.6之后進(jìn)行了主要包括為了減少獲得鎖和釋放鎖帶來的性能消耗而引入的 偏向鎖 和 輕量級鎖?
?? ??? ?以及其它各種優(yōu)化之后變得在某些情況下并不是那么重了。synchronized的底層實現(xiàn)主要依靠 Lock-Free 的隊列，基本思路是
?? ??? ?自旋后阻塞，競爭切換后繼續(xù)競爭鎖，稍微犧牲了公平性，但獲得了高吞吐量。
?? ??? ?在線程沖突較少的情況下，可以獲得和CAS類似的性能；
?? ??? ?而線程沖突嚴(yán)重的情況下，性能遠(yuǎn)高于CAS。

177. MySQL 問題排查都有哪些手段？
?? ?使用 show processlist 命令查看當(dāng)前所有連接信息。
?? ?使用 explain 命令查詢 SQL 語句執(zhí)行計劃。
?? ?開啟慢查詢?nèi)罩?#xff0c;查看慢查詢的 SQL。

178. 如何做 MySQL 的性能優(yōu)化？
?? ?為搜索字段創(chuàng)建索引。
?? ?避免使用 select *，列出需要查詢的字段。
?? ?垂直分割分表。
?? ?選擇正確的存儲引擎。

Redis
179. Redis 是什么？都有哪些使用場景？
?? ?Redis是一個高性能的key-value數(shù)據(jù)庫。
?? ?Redis 與其他 key - value 緩存產(chǎn)品有以下三個特點：
?? ?- Redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保存在磁盤中，重啟的時候可以再次加載進(jìn)行使用。
?? ?- Redis不僅僅支持簡單的key-value類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。
?? ?- Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

總結(jié)

以上是生活随笔為你收集整理的面试题总结151-179的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。