1.行程單介面設計
技術上的收穫
rpc一、為什麼要用rpc？
1.減少客戶端jar包大小，提高發布效率
2.提高**的可移植性
3.業務解耦，避免部分出問題，全部掛掉
二、rpc的原理？
socket，不同機器中的程序間通訊
io，每來乙個鏈結，新開乙個執行緒，輪詢
nio 所有的連線都註冊到乙個執行緒，然後批量輪詢。
netty 封裝nio
三、rpc沒有呼叫成功怎麼辦
根據業務場景（是否可重入，冪等）選擇重試和補償策略。
四、rpc和rest的差異
rest通訊協議是http協議，rpc通訊協議是tcp
五、rpc要做的事情
1.服務端如何確定客戶端要呼叫的函式
在遠端呼叫中，客戶端和服務端分別維護乙個【id->函式】的對應表
2.如何進行序列化和反序列化
客戶端和服務端互動時將引數或結果轉化為位元組流在網路中傳輸
3.如何進行網路傳輸
tcpqmq原理，實現機制？
1.為什麼要使用qmq？
解耦，非同步，削峰
2.使用qmq有什麼缺點？
系統可用性降低，複雜性增加
3.如何保證訊息佇列是高可用的？
集群防單點故障，持久化可恢復
4.如何保證訊息不被重複消費
先考慮對應業務是否具有排他性
如果沒有，考慮第三方介質redis，或mysql
5.如何保證消費的可靠性傳輸？
生產者 通道先統一收納發出來的訊息，如果傳送給消費者失敗，則返回給生產者nack，傳送成功，返回給生產者ack。
訊息佇列 開啟持久化磁碟的配置
消費者丟資料 自動確認機制的問題，若出現異常沒有處理該訊息，就會丟失。
6.如何保證訊息的有序性
通過某種演算法，將需要保持先後順序的訊息放到同乙個訊息佇列中(kafka中就是partition,rabbitmq中就是queue)。然後只用乙個消費者去消費該佇列。
關於所做的事情
新老介面切換，訊息消費。
上線後檢視日誌是否報錯，抽出部分資料檢視是否正確
發票超開時，通過日誌記錄到es中，統計收到的訂單都有哪些特點
實習期間相關工作總結
實習期間學到了很多東西，覺得總結一下可以讓自己以後方便回顧知識點 1.用squeezenet跑了貓狗大戰的二分類 2.系統學習了語義分割 fcn 的相關知識，看了很多fcn相關 主要是deeplab v2，改了一些 git上面deeplab上面沒有加crf，加上以後改進巨大 3.復現了乙個美學評價演...
實習期間收藏鏈結
1.github上目標檢測演算法更新 基於深度學習的目標檢測演算法綜述 一 基於深度學習的目標檢測 綜述 深度學習時代的目標檢測演算法 ronald 聊聊目標檢測的多尺度檢測 2.目標檢測演算法ssd ssd 閱讀 wei liu eccv2016 ssd single shot multibox ...
實習期間，異常斷電。。。
然後又發現，拉過來的資料庫中檢視有問題 ora 04063 view has errors 就此解決了一部分，還有一部分沒有解決，不知道什麼問題，還是顯示缺少 最終找到了乙個取巧的方法，將檢視刪掉，新建 此 名與檢視名稱相同，內容為檢視內容，那麼就不會影響現有 的使用。採用的方法是用sql將查詢結果...