面试题总结151-179
151. RabbitMQ 對集群節點停止順序有要求嗎？
?? ?RabbitMQ 對集群的停止的順序是有要求的，應該先關閉內存節點，最后再關閉磁盤節點。
?? ?如果順序恰好相反的話，可能會造成消息的丟失。
Kafka
152.kafka 可以脫離 zookeeper 單獨使用嗎？為什么？
?? ?kafka 不能脫離 zookeeper 單獨使用，因為 kafka 使用 zookeeper 管理和協調 kafka 的節點服務器。
153.kafka 有幾種數據保留的策略？
?? ?kafka 有兩種數據保存策略：按照過期時間保留和按照存儲的消息大小保留。
154.kafka 同時設置了 7 天和 10G 清除數據，到第五天的時候消息達到了 10G，這個時候 kafka 將如何處理？
?? ?這個時候 kafka 會執行數據清除工作，時間和大小不論那個滿足條件，都會清空數據。
155.什么情況會導致 kafka 運行變慢？
?? ?cpu 性能瓶頸
?? ?磁盤讀寫瓶頸
?? ?網絡瓶頸
156.使用 kafka 集群需要注意什么？
?? ?集群的數量不是越多越好，最好不要超過 7 個，因為節點越多，消息復制需要的時間就越長，整個群組的吞吐量就越低。
?? ?集群數量最好是單數，因為超過一半故障集群就不能用了，設置為單數容錯率更高。
?? ?
?? ?
Zookeeper
157. zookeeper 是什么？
?? ?一.zookeeper 是什么
?? ??? ?ZooKeeper由雅虎研究院開發，是Google Chubby的開源實現，后來托管到Apache，于2010年11月正式成為Apache的頂級項目。
?? ??? ?ZooKeeper是一個經典的分布式數據一致性解決方案，致力于為分布式應用提供一個高性能、高可用，
?? ??? ?且具有嚴格順序訪問控制能力的分布式協調服務。
?? ??? ?分布式應用程序可以基于ZooKeeper實現數據發布與訂閱、負載均衡、命名服務、分布式協調與通知、集群管理、
?? ??? ?Leader選舉、分布式鎖、分布式隊列等功能。
?? ?二.ZooKeeper目標
?? ??? ?ZooKeeper致力于為分布式應用提供一個高性能、高可用，且具有嚴格順序訪問控制能力的分布式協調服務
?? ??? ?2.1 高性能
?? ??? ?ZooKeeper將全量數據存儲在內存中，并直接服務于客戶端的所有非事務請求，尤其適用于以讀為主的應用場景
?? ??? ?2.2 高可用
?? ??? ?ZooKeeper一般以集群的方式對外提供服務，一般3 ~ 5臺機器就可以組成一個可用的Zookeeper集群了，
?? ??? ?每臺機器都會在內存中維護當前的服務器狀態，并且每臺機器之間都相互保持著通信。
?? ??? ?只要集群中超過一般的機器都能夠正常工作，那么整個集群就能夠正常對外服務
?? ??? ?2.3 嚴格順序訪問
?? ??? ?對于來自客戶端的每個更新請求，ZooKeeper都會分配一個全局唯一的遞增編號，這個編號反映了所有事務操作的先后順序
?? ?三.ZooKeeper五大特性
?? ??? ?ZooKeeper一般以集群的方式對外提供服務，一個集群包含多個節點，每個節點對應一臺ZooKeeper服務器，
?? ??? ?所有的節點共同對外提供服務，整個集群環境對分布式數據一致性提供了全面的支持，具體包括以下五大特性：
?? ??? ?3.1 順序一致性
?? ??? ?從同一個客戶端發起的請求，最終將會嚴格按照其發送順序進入ZooKeeper中
?? ??? ?3.2 原子性
?? ??? ?所有請求的響應結果在整個分布式集群環境中具備原子性，即要么整個集群中所有機器都成功的處理了某個請求，
?? ??? ?要么就都沒有處理，絕對不會出現集群中一部分機器處理了某一個請求，而另一部分機器卻沒有處理的情況
?? ??? ?3.3 單一性
?? ??? ?無論客戶端連接到ZooKeeper集群中哪個服務器，每個客戶端所看到的服務端模型都是一致的，
?? ??? ?不可能出現兩種不同的數據狀態，因為ZooKeeper集群中每臺服務器之間會進行數據同步
?? ??? ?3.4 可靠性
?? ??? ?一旦服務端數據的狀態發送了變化，就會立即存儲起來，除非此時有另一個請求對其進行了變更，否則數據一定是可靠的
?? ??? ?3.5 實時性
?? ??? ?當某個請求被成功處理后，ZooKeeper僅僅保證在一定的時間段內，客戶端最終一定能從服務端上讀取到最新的數據狀態，
?? ??? ?即ZooKeeper保證數據的最終一致性
?? ?四.ZooKeeper集群角色
?? ??? ?在分布式系統中，集群中每臺機器都有自己的角色，ZooKeeper沒有沿用傳統的Master/Slave模式（主備模式），
?? ??? ?而是引入了Leader、Follower和Observer三種角色
?? ??? ?4.1 Leader
?? ??? ?集群通過一個Leader選舉過程從所有的機器中選舉一臺機器作為”Leader”，Leader能為客戶端提供讀和寫服務
?? ??? ?Leader服務器是整個集群工作機制的核心，主要工作：
?? ??? ??? ?1.事務請求的唯一調度者和處理者，保證集群事務處理的順序性
?? ??? ??? ?2.集群內部各服務器的調度者
?? ??? ?4.2 Follower
?? ??? ?顧名思義，Follower是追隨者，主要工作：
?? ??? ??? ?1.參與Leader選舉投票
?? ??? ??? ?2.處理客戶端非事務請求 - 即讀服務
?? ??? ??? ?3.轉發事務請求給Leader服務器
?? ??? ??? ?4.參與事務請求Proposal的投票
?? ??? ?4.3 Observer
?? ??? ?Observer是ZooKeeper自3.3.0版本開始引入的一個全新的服務器角色，充當一個觀察者角色，
?? ??? ?工作原理和Follower基本是一致的，和Follower唯一的區別是Observer不參與任何形式的投票
?? ??? ??? ?1.處理客戶端非事務請求 - 即讀服務
?? ??? ??? ?2.轉發事務請求給Leader服務器
?? ??? ??? ?3.不參與Leader選舉投票
?? ??? ??? ?4.參與事務請求Proposal的投票
?? ??? ?所以Observer可以在不影響寫性能的情況下提升集群的讀性能
?? ?五. 原子廣播協議 - Zab
?? ??? ?ZooKeeper并非采用經典的分布式一致性協議 - Paxos，
?? ??? ?而是參考了Paxos設計了一種更加輕量級的支持崩潰可恢復的原子廣播協議-Zab（ZooKeeper Atomic Broadcast）。
?? ??? ?ZAB協議分為兩個階段 - Leader Election（領導選舉）和Atomic Broadcast（原子廣播）
?? ??? ?5.1 領導選舉 - Leader Election
?? ??? ?當集群啟動時，會選舉一臺節點為Leader，而其他節點為Follower，當Leader節點出現網絡中斷、崩潰退出與重啟等異常情況，
?? ??? ?ZAB會進入恢復模式并選舉產生新的Leader服務器，當集群中已有過半機器與該Leader服務器完成數據狀態同步，退出恢復模式
?? ??? ?5.2 原子廣播 - Atomic Broadcast
?? ??? ?當領導選舉完成后，就進入原子廣播階段。此時集群中已存在一個Leader服務器在進行消息廣播，
?? ??? ?當一臺同樣遵循ZAB協議的服務器啟動后加入到集群中，新加的服務器會自動進入數據恢復階段
?? ?六. 事務請求
?? ??? ?在ZooKeeper中，事務是指能夠改變ZooKeeper服務器狀態的請求，一般指創建節點、更新數據、刪除節點以及創建會話操作
?? ??? ?6.1 事務轉發
?? ??? ?為了保證事務請求被順序執行，從而確保ZooKeeper集群的數據一致性，所有的事務請求必須由Leader服務器處理，
?? ??? ?ZooKeeper實現了非常特別的事務請求轉發機制：
?? ??? ?所有非Leader服務器如果接收到來自客戶端的事務請求，必須將其轉發給Leader服務器來處理
?? ??? ?6.2 事務ID - ZXID
?? ??? ?在分布式系統中，事務請求可能存在依賴關系，如變更C需要依賴變更A和變更B，
?? ??? ?這樣就要求ZAB協議能夠保證如果一個狀態變更成功被處理了，那么其所有依賴的狀態變更都應該已經提前被處理掉了。
?? ??? ?在ZooKeeper中對每一個事務請求，都會為其分配一個全局唯一的事務ID，使用ZXID表示，通常是一個64位的數字。
?? ??? ?每一個ZXID對應一次事務，從這些ZXID可以間接識別出ZooKeeper處理這些事務請求的全局順序
?? ?七. 數據節點 - ZNode
?? ??? ?ZooKeeper內部擁有一個樹狀的內存模型，類似文件系統，只是在ZooKeeper中將這些目錄與文件系統統稱為ZNode，
?? ??? ?ZNode是ZooKeeper中數據的最小單元，每個ZNode上可以保存數據，還可以掛載子節點，因此構成了一個層次化的命名空間
?? ??? ?7.1 節點路徑
?? ??? ?ZooKeeper中使用斜杠（/）分割的路徑表示ZNode路徑，斜杠（/）表示根節點
?? ??? ?7.2 節點特性
?? ??? ?在ZooKeeper中，每個數據節點ZNode都是有生命周期的，其生命周期的長短取決于ZNode的節點類型
?? ??? ?7.3 權限控制 - ACL
?? ??? ?為了有效保障ZooKeeper中數據的安全，避免因誤操作而帶來數據隨意變更導致分布式系統異常，
?? ??? ?ZooKeeper提供了一套完善的ACL（Access Contro List）權限控制機制來保障數據的安全。
?? ??? ?可以從三個方面理解ACL機制，分別是：權限模式（Scheme）、授權對象（ID）和權限（Permission），
?? ??? ?通常使用”scheme:id:permission”來標識一個有效的ACL信息
?? ??? ?7.4 節點狀態信息
?? ??? ?每個數據節點ZNode除了存儲數據內容外，還存儲了數據節點本身的一些狀態信息
?? ??? ?7.5 節點版本
?? ??? ?ZooKeeper為數據節點引入版本的概念，對個數據節點都具有三種類型的版本信息，對數據節點的任何更新操作都會引起版本號的變化
?? ??? ?在分布式系統中，在運行過程中往往需要保證數據訪問的排他性。Java并發中是實現了對CAS的指令支持，即對于值V，
?? ??? ?每次更新前都會比對其值是否是預期值A，只有符合預期，才會將V原子化的更新到新值B
?? ??? ?而ZooKeeper每個節點都有數據版本的概念，在調用更新操作的時候，先從請求中獲取當前請求的版本version，
?? ??? ?同時獲取服務器上該數據最新版本currentVersion，如果無法匹配，就無法更新成功，這樣可以有效避免一些分布式更新的并發問題
?? ?八. Watcher - 數據變更的通知
?? ??? ?在ZooKeeper中，引入Watcher機制來實現分布式數據的發布/訂閱功能。ZooKeeper允許客戶端向服務器注冊一個Watcher監聽，
?? ??? ?當服務器的一些指定事件觸發了這個Watcher，那么就會向指定客戶端發送一個事件通知來實現分布式的通知功能
?? ??? ?Watcher機制為以下三個過程：
?? ??? ?8.1 客戶端注冊Watcher
?? ??? ?在創建一個ZooKeeper客戶端對象實例時，可以向構造方法中傳入一個Watcher，這個Watcher將作為整個ZooKeeper會話期間的默認Watcher，
?? ??? ?一致保存在客戶端，并向ZooKeeper服務器注冊Watcher
?? ??? ?客戶端并不會把真實的Watcher對象傳遞到服務器，僅僅只是在客戶端請求中使用boolean類型屬性進行標記，降低網絡開銷和服務器內存開銷
?? ??? ?8.2 服務端處理Watcher
?? ??? ?服務端執行數據變更，當Watcher監聽的對應數據節點的數據內容發生變更，如果找到對應的Watcher，會將其提取出來，
?? ??? ?同時從管理中將其刪除（說明Watcher在服務端是一次性的，即觸發一次就失效了），觸發Watcher，向客戶端發送通知
?? ??? ?8.3 客戶端回調Watcher
?? ??? ?客戶端獲取通知，識別出事件類型，從相應的Watcher存儲中去除對應的Watcher（說明客戶端也是一次性的，即一旦觸發就會失效）
?? ??? ?8.4 總結
?? ??? ?一致性：無論是客戶端還是服務器，一旦一個Watcher被處罰，ZooKeeper都會將其從相應的存儲中移除，
?? ??? ?因此開發人員在Watcher使用上要反復注冊，這樣可以有效減輕服務器壓力
?? ??? ?客戶端串行執行：客戶端Watcher回調的過程是一個串行同步的過程，這保證了順序
?? ??? ?輕量：客戶端并不會把真實的Watcher對象傳遞到服務器，僅僅只是在客戶端請求中使用boolean類型屬性進行標記，
?? ??? ?降低網絡開銷和服務器內存開銷
?? ?九. Session - 會話
?? ??? ?Session是指客戶端連接 - 客戶端和服務器之間的一個TCP長連接
?? ??? ?9.1 會話狀態
?? ??? ?會話在整個生命周期中，會在不同的會話轉態之間進行切換
?? ??? ?9.2 Session屬性
?? ??? ?Session是ZooKeeper中的會話實體，代表了一個客戶端會話，其包含4個屬性：
?? ??? ?9.3 心跳檢測
?? ??? ?為了保證客戶端會話的有效性，客戶端會在會話超時時間范圍內向服務器發送PING請求來保持會話的有效性，即心跳檢測。
?? ??? ?服務器接收到客戶端的這個心跳檢測，就會重新激活對應的客戶端會話
?? ??? ?9.4 會話清理
?? ??? ?服務器的超級檢查線程會在指定時間點進行檢查，整理出一些已經過期的會話后，就要開始進行會話清理了：
?? ??? ?關閉會話
?? ??? ?清理相關的臨時節點
?? ??? ?9.5 重連
?? ??? ?當客戶端和服務器之間網絡連接斷開，客戶端會自動進行反復的重連，直到最終成功連接上ZooKeeper集群中的一臺機器
?? ??? ?在會話超時時間內重新連接上，被視為重連成功
?? ??? ?在會話超時時間外重新連接上，此時服務器已經進行了會話清理，但客戶端不知道會話已經失效，
?? ??? ?重新連接服務器會告訴客戶端會話已失效，被視為非法會話
158. zookeeper 都有哪些功能？
?? ?集群管理：監控節點存活狀態、運行請求等。
?? ?主節點選舉：主節點掛掉之后可以從備用節點開始新一輪選舉，主節點選舉說的就是這個選舉的過程，使用zookeeper可以是協助完成這個過程。
?? ?費不是鎖：zookeeper提供兩種鎖：獨占鎖、共享鎖。獨占鎖即一次只能有一個線程使用資源，共享鎖是讀鎖共享，讀寫互斥，
?? ?既可以有多線程童師傅去一個資源，如果要使用寫鎖也只能有一個線程使用。zookeeper可以對分布式鎖進行控制。
?? ?命名服務：在分布式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等信息。
159. zookeeper 有幾種部署模式？
?? ?zookeeper有三種部署模式：
?? ?單機部署：一臺集群上運行；
?? ?集群部署：多臺集群運行；
?? ?偽集群部署：一臺進群啟動多個zookeeper實例運行；
?? ?
?? ?
160. zookeeper 怎么保證主從節點的狀態同步？
?? ?Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。
?? ?Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。
?? ?恢復模式：當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，
?? ?且大多數Server完成了和leader的狀態同步以后，恢復模式就結束了。因此，選主得到的leader保證了同步狀態的進行，
?? ?狀態同步又保證了leader和Server具有相同的系統狀態，當leader失去主權后可以在其他follower中選主新的leader。
161. 集群中為什么要有主節點？
?? ?在分布式環境中，有些業務邏輯只需要集群中的某一臺機器進行執行，
?? ?其他的機器可以共享這個結果，這樣可以大大減少重復計算，提高性能，所以就需要主節點
162. 集群中有 3 臺服務器，其中一個節點宕機，這個時候 zookeeper 還可以使用嗎？
?? ?可以繼續使用，單數服務器只要沒超過一半的服務器宕機就可以繼續使用。
163. 說一下 zookeeper 的通知機制？
?? ?客戶端端會對某個 znode 建立一個 watcher 事件，
?? ?當該 znode 發生變化時，這些客戶端會收到 zookeeper 的通知，
?? ?然后客戶端可以根據 znode 變化來做出業務上的改變。
?? ?
?? ?
MySQL
164. 數據庫的三范式是什么？
?? ?1、第一范式，又稱1NF，它指的是在一個應用中的數據都可以組織成由行和列的表格形式，且表格的任意一個行列交叉點即單元格，
?? ?都不可再劃分為行和列的形式，實際上任意一張表格都滿復足1NF；?
?? ?2、第二范式，又稱2NF，它指的是在滿足1NF的基礎上，
?? ?一張數據表中的任何非主鍵字段都全部依賴于主鍵字段，沒有制任何非主鍵字段只依賴于主鍵字段的一部分。
?? ?即，可以由主鍵字段來唯一的確定一條記錄。比如學號+課程號的聯合主鍵，可以唯一的確定某個成績是哪個學員的哪門課的成績，
?? ?缺少學號或者缺少課程號，都不能確定成績的意義。
?? ?3、第三范式，又稱3NF，它是知指在滿足2NF的基礎上，
?? ?數據表的任何非主鍵字段之間都不產生函數依賴，即非主鍵字段之間沒有依賴關系，全部只依賴于道主鍵字段。
?? ?例如將學員姓名和所屬班級名稱放在同一張表中是不科學的，因為學員依賴于班級，可將學員信息和班級信息單獨存放，以滿足3NF。
165. 一張自增表里面總共有 7 條數據，刪除了最后 2 條數據，重啟 MySQL 數據庫，又插入了一條數據，此時 id 是幾？
?? ?一般情況下，我們創建的表的類型是InnoDB，如果新增一條記錄（不重啟mysql的情況下），這條記錄的id是8；
?? ?但是如果重啟（文中提到的）MySQL的話，這條記錄的ID是6。因為InnoDB表只把自增主鍵的最大ID記錄到內存中，
?? ?所以重啟數據庫或者對表OPTIMIZE操作，都會使最大ID丟失。
?? ?但是，如果我們使用表的類型是MylSAM，那么這條記錄的ID就是8。因為MylSAM表會把自增主鍵的最大ID記錄到數據文件里面，
?? ?重啟MYSQL后，自增主鍵的最大ID也不會丟失。
?? ?注：如果在這7條記錄里面刪除的是中間的幾個記錄（比如刪除的是3,4兩條記錄），重啟MySQL數據庫后，
?? ?insert一條記錄后，ID都是8。因為內存或者數據庫文件存儲都是自增主鍵最大ID
166. 如何獲取當前數據庫版本？
?? ?mysql
?? ?select version();
?? ?oralce
?? ?select * from v$version;
167. 說一下 ACID 是什么？
?? ?ACID，是指在可靠數據庫管理系統（DBMS）中，事務(transaction)所應該具有的四個特性：
?? ?原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）.
?? ?這是可靠數據庫所應具備的幾個特性.所以ACID就是這四大特性的縮寫。
?? ?原子性（Atomicity）
?? ??? ?原子性意味著數據庫中的事務執行是作為原子。即不可再分，整個語句要么執行，要么不執行。
?? ??? ?在SQL SERVER中，每一個單獨的語句都可以看作是默認包含在一個事務之中，每一個語句本身具有原子性，
?? ??? ?要么全部執行，這么全部不執行，不會有中間狀態:
?? ??? ?例如：
?? ??? ?銀行轉賬功能，從A賬戶減去100，在B賬戶增加100，如果這兩個語句不能保證原子性的話，比如從A賬戶減去100后，
?? ??? ?服務器斷電，而在B賬戶中卻沒有增加100.雖然這種情況會讓銀行很開心，但作為開發人員的你可不希望這種結果.
?? ??? ?而默認事務中，即使出錯了也不會整個事務進行回滾。而是失敗的語句拋出異常，而正確的語句成功執行。
?? ??? ?這樣會破壞原子性。所以SQL SERVER給予了一些選項來保證事務的原子性。
?? ?一致性(Consistency)
?? ??? ?一致性即在事務開始之前和事務結束以后，數據庫的完整性約束沒有被破壞。
?? ??? ?一致性體現在兩個層面：
?? ??? ?1.數據庫機制層面
?? ??? ?數據庫層面的一致性是，在一個事務執行之前和之后，
?? ??? ?數據會符合你設置的約束（唯一約束，外鍵約束,Check約束等)和觸發器設置.
?? ??? ?這一點是由SQL SERVER進行保證的.
?? ??? ?2.業務層面
?? ??? ?對于業務層面來說,一致性是保持業務的一致性.這個業務一致性需要由開發人員進行保證.
?? ??? ?很多業務方面的一致性可以通過轉移到數據庫機制層面進行保證.比如，產品只有兩個型號，
?? ??? ?則可以轉移到使用CHECK約束使某一列必須只能存這兩個型號.
?? ?隔離性（Isolation)
?? ??? ?隔離性。事務的執行是互不干擾的，一個事務不可能看到其他事務運行時，中間某一時刻的數據。
?? ??? ?在Windows中，如果多個進程對同一個文件進行修改是不允許的，Windows通過這種方式來保證不同進程的隔離性，
?? ??? ?而SQL Server中，通過SQL SERVER對數據庫文件進行管理，從而可以讓多個進程可以同時訪問數據庫:
?? ??? ?SQL Server利用加鎖和阻塞來保證事務之間不同等級的隔離性.
?? ??? ?一般情況下，完全的隔離性是不現實的，完全的隔離性要求數據庫同一時間只執行一條事務，這樣的性能可想而知.
?? ??? ?想要理解SQL Server中對于隔離性的保障，首先要了解事務之間是如何干擾的.事務之間的互相影響的情況分為幾種，
?? ??? ?分別為:臟讀(Dirty Read)，不可重復讀，幻讀。
?? ?持久性（Durability)
?? ??? ?持久性，意味著在事務完成以后，該事務所對數據庫所作的更改便持久的保存在數據庫之中，并不會被回滾。
?? ??? ?即使出現了任何事故比如斷電等，事務一旦提交，則持久化保存在數據庫中.
168. char 和 varchar 的區別是什么？
?? ?1. char類型的長度是固定的，varchar的長度是可變的。
?? ? ? 這就表示，存儲字符串'abc'，使用char(10)，表示存儲的字符將占10個字節（包括7個空字符）
?? ? 使用varchar2(10),，則表示只占3個字節，10是最大值，當存儲的字符小于10時，按照實際的長度存儲。
?? ?2.char類型的效率比varchar的效率稍高
?? ?3.varchar 與 varchar2的區別
?? ?varchar2是oracle開發的一個數據類型。
?? ?工業標準的varchar可以存儲空字符串，oracle的varchar2還可以存儲NULL值，如果想要有向后兼容的能力建議使用varchar2
?? ?4.varchar2比char節省空間，但是在效率上比char稍差些。既要獲得效率即必須犧牲一點空間，這就是設計上的"以空間換時間"
?? ?varchar2雖然比char節省空間，但是一個varchar2列經常被修改，而且每次修改的數據長度不同，這會引起“行遷移的現象”，
?? ?而這造成的多余的I/O，是數據庫設計中盡量避免的，在這種情況下使用char代替varchar2會更好些。
?? ?總結：1. 如果一個字段經常被修改，而且每次修改的數據長度不同，
?? ?為了效率應當考慮用char定長代替varchar2變長。（列如一個用戶的名字經常被修改）
?? ? ? ? 2. 設計的時候盡量考慮 ?用空間換時間。
169. float 和 double 的區別是什么？
01.在內存中占有的字節數不同
單精度浮點數在機內存占4個字節
雙精度浮點數在機內存占8個字節
02.有效數字位數不同
單精度浮點數有效數字8位
雙精度浮點數有效數字16位
03.數值取值范圍
單精度浮點數的表示范圍：-3.40E+38~3.40E+38
雙精度浮點數的表示范圍：-1.79E+308~-1.79E+308
04.在程序中處理速度不同
一般來說，CPU處理單精度浮點數的速度比處理雙精度浮點數快
?? ?如果不聲明，默認小數為double類型，所以如果要用float的話，必須進行強轉
?? ? 例如：float ?a=1.3; 會編譯報錯，正確的寫法 float a = (float)1.3;
?? ?或者float a = 1.3f;（f或F都可以不區分大小寫）
?? ?注意：float是8位有效數字，第7位數字將會四舍五入
170. MySQL 的內連接、左連接、右連接有什么區別？
?? ?1.內連接,顯示兩個表中有聯系的所有數據;
?? ?2.左鏈接,以左表為參照,顯示所有數據,右表中沒有則以null顯示
?? ?3.右鏈接,以右表為參照顯示數據，,左表中沒有則以null顯示
171. MySQL 索引是怎么實現的？
?? ?.B_Tree適用于：
?? ?1.全值匹配
?? ?全值匹配是指和索引中的所有列進行匹配。
?? ?2.匹配最左前綴
?? ?匹配左左前綴即只使用索引的第4102一列
?? ?3.匹配列前綴
?? ?匹配某一列開頭部分（指的第一列）。
?? ?4.匹配范圍值
?? ?5.精確匹配某一列并范圍匹配另1653一列
?? ?6.只訪問索引的查內詢
?? ?只需訪問索引，無需訪問數據行。
?? ?.B_Tree限制
?? ?1.如果不是按照索引的最左列開始查找，則無法使用索引。
?? ?2.不能跳過索引中的列。
?? ?3.如果查詢中有容某個列的范圍查詢，則其右邊左右列無法使用索引優化查找。
172. 怎么驗證 MySQL 的索引是否滿足需求？
?? ?使用 explain 查看 SQL 是如何執行查詢語句的，從而分析你的索引是否滿足需求。
?? ?explain 語法：explain select * from table where type=1。
?? ?
173. 說一下數據庫的事務隔離？
?? ?Read uncommitted (讀未提交)：最低級別，以上問題均無法解決。
?? ?Read committed (讀已提交)：讀已提交，可避免臟讀情況發生。
?? ?Repeatable Read（可重復讀）：確保事務可以多次從一個字段中讀取相同的值，
?? ?在此事務持續期間，禁止其他事務對此字段的更新，
?? ?可以避免臟讀和不可重復讀，仍會出現幻讀問題。
?? ?Serializable （串行化）：最嚴格的事務隔離級別，要求所有事務被串行執行，
?? ?不能并發執行，可避免臟讀、不可重復讀、幻讀情況的發生。
?? ?
174. 說一下 MySQL 常用的引擎？
?? ?（1）：MyISAM存儲引擎：不支持事務、也不支持外鍵，優勢是訪問速度快，對事務完整性沒有?
?? ?要求或者以select，insert為主的應用基本上可以用這個引擎來創建表
?? ?支持3種不同的存儲格式，分別是：靜態表；動態表；壓縮表
?? ?靜態表：表中的字段都是非變長字段，這樣每個記錄都是固定長度的，優點存儲非常迅速，容易緩存，出現故障容易恢復；
?? ?缺點是占用的空間通常比動態表多（因為存儲時會按照列的寬度定義補足空格）
?? ?ps：在取數據的時候，默認會把字段后面的空格去掉，
?? ?如果不注意會把數據本身帶的空格也會忽略。
?? ?動態表：記錄不是固定長度的，這樣存儲的優點是占用的空間相對較少；缺點：頻繁的更新、刪除數據容易產生碎片，
?? ?需要定期執行OPTIMIZE TABLE或者myisamchk-r命令來改善性能
?? ?壓縮表：因為每個記錄是被單獨壓縮的，所以只有非常小的訪問開支
?? ?（2）InnoDB存儲引擎*
?? ?該存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比MyISAM引擎，寫的處理效率會差一些，
?? ?并且會占用更多的磁盤空間以保留數據和索引。?
?? ?InnoDB存儲引擎的特點：支持自動增長列，支持外鍵約束
?? ?(3)：MEMORY存儲引擎
?? ?Memory存儲引擎使用存在于內存中的內容來創建表。每個memory表只實際對應一個磁盤文件，格式是.frm。
?? ?memory類型的表訪問非常的快，因為它的數據是放在內存中的，
?? ?并且默認使用HASH索引，但是一旦服務關閉，表中的數據就會丟失掉。?
?? ?MEMORY存儲引擎的表可以選擇使用BTREE索引或者HASH索引，兩種不同類型的索引有其不同的使用范圍
?? ?Hash索引優點：?
?? ?Hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像B-Tree 索引需要從根節點到枝節點，
?? ?最后才能訪問到頁節點這樣多次的IO訪問，所以 Hash 索引的查詢效率要遠高于 B-Tree 索引。?
?? ?Hash索引缺點： 那么不精確查找呢，也很明顯，因為hash算法是基于等值計算的，
?? ?所以對于“like”等范圍查找hash索引無效，不支持；
?? ?Memory類型的存儲引擎主要用于哪些內容變化不頻繁的代碼表，或者作為統計操作的中間結果表，
?? ?便于高效地對中間結果進行分析并得到最終的統計結果，。
?? ?對存儲引擎為memory的表進行更新操作要謹慎，因為數據并沒有實際寫入到磁盤中，
?? ?所以一定要對下次重新啟動服務后如何獲得這些修改后的數據有所考慮。
?? ?（4）MERGE存儲引擎
?? ?Merge存儲引擎是一組MyISAM表的組合，這些MyISAM表必須結構完全相同，merge表本身并沒有數據，
?? ?對merge類型的表可以進行查詢，更新，刪除操作，這些操作實際上是對內部的MyISAM表進行的。
175. 說一下 MySQL 的行鎖和表鎖？
?? ?表鎖：偏向MyISAM存儲引擎，開銷小，加鎖快，無死鎖，鎖定粒度大，發送鎖沖突的概率最高，并發度最低
?? ?結論:讀鎖會阻塞寫，寫鎖會阻塞讀和寫
?? ?對MyISAM表的讀操作，不會阻塞其它進程對同一表的讀請求，但會阻塞對同一表的寫請求。
?? ?只有當讀鎖釋放后，才會執行其它進程的寫操作。
?? ?對MyISAM表的寫操作，會阻塞其它進程對同一表的讀和寫操作，只有當寫鎖釋放后，才會執行其它進程的讀寫操作。
?? ?MyISAM不適合做寫為主表的引擎，因為寫鎖后，其它線程不能做任何操作，大量的更新會使查詢很難得到鎖，從而造成永遠阻塞
?? ?
?? ?行鎖：偏向InnoDB存儲引擎，開銷大，加鎖慢，會出現死鎖，鎖定粒度小，發送鎖沖突的概率最低，并發度也最高
?? ?當選中某一行時，如果是通過主鍵或者索引選中的，這個時候是行級鎖；如果是通過其它條件選中的，這個時候行級鎖會升級成表鎖，
?? ?其它事務無法對當前表進行更新或插入操作
?? ?適用范圍：
?? ??? ?A用戶消費，service層先查詢該用戶的賬戶余額，若余額足夠，則進行后續的扣款操作；
?? ??? ?這種情況查詢的時候應該對該記錄進行加鎖
?? ??? ?否則，B用戶在A用戶查詢后消費前先一步將A用戶賬號上的錢轉走，而此時A用戶已經進行了用戶余額是否足夠的判斷，
?? ??? ?則可能會出現余額已經不足但卻扣款成功的情況
?? ??? ?為了避免此情況，需要在A用戶操作該記錄的時候進行for update加鎖
?? ?當我們用范圍條件而不是相等條件檢索數據，并請求共享或排他鎖時，InnoDB會給符合條件的已有數據記錄的索引項加鎖；
?? ?對于鍵值在條件范圍內并不存在的記錄，叫做間隙
?? ?InnoDB也會對這個"間隙"加鎖，這種鎖機制就是所謂的間隙鎖
?? ?優化建議：
?? ??? ?盡可能讓所有數據檢索都通過索引來完成，避免無索引行鎖升級為表鎖
?? ??? ?合理設計索引，盡量縮小鎖的范圍
?? ??? ?盡可能減少索引條件，避免間隙鎖
?? ??? ?盡量控制事務大小，減少鎖定資源量和時間長度
?? ??? ?盡可能低級別事務隔離
?? ?
?? ?
176. 說一下樂觀鎖和悲觀鎖？
?? ?何謂悲觀鎖與樂觀鎖
?? ??? ?樂觀鎖對應于生活中樂觀的人總是想著事情往好的方向發展，悲觀鎖對應于生活中悲觀的人總是想著事情往壞的方向發展。
?? ??? ?這兩種人各有優缺點，不能不以場景而定說一種人好于另外一種人。
?? ?悲觀鎖
?? ??? ?總是假設最壞的情況，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，
?? ??? ?這樣別人想拿這個數據就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉讓給其它線程）。
?? ??? ?傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
?? ??? ?Java中synchronized和ReentrantLock等獨占鎖就是悲觀鎖思想的實現。
?? ?樂觀鎖
?? ??? ?總是假設最好的情況，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，
?? ??? ?但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號機制和CAS算法實現。
?? ??? ?樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量，像數據庫提供的類似于write_condition機制，其實都是提供的樂觀鎖。
?? ??? ?在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現方式CAS實現的。
?? ?兩種鎖的使用場景
?? ??? ?從上面對兩種鎖的介紹，我們知道兩種鎖各有優缺點，不可認為一種好于另一種，像樂觀鎖適用于寫比較少的情況下（多讀場景），
?? ??? ?即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果是多寫的情況，一般會經常產生沖突，
?? ??? ?這就會導致上層應用會不斷的進行retry，這樣反倒是降低了性能，所以一般多寫的場景下用悲觀鎖就比較合適。
?? ?樂觀鎖常見的兩種實現方式
?? ??? ?樂觀鎖一般會使用版本號機制或CAS算法實現。
?? ??? ?1. 版本號機制
?? ??? ?一般是在數據表中加上一個數據版本號version字段，表示數據被修改的次數，當數據被修改時，version值會加一。
?? ??? ?當線程A要更新數據值時，在讀取數據的同時也會讀取version值，在提交更新時，
?? ??? ?若剛才讀取到的version值為當前數據庫中的version值相等時才更新，否則重試更新操作，直到更新成功。
?? ??? ?2. CAS算法
?? ??? ?即compare and swap（比較與交換），是一種有名的無鎖算法。無鎖編程，即不使用鎖的情況下實現多線程之間的變量同步，
?? ??? ?也就是在沒有線程被阻塞的情況下實現變量的同步，
?? ??? ?所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三個操作數
?? ??? ?需要讀寫的內存值 V
?? ??? ?進行比較的值 A
?? ??? ?擬寫入的新值 B
?? ??? ?當且僅當 V 的值等于 A時，CAS通過原子方式用新值B來更新V的值，否則不會執行任何操作（比較和替換是一個原子操作）。
?? ??? ?一般情況下是一個自旋操作，即不斷的重試。
?? ?樂觀鎖的缺點：
?? ??? ?ABA 問題是樂觀鎖一個常見的問題
?? ??? ?1 ABA 問題
?? ??? ?如果一個變量V初次讀取的時候是A值，并且在準備賦值的時候檢查到它仍然是A值，
?? ??? ?那我們就能說明它的值沒有被其他線程修改過了嗎？
?? ??? ?很明顯是不能的，因為在這段時間它的值可能被改為其他值，然后又改回A，那CAS操作就會誤認為它從來沒有被修改過。
?? ??? ?這個問題被稱為CAS操作的 "ABA"問題。
?? ??? ?JDK 1.5 以后的 AtomicStampedReference 類就提供了此種能力，
?? ??? ?其中的 compareAndSet 方法就是首先檢查當前引用是否等于預期引用，
?? ??? ?并且當前標志是否等于預期標志，如果全部相等，則以原子方式將該引用和該標志的值設置為給定的更新值。
?? ??? ?2 循環時間長開銷大
?? ??? ?自旋CAS（也就是不成功就一直循環執行直到成功）如果長時間不成功，會給CPU帶來非常大的執行開銷。?
?? ??? ?如果JVM能支持處理器提供的pause指令那么效率會有一定的提升，pause指令有兩個作用，
?? ??? ?第一它可以延遲流水線執行指令（de-pipeline）,使CPU不會消耗過多的執行資源，延遲的時間取決于具體實現的版本，
?? ??? ?在一些處理器上延遲時間是零。第二它可以避免在退出循環的時候因內存順序沖突（memory order violation）
?? ??? ?而引起CPU流水線被清空（CPU pipeline flush），從而提高CPU的執行效率。
?? ??? ?3 只能保證一個共享變量的原子操作
?? ??? ?CAS 只對單個共享變量有效，當操作涉及跨多個共享變量時 CAS 無效。但是從 JDK 1.5開始，
?? ??? ?提供了AtomicReference類來保證引用對象之間的原子性，你可以把多個變量放在一個對象里來進行 CAS 操作.
?? ??? ?所以我們可以使用鎖或者利用AtomicReference類把多個共享變量合并成一個共享變量來操作。
?? ?CAS與synchronized的使用情景
?? ??? ?簡單的來說CAS適用于寫比較少的情況下（多讀場景，沖突一般較少），
?? ??? ?synchronized適用于寫比較多的情況下（多寫場景，沖突一般較多）
?? ??? ?對于資源競爭較少（線程沖突較輕）的情況，
?? ??? ?使用synchronized同步鎖進行線程阻塞和喚醒切換以及用戶態內核態間的切換操作額外浪費消耗cpu資源；
?? ??? ?而CAS基于硬件實現，不需要進入內核，不需要切換線程，操作自旋幾率較少，因此可以獲得更高的性能。
?? ??? ?對于資源競爭嚴重（線程沖突嚴重）的情況，CAS自旋的概率會比較大，從而浪費更多的CPU資源，效率低于synchronized。
?? ?補充： Java并發編程這個領域中synchronized關鍵字一直都是元老級的角色，很久之前很多人都會稱它為 “重量級鎖” 。
?? ??? ?但是，在JavaSE 1.6之后進行了主要包括為了減少獲得鎖和釋放鎖帶來的性能消耗而引入的 偏向鎖 和 輕量級鎖?
?? ??? ?以及其它各種優化之后變得在某些情況下并不是那么重了。synchronized的底層實現主要依靠 Lock-Free 的隊列，基本思路是
?? ??? ?自旋后阻塞，競爭切換后繼續競爭鎖，稍微犧牲了公平性，但獲得了高吞吐量。
?? ??? ?在線程沖突較少的情況下，可以獲得和CAS類似的性能；
?? ??? ?而線程沖突嚴重的情況下，性能遠高于CAS。
177. MySQL 問題排查都有哪些手段？
?? ?使用 show processlist 命令查看當前所有連接信息。
?? ?使用 explain 命令查詢 SQL 語句執行計劃。
?? ?開啟慢查詢日志，查看慢查詢的 SQL。
178. 如何做 MySQL 的性能優化？
?? ?為搜索字段創建索引。
?? ?避免使用 select *，列出需要查詢的字段。
?? ?垂直分割分表。
?? ?選擇正確的存儲引擎。
Redis
179. Redis 是什么？都有哪些使用場景？
?? ?Redis是一個高性能的key-value數據庫。
?? ?Redis 與其他 key - value 緩存產品有以下三個特點：
?? ?- Redis支持數據的持久化，可以將內存中的數據保存在磁盤中，重啟的時候可以再次加載進行使用。
?? ?- Redis不僅僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
?? ?- Redis支持數據的備份，即master-slave模式的數據備份。
總結
以上是生活随笔為你收集整理的面试题总结151-179的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux-bash脚本
- 下一篇： 编程题：小名的回答