java重連

A. 在java web useUnicode=true&characterEncoding=UTF-8&autoReconnect=true代碼是什麼意思。

使用Unicode編碼，字元編碼為UTF-8，自動重連

B. java分布式架構有哪些技術

既然是分布式系統，系統間通信的技術就不可避免的要掌握。

首先，我們必須掌握一些基本知識，例如網路通信協議（例如TCP / UDP等），網路IO（Blocking-IO，NonBlocking-IO，Asyn-IO），網卡（多隊列等）。 了解有關連接重用，序列化/反序列化，RPC，負載平衡等的信息。

在學習了這些基本知識之後，您基本上可以在分布式系統中編寫一個簡單的通信模塊，但這實際上還遠遠不夠。 現在，您已經進入了分布式欄位，您已經對規模有很多要求。 這意味著需要一種通信程序，該程序可以支持大量連接，高並發性和低資源消耗。

大量的連接通常會有兩種方式：

大量client連一個server

當前在NonBlocking-IO非常成熟的情況下，支持大量客戶端的伺服器並不難編寫，但是在大規模且通常是長連接的情況下，有一點需要特別注意 ，即伺服器掛起時不可能所有客戶端都在某個時間點啟動重新連接。 那基本上是一場災難。 我見過一些沒有經驗的類似案例。 客戶端規模擴大後，伺服器基本上會在重新啟動後立即刷新。 大量傳入連接中斷（當然，伺服器的積壓隊列首先應設置為稍大一些）。 可以使用的通常方法是在客戶端重新連接之前睡眠一段隨機的時間。 另外，重連間隔採用避讓演算法。

一個client連大量的server

有些場景也會出現需要連大量server的現象，在這種情況下，同樣要注意的也是不要並發同時去建所有的連接，而是在能力范圍內分批去建。

除了建連接外，另外還要注意的地方是並發發送請求也同樣，一定要做好限流，否則很容易會因為一些點慢導致內存爆掉。

這些問題在技術風險上得考慮進去，並在設計和代碼實現上體現，否則一旦隨著規模上去了，問題一時半會還真不太好解。

高並發這個點需要掌握CAS、常見的lock-free演算法、讀寫鎖、線程相關知識（例如線程交互、線程池）等，通信層面的高並發在NonBlocking-IO的情況下，最重要的是要注意在整體設計和代碼實現上盡量減少對io線程池的時間佔用。

低資源消耗這點的話NonBlocking-IO本身基本已經做到。

伸縮性

分布式系統基本上意味著規模不小。 對於此類系統，在設計時必須考慮可伸縮性。 在體系結構圖上繪制的任何點，如果請求量或數據量繼續增加，該怎麼辦？ 通過添加機器來解決。 當然，此過程不需要考慮無限的情況。 如果您有經驗的建築師，從相對較小的規模到非常大型的范圍，那麼優勢顯然並不小，而且它們也將越來越稀缺。 。

橫向可擴展性（Scale Out）是指通過增加伺服器數量來提高群集的整體性能。 垂直可伸縮性（Scale Up）是指提高每台伺服器的性能以提高集群的整體性能。 縱向可擴展性的上限非常明顯，而分布式系統則強調水平可伸縮性。

分布式系統應用服務最好做成無狀態的

應用服務的狀態是指運行時程序因為處理服務請求而存在內存的數據。分布式應用服務最好是設計成無狀態。因為如果應用程序是有狀態的，那麼一旦伺服器宕機就會使得應用服務程序受影響而掛掉，那存在內存的數據也就丟失了，這顯然不是高可靠的服務。把應用服務設計成無狀態的，讓程序把需要保存的數據都保存在專門的存儲上(eg. 資料庫)，這樣應用服務程序可以任意重啟而不丟失數據，方便分布式系統在伺服器宕機後恢復應用服務。

伸縮性的問題圍繞著以下兩種場景在解決：

無狀態場景

對於無狀態場景，要實現隨量增長而加機器支撐會比較簡單，這種情況下只用解決節點發現的問題，通常只要基於負載均衡就可以搞定，硬體或軟體方式都有；

無狀態場景通常會把很多狀態放在db，當量到一定階段後會需要引入服務化，去緩解對db連接數太多的情況。

有狀態場景

所謂狀態其實就是數據，通常採用Sharding來實現伸縮性，Sharding有多種的實現方式，常見的有這么一些：

2.1 規則Sharding

基於一定規則把狀態數據進行Sharding，例如分庫分表很多時候採用的就是這樣的，這種方式支持了伸縮性，但通常也帶來了很復雜的管理、狀態數據搬遷，甚至業務功能很難實現的問題，例如全局join，跨表事務等。

2.2 一致性Hash

