1 實(shí)習(xí)

1.1 講講你做的一個(gè)需求，為什么這么做之類的

答：

1.2 什么是接線

1.3 什么的初始接線，和權(quán)威接線

答：初始接線是現(xiàn)狀，權(quán)威是規(guī)劃中的

1.4 為什么要做比較呢？

答：運(yùn)維人員需要查看差異，看一下建設(shè)的差異，如果走偏了，可以糾正

1.5 一個(gè)機(jī)房有多少個(gè)端口呢（首次提問）

答：這個(gè)我不知道的，一個(gè)機(jī)器大概10w臺(tái)服務(wù)器，雙端互聯(lián)（出端和入端），大概20w

1.6 機(jī)器的內(nèi)存多大

答：堆內(nèi)存是8GB，機(jī)器內(nèi)存是12GB

1.7 你這19個(gè)機(jī)房，算完大概用了多長(zhǎng)時(shí)間呢（首次提問）

答：大概讀取一個(gè)機(jī)房的接線數(shù)據(jù)的時(shí)間是10s，權(quán)威和基礎(chǔ)都要讀，相當(dāng)于讀取2次，處理時(shí)間是1min，19個(gè)機(jī)房差不多19*1.2=22.8min

1. 服務(wù)器的接線和端口數(shù)量：

   • 假設(shè)每臺(tái)服務(wù)器都有一個(gè)主要的網(wǎng)絡(luò)接口（例如，一個(gè)以太網(wǎng)接口），那么總共會(huì)有10萬根接線。
   • 如果每臺(tái)服務(wù)器都有一個(gè)網(wǎng)絡(luò)端口，那么總共會(huì)有10萬個(gè)端口。
   • 但這只是一個(gè)簡(jiǎn)化的估計(jì)。實(shí)際上，一些服務(wù)器可能有多個(gè)網(wǎng)絡(luò)接口，或者在機(jī)房中可能使用了交換機(jī)和路由器，這會(huì)影響實(shí)際的接線和端口數(shù)量。

2. 從數(shù)據(jù)庫(kù)拉取10w記錄的通信時(shí)間：

   • 這個(gè)問題的答案取決于多個(gè)因素，包括每條記錄的大小、網(wǎng)絡(luò)帶寬、數(shù)據(jù)庫(kù)的性能和響應(yīng)時(shí)間等。
   • 假設(shè)每條記錄大小為1KB，那么10萬條記錄總大小為約100MB。
   • 如果網(wǎng)絡(luò)帶寬為1Gbps（約125MB/s），那么理論上需要不到1秒的時(shí)間來傳輸這100MB的數(shù)據(jù)。但實(shí)際的時(shí)間可能會(huì)更長(zhǎng)，因?yàn)檫€需要考慮到數(shù)據(jù)庫(kù)查詢的時(shí)間、網(wǎng)絡(luò)延遲等因素。

3. 將10w條記錄的列表進(jìn)行遍歷，依次放入到一個(gè)map中的時(shí)間：

   • 這個(gè)問題的答案取決于處理數(shù)據(jù)的程序的效率、運(yùn)行的硬件性能等因素。
   • 在一臺(tái)性能良好的服務(wù)器上，將10萬條記錄放入一個(gè)map中通常只需要幾秒鐘或更短的時(shí)間。但這只是一個(gè)大致的估計(jì)，實(shí)際的時(shí)間可能會(huì)根據(jù)具體的情況有所不同。

以上的答案都是基于一些假設(shè)和估計(jì)的，實(shí)際的情況可能會(huì)有所不同。如果需要更準(zhǔn)確的答案，可能需要提供更多的具體信息。

1.8 基礎(chǔ)curd啟動(dòng)器是個(gè)什么需求

答：

1.9 你的curd啟動(dòng)器是支持單表還是聯(lián)表查詢呢

答：單表和聯(lián)表都支持，但是聯(lián)表還是需要我們?cè)赿ao層寫sql

2.0 你的聯(lián)表是怎么做的呢（重要）

答：

3 rpc

3.1 你做出的有什么亮點(diǎn)，比其他rpc更優(yōu)秀嗎

