ms

1. 分佈式鎖

http://www.hollischuang.com/archives/1716

http://www.cnblogs.com/green-hand/p/5687611.html

 

分佈式的CAP理論告訴咱們「任何一個分佈式系統都沒法同時知足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance），最多隻能同時知足兩項。

咱們須要的分佈式鎖應該是怎麼樣的？（這裏以方法鎖爲例，資源鎖同理）

能夠保證在分佈式部署的應用集羣中，同一個方法在同一時間只能被一臺機器上的一個線程執行。

這把鎖要是一把可重入鎖（避免死鎖）

這把鎖最好是一把阻塞鎖（根據業務需求考慮要不要這條）

有高可用的獲取鎖和釋放鎖功能

獲取鎖和釋放鎖的性能要好

 

ZK分佈式鎖（使用臨時有序節點 。順序值由master節點來分配？）
在 ZooKeeper 中，節點類型能夠分爲持久節點（PERSISTENT ）、臨時節點（EPHEMERAL），以及時序節點（SEQUENTIAL ），具體在節點建立過程當中，通常是組合使用，能夠生成 4 種節點類型：持久節點（PERSISTENT），持久順序節點（PERSISTENT_SEQUENTIAL），臨時節點（EPHEMERAL），臨時順序節點（EPHEMERAL_SEQUENTIAL）；

 Redis分佈式鎖 （setNX + getSet）

 

BASE理論是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency）。

 當網絡因爲發生異常狀況，致使分佈式系統中部分節點之間的網絡延時不斷增大，最終致使組成分佈式系統的全部節點中，只有部分節點之間可以正常通訊，而另外一些節點則不能----咱們將這個現象稱爲網絡分區。當網絡分區出現時，分佈式系統會出現局部小集羣，在極端狀況下，這些局部小集羣會獨立完成本來須要整個分佈式系統才能完成的功能，包括對數據的事物處理，這就對分佈式一致性提出了很是大的挑戰

 

2. 數據庫

內連、左連、右連、全連

oracle minus 集合操做

in(, , , )  exist

select * from (
select 1 as id, 'a' as name from dual
union
select 2 as id, 'b' as name from dual
) t1
left join
(
select 1 as id, 'a' as name from dual
union
select 3 as id, 'c' as name from dual
) t2
on t1.id = t2.id

結果：
       ID    NAME ID    NAME
    1    a    1    a
    2    b            

View Code

 

 

3. BIO、NIO

http://www.javashuo.com/article/p-cjevdyzn-a.html

http://www.importnew.com/22623.html

 

4. 短鏈接、長鏈接
dubbo（長鏈接 netty, socket）
HTTP的長鏈接和短鏈接本質上是TCP長鏈接和短鏈接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另外一端收到發端發出的全部包，而且順序與發出順序一致。TCP有可靠，面向鏈接的特色。
http://www.cnblogs.com/0201zcr/p/4694945.html

OSI中的層 功能 TCP/IP協議族

7 應用層 文件傳輸，電子郵件，文件服務，虛擬終端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet

6 表示層 數據格式化，代碼轉換，數據加密 沒有協議

5 會話層 解除或創建與別的接點的聯繫 沒有協議

4 傳輸層 提供端對端的接口 TCP，UDP

3 網絡層 爲數據包選擇路由 IP，ICMP，RIP，OSPF，BGP，IGMP

2 數據鏈路層 傳輸有地址的幀以及錯誤檢測功能 SLIP，CSLIP，PPP，ARP，RARP，MTU

1 物理層 以二進制數據形式在物理媒體上傳輸數據 ISO2110，IEEE802，IEEE802.2

 

5. spring scope
默認是單例模式，即scope="singleton"。另外scope還有prototype、request、session、global session做用域。

 

6. netty
NIO
零拷貝
粘包：經過協議約定，好比指定數據包的size來切分消息。

爲何會發生TCP粘包、拆包
1. 應用程序寫入的數據大於套接字緩衝區大小，這將會發生拆包。
2. 應用程序寫入數據小於套接字緩衝區大小，網卡將應用屢次寫入的數據發送到網絡上，這將會發生粘包。
3. 進行MSS（最大報文長度）大小的TCP分段，當TCP報文長度-TCP頭部長度>MSS的時候將發生拆包。
4. 接收方法不及時讀取套接字緩衝區數據，這將發生粘包。

