nginx的請求轉(zhuǎn)發(fā)算法，如何配置根據(jù)權(quán)重轉(zhuǎn)發(fā)

負(fù)載均衡策略：內(nèi)置策略：輪詢（默認(rèn)）结澄、加權(quán)輪詢（處理1次連接則權(quán)重減1重新排序莹汤，所有機器down后重置所有機器的狀態(tài)）夫晌、IP hash（經(jīng)過20次hash仍找不到可用的機器時退化成輪詢）、least_conn（把請求轉(zhuǎn)發(fā)給連接數(shù)較少的后端服務(wù)器）胶哲；擴展策略：fair（根據(jù)服務(wù)器響應(yīng)時間判斷負(fù)載畔塔，選出負(fù)載最輕的機器）、url_hash（按url的hash結(jié)果分配請求，每個請求的url會指向后端固定的某個服務(wù)器）澈吨、一致性hash把敢；upstream配置參數(shù)：ip_hash、least_conn棚辽、weight（加權(quán)輪詢的權(quán)重）技竟、backup（標(biāo)記備份服務(wù)器，主服務(wù)器掛掉才會處理請求）屈藐、down（標(biāo)記服務(wù)器永久停機）榔组、max_fails/fail_timeout/fail_time（fail_timeout時間內(nèi)失敗了max_fails次則認(rèn)為服務(wù)器停機，停機時間為fail_time联逻，默認(rèn)10s）搓扯；

zookeeper的實現(xiàn)機制，有緩存包归，如何存儲注冊服務(wù)的

Zookeeper是分布式協(xié)調(diào)服務(wù)锨推，主要提供文件系統(tǒng)和通知機制2個功能；文件系統(tǒng)：提供多層級節(jié)點空間的樹狀結(jié)構(gòu)公壤，每個節(jié)點都可以存數(shù)據(jù)（包括目錄）换可，由于數(shù)據(jù)存放于內(nèi)存，所有不能存儲大量數(shù)據(jù)厦幅，單節(jié)點1M沾鳄；節(jié)點znode類型：持久節(jié)點、持久有序節(jié)點确憨、臨時節(jié)點译荞、臨時有序節(jié)點；臨時節(jié)點會話斷開自動刪除休弃；有序通過父節(jié)點生成自增整數(shù)吞歼；通知機制watcher：通過觀察者模式實現(xiàn)輕量級的通知機制，客戶端注冊某個znode節(jié)點的watcher塔猾、服務(wù)端處理watcher篙骡、客戶端回調(diào)watcher；watcher是一次性的丈甸，觸發(fā)后刪除医增，避免節(jié)點頻繁變更的性能問題；?

服務(wù)提供者在啟動的時候老虫，會在ZooKeeper上注冊服務(wù)，就是在ZooKeeper的service/version/ipport目錄/providers節(jié)點下創(chuàng)建一個子節(jié)點茫多，并寫入自己的URL地址祈匙；服務(wù)消費者在啟動的時候，會向ZooKeeper注冊中心訂閱自己的服務(wù)，就是讀取并訂閱ZooKeeper上對應(yīng)服務(wù)名目錄/providers節(jié)點下的所有子節(jié)點夺欲，并解析出所有提供者的URL地址來作為該服務(wù)地址列表跪帝，并在以服務(wù)名命名的目錄/consumers節(jié)點下創(chuàng)建一個臨時節(jié)點，并寫入自己的URL地址些阅；

zookeeper的事務(wù)伞剑，結(jié)點，服務(wù)提供方掛了如何告知消費方

客戶端會隨機連接到zookeeper集群中的一個節(jié)點市埋，如果是讀請求就直接從當(dāng)前節(jié)點中讀取數(shù)據(jù)黎泣，如果是寫請求那么請求會被轉(zhuǎn)發(fā)給leader提交事務(wù)，然后leader會廣播事務(wù)缤谎，只要有超過半數(shù)節(jié)點寫入成功抒倚，那么寫請求就會被提交（類似2PC事務(wù)）；所有事務(wù)請求必須由一個全局唯一的服務(wù)器來協(xié)調(diào)處理坷澡，這個服務(wù)器就是Leader服務(wù)器托呕，其他的服務(wù)器就是follower；?

