redis
持久化：AOF/RDB
IO多路復(fù)用：select epoll evport kqueue
Nmap 虛擬內(nèi)存 內(nèi)存映射
網(wǎng)絡(luò)轉(zhuǎn)換 分發(fā)
binlog記錄過程
redis 的AOF 只記錄結(jié)果
內(nèi)存數(shù)據(jù)結(jié)構(gòu) 支持更多的數(shù)據(jù)結(jié)構(gòu) 相對(duì)于memcached
linux
pgm -A `armory -leg projectnamehost` "grep 'Exception' /home/admin/projectname/logs/service.log"
BIONIOAIO
aone/spring/maven
aone
構(gòu)建：分支合并、編譯
打二方包
部署
發(fā)布
代碼規(guī)約
-
集成測試
構(gòu)建常見的問題：
- 環(huán)境變量缺失
- 多分支構(gòu)建時(shí)，找不到某個(gè)類的某個(gè)方法/某個(gè)變量，但是本地編譯ok，啥原因？
分批發(fā)布：保持對(duì)外提供的服務(wù)在線，不影響線上使用；
第一批暫定：觀察，看日志，
## alitomcat&pandora
-
tomcat原理
啟動(dòng)時(shí)會(huì)加載自己lib/庫，以及應(yīng)用程序的lib，以及應(yīng)用程序類class。
自身類庫與應(yīng)用程序所依賴類庫的隔離，如何實(shí)現(xiàn)的？
通過類加載器實(shí)現(xiàn)的
jvm的3種加載器：啟動(dòng)類加載器、擴(kuò)展加載器、系統(tǒng)加載器
jsp是怎么被編譯的，加載器的機(jī)制是怎么樣的？
jsp是一個(gè)servlet，被類加載器加載
-
Spring-boot與tomcat的關(guān)系
spring-boot集成了tomcat，所以spring-boot可以直接執(zhí)行main()函數(shù)進(jìn)行啟動(dòng)，或者執(zhí)行jar相關(guān)命令即可
而傳統(tǒng)的tomcat啟動(dòng)方式，需要依賴startup.sh啟動(dòng)腳本
spring-boot
的優(yōu)點(diǎn)和缺點(diǎn)？優(yōu)點(diǎn)很多，總結(jié)成一句話—減少各種配置、集成時(shí)間，提高開發(fā)和調(diào)試效率
-
war包結(jié)構(gòu)
web應(yīng)用打成war包之后，tomcat在部署時(shí)會(huì)先對(duì)其解壓，解壓后形成webapp/WEB-INF/classes和webapp*/WEB-INF/lib，classes下面放的是你的java包。
spring-boot之后，我們打的是jar包，解壓生成的是webapp**/BOOT-INF
發(fā)布完成之后，需要去服務(wù)器上看看這個(gè)目錄，尤其是lib目錄。尤其是當(dāng)出現(xiàn)jar包沖突時(shí)，更要看看，是否真的有兩個(gè)一樣的jar包在該目錄下
HSF(同步調(diào)用)
hsf定義：添加hsf注解
hsf消費(fèi)：spring-boot:在config中通過@Consumer注解定義
注意：
- 確定好自己服務(wù)的超時(shí)時(shí)間，一般是3秒；時(shí)間過長，占用連接池，阻塞應(yīng)用
- 異常處理，hsf接口返回值一般都封裝為result。為什么要封裝？和http訪問一樣，status，定義友好的返回信息
- 調(diào)用hsf服務(wù)時(shí)，要先判斷result.isSuccess，接下來判斷result.data是否為null或者列表是否為空，否則可能NPE
- 循環(huán)調(diào)用：循環(huán)調(diào)用別人的hsf服務(wù)時(shí)，要控制循環(huán)次數(shù)，如果超過20次，容易把別人的hsf線程池打爆。如何解決？循環(huán)要控制次數(shù)
- 限流與降級(jí)：大促期間根據(jù)qps，進(jìn)行限流和降級(jí)。
- 入?yún)⒋笮】刂疲喝绻嫌握{(diào)用時(shí)傳入的參數(shù)很大，如果調(diào)用很頻繁、并且內(nèi)部處理很耗時(shí)，會(huì)導(dǎo)致什么結(jié)果？頻繁GC、甚至引發(fā)FGC，并造成hsf線程池被打爆，使整個(gè)系統(tǒng)不可用。如果入?yún)⒄娴暮艽?，怎么處?/li>
metaq(異步調(diào)用)
同一個(gè)topic，但是不同應(yīng)用消費(fèi)不同的內(nèi)容，需要加tag，形成topic+tag兩級(jí)標(biāo)識(shí)。特別是tag，直接在mq服務(wù)端就進(jìn)行過濾，不需要push到客戶端
-
消息風(fēng)暴：如果編程不當(dāng)，或者消費(fèi)業(yè)務(wù)本身就很復(fù)雜，消費(fèi)一次要處理很久，導(dǎo)致本次消費(fèi)還沒結(jié)束，服務(wù)器以為消費(fèi)失敗，于是重發(fā)消息，從而導(dǎo)致應(yīng)用服務(wù)器消息堆積。這種堆積是指數(shù)級(jí)的，很快就會(huì)把應(yīng)用搞掛。通過mq控制臺(tái)可以看消息堆積量。解決辦法：重啟服務(wù)器；如果消息過多，重啟消息服務(wù)器不行的話，到消息平臺(tái)，先清空消息。
在代碼中如何避免？先返回給用戶成功，然后異步去處理；或者構(gòu)建緩存區(qū)，來處理用戶的請(qǐng)求和消息
diamond
-
原理
基于推拉模式，主要基于拉
長連接和短連接的原理是啥？ 需要看底層
http協(xié)議，1.1開始就是長連接；長連接表示keepLive
長短連接的優(yōu)缺點(diǎn)？
長連接：建立連接之后，不斷開；優(yōu)點(diǎn)：交流方便；缺點(diǎn)：連接是系統(tǒng)資源，占用系統(tǒng)內(nèi)存
一臺(tái)linux服務(wù)器支持的最大連接數(shù)是
diamond
-
double check 兩次檢查
解析:文本按換行符split，遍歷數(shù)組，轉(zhuǎn)換成對(duì)象或map
（1）推送開關(guān)時(shí)，必須要double check
（2）解析開關(guān)值時(shí)，要注意健壯性。特例：
若一個(gè)開關(guān)包含多個(gè)參數(shù)，如果其中一個(gè)解析失敗，會(huì)帶來什么問題，如何解決？
JVM內(nèi)存
- jvm內(nèi)存
三大塊：堆 棧 方法區(qū)
so，有哪幾種oom場景？
堆的溢出、棧溢出、方法溢出
棧：方法調(diào)用是引用棧內(nèi)存，無限調(diào)用
方法區(qū)：
堆：
只要有一個(gè)溢出，jvm就會(huì)直接退出
-
常見問題
查詢DB沒做分頁，導(dǎo)致頻繁GC甚至FGC
接受參數(shù)太大，并且QPS高，直接將系統(tǒng)搞死
死循環(huán)，導(dǎo)致stack oom
批處理耗時(shí)，并且QPS較高，系統(tǒng)load飆升，假死
-
JVM問題排查
top， jmap， jstack， jps， load， rt...
各個(gè)工具怎么用，用來分析什么問題？
-
舉例
某個(gè)hsf請(qǐng)求處理很耗時(shí)，并且占用大量資源，怎么快速定位？
top -h 那個(gè)線程跑的最多，最耗時(shí)
jstack 根據(jù)pid，看對(duì)應(yīng)那個(gè)類
## tair(緩存)
* 如何保證tair與db之間的一致性？
* tair異常：寫成功，讀不到，啥原因？
tair滿了，寫不進(jìn)去
* tair失效：一定要進(jìn)行失效機(jī)制，這是保證數(shù)據(jù)一致性的根本措施。容忍短時(shí)間內(nèi)的數(shù)據(jù)不一致性，但是絕不允許長時(shí)間不一致
* 寫>讀的場景下，是否要使用tair？不需要
* 本地cache：tair自帶本地cache熱點(diǎn)數(shù)據(jù)功能，但是必須根據(jù)業(yè)務(wù)特點(diǎn)設(shè)置何時(shí)的失效期
* 緩存分流：多個(gè)系統(tǒng)如果都依賴basic系統(tǒng)的緩存數(shù)據(jù)，當(dāng)QPS很大時(shí)，basic系統(tǒng)因?yàn)閠air訪問流量過大觸發(fā)tair限流，導(dǎo)致basic頻繁讀取DB，造成性能降低，如何破解？
重復(fù)訪問少，緩存命中概率低
## mysql
b+tree的結(jié)構(gòu)是啥？為啥比其他樹快
status字段能建索引嗎？不需要鍵，因?yàn)闋顟B(tài)值比較少
批量查詢時(shí)，limit start step查詢?nèi)绾翁嵘? id，order by, 100w條的時(shí)候，需要注意
## eagleeye(鷹眼)
load cpu時(shí)間片 任務(wù)
在一個(gè)時(shí)間片內(nèi)沒做完，又來一個(gè)任務(wù)，load+1
一個(gè)時(shí)間片時(shí)間沒到就做完了，load=0
load/qps的關(guān)系：
qps高，load一定高嗎？
load的含義是啥
如何設(shè)計(jì)程序，使qps即使很低，load也很高
4核處理器上，load的健康值是多少
正常業(yè)務(wù)系統(tǒng)的qps健康值是多少
正常業(yè)務(wù)系統(tǒng)的線程數(shù)量是多少
服務(wù)治理框架
hsf：
序列化 hessian 支持跨語言，速度慢
dubbo序列化也是hessian2
普通的輪詢方案會(huì)給服務(wù)器帶來過多訪問壓力，而且很多時(shí)候輪詢請(qǐng)求都沒有配置更新，白跑一趟，Diamond采用的是改進(jìn)的長輪詢方案，長短輪詢結(jié)合，即輪詢配置是否更新時(shí)，使用長輪詢，減少配置沒更新時(shí)無意義的訪問；在獲取配置時(shí)，使用短輪詢，及時(shí)獲取配置。
基于Http長輪詢模型，這樣減少了無意義的輪詢請(qǐng)求量，提高了輪詢的效率；也降低了系統(tǒng)負(fù)載，提升了整個(gè)系統(tǒng)的資源利用率。這種推拉結(jié)合的策略，做到了在長連接和短連接之間的平衡，實(shí)現(xiàn)上讓服務(wù)端不用太關(guān)注連接的管理，效果上又獲得了類似TCP長連接的信息推送的實(shí)時(shí)性。由于輪詢之間的間隔，無法保證連續(xù)的配置更新，都會(huì)被客戶端接受，但最后一次的配置更新一定會(huì)被客戶端接受到，例如發(fā)布了A B C 配置，可能客戶端只接受到了 A C，也可能只接受到 B C，或者只接收到 C。