如何處理粘包、拆包，一般會有如下一些經常使用的方法：
1. 使用帶消息頭的協議、消息頭存儲消息開始標識及消息長度信息，服務端獲取消息頭的時候解析出消息長度，而後向後讀取該長度的內容。
2. 設置定長消息，服務端每次讀取既定長度的內容做爲一條完整消息，當消息不夠長時，空位補上固定字符。
3. 設置消息邊界，服務端從網絡流中按消息編輯分離出消息內容，通常使用‘\n’。
4. 更爲複雜的協議，例如樓主最近接觸比較多的車聯網協議808,809協議。

https://www.hchstudio.cn/article/2018/d5b3/

 netty 題目 http://www.javashuo.com/article/p-qdxknhvh-o.html

 

 

7. logback MDC 在spring異步@Async使用線程池時，值取到舊值問題
http://forum.spring.io/forum/spring-projects/container/129674-async-with-log4j-s-mdc
https://moelholm.com/2017/07/24/spring-4-3-using-a-taskdecorator-to-copy-mdc-data-to-async-threads/  (sprint boot 中使用這個)

8. stream  <-->  channel + buffer 

9. 數據庫事務隔離級別 (http://www.cnblogs.com/fjdingsd/p/5273008.html)
　　read uncommitted  -->  read committed  --> repeatable read --> Serializable
　　   髒讀　　　　　　　　　不可重複讀　　　　　　幻讀

MySQL  默認 repeatable read
https://dev.mysql.com/doc/refman/5.6/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read
https://dev.mysql.com/doc/refman/5.6/en/innodb-consistent-read.html
Oracle 默認 read committed

 

10. 雪崩
http://www.2cto.com/os/201508/433330.html
1。 緩存Cache在A服務上，找不到緩存去B服務查庫
雪崩可能緣由：a. A服務掛了，重啓時緩存所有被清空，致使流量所有到B服務
b. B服務掛了致使緩存過時，B重啓後流量所有到B

2。緩存Cache在A服務上，找不到Cache經過A去查庫

3。緩存Cache單獨部署 + A服務

關鍵詞：雪崩、緩存擊穿、過載保護、緩存預熱、限流、服務降級

 

11. vilatile  http://www.importnew.com/24082.html

 Java內存模型：主內存、工做內存

併發編程的三大概念：原子性，有序性，可見性

volatile保證可見性。實現原理：經過向處理器發送一條Lock前綴的指令，將這個變量所在緩存行的數據寫會到系統內存。
一旦一個共享變量（類的成員變量、類的靜態成員變量）被volatile修飾以後，那麼就具有了兩層語義：
1）保證了不一樣線程對這個變量進行操做時的可見性，即一個線程修改了某個變量的值，這新值對其餘線程來講是當即可見的。
2）禁止進行指令重排序。

volatile不能確保原子性
解決方案：能夠經過synchronized或lock，進行加鎖，來保證操做的原子性。也能夠經過AtomicInteger。

volatile保證有序性。實現原理：Lock前綴指令實際上至關於一個內存屏障（也成內存柵欄），它確保指令重排序時不會把其後面的指令排到內存屏障以前的位置，也不會把前面的指令排到內存屏障的後面。

volatile的變量在被操做的時候不會產生working memory的拷貝，而是直接操做main memory，固然volatile雖然解決了變量的可見性問題，但沒有解決變量操做的原子性的問題，這個還須要synchronized或者CAS相關操做配合進行。

 

12. Java泛型（http://www.importnew.com/24029.html）
T、    泛型通配符（?）、     ? extends T、      ? super T、    類型擦除

「Producer Extends」 – 若是你須要一個只讀List，用它來produce T，那麼使用   ? extends T。
「Consumer Super」 – 若是你須要一個只寫List，用它來consume T，那麼使用   ? super T。
若是須要同時讀取以及寫入，那麼咱們就不能使用通配符了。

如何閱讀過一些Java集合類的源碼，能夠發現一般咱們會將二者結合起來一塊兒用，好比像下面這樣：

public class Collections {
    public static <T> void copy(List<? super T> dest, List<? extends T> src) {
        for (int i=0; i<src.size(); i++)
            dest.set(i, src.get(i));
    }
}

 

13. 正向代理   反向代理  （http://blog.csdn.net/m13666368773/article/details/8060481）

正向代理：位於客戶端和原始服務器(origin server)之間的服務器，客戶端必需要進行一些特別的設置才能使用正向代理。容許客戶端經過它訪問任意網站而且隱藏客戶端自身

反向代理：對外都是透明的，對於客戶端而言它就像是原始服務器，訪問者並不知道本身訪問的是一個代理，而且客戶端不須要進行任何特別的設置。反向代理還能夠爲後端的多臺服務器提供負載平衡，或爲後端較慢的服務器提供緩衝服務。（nginx反向代理，動靜分離）

 

14. 高可用（HA）架構
http://aokunsang.iteye.com/blog/2053719   淺談web應用的負載均衡、集羣、高可用(HA)解決方案

http://zhuanlan.51cto.com/art/201612/524201.htm  互聯網架構「高可用」
http://www.blogjava.net/ivanwan/archive/2013/12/25/408014.html    LVS/Nginx/HAProxy負載均衡器的對比分析

高可用HA(High Availability)是分佈式系統架構設計中必須考慮的因素之一，它一般是指，經過設計減小系統不能提供服務的時間。

方法論上，高可用是經過 冗餘(集羣化) + 自動故障轉移(failover)來實現的。 

虛擬IP（VirtualIP/VIP）: 實現原理主要是靠TCP/IP的ARP協議。  http://blog.csdn.net/whycold/article/details/11898249

常見的Tomcat集羣方案：ngnix+tomcat；lvs+ngnix+tomcat；(lvs負責集羣調度，nginx負責靜態文件處理，tomcat負責動態文件處理[最優選擇])。

 

 

15. 分佈式環境下的 黏性Session 和 非黏性Session

 

16. 六大設計原則  http://blog.csdn.net/cq361106306/article/details/38708967

http://www.javashuo.com/article/p-dttkmyhb-b.html

單一職責原則
里氏替換原則
依賴倒置原則
接口隔離原則
迪米特法則
開閉原則

單一職責原則告訴咱們實現類要職責單一；
里氏替換原則告訴咱們不要破壞繼承體系；
依賴倒置原則告訴咱們要面向接口編程；
接口隔離原則告訴咱們在設計接口的時候要精簡單一；
迪米特法則告訴咱們要下降耦合。
而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。

 

17. 瀏覽器與服務器交互的過程

http://www.cnblogs.com/xdp-gacl/p/3734395.html

 

 

18. 線程的狀態和生命週期

http://blog.csdn.net/lonelyroamer/article/details/7949969

 

 

19. java.util.concurrent.atomic.AtomicXXX
其內部實現不是簡單的使用synchronized，而是一個更爲高效的方式CAS (compare and swap) + volatile和native方法，從而避免了synchronized的高開銷，執行效率大爲提高。

CAS指令在Intel CPU上稱爲CMPXCHG指令，它的做用是將指定內存地址的內容與所給的某個值相比，若是相等，則將其內容替換爲指令中提供的新值，若是不相等，則更新失敗。

從內存領域來講這是樂觀鎖，由於它在對共享變量更新以前會先比較當前值是否與更新前的值一致，若是是，則更新，若是不是，則無限循環執行(稱爲自旋鎖)，直到當前值與更新前的值一致爲止，才執行更新。

 

20. 線程池

ThreadPoolExecutor、AbstractExecutorService、ExecutorService和Executor

ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)  各個參數的含義