注冊中心集群掛掉之后消費者和生產(chǎn)者之前還能繼續(xù)通信污呼，因為消費者在啟動時會從zk拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)緩存在本地十办，每次調(diào)用時按照本地存儲的地址進行調(diào)用芒粹，集群掛掉之后只是不能同步最新的服務(wù)列表；??

ZK提供心跳檢測功能着降，會定時向服務(wù)提供者發(fā)送心跳請求，若長期沒響應(yīng)汁展，服務(wù)中心會任務(wù)服務(wù)提供者掛掉而將其剔除鹊碍；服務(wù)消費者會監(jiān)聽相應(yīng)的路徑，一旦發(fā)生變化食绿，ZK會通知服務(wù)消費者更新服務(wù)列表侈咕；

如何用zk實現(xiàn)分布式鎖，與redis分布式鎖有和優(yōu)缺點

利用Zookeeper創(chuàng)建臨時有序節(jié)點來實現(xiàn)分布式鎖器紧；判斷節(jié)點序號最小則加鎖成功耀销，否則注冊Watcher事件等待前面節(jié)點（序號小的獲取到鎖的）通知則獲取到鎖；通過客戶端加鎖時將主機和線程信息寫入鎖中铲汪，下一次再來加鎖時直接和序列最小的節(jié)點對比實現(xiàn)可重入熊尉，ZK自動刪除會話斷開的臨時節(jié)點實現(xiàn)鎖超時；ZK集群解決單點問題掌腰；通過curator框架可實現(xiàn)ZK分布式鎖狰住；??

區(qū)別：Redis分布式鎖需要自己不斷去嘗試獲取鎖，比較消耗性能齿梁；ZK分布式鎖獲取不到鎖時注冊監(jiān)聽器即可催植，不需要不斷主動嘗試獲取鎖肮蛹，性能開銷較小创南；Redis獲取鎖的客戶端掛了之后只能等待超時釋放伦忠，ZK只要客戶端掛了會自動刪除臨時節(jié)點來釋放鎖；Redis鎖是數(shù)值操作稿辙，ZK需要操作文件節(jié)點昆码，總的來說Redis性能高些；

ZK 5臺服務(wù)器如何選出leader(選舉算法)

ZK集群是Master/Slave模式邻储，通過ZAB（ZooKeeperAtomicBroadcast）原子廣播協(xié)議進行選主赋咽，有兩種基本的模式：崩潰恢復(fù)和消息廣播，框架啟動芥备、Leader異常時進入崩潰恢復(fù)冬耿，已選舉新Leader并且半數(shù)機器和leader完成同步后進入消息廣播模式；

選舉過程：每個服務(wù)器發(fā)起投票包括SID服務(wù)器ID和ZXID事務(wù)ID萌壳，第一次會先投自己亦镶，然后每個服務(wù)器收到所有投票并開始處理，優(yōu)先選舉ZXID和SID較大的服務(wù)器為Leader袱瓮，每個服務(wù)器根據(jù)ZXID和SID決定是否更新自己的投票缤骨，再統(tǒng)計投票結(jié)果，超半數(shù)接受的SID即為Leader尺借，最后更新服務(wù)器狀態(tài)：LOOKING（選舉中）绊起、FOLLOWING（跟隨者）、LEADING（領(lǐng)導(dǎo)者）燎斩；當(dāng)Leader掛掉之后虱歪，其他所有服務(wù)器進入LOOKING狀態(tài)，重復(fù)上述過程選舉新的Leader栅表；?

Zookeeper watch機制原理

通知機制watcher：客戶端注冊某個znode節(jié)點的watcher（將watcher封裝到請求中）笋鄙、服務(wù)端處理watcher（解析請求中的watcher放入注冊管理器，后續(xù)請求解析時判斷是否有watcher怪瓶，有則通過TCP發(fā)送通知）萧落、客戶端回調(diào)watcher（線程接收事件處理）；watcher是一次性的洗贰，觸發(fā)后刪除找岖，避免節(jié)點頻繁變更的性能問題；輕量敛滋，不傳實體只傳boolean许布；

Junit用法，before,beforeClass,after, afterClass的執(zhí)行順序

