rpc
說明：單體架構到分布式架構的演進，必不可少的會使用到rps，rpc是遠端呼叫協議，隨著系統體諒主鍵增大，各個系統部署在不同的機器上，
致使服務間的呼叫需要依賴到網路通訊，使用rpc服務，消費方每次呼叫遠端服務，客戶端不用關心底層網路的互動問題，
大大提高了系統的可靠性。
rpc的架構包含四個核心元件
1、客戶端（client）:服務呼叫方（服務消費者）
2、客戶端存根（client stub）:存放服務端位址資訊，將客戶端的請求引數資料資訊打包成網路訊息，再通過網路傳輸傳送給服務端
3、服務端存根（server stub）:接收客戶端傳送過來的請求訊息並進行解包，然後再呼叫本地服務進行處理
4、服務端（server）:服務的真正提供者
rpc呼叫過程
1、服務消費者（client客戶端）通過本地呼叫的方式呼叫服務
2、客戶端存根（client stub）接收到呼叫請求後負責將方法、入參等資訊序列化（組裝）成能夠進行網路傳輸的訊息體
3、客戶端存根（client stub）找到遠端的服務位址，並且將訊息通過網路傳送給服務端
4、服務端存根（server stub）收到訊息後進行解碼（反序列化操作）
5、服務端存根（server stub）根據解碼結果呼叫本地的服務進行相關處理
6、本地服務執行具體業務邏輯並將處理結果返回給服務端存根（server stub）
7、服務端存根（server stub）將返回結果重新打包成訊息（序列化）並通過網路傳送至消費方
8、客戶端存根（client stub）接收到訊息，並進行解碼（反序列化）
9、服務消費方得到最終結果
rpc用到的關鍵技術點
動態**
通過rpc呼叫服務，如果要實現類似於調本地service的效果，需要基於介面獲取動態**，就是在介面的本地存在這個**，
**會找到服務對應機器位址，高併發還需要考慮負載均衡問題
均衡的策略
隨機權重
一致性雜湊
輪詢序列化，反序列化
nio通訊
服務註冊中心
如何設計乙個rpc框架
rpc互動協議
請求頭header
請求體body
服務註冊與發現的流程
1：服務提供方繫結指定埠並啟動服務，連線服務註冊中心，將本機ip,埠，應用資訊傳送到過去並儲存，
狀態變更時會推送到註冊中心，再由註冊中心推送給消費者
2：消費者連線註冊中心，傳送應用資訊請求服務資訊到註冊中心，註冊中心根據訊息內容匹配相應的服務列表傳送到消費者應用快取，
消費者基於列表選擇並發起呼叫
微服務帶來哪些問題
客戶端的呼叫會受到網路問題的影響
註冊中心網路異常需要服務治理
redis
為什麼redis單執行緒模型效率卻很高
基於純記憶體的操作
非阻塞的io多路復用機制
避免多執行緒頻繁切換上下文的額外消耗
redis執行緒模型
io 多路復用程式
檔案事件處理器
檔案事件分派器
多個 socket
快取與資料庫一致性問題
幻讀：寫入沒成功，但被其他執行緒讀到
高併發讀，並有少量更新
解決辦法
1：先讀快取，不存在則請求資料庫，取出後存入快取，並響應資料
2：更新時，先刪除快取，在更新資料庫
3：高併發時使用非同步序列化方案，通過佇列實現
面試你的面試官
大多數面試都是面試官從簡歷，學歷，經歷，技術，為人上對你 乙個求職者 一番拷問，以確定是否是他們想要的人。而這些對找到適合你的工作的確沒什麼用。某公司某職位需要你，而某公司某職位不一定是你想要的！如果你想找到適合你的公司 如果你想找到適合你的職位 記得面試你的面試官，沒錯！做出很重要的職業決定前，面...
面試官！讓我們聊聊正則
正規表示式是處理字串的利器，並提高工作效率，乙個好的正則能夠幫我們省去幾十甚至上百行 在工作中，也許你會見到在 現很多正則處理字串，也可能見到 中毫無正則，原因在於會正則的人往往處理字串首先想到用正則去處理，不會的那必然用很多api處理。並且在面試的時候很多同學往往掛在正則這裡，所以對於前端正則是乙...
面試官的心得筆記
趁國慶放假，整理了一下這兩三年當技術面試官的一些心得筆記 被我面試過的求職者估計將近 100位 我一般是分六個環節來依次詢問。時間控制在半小時至 1小時內，為了節省時間，對於求職者前面部分的環節考核不通過的則後面的環節可以省略。一 第一印象 這部分對於技術面試是最重要的，有六成以上可以判定這個人是否...