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) 相對于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)建時，找不到某個類的某個方法/某個變量，但是本地編譯ok柑土，啥原因辑畦？
分批發(fā)布：保持對外提供的服務(wù)在線匣砖，不影響線上使用偎肃；
第一批暫定：觀察煞烫，看日志，
## alitomcat&pandora
-
tomcat原理
啟動時會加載自己lib/庫累颂，以及應(yīng)用程序的lib滞详，以及應(yīng)用程序類class。
自身類庫與應(yīng)用程序所依賴類庫的隔離紊馏，如何實(shí)現(xiàn)的料饥？
通過類加載器實(shí)現(xiàn)的
jvm的3種加載器：啟動類加載器、擴(kuò)展加載器朱监、系統(tǒng)加載器
jsp是怎么被編譯的岸啡，加載器的機(jī)制是怎么樣的？
jsp是一個servlet赫编，被類加載器加載
-
Spring-boot與tomcat的關(guān)系
spring-boot集成了tomcat巡蘸，所以spring-boot可以直接執(zhí)行main()函數(shù)進(jìn)行啟動，或者執(zhí)行jar相關(guān)命令即可
而傳統(tǒng)的tomcat啟動方式沛慢，需要依賴startup.sh啟動腳本
spring-boot
的優(yōu)點(diǎn)和缺點(diǎn)赡若？優(yōu)點(diǎn)很多，總結(jié)成一句話—減少各種配置团甲、集成時間逾冬，提高開發(fā)和調(diào)試效率
-
war包結(jié)構(gòu)
web應(yīng)用打成war包之后，tomcat在部署時會先對其解壓躺苦，解壓后形成webapp/WEB-INF/classes和webapp*/WEB-INF/lib身腻，classes下面放的是你的java包。
spring-boot之后匹厘，我們打的是jar包嘀趟，解壓生成的是webapp**/BOOT-INF
發(fā)布完成之后，需要去服務(wù)器上看看這個目錄愈诚，尤其是lib目錄她按。尤其是當(dāng)出現(xiàn)jar包沖突時，更要看看炕柔，是否真的有兩個一樣的jar包在該目錄下
HSF(同步調(diào)用)
hsf定義：添加hsf注解
hsf消費(fèi)：spring-boot:在config中通過@Consumer注解定義
注意：
- 確定好自己服務(wù)的超時時間酌泰，一般是3秒；時間過長匕累，占用連接池陵刹，阻塞應(yīng)用
- 異常處理，hsf接口返回值一般都封裝為result欢嘿。為什么要封裝衰琐？和http訪問一樣也糊，status，定義友好的返回信息
- 調(diào)用hsf服務(wù)時羡宙，要先判斷result.isSuccess狸剃，接下來判斷result.data是否為null或者列表是否為空，否則可能NPE
- 循環(huán)調(diào)用：循環(huán)調(diào)用別人的hsf服務(wù)時辛辨，要控制循環(huán)次數(shù)捕捂，如果超過20次，容易把別人的hsf線程池打爆斗搞。如何解決指攒？循環(huán)要控制次數(shù)
- 限流與降級：大促期間根據(jù)qps，進(jìn)行限流和降級僻焚。
- 入?yún)⒋笮】刂疲喝绻嫌握{(diào)用時傳入的參數(shù)很大允悦，如果調(diào)用很頻繁、并且內(nèi)部處理很耗時虑啤，會導(dǎo)致什么結(jié)果隙弛？頻繁GC、甚至引發(fā)FGC狞山，并造成hsf線程池被打爆全闷，使整個系統(tǒng)不可用。如果入?yún)⒄娴暮艽笃计簦趺刺幚?/li>
metaq(異步調(diào)用)
同一個topic总珠，但是不同應(yīng)用消費(fèi)不同的內(nèi)容，需要加tag勘纯，形成topic+tag兩級標(biāo)識局服。特別是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ù)級的，很快就會把應(yīng)用搞掛来庭。通過mq控制臺可以看消息堆積量妒蔚。解決辦法：重啟服務(wù)器穿挨；如果消息過多月弛，重啟消息服務(wù)器不行的話肴盏，到消息平臺，先清空消息帽衙。
在代碼中如何避免菜皂？先返回給用戶成功，然后異步去處理厉萝；或者構(gòu)建緩存區(qū)恍飘，來處理用戶的請求和消息
diamond
-
原理
基于推拉模式，主要基于拉
長連接和短連接的原理是啥谴垫？ 需要看底層
http協(xié)議章母，1.1開始就是長連接；長連接表示keepLive
長短連接的優(yōu)缺點(diǎn)翩剪？
長連接：建立連接之后乳怎，不斷開；優(yōu)點(diǎn)：交流方便前弯；缺點(diǎn)：連接是系統(tǒng)資源蚪缀，占用系統(tǒng)內(nèi)存
一臺linux服務(wù)器支持的最大連接數(shù)是
diamond
-
double check 兩次檢查
解析:文本按換行符split，遍歷數(shù)組恕出，轉(zhuǎn)換成對象或map
（1）推送開關(guān)時询枚，必須要double check
（2）解析開關(guān)值時，要注意健壯性浙巫。特例：
若一個開關(guān)包含多個參數(shù)金蜀，如果其中一個解析失敗，會帶來什么問題狈醉，如何解決廉油？
JVM內(nèi)存
- jvm內(nèi)存
三大塊：堆 棧 方法區(qū)
so，有哪幾種oom場景苗傅？
堆的溢出抒线、棧溢出、方法溢出
棧：方法調(diào)用是引用棧內(nèi)存渣慕，無限調(diào)用
方法區(qū)：
堆：
只要有一個溢出嘶炭，jvm就會直接退出
-
常見問題
查詢DB沒做分頁，導(dǎo)致頻繁GC甚至FGC
接受參數(shù)太大逊桦，并且QPS高眨猎，直接將系統(tǒng)搞死
死循環(huán)，導(dǎo)致stack oom
批處理耗時强经，并且QPS較高睡陪，系統(tǒng)load飆升，假死
-
JVM問題排查
top， jmap兰迫， jstack信殊， jps， load汁果， rt...
各個工具怎么用涡拘，用來分析什么問題？
-
舉例
某個hsf請求處理很耗時据德，并且占用大量資源鳄乏，怎么快速定位？
top -h 那個線程跑的最多棘利，最耗時
jstack 根據(jù)pid橱野，看對應(yīng)那個類
## tair(緩存)
* 如何保證tair與db之間的一致性？
* tair異常：寫成功善玫，讀不到仲吏，啥原因？
tair滿了蝌焚，寫不進(jìn)去
* tair失效：一定要進(jìn)行失效機(jī)制裹唆，這是保證數(shù)據(jù)一致性的根本措施。容忍短時間內(nèi)的數(shù)據(jù)不一致性只洒，但是絕不允許長時間不一致
* 寫>讀的場景下许帐，是否要使用tair？不需要
* 本地cache：tair自帶本地cache熱點(diǎn)數(shù)據(jù)功能毕谴，但是必須根據(jù)業(yè)務(wù)特點(diǎn)設(shè)置何時的失效期
* 緩存分流：多個系統(tǒng)如果都依賴basic系統(tǒng)的緩存數(shù)據(jù)成畦，當(dāng)QPS很大時，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)值比較少
批量查詢時，limit start step查詢?nèi)绾翁嵘? id寻馏，order by, 100w條的時候棋弥，需要注意
## eagleeye(鷹眼)
load cpu時間片 任務(wù)
在一個時間片內(nèi)沒做完，又來一個任務(wù)诚欠，load+1
一個時間片時間沒到就做完了顽染，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
普通的輪詢方案會給服務(wù)器帶來過多訪問壓力，而且很多時候輪詢請求都沒有配置更新翔悠，白跑一趟业崖，Diamond采用的是改進(jìn)的長輪詢方案，長短輪詢結(jié)合蓄愁，即輪詢配置是否更新時双炕，使用長輪詢，減少配置沒更新時無意義的訪問撮抓；在獲取配置時妇斤，使用短輪詢，及時獲取配置丹拯。
基于Http長輪詢模型站超，這樣減少了無意義的輪詢請求量，提高了輪詢的效率乖酬；也降低了系統(tǒng)負(fù)載死相，提升了整個系統(tǒng)的資源利用率。這種推拉結(jié)合的策略咬像，做到了在長連接和短連接之間的平衡算撮，實(shí)現(xiàn)上讓服務(wù)端不用太關(guān)注連接的管理，效果上又獲得了類似TCP長連接的信息推送的實(shí)時性县昂。由于輪詢之間的間隔肮柜，無法保證連續(xù)的配置更新，都會被客戶端接受倒彰，但最后一次的配置更新一定會被客戶端接受到审洞，例如發(fā)布了A B C 配置，可能客戶端只接受到了 A C待讳，也可能只接受到 B C预明，或者只接收到 C。