@BeforeClass绎晃、@AfterClass必須設(shè)置在public靜態(tài)方法之上爹脾，表示在class加載之前執(zhí)行帖旨，只會執(zhí)行一次；@Before灵妨、@After則會再每次方法調(diào)用之前/之后執(zhí)行；一個單元測試類執(zhí)行順序：@BeforeClass落竹、@Before泌霍、@Test、@After述召、@AfterClass朱转；一個單元測試方法執(zhí)行順序：@Before、@Test积暖、@After藤为；

Tomcat的各種配置，如何配置docBase

server.xml包括頂級組件server：1個Tomcat實例夺刑；容器組件：service：關(guān)聯(lián)多個connector和1個engine缅疟；engine：通過connector接收請求，處理請求遍愿，轉(zhuǎn)發(fā)請求到對應(yīng)的host存淫；host：虛擬主機；context：應(yīng)用程序沼填，docbase指定webapp本地文件路徑桅咆，path指定訪問URL；連接器組件connector：指定端口接收請求坞笙；被嵌套類組件：Valve：閥門岩饼，發(fā)送到webapp前攔截請求，實現(xiàn)如日志薛夜、IP控制等籍茧；realm：關(guān)聯(lián)一個用戶認(rèn)證庫，實現(xiàn)認(rèn)證和授權(quán)却邓，包括UserDatabaseRealm使用JNDI自定義硕糊、MemoryRealm使用tomcat-users.xml、JDBCRealm使用JDBC鏈接數(shù)據(jù)庫腊徙；

簡單講講Tomcat結(jié)構(gòu)简十，以及其類加載器流程，線程模型等

Tomcat核心組件是Connector和Container撬腾，Connector通過Socket接收請求并將Socket請求封裝成HttpRequest傳給Container螟蝙；Container封裝和管理Servlet和處理請求并返回HttpResponse給Connector；Connector將HttpResponse轉(zhuǎn)換成Socket返回給客戶端民傻；Container包括engine胰默、host场斑、context、wrapper4種牵署，engine+Connector組成service并基于server對外提供服務(wù)漏隐；?

類加載流程：4種類加載器，Bootstrap引導(dǎo)類加載器加載JVM啟動類和擴展類奴迅；System系統(tǒng)類加載器加載Tomcat啟動類如tomcat-juli.jar青责；webapp應(yīng)用類加載器加載每個Web應(yīng)用的WEB-INF/classes和WEB-INF/lib；Common通用類加載器加載通用類如servlet.jar取具；

線程模型：4種線程模型脖隶，BIO：阻塞IO，每個請求創(chuàng)建一個線程暇检；NIO：同步非阻塞产阱，8.0版本默認(rèn)；APR：JNI形式調(diào)用動態(tài)鏈接庫處理請求块仆，需安裝APR庫构蹬；AIO：異步非阻塞，8.0版本后支持榨乎；?

Tomcat如何調(diào)優(yōu)怎燥，涉及哪些參數(shù)

優(yōu)化：安全優(yōu)化：普通用戶啟動、SHUTDOWN端口禁telnet蜜暑、禁用AJP連接铐姚、刪除多余的Root目錄避免漏洞；性能優(yōu)化：禁止DNS查詢（Connector配置enableLookups=false）肛捍、JVM調(diào)優(yōu)（catalina.sh增加JAVA_OPTS）隐绵、使用線程池（定義線程池Executor在Connector中使用）、使用NIO（Connector中配置protocol：bio/nio/nio2/apr）拙毫；

是否用過maven instal依许、 maven test

mvn clean：刪除target目錄；mvn install：編譯項目缀蹄，并將項目打包發(fā)布到本地峭跳；mvn test：編譯項目并運行測試代碼；

Mongodb和Hbase的區(qū)別

1缺前、HBase依賴于HDFS和ZK蛀醉；MongoDB直接存儲在本地磁盤中，不依賴其他三方組件衅码；2拯刁、HBase基于列存儲，按照列族將數(shù)據(jù)存儲在不同的文件中逝段；MongoDB基于文檔存儲垛玻，整個文檔都存儲在一個文件中割捅；3、HBase一個region只有一個HRegionServer對外提供服務(wù)（沒有負(fù)載均衡的概念）帚桩；MongoDB的shards（類似于region）支持負(fù)載均衡（主從結(jié)構(gòu)亿驾，通過日志進行同步）4、HBase根據(jù)文件的大小來控制region的分裂朗儒；MongoDB根據(jù)負(fù)載來決定shards的分裂颊乘；

