知識積累

互聯網兩年多的思考，但願能和各位探討。

http請求應該首先打在堡壘主機的Nginx(運行docker拉取的鏡像，還須要指定掛載的配置文件，容器運行時會讀取這些配置文件，就像是JAVA類中屬性設置初始值，方法調用時能夠訪問該屬性)上而後基於某種隨機輪詢或客戶端地址hash的方式請求落在springboot內置的tomcat上面(在這個過程當中優先執行過濾器的一些操做)，提供該web服務應該是運行的jar或者war包.web服務將注入eureka註冊中心提供的來自各分佈式節點提供的微服務。若是是dubbo則使用zk註冊中心提供的來自各分佈式節點提供的微服務。控制層通常做爲服務消費者調用註冊中心的服務，響應頁面過來的請求，服務提供者通常是鏈接了數據庫的jar包。

先後端數據交互使用http請求作json數據交互基本足夠了，一些文檔流類型的傳輸可使用mongodb提供副本集羣上傳下載文檔流的服務。作分佈式緩存使用redis提供相應的服務(是否須要使用集羣模式？分佈式大牛與redis設計者何去何從)。分佈式事務解決方案能夠設計並使用本地消息表或者使用消息中間件。使用spring整合各類中間件都是一向的料性(配置相關中間件的套接字訪問方式)。
微服務讀取套接字地址使用springcould的配置中心或者zk提供的配置文件讀取方式都可。配置文件和源碼應該在git庫分別建立不一樣的文件夾用於分離。jekins構建各個模塊的jar包和本地maven install 差很少，不過本地構建jar包在本地maven庫，jekins則通常指定了遠程git代碼庫和遠程maven私庫。springcould的配置中心須要提供有消息中間件的套接字訪問方式。docker運行rabbitmq鏡像提供rabbitmq的套接字訪問方式。docker有個好處就是不須要關注erlong的安裝。docker運行mysql鏡像做爲容器運行並無使用數據卷volume時產生的數據會丟失。而數據卷volume的學習須要花費必定的精力。花費更多精力的應該是docker提供中間件集羣服務，好比如何提供nginx的lvs反向代理服務，如何提供redis集羣的套接字訪問方式，如何提供rabbitmq集羣的套接字訪問方式(雖然我知道這個有直接的集羣鏡像)，如何提供zookeeper集羣的套接字訪問方式。(docker-compose或是k8s？)傳統的物理集羣至少應該打通各節點間的免密登陸ssh
用戶及其權限模塊單點登陸使用redis？
流程審覈模塊使用activiti工做流？
線程異步處理使用quartz？
之前我認爲使用spring整合中間件並掌握中間件的經常使用api就已經把spring玩的一溜一溜的，後來我發現手動掃包
並對包下的接口生成動態代理對象注入spring容器併爲容器中不一樣的代理對象注入屬性才能得到一些成就感。

基於多份數據帶來的思考，數據備份每每消耗網絡帶寬，並在這備份的過程當中，若是要保證主從一致，那麼就必須保證從節點成功處理主節點下發的任務並告知主節點，主節點纔算成功，主節點漫長等待從節點的迴應能增長數據的安全性卻讓用戶感到不耐煩，一般的作法是記個日誌而後從節點異步處理，這時候若是異步到從節點失敗，那麼主從數據就會不一致。zk 使用paxos算法能夠保證強一致。一些普通的選舉算法並不附帶強一致功能，而是經過一些網絡流暢度的因素選舉出主節點。根據不一樣的場景權衡是須要強一致仍是高可用。

NIO能夠看做IO密集型時對cpu極限壓榨。

經常使用的多線程設計以下: 須要一個隊列，請求消息寫入隊列，隊列須要提供一個監聽機制可以從一個給定的線程池中獲取一個線程用於處理請求。或者給定的線程池不斷輪詢領取隊列中的消息，取出消息做爲參數執行響應的邏輯。

紅黑樹只有兩個子節點因此樹的的高度會比較大，適用於純內存操做，不和磁盤交互，因此樹深度對查詢效率的影響微不足道。B樹相比B+樹的特色是B樹非葉子節點也攜帶數據，二者相比紅黑樹分叉更多，假設分別有20G的結構化數據和文檔流數據，能夠直觀的感覺到文檔流類型的key會比較少，因key量相對較少，程序局部性原理相對索引的區分度顯得更重要，mongodb用B樹實現有較大機率從內存直接獲取數據(磁盤預讀+使用合適的頁面淘汰算法)。mysql因key量大，從內存中一次性就命中想要的數據不太現實，此時索引的區分度相對程序局部性原理顯得更重要，B+樹非葉子節點因不攜帶數據而使內存頁存儲更多區分度數據。因此mongodb索引使用B樹結構，而mysql索引使用B+樹

爲何是三次握手四次揮手？
系統設計應遵循簡單性原則，能兩次解決問題就不三次，能三次解決就不四次。
客戶端向web服務器發起鏈接請求，但因網絡延時因素，客戶端關閉了鏈接，而延時一段時間後，請求到達了web服務器，若是是兩次握手，那麼服務端就沒有額外的機會獲知客戶端此時是否還須要創建鏈接。
四次揮手是由於請求釋放鏈接時，web服務器可能還處於報文發送中狀態，三次溝通不能解決該問題

有新想法再更新。。。