Java經過Executors提供四種線程池，分別爲：
newCachedThreadPool建立一個可緩存線程池，若是線程池長度超過處理須要，可靈活回收空閒線程，若無可回收，則新建線程。
newFixedThreadPool 建立一個定長線程池，可控制線程最大併發數，超出的線程會在隊列中等待。
newScheduledThreadPool 建立一個定長線程池，支持定時及週期性任務執行。
newSingleThreadExecutor 建立一個單線程化的線程池，它只會用惟一的工做線程來執行任務，保證全部任務按照指定順序(FIFO, LIFO, 優先級)執行。

http://ifeve.com/java-threadpool/

http://www.javashuo.com/article/p-hcakyhag-a.html

http://www.importnew.com/19011.html

 

21. zookeeper 選舉算法

zookeeper 如何保證一致性

http://blog.csdn.net/liuhaiabc/article/details/70771322

 

22. 安全

XSS ------ Filter進行特殊字符(<script>)過濾
CSRF ------- 更新數據時，使用POST請求而且攜帶token
SQL注入 -------  Filter進行特殊字符(;)過濾

 

23. Socket三次握手、四次揮手

http://www.cnblogs.com/Jessy/p/3535612.html

首先，咱們要知道TCP是全雙工的，即客戶端在給服務器端發送信息的同時，服務器端也能夠給客戶端發送信息。而半雙工的意思是A能夠給B發，B也能夠給A發，可是A在給B發的時候，B不能給A發，即不一樣時，爲半雙工。 單工爲只能A給B發，B不能給A發； 或者是隻能B給A發，不能A給B發。
http://www.javashuo.com/article/p-swvqtzls-b.html  爲何不是兩次握手，而是三次
http://www.javashuo.com/article/p-mhmgxyoa-bv.html 

 

 