git rebase

rebase通過合并多個commit解決分支樹分叉，讓分支樹呈現(xiàn)線性的commit記錄醉锄，可用于多個分支的合并；

Mybatis如何映射表結(jié)構(gòu)

實體類屬性名和表字段名相同時MyBatis會自動映射浙值，否則可通過Select as別名恳不、或者在XML中通過resultMap配置映射關(guān)系、或者通過注解@Result开呐、@Column配置映射烟勋；

Mybatis的底層實現(xiàn)原理

Mybatis是半ORM框架，需要自己寫SQL筐付，內(nèi)部封裝了JDBC來連接數(shù)據(jù)庫卵惦，所以數(shù)據(jù)庫兼容性較好，可通過XML和注解完成映射和配置瓦戚；通過Mapper接口的全限定名和接口方法定位到XML的SQL沮尿，將每個select/update等語句解析成MapperStatement對象，使用JDK動態(tài)代理為Mapper接口生成代理對象较解，調(diào)用對應(yīng)的MapperStatement執(zhí)行SQL畜疾；通過反射和SQL列名和對象屬性映射創(chuàng)建對象并賦值完成查詢結(jié)果的封裝；

了解幾種消息中間件產(chǎn)品印衔？各產(chǎn)品的優(yōu)缺點介紹

ActiveMQ啡捶、RabbitMQ、RocketMQ奸焙、Kafka瞎暑、Redis；吞吐量：RocketMQ与帆、Kafka高于ActiveMQ了赌、RabbitMQ；延遲：RabbitMQ基于erlang實現(xiàn)鲤桥，延遲最低揍拆；可用性：RocketMQ、Kafka實現(xiàn)了分布式茶凳，可用于高于ActiveMQ嫂拴、RabbitMQ只實現(xiàn)了主從播揪；消息可靠性：ActiveMQ低概率丟失數(shù)據(jù)；RabbitMQ管理界面較豐富筒狠；RocketMQ是阿里實現(xiàn)猪狈，社區(qū)活躍度沒有其他3個高；只有RocketMQ 支持事務(wù)消息即保證消息的生產(chǎn)和發(fā)送的原子性辩恼；

消息中間件如何保證消息的一致性和如何進行消息的重試機制雇庙？

數(shù)據(jù)一致性指消息發(fā)送成功后即使leader掛了也能讀取到該消息；Kafka是通過ISR機制保證的灶伊，Kafka中每個Topic有多個分區(qū)疆前，每個分區(qū)有多個副本，不同副本保存在不同的broker聘萨，每個分區(qū)維護自己的ISR列表即與leader保持?jǐn)?shù)據(jù)同步的副本列表竹椒，寫入消息時會先發(fā)送給leader，leader再同步的把消息同步給ISR內(nèi)的多個副本后再提交米辐，再異步的把消息同步給ISR外的副本胸完，所以即使leader掛了之后也可以從新的leader上消費消息；

Kafka重試機制比較簡單翘贮，通過配置重試次數(shù)支持在特定異常時重試赊窥；自己可以通過新建Topic，將需要重試的消息寫入Topic狸页，再通過定時任務(wù)來處理實現(xiàn)完善的重試機制锨能；RocketMQ通過重試隊列（失敗的消息加入）和死信隊列（失敗了指定次數(shù)的消息加入）實現(xiàn)了完善的重試機制，包括生產(chǎn)端和消費端兩類重試機制肴捉，主要通過重試次數(shù)腹侣、重試時間、超時重試齿穗、異常重試控制傲隶；通過消息ID解決冪等性；

消息隊列的使用場景

異步處理窃页，應(yīng)用解耦跺株，流量削鋒，消息通訊脖卖，日志收集乒省；

如何保證消息的有序性

Kafka中對同一個分區(qū)的消息的生產(chǎn)和消費是有序的，可以通過將需要保序的消息設(shè)置Key來發(fā)送到同一個分區(qū)畦木；另外消費端多線程處理（不是從分區(qū)消費）消息時袖扛，可通過對key進行hash將需要保序的消息維護到內(nèi)部的多個隊列里面，一個線程消費一個隊列；