一致性Hash方案會使得加機器代價更低一些，另外就是壓力可以更為均衡，例如分布式cache經常採用，和規則Sharding帶來的問題基本一樣。

2.3 Auto Sharding

Auto Sharding的好處是基本上不用管數據搬遷，而且隨著量上漲加機器就OK，但通常Auto Sharding的情況下對如何使用會有比較高的要求，而這個通常也就會造成一些限制，這種方案例如HBase。

2.4 Copy

Copy這種常見於讀遠多於寫的情況，實現起來又會有最終一致的方案和全局一致的方案，最終一致的多數可通過消息機制等，全局一致的例如zookeeper/etcd之類的，既要全局一致又要做到很高的寫支撐能力就很難實現了。

即使發展到今天，Sharding方式下的伸縮性問題仍然是很大的挑戰，非常不好做。

上面所寫的基本都還只是解決的方向，到細節點基本就很容易判斷是一個解決過多大規模場景問題的架構師，:)

穩定性

作為分布式系統，必須要考慮清楚整個系統中任何一個點掛掉應該怎麼處理（到了一定機器規模，每天掛掉一些機器很正常），同樣主要還是分成了無狀態和有狀態：

無狀態場景

對於無狀態場景，通常好辦，只用節點發現的機制上具備心跳等檢測機制就OK，經驗上來說無非就是純粹靠4層的檢測對業務不太夠，通常得做成7層的，當然，做成7層的就得處理好規模大了後的問題。

有狀態場景

對於有狀態場景，就比較麻煩了，對數據一致性要求不高的還OK，主備類型的方案基本也可以用，當然，主備方案要做的很好也非常不容易，有各種各樣的方案，對於主備方案又覺得不太爽的情況下，例如HBase這樣的，就意味著掛掉一台，另外一台接管的話是需要一定時間的，這個對可用性還是有一定影響的；

全局一致類型的場景中，如果一台掛了，就通常意味著得有選舉機制來決定其他機器哪台成為主，常見的例如基於paxos的實現。

可維護性

維護性是很容易被遺漏的部分，但對分布式系統來說其實是很重要的部分，例如整個系統環境應該怎麼搭建，部署，配套的維護工具、監控點、報警點、問題定位、問題處理策略等等。

C. java socket如果服務端掉線 客戶端應該怎樣重連，實現的思路是怎麼樣的，最好能有具體的代碼參考一下

看代碼,不明白的追問

// 無窮循環,用於自動重新連接網關
while (true) {
// 捕獲sleep異常
try {
// 捕獲socket異常
try {
// 創建socket連接
socketGateway = new Socket("127.0.0.1", 8888);

// 創建輸入輸出對象
inStream = new DataInputStream(socketGateway.getInputStream());
outStream = new DataOutputStream(socketGateway.getOutputStream());

byte buf[] = new byte[1]; // 數據緩沖區
int intLen; // 讀緩沖區返回的長度

// 無窮循環,用於讀緩沖區數據
while (true) {
// 捕獲讀緩沖區異常
try {
intLen = inStream.read(buf, 0, 1);

// 可讀長度-1則斷開連接
if (intLen == -1) {
break;
}

// 處理buf
}

// 連接斷開
catch (EOFException e) {
break;
}

// 接收數據超時
catch (SocketTimeoutException e) {
break;
}

// 超過數據包末尾
catch (IOException e) {
break;
}
}
} catch (Exception e) {
// 處理socket錯誤
}

// 休眠1秒後重連
sleep(1000);
} catch (Exception e) {
// 處理sleep錯誤
}
}

D. java服務redis重啟後需要重啟嗎

Java服務不需要重啟，當Redis重啟後，Java應用程序會自動重新連接到Redis。這是因為Java應用程序中的Redis客戶端會自動嘗試重新建立連接。在Redis重啟後，客戶端會向Redis發送PING命令，如果連接成功，則Redis會返回PONG響應，Java應用程序會收到這個響應並繼續執行。如果連接失敗，則客戶端會嘗試重新連接，直到連接成功或達到最大連接嘗試次數。

需要注意的是，在Redis重啟後，可能會出現一段時間無法訪問Redis的情況，因為Redis需要重新載入數據到內存中。如果Java應用程序需要立即訪問Redis，可以通過設置Redis的持久化配置參數來避免這種情況。另外，如果Java應用程序中有使用Redis的緩存數據，建議設置緩存過期時間，以避免緩存數據過期後無法及時更新的情況。

E. ZMQ JAVA使用經驗之 ZMQ簡介怎麼解決