答：

3.2 哪些部分是你自己手寫的

3.3 你做的這個(gè)事情，遇到了什么困難嘛

答：自定義協(xié)議上，沒搞懂，為什么要這個(gè)，不是已經(jīng)有了通用的http協(xié)議嘛

3.4 什么情況下用什么協(xié)議呢

答：

選擇協(xié)議主要取決于應(yīng)用的需求和場(chǎng)景。例如，如果是內(nèi)部服務(wù)之間的通信，追求高性能和低延遲，可以選擇更為輕量級(jí)的自定義協(xié)議。而如果是與外部系統(tǒng)或第三方服務(wù)進(jìn)行通信，可能需要選擇更為通用和標(biāo)準(zhǔn)的協(xié)議，如HTTP或gRPC。

查找域名用DNS，遠(yuǎn)程登陸用telnet，文件上傳下載用ftp，郵件傳輸用smtp

4 mysql

4.1 為什么要遵循最左匹配原則，底層是怎么實(shí)現(xiàn)的呢

答：

MySQL中的“最左匹配原則”主要與復(fù)合索引（composite index）的使用有關(guān)。當(dāng)我們?cè)贛ySQL中創(chuàng)建一個(gè)復(fù)合索引，例如INDEX(a, b, c)，最左匹配原則意味著在查詢時(shí)，必須從左到右地使用索引的列。例如，可以使用索引查詢a或a和b，但不能僅使用b或c。

為什么MySQL要遵循最左匹配原則？

1. 索引結(jié)構(gòu)：MySQL主要使用B-Tree（特別是InnoDB存儲(chǔ)引擎使用的是B+Tree）來實(shí)現(xiàn)其索引。在這種結(jié)構(gòu)中，數(shù)據(jù)是按照索引列的順序存儲(chǔ)的。因此，如果不從最左邊的列開始查詢，MySQL將無法有效地使用索引。

2. 效率：遵循最左匹配原則可以確保MySQL在查詢時(shí)最大限度地利用索引，從而提高查詢效率。

底層是怎么實(shí)現(xiàn)的？

1. B-Tree索引：在B-Tree索引中，數(shù)據(jù)是按照鍵值的順序存儲(chǔ)的。對(duì)于復(fù)合索引INDEX(a, b, c)，數(shù)據(jù)首先按照a的值排序，然后在a的每個(gè)值內(nèi)部，數(shù)據(jù)按照b的值排序，以此類推。因此，如果查詢不從a開始，MySQL將無法直接跳到索引的相關(guān)部分，導(dǎo)致查詢效率降低。

2. 索引查找：當(dāng)MySQL查詢復(fù)合索引時(shí)，它會(huì)從最左邊的列開始，在B-Tree中查找匹配的值。如果查詢條件中包含了索引的更多列，MySQL會(huì)繼續(xù)在當(dāng)前的索引部分中查找，直到找到所有匹配的記錄或到達(dá)索引的末尾。

總之，最左匹配原則是基于MySQL索引的B-Tree結(jié)構(gòu)和查找算法的。遵循這一原則可以確保MySQL在查詢時(shí)最大限度地利用索引，從而提高查詢效率。

5 反問

5.1 你們主要是哪個(gè)部門的

答：我們是美團(tuán)的服務(wù)體驗(yàn)部，我們做的主要是美團(tuán)的所有業(yè)務(wù)的售后服務(wù)系統(tǒng)

6 算法：給a開b次方，要求精確到小數(shù)點(diǎn)后5位(參考69. x 的平方根?)

import java.util.*;
public class Main {public static void main(String[] args) {        double res=findRoot(8,2);System.out.println(res);//給a開b次方}// 10: 3*3// 5位static double findRoot(int a, int b){double l=0,r=a;double m=0;while(true){m=(l+r)/2.0;double ch=check(m,b,(double)a);if(ch>0.00001){r=m;}else if(ch<-0.00001){l=m;}else{break;}}return m;}static double check(double m, int b,double a){double res=1;while(b>0){res=res*m;b--;}return res-a;}
}