MQ系統(tǒng)的數(shù)據(jù)如何保證不丟失

發(fā)送消息不丟失：Kafka通過ack機制保證蛆封，每次發(fā)送都會有確認(rèn)反饋機制唇礁，有3個狀態(tài)：0：不等broker確認(rèn)、1：leader確認(rèn)惨篱，異步同步盏筐、-1：leader和ISR所有副本都確認(rèn)；?

消費消息不丟失：Kafka通過offset commit機制保證砸讳，Kafka在單獨的Topic中保存了每次消費的offset琢融，消費者重啟時會從上次的offset處開始消費，commit時機也可以程序控制簿寂；

?Broker消息不丟失：1個Topic多個分區(qū)漾抬，1個分區(qū)多個副本，不同副本保存在不同broker常遂，每個分區(qū)維護自己的ISR（與leader保持同步的副本列表奋蔚，定期消息同步，不同步則剔除）烈钞，寫入消息時先給leader，leader再同步的把消息同步給ISR內(nèi)的多個副本坤按，再提交毯欣，再異步的把消息同步給ISR外的副本；??

Kafka吞吐量高的原因

partiton機制：1個Topic有多個partiton臭脓，partiton分布在不同節(jié)點且存儲在本地文件夾且可在不同磁盤酗钞，1個partiton有多個segment，1個segment有1個數(shù)據(jù)和索引文件来累，從節(jié)點砚作、磁盤、文件上都可并發(fā)嘹锁，同時1個partiton只有1個消費者線程葫录，避免競爭；ISR機制：可用性和一致性的動態(tài)平衡领猾，動態(tài)復(fù)制米同，避免慢節(jié)點拖慢整體性能；順序?qū)?/b>磁盤：新消息順序?qū)懭胛募じ停x消息通過offset順序讀面粮，刪消息刪整個segment文件，避免磁盤隨機寫继低；支持多磁盤：broker數(shù)據(jù)存儲支持配置多個磁盤路徑熬苍，不同分區(qū)數(shù)據(jù)盡量寫到不同路徑；零拷貝：用mmap作為文件讀寫方式的袁翁，直接把它傳給sendfile柴底，通過transferTo和transferFrom使用零拷貝讀寫文件婿脸；批處理：同一主題和分區(qū)的多條消息合并傳輸，并支持?jǐn)?shù)據(jù)壓縮似枕；高效的序列化：可自定義使用更高效的序列化方式盖淡；

Kafka主從同步怎么實現(xiàn)

Kafka中同一個Topic可以被分配成多個Partition，每個Partition的可以有一個或者多個Replicas凿歼，即會有一個Leader以及0到多個Follower褪迟，在consumer讀取數(shù)據(jù)的時候，只會從Leader上讀取數(shù)據(jù)答憔，F(xiàn)ollower只是在Leader宕機的時候來替代Leader味赃，主從同步有兩種方式：同步復(fù)制和異步復(fù)制，Kafka采用的是中間策略ISR（In Sync Replicas）虐拓，每個分區(qū)維護自己的ISR列表（與leader保持同步的副本列表心俗，定期消息同步，不同步則剔除）蓉驹，寫入消息時先給leader城榛，leader再同步的把消息同步給ISR內(nèi)的多個副本后再提交，再異步的把消息同步給ISR外的副本态兴；

利用mq怎么實現(xiàn)最終一致性

在服務(wù)生產(chǎn)方和服務(wù)消費方中間加一層MQ狠持，服務(wù)生產(chǎn)方保證消息發(fā)送成功，MQ保證消息不會丟失瞻润，服務(wù)消費方保證消息消費成功喘垂，每個服務(wù)保證自己的本地事務(wù)，如果生產(chǎn)方掛了可以直接回滾绍撞，MQ或消費方掛了由于消息還在所以可以再次消費從而保證最終一致性正勒；另外RocketMQ支持事務(wù)消息，即保證消息生產(chǎn)和發(fā)送成功的原子性傻铣，可以更方便的解決上述問題章贞，通過預(yù)先發(fā)送半消息及多次和MQ的確認(rèn)交互實現(xiàn)；

使用Kafka有沒有遇到什么問題矾柜，怎么解決的

