1.分佈式系統相對集中式而言，是指多臺計算機互相通過消息通信進行協作而對外提供服務；可解決大型機的伸縮性和單點等問題；
2.網絡i/o有bio/nio，還有aio，aio是指線程拿到消息後並不自己處理或等處理結束之後再響應，而是將消息投遞之後繼續後面的處理，只將回調傳遞給被調用方，消息處理完成之後自動由被調用方完成回調，也就是異步io，java7支持aio；
3.分佈式系統有幾個難點：缺乏全局時鐘（可以把時間序號獲取交給單獨集羣來做）；面對故障的獨立性（要考慮其它模塊可靠與不可靠的情況）；單點故障處理（能拆分的拆分，能換集羣的換集羣，不能拆分到最細的做到備份以備自動恢復）；事務的挑戰（兩階段提交協議，最終一致性等）；
4.單機應用演化過程：
1）單機負載告警後，數據庫與應用服務器做分享；
2）應用服務器負載告警後應用服務器做集羣，涉及負載均衡設備，涉及session問題可將session存cookie或session拷貝或統一session服務管理中心；
3）數據庫壓力變大，讀寫分離，涉及數據複製問題和應用對數據源的選擇問題，讀庫前面也可再加緩存，數據實時要求不高還可採用搜索引擎作爲讀；
4）緩存除了可用來緩存數據，還可用來緩存頁面，緩存一切對實時性要求不高的內容；
5）引入分佈式存儲（文件/kv）系統緩解數據庫的存取；
6）讀寫分離後數據庫仍有瓶頸，採用專庫專用，數據庫的垂直拆分；
7）數據庫垂直拆分後再遇到數據庫單機瓶頸，考慮水平拆分；此時引入數據存取中間件；
8）數據庫問題解決後，新的挑戰時採用應用拆分服務化方式；此時引入消息中間件的服務框架中間件；
5.Java中間件主要有三類：服務框架中間件，消息中間件和數據訪問中間件；
6.votatile和synchronized的區別：volatile表示每次讀寫都直接讀寫主存，不會拷貝到線程存儲中，也就是所有線程操作的都是同一份，這並不表示只有一個線程能同時操作；sychronized是表示加鎖，保持數據的一致性；
7.Java的Atomics包中的類是一些支持原子性操作的類，它們的性能會有明顯的提升是因爲Java使用了硬件特性來支持；
8.CountDownLatch是等待線程調用latch.await，等待latch減少到0就能往下走了，而釋放線程則使用latch.countDown來每次調用釋放1；
9.CyclicBarrier是指所有調用barrier.await的線程都要等到其它線程都執行到這一條語句之後才往後執行，barrier還可以預設一個線程在滿足條件後運行；
10.Exchanger是指兩個線程都執行到這條語句時互換一個信號，然後各自繼續執行；
11.Future是指獲取這個結果的線程調用是異步的，代碼可以先往下執行，等到要真正要使用這個返回值時如果仍未返回纔會停下來，FutureTask是其實現類。
12.併發容器如果有合適場景儘量使用Java提供的，不要自己基於鎖去實現；
13.動態代理，是指把類和接口，接口Handler等名稱傳遞進去給Proxy.newProxyInstance方法來動態創建代理的方式，可在方法觸發前後甚至觸發時進行對應處理，這在服務調用框架之類的客戶端或服務端，一些能用Bean可以讓用戶配置接口，從而生成代理，由代理來處理來自外部的調用，而在調用前後進行替換。
14.服務框架大致是這樣實現的：
1）調用端：通過bean配置方式來配置遠程服務，服務提供方地址一般通過一個配置中心來給出，動態代理在接口調用時通過服務框架的方法來獲取遠程對應服務提供方地址，接裝請求參數等來進行序列化進行Socket直連（採用bio/nio等），得到響應結果後反序列化爲對應的對象返回給上層調用方；超時等問題的處理可通過Future來實現，還可以實現多個調用之間的合併優化，即發起多個類似異步調用，在使用到它們結果時纔會卡住；
2）服務方：通過bean配置方式來配置遠程服務提供者，啓動後註冊到對應的配置中心，啓動若干個線程（池，用來處理流控）來監聽某一個端口的請求，當連接到來時調用具體實現類之前做一些返序列化工具，調用之後再進行一些序列化操作返回給遠程調用者； 應用本身與框架的jar包衝突問題通過ClassLoader來解決；
3）服務註冊中心：主要用來管理註冊來上的調用者和服務提供方，同時可兼具路由管理，信息查看等功能；路由可細化到類或方法，還可通過分組來把同一機房的提供者標識出來；服務升級一般是採用版本號的方式來，即先將服務升級，新老並存，老的調用方全升級後再下線老服務；
15.服務框架實戰中的優化，即服務治理需要的內容：服務信息管理，服務質量管理評估，服務容量評估，服務依賴展示，服務分佈展示，服務統計，服務報表，服務元數據等；服務管理還有服務的限流，上下線，降級，路由，服務授權管理等等；
16.服務框架與ESB異同，都是面向服務化，服務框架主要考慮同構系統不考慮異構，ESB會考慮不同廠商的實現；
17.數據庫水平/垂直拆分的困難：
1）單機的事務機制被打破，要考慮分佈式事務的控制；
2）一些單庫操作需要到多個庫中操作，表連接需要用應用方式來實現；
3）外鍵約束需要程序來保證而非數據庫；
4）依靠單庫的自增序列方式要改變；
18.分佈式事務有兩階段提交協議，但對大型網站來說還是太複雜而且會有性能問題，比之更輕量的有Paxos協議，其核心原則是少數服務多數；一般能不引入分佈式事務就不要引入，如果一定要引入也不追求強一致性而只要求最終一致性，即通過重試的方式把未完成的做完而不回滾；
19.大型網站一致性理論：CAP，即一致性，響應/可用性，部分出問題時仍能工作（Partition-Tolerance），這幾個屬性之間是互斥的，因此更多是放棄完全一致性，只追求最終一致性即可；
20.跨庫查詢且要排序是最難處理的問題，等於要將所有分庫的數據查出來再運算，應該儘量避免這種情況，尤其是分頁到後面數據量更在，如果數據量巨大的，可考慮使用搜索引擎；
21.數據訪問中間件的設計一般是在jdbc/orm框架之下加一層用來處理路由，sql分析等；一般會有一堆的數據源需要處理，包括數據的劃分規則（取模不易於擴展，考慮一致性哈希，有人退出時旁邊的接管之，可以將一個物理結點虛出多個虛擬結點方式緩解任務過於集中的問題），而數據層需要進行如下轉換：sql解析，規則處理，sql改寫（在各庫中表名可能不一樣），數據源選擇，sql執行，結果集返回合併處理這些步驟。
22.數據訪問中間件可以在應用中以jar包方式引入，也可以考慮單獨部署一個應用，業務應用只與這個應用打交道，而各種規則由這個應用來解析與執行。
23.讀寫分享等的數據同步，主要由otter來完成，基於數據庫日誌解析的，國際站可做到秒級延時，國內可做到ms級，阿里內部現在在做單元化，多地多活等方案，也需要這些同步技術。
24.平滑數據遷移其實是先全量遷移，然後再將這一過程中老庫的變更記錄在新庫執行，這個遞歸過程會越來越短，當需要遷移的增量很少時，暫停對這部分數據的寫操作，然後快速完成處理，切換路由到新庫。
25.消息中間件可解耦應用之間的依賴，而且一般用業解決異步調用等實時性要求不高的問題，比如登錄後發短信或是數據同步，記錄日誌這些。
26.消息投遞與業務處理的一致性問題很長時候都需要保證，一些可讓用戶隨意重複的除外，因此需要引入事務類似的方式，但分佈式事務成本太高，所以一個相對摺中的方案是：
1）發送消息給消息中間件；
2）消息中間件入庫消息；
3）消息中間件返回結果；
4）業務操作；
5）發送業務操作結果給消息中間件；
6）更改存儲中的消息狀態；
這個方案只有第5第6步可能引發不一致性問題，但這種情況下消息都可以通過消息中間件的未處理消息狀態來問消息發送源進行反查。
27.消息中間件一般有topic和queue兩種，有不同的應用場景，有時候還需要級聯的方式來處理。
28.消息發送端及發送過程的可靠性是通過本地存儲+重試的方式來保證，對於失敗的消息會保留下來並在消息中心恢復之後重新發送；而對於存儲端則一般可採用數據庫來存儲消息，還可以採用雙機內存的方式來加快速度，使存儲只在內存中運轉並兩臺機器之間相互備份，一旦一臺掛掉則另一臺落磁盤存儲並接管消息。
29.消息處理端一般都需要保證消息處理操作的等冪性以防止消息投遞出錯有重複的消息產生；