ZMQ JAVA使用經驗之 ZMQ簡介怎麼解決：
ZMQ被稱為史上最快消息隊列，它處於會話層之上，應用層之下，使用後台非同步線程完成消息的接受和發送，完美的封裝了Socket API，大大簡化了編程人員的復雜度，被稱為史上最強大的消息中間件。ZMQ是用C語言編寫的，30s內完成消息的傳輸，能夠兼容多個平台，多種語言，可以使用多種方式實現N對N的Socket連接。本文僅以JAVA版本的ZMQ API為例，介紹ZMQ。
ZMQ與傳統的TCP Socket相比，具有以下優點:
1） ZMQ發送和接受的是具有固定長度的二進制對象，ZMQ的消息包最大254個位元組，前6個位元組是協議，然後是數據包。數據包由3個部分組成，第一個位元組是包的長度，第二個位元組是包的一些屬性，最後是包的內容。如果超過255個位元組（有一個位元組表示包屬性），則ZMQ會自動分包傳輸；而對於TCP Socket，是面向位元組流的連接，編程人員需要處理數據塊與數據塊之間的邊界問題，而ZMQ能夠保證每次用戶發送和接受的都是一個完整的數據塊；
2) 傳統的TCP Socket的連接是1對1的，可以認為「1個Socket=1個連接」，每一個線程獨立的維護一個Socket。但是ZMQ摒棄了這種1對1的模式，ZMQ的Socket可以很輕松的實現1對N，N對1和N對N的連接模式，一個ZMQ的Socket可以自動的維護一組連接，用戶無法操作這些連接，用戶只能操作套接字，而不是連接本身，所以說ZMQ的世界裡，連接是私有的。這里大家關心的一點是，一個Socket是如何識別來自多個Socket的連接的，這里以請求響應模式為例介紹ZMQ是如何實現一個Socket連接N個Socket的；
3）ZMQ使用非同步後台線程處理接受和發送請求，這意味著發送完消息，不可以立即釋放資源，消息什麼時候發送用戶是無法控制的，同時，ZMQ自動重連，這意味著用戶可以以任意順序加入到網路中，伺服器也可以隨時加入或者退出網路；
ZMQ之所以能夠在無狀態的網路中實現1對N的連接，關鍵在於信封的機制，信封里保存了應答目標的位置。ZMQ涉及到請求-響應模式的Socket一共有4種類型：

DEALER是一種負載均衡，它會將消息分發給已連接的節點，並使用公平隊列的機制處理接受到的消息。
REQ發送消息時會在消息頂部插入一個空幀，接受時會將空幀移去。其實REQ是建立在DEALER之上的，但REQ只有當消息發送並接受到回應後才能繼續運行。
ROUTER在收到消息時會在頂部添加一個信封，標記消息來源。發送時會通過該信封決定哪個節點可以獲取到該條消息。
REP在收到消息時會將第一個空幀之前的所有信息保存起來，將原始信息傳送給應用程序。在發送消息時，REP會用剛才保存的信息包裹應答消息。REP其實是建立在ROUTER之上的，但和REQ一樣，必須完成接受和發送這兩個動作後才能繼續。
在了解了4種類型的Socket之後，我們就不難理解ZMQ的信封機制了。ZMQ信封機制的核心是Router Socket，它的工作原理如下：
從ROUTER中讀取一條消息時，ZMQ會包上一層信封，上面註明了消息的來源。向ROUTER寫入一條消息時（包含信封），ZMQ會將信封拆開，並將消息遞送給相應的對象。當REQ Socket向ROUTER Socket發送一條請求後，REP會從ROUTER收到一條消息，消息格式如下：

第三幀是REP從應用程序收到的數據，第二幀是空幀，是REQ在發送ROUTER數據之前添加的，用來表示結束，第一幀即信封，是ROUTER添加的，主要用來記錄消息來源；整個數據包處理過程如下：

對於REQ Socket，可以在創建Socket的時候，為該Sock指定標示符，此時的Socket稱為持久Socket，沒有指定標示符的我們稱為瞬時Socket，ROUTER會自動為瞬時Socket生成一個標示符；

這樣REP返回包含信封的數據給ROUTER，ROUTER就可以根據信封上的標示符將該消息發送到對應的REQ上；
ZMQ使用注意事項：
ZMQ是在發送端緩存消息的，可以通過閾值控制消息的溢出；
ZMQ不可以線程之間共享Socket，否則會報org.zeromq.ZMQException: Operation cannot be accomplished in current state錯誤。
ZMQ一個進程只允許有一個Context，new Context(int arg) arg表示後台線程的數量；
ZMQ的Socket類有一個Linger參數，可以通過SetLinger設置，主要用於表示該Socket關閉以後，未發送成功的消息是否還保存，如果設置為-1表示該消息將永久保存（除非宕機，ZMQ是不持久化消息的），如果為0表示所有未發送成功的消息在Socker關閉以後都將立即清除，如果是一個正數，則表示該消息在Socket關閉後多少毫秒內被刪除；這個方法非常有用，尤其在控制發送失敗時，是否重發消息。