問題一：消息的順序問題阱驾，發(fā)送消息時通過指定key讓同類消息發(fā)送到同一個分區(qū)解決；問題二：消息擠壓多的問題怪蔑，通過增加Topic分區(qū)和水平擴容消費者服務(wù)解決里覆；問題三：消費不到消息，經(jīng)常掛的問題缆瓣，是Windows部署低版本的Bug喧枷，通過升級版本使用Linux部署解決；

MQ有可能發(fā)生重復(fù)消費，如何避免隧甚，如何做到冪等

MQ為了保證消息必達可能重復(fù)發(fā)送消息车荔，首先需要MQ服務(wù)器內(nèi)部生成唯一的和業(yè)務(wù)無關(guān)的消息ID：inner-msg-id來去重，重復(fù)的消息不持久化戚扳；然后消息發(fā)送的業(yè)務(wù)方發(fā)送消息時需要帶上和業(yè)務(wù)相關(guān)的biz-id忧便，消費方根據(jù)biz-id去重，通過MQ服務(wù)器和業(yè)務(wù)服務(wù)共同的處理達到冪等性帽借；

MQ的消息延遲了怎么處理珠增，消息可以設(shè)置過期時間么，過期了你們一般怎么處理

Kakfa處理消息延遲：1砍艾、根據(jù)業(yè)務(wù)邏輯調(diào)整max.poll.records與max.poll.interval.ms之間的平衡點蒂教，避免出現(xiàn)消費者被頻繁踢出消費組導(dǎo)致重平衡； 2脆荷、消費線程邏輯輕量化凝垛；3、增加分區(qū)數(shù)和消費節(jié)點蜓谋；ActiveMQ梦皮、Rabbitmq發(fā)送消息時可以設(shè)置消息過期時間，過期的消息可以設(shè)置自動刪除或者單獨寫程序補償發(fā)送桃焕；

netty的線程模型届氢，netty如何基于reactor模型上實現(xiàn)的

Reactor線程模型：所有線程都是NIO線程，單線程模型：1個Reactor線程（完成所有IO操作包括接收覆旭、分發(fā)和處理），實現(xiàn)：ServerBootstrap().group(NioEventLoopGroup)岖妄；多線程模型：1個Reactor線程（負(fù)責(zé)接收）+多個Acceptor線程（線程池型将，負(fù)責(zé)處理），實現(xiàn)：ServerBootstrap().group(NioEventLoopGroup(1),NioEventLoopGroup)荐虐；主從模型：1個主Reactor線程（負(fù)責(zé)接收七兜，只負(fù)責(zé)接入認(rèn)證、握手等福扬，然后重新注冊到從Reactor）+多個從Reactor線程（線程池）+多個Acceptor線程（線程池腕铸，負(fù)責(zé)處理），實現(xiàn)：ServerBootstrap().group(NioEventLoopGroup,NioEventLoopGroup)铛碑；

Netty的HashWheelTimer的用法狠裹，實現(xiàn)原理，是否出現(xiàn)過調(diào)用不夠準(zhǔn)時汽烦，怎么解決

HashedWheelTimer底層數(shù)據(jù)結(jié)構(gòu)是DelayedQueue涛菠，加上時間輪的算法來實現(xiàn)；新建HashedWheelTimer實例的時候可以傳入幾個參數(shù)：時間長度（類似手表一圈的長度）、刻度數(shù)（類似手表的刻度俗冻，越大精度越細）礁叔；添加一個任務(wù)時會根據(jù)任務(wù)得到一個hash值，并根據(jù)時間輪長度和刻度得到一個商值round（圈數(shù)）和模index（刻度）迄薄，比如時間長度24小時琅关，刻度為12，延遲時間為32小時讥蔽，那么round=1涣易，index=8。時間輪從開啟之時起每24/12個時間走一個指針勤篮，即index+1,第一圈round=0都毒。當(dāng)走到第7個指針時，此時index=7碰缔，此時剛才的任務(wù)并不能執(zhí)行账劲，因為剛才的任務(wù)round=1，必須要等到下一輪index=7的時候才能執(zhí)行金抡；

時間輪對時間精度要求不高瀑焦，內(nèi)存占用較大，效率比延遲隊列高梗肝；

Netty的心跳處理在弱網(wǎng)下怎么辦