24. 分佈式 id 生成器

百度uid生成器：https://github.com/baidu/uid-generator

美團點評生成器：http://tech.meituan.com/MT_Leaf.html

 

25. 消息隊列的順序性和重複消費問題

消息隊列的順序性：消息投遞到同一個消息服務器的同一個消息隊列Q1，只有一個消費者消費Q1

重複消息：消費者接口冪等

RocketMQ支持事務消息：http://blog.csdn.net/u012422829/article/details/70248286
（作本地事務前發送prepared消息，本地事務完成後發送確認消息。若是確認消息發送失敗，RocketMQ會檢查prepared消息，而後回調業務系統確認業務是否成功）

事務消息：解決業務作成功了，發送消息失敗的問題（可靠MQ）。
也能夠經過在業務系統中建一張消息發送隊列表來解決，業務事務與發送消息放在同一個事務中

 

26. Redis、Memcache 一致性hash算法

一致性 hash 解決的問題：
在緩存場景中，當集羣中加入 1 臺機器後，這臺機器要可以分攤其餘機器的流量和緩存數據，簡單的取模方式去路由和普通 hash 環是行不通的，一致性 hash 引入了虛擬節點，就能夠作到了
新增節點對數據的影響比例爲：（一致性 hash 的節點是均勻分佈的）
3臺 --> 4臺 = 1/4
n-1臺 --> n臺 = 1/n

 

 

27. happen-before規則

出現線程安全的問題通常是由於主內存和工做內存數據不一致性和重排序致使的

在執行程序時，爲了提升性能，編譯器和處理器經常會對指令進行重排序。

對於主內存和工做內存的「髒讀」問題，能夠經過同步機制（控制不一樣線程間操做發生的相對順序）來解決或者經過volatile關鍵字使得每次volatile變量都可以強制刷新到主存，從而對每一個線程都是可見的。

針對編譯器重排序，JMM的編譯器重排序規則會禁止一些特定類型的編譯器重排序；針對處理器重排序，編譯器在生成指令序列的時候會經過插入內存屏障指令來禁止某些特殊的處理器重排序。

JMM實際上是在遵循一個基本原則：只要不改變程序的執行結果（指的是單線程程序和正確同步的多線程程序），編譯器和處理器怎麼優化都行。

 

28. Dubbo的Consumber 和 Provider 在不一樣的線程組中，爲何可使用 ThreadLocal（RpcContext） 來保存微服務的上下文？
由於 Consumber 調用 Provider 時，會將 RpcContext 往 Provider 端傳遞，而且在 Provider 端進行反序列化，這樣就能夠作到了。

 

29. Socket 調用能夠像普通的方法調用同樣準確的拿到返回值嗎？
不能，由於接收返回消息時，不能確切的知道返回的是哪一個請求的結果。因此，須要在發出請求時，將請求打上標記（惟一id），返回結果時，帶上這個標記。就像 Dubbo 同樣。
（短鏈接是能夠的，nio長鏈接就可能會串）
那 http 1.1 也是基於 tcp ，當 keep-alive=true（長鏈接）時，爲何就能夠作到在同一個 channel 通道中發多個請求時，返回結果不串呢？
由於：http 1.1 協議規定 server 發送返回報文的順序必須與接收請求的順序相同。這樣先發的請求就能先收到返回，在不須要知道請求 id 的狀況下，也能正確處理響應了

 

 30. dubbo 按權重隨機算法  https://blog.csdn.net/danny_idea/article/details/82258367

31. spring 如何解決循環依賴？
spring 經過對 bean 的早期引用（early reference）進行緩存，在預到循環依賴的bean 初始化時，取早期引用緩存進行注入
http://www.imooc.com/article/34150

深度分析 ：
http://www.javashuo.com/article/p-smkruniq-nt.html
http://www.javashuo.com/article/p-stnwfmxu-nt.html
https://blog.csdn.net/f641385712/article/details/93475774