Netty實現(xiàn)心跳機制的關(guān)鍵就是利用IdleStateHandler來產(chǎn)生對應(yīng)的idle 事件榛瓮，一般是客戶端負(fù)責(zé)發(fā)送心跳的PING消息， 當(dāng)服務(wù)器收到客戶端的 PING 消息時會發(fā)送一個 PONG 消息作為回復(fù)巫击，一個 PING-PONG消息對就是一個心跳交互禀晓；客戶端在監(jiān)測到與服務(wù)器端的連接斷開后，或者一開始就無法連接的情況下坝锰，使用指定的重連策略進行重連操作粹懒，直到重新建立連接或重試次數(shù)耗盡，對于如何監(jiān)測連接是否斷開顷级，則是通過重寫ChannelInboundHandler#channelInactive來實現(xiàn)凫乖，但連接不可用，該方法會被觸發(fā)弓颈，所以只需要在該方法做好重連工作即可帽芽；

Netty的通訊協(xié)議是什么樣的

通訊協(xié)議指的是把Netty通訊管道中的二進制流轉(zhuǎn)換為對象、把對象轉(zhuǎn)換成二進制流的過程翔冀，轉(zhuǎn)換過程追根究底還是ChannelInboundHandler（二進制轉(zhuǎn)對象）导街、ChannelOutboundHandler（對象轉(zhuǎn)二進制）的實現(xiàn)類在進行處理，通過自定義編解碼可以實現(xiàn)自己的通信協(xié)議纤子，從而實現(xiàn)各種服務(wù)器如Http菊匿、FTP等付呕；

為什么選擇Netty

1、API 使用簡單跌捆，開發(fā)門檻低徽职；2、功能強大佩厚，預(yù)置了多種編解碼功能姆钉，支持多種主流協(xié)議； 3抄瓦、定制能力強潮瓶，可以通過 ChannelHandler對通信框架進行靈活的擴展； 4钙姊、性能高毯辅，通過與其它業(yè)界主流的 NIO 框架對比，Netty 的綜合性能最優(yōu)煞额； 5思恐、成熟、穩(wěn)定膊毁，社區(qū)活躍胀莹，版本迭代周期短，發(fā)現(xiàn)的BUG可以被及時修復(fù)婚温，同時描焰，更多的新功能會被加入； 6栅螟、經(jīng)歷了大規(guī)模的商業(yè)應(yīng)用考驗荆秦，質(zhì)量已經(jīng)得到驗證，在互聯(lián)網(wǎng)力图、大數(shù)據(jù)萄凤、網(wǎng)絡(luò)游戲、企業(yè)應(yīng)用搪哪、電信軟件等眾多行業(yè)得到成功商用坪圾，證明了它可以完全滿足不同行業(yè)的商業(yè)應(yīng)用；?

ElasticSearch了解多少梁肿，以及一些調(diào)優(yōu)手段

ElasticSearch是分布式搜索和處理平臺填抬，基于Lucene，可實現(xiàn)近實時查詢遣臼；核心概念有索引：文檔的集合辟灰，類似數(shù)據(jù)庫；索引中的邏輯分類即類型武通，類似表；分片：一個索引被切成多塊存在不同的服務(wù)器即分片，類似水平分表；包括主分片（默認(rèn)5）和復(fù)制分片（默認(rèn)1）曲掰；一個分片包括多個segment；文檔：索引和搜索的原子單位，JSON表示，由多個域（包含一個名字和多個值）組成蜡峰；節(jié)點：集群通過名字標(biāo)識湿颅，節(jié)點通過節(jié)點名字加入载绿；分為主節(jié)點（管理所有變更）、數(shù)據(jù)節(jié)點（存儲數(shù)據(jù)和倒排索引）油航、協(xié)調(diào)節(jié)點（處理客戶端請求）崭庸；使用：配置（集群和節(jié)點名稱、數(shù)據(jù)和日志路徑谊囚、改大操作系統(tǒng)默認(rèn)文件描述符）怕享、使用（提供內(nèi)置RestAPI：_doc、_search等）镰踏；?

優(yōu)化：1函筋、冷熱數(shù)據(jù)分離，冷數(shù)據(jù)存儲機械硬盤奠伪，熱數(shù)據(jù)可存儲SSD提高效率跌帐；2、根據(jù)業(yè)務(wù)場景绊率、通道谨敛、節(jié)點數(shù)通過合理規(guī)劃索引數(shù)和分片數(shù)，分片大小不超過30G即舌，一個索引不要創(chuàng)建多個Type；3挎袜、按照日期規(guī)劃索引顽聂，可以方便的刪除歷史數(shù)據(jù)肥惭；使用別名管理索引；4紊搪、定時在后臺空閑時對索引使用force_merge合并段來釋放空間蜜葱；5、根據(jù)是否需要精確查詢耀石、是否需要檢索等設(shè)置合理的Mapping（類似表結(jié)構(gòu)字段）牵囤；6、僅針對需要分詞的字段滞伟，合理的設(shè)置分詞器揭鳞；7、查詢的優(yōu)化梆奈，禁用wildcard野崇，禁用批量terms，數(shù)據(jù)量大時先基于時間篩選亩钟，設(shè)置合理的路由機制乓梨；8、寫入優(yōu)化：寫入前設(shè)置副本為0和關(guān)閉刷新清酥，寫入后恢復(fù)副本數(shù)和刷新間隔扶镀；9、采用批量請求并調(diào)整合適的提交大醒媲帷臭觉；10、部署優(yōu)化：磁盤容量留出足夠的buffer鹦马，不要和其他耗內(nèi)存的服務(wù)同機部署胧谈，內(nèi)存CPU不要太小荸频；

ElasticSearch的倒排索引是什么

倒排索引相反于一篇文章包含了哪些詞菱肖，它從詞出發(fā)記載了這個詞在哪些文檔中出現(xiàn)過，由詞典和倒排表兩部分組成旭从；ES利用倒排索引對文檔進行分詞并維護一張分詞字典稳强、出現(xiàn)頻率、出現(xiàn)的文檔ID的表和悦，提高了檢索效率O(1)退疫；倒排索引的底層實現(xiàn)是基于FST（有限狀態(tài)轉(zhuǎn)換器）數(shù)據(jù)結(jié)構(gòu)，F(xiàn)ST有兩個優(yōu)點：空間占用小鸽素，重復(fù)利用了單詞褒繁，壓縮了存儲空間；查詢速度快馍忽；

ElasticSearch是如何實現(xiàn)master選舉的

ES采用了多數(shù)派的思想選舉Master棒坏，每個節(jié)點都可以成為候選主節(jié)點燕差，只有候選主節(jié)點（master：true）的節(jié)點才能成為主節(jié)點；集群啟動時或者Master掛掉時會進入Master選舉流程坝冕，先確定候選主節(jié)點數(shù)是否達到多數(shù)節(jié)點徒探，再優(yōu)先選擇節(jié)點id較小的節(jié)點為主節(jié)點；

詳細描述一下Elasticsearch索引文檔的過程

索引文檔理解為文檔寫入ES并創(chuàng)建索引的過程喂窟，文檔寫入包含單文檔寫入和批量bulk寫入测暗；寫文檔過程：協(xié)調(diào)節(jié)點處理請求計算新文檔加入哪個主分片；主分片完成后再請求副分片磨澡；過程：內(nèi)存+操作日志translog（用于故障恢復(fù)）碗啄、文件系統(tǒng)緩存生成segment（每隔1秒生成1個）、寫磁盤（fsync操作钱贯，文件系統(tǒng)緩存所有segment落盤并清空translog）挫掏、合并segment（1秒1個太多而優(yōu)化）；

詳細描述一下Elasticsearch搜索的過程

查詢文檔包括查詢和獲取兩個階段秩命，先查詢需要查詢哪些文檔和segment（協(xié)調(diào)節(jié)點廣播查詢請求到所有相關(guān)分片尉共，整合所有節(jié)點的響應(yīng)并排序），再根據(jù)segment獲取內(nèi)容返回弃锐；

Elasticsearch在部署時袄友，對Linux的設(shè)置有哪些優(yōu)化方法？

關(guān)閉緩存Swap霹菊；設(shè)置最大文件句柄數(shù)剧蚣；磁盤存儲raid方式，存儲有條件使用RAID10旋廷，增加單節(jié)點性能以及避免單節(jié)點存儲故障鸠按；線程池+隊列大小根據(jù)業(yè)務(wù)需要做調(diào)整