文章內容結構
第一部分介紹生產(chǎn)上出現Dubbo服務(wù)擁堵的情況，以及Dubbo官方對于單個(gè)長(cháng)連接的使用建議。
第二部分介紹Dubbo在特定配置下的通信過(guò)程，輔以代碼。
第三部分介紹整個(gè)調用過(guò)程中與性能相關(guān)的一些參數。
第四部分通過(guò)調整連接數和TCP緩沖區觀(guān)察Dubbo的性能。
一、背景
生產(chǎn)擁堵回顧
近期在一次生產(chǎn)發(fā)布過(guò)程中，因為突發(fā)的流量，出現了擁堵。系統的部署圖如下，客戶(hù)端通過(guò)Http協(xié)議訪(fǎng)問(wèn)到Dubbo的消費者，消費者通過(guò)Dubbo協(xié)議訪(fǎng)問(wèn)服務(wù)提供者。這是單個(gè)機房，8個(gè)消費者3個(gè)提供者，共兩個(gè)機房對外服務(wù)。
在發(fā)布的過(guò)程中，摘掉一個(gè)機房，讓另一個(gè)機房對外服務(wù)，然后摘掉的機房發(fā)布新版本，然后再互換，最終兩個(gè)機房都以新版本對外服務(wù)。問(wèn)題就出現單機房對外服務(wù)的時(shí)候，這時(shí)候單機房還是老版本應用。以前不知道晚上會(huì )有一個(gè)高峰，結果當晚的高峰和早上的高峰差不多了，單機房扛不住這么大的流量，出現了擁堵。這些流量的特點(diǎn)是并發(fā)比較高，個(gè)別交易返回報文較大，因為是一個(gè)產(chǎn)品列表頁(yè)，點(diǎn)擊后會(huì )發(fā)送多個(gè)交易到后臺。
在問(wèn)題發(fā)生時(shí)，因為不清楚狀態(tài)，先切到另外一個(gè)機房，結果也擁堵了，最后整體回退，折騰了一段時(shí)間沒(méi)有問(wèn)題了。當時(shí)有一些現象：
(1)提供者的CPU內存等都不高，第一個(gè)機房的最高CPU 66%(8核虛擬機)，第二個(gè)機房的最高CPU 40%(16核虛擬機)。消費者的最高CPU只有30%多(兩個(gè)消費者結點(diǎn)位于同一臺虛擬機上)
(2)在擁堵的時(shí)候，服務(wù)提供者的Dubbo業(yè)務(wù)線(xiàn)程池(下面會(huì )詳細介紹這個(gè)線(xiàn)程池)并沒(méi)滿(mǎn)，最多到了300，最大值是500。但是把這個(gè)機房摘下后，也就是沒(méi)有外部的流量了，線(xiàn)程池反而滿(mǎn)了，而且好幾分鐘才把堆積的請求處理完。
(3)通過(guò)監控工具統計的每秒進(jìn)入Dubbo業(yè)務(wù)線(xiàn)程池的請求數，在擁堵時(shí)，時(shí)而是0，時(shí)而特別大，在日間正常的時(shí)候，這個(gè)值不存在為0的時(shí)候。
事故原因猜測
當時(shí)其他指標沒(méi)有檢測到異常，也沒(méi)有打Dump，我們通過(guò)分析這些現象以及我們的Dubbo配置，猜測是在網(wǎng)絡(luò )上發(fā)生了擁堵，而影響擁堵的關(guān)鍵參數就是Dubbo協(xié)議的連接數，我們默認使用了單個(gè)連接，但是消費者數量較少，沒(méi)能充分把網(wǎng)絡(luò )資源利用起來(lái)。
默認的情況下，每個(gè)Dubbo消費者與Dubbo提供者建立一個(gè)長(cháng)連接，Dubbo官方對此的建議是：
Dubbo 缺省協(xié)議采用單一長(cháng)連接和 NIO 異步通訊，適合于小數據量大并發(fā)的服務(wù)調用，以及服務(wù)消費者機器數遠大于服務(wù)提供者機器數的情況。
反之，Dubbo 缺省協(xié)議不適合傳送大數據量的服務(wù)，比如傳文件，傳視頻等，除非請求量很低。
以下也是Dubbo官方提供的一些常見(jiàn)問(wèn)題回答：
為什么要消費者比提供者個(gè)數多?
因 dubbo 協(xié)議采用單一長(cháng)連接，假設網(wǎng)絡(luò )為千兆網(wǎng)卡，根據測試經(jīng)驗數據每條連接最多只能壓滿(mǎn) 7MByte(不同的環(huán)境可能不一樣，供參考)，理論上 1 個(gè)服務(wù)提供者需要 20 個(gè)服務(wù)消費者才能壓滿(mǎn)網(wǎng)卡。
為什么不能傳大包?
因 dubbo 協(xié)議采用單一長(cháng)連接，如果每次請求的數據包大小為 500KByte，假設網(wǎng)絡(luò )為千兆網(wǎng)卡，每條連接最大 7MByte(不同的環(huán)境可能不一樣，供參考)，單個(gè)服務(wù)提供者的 TPS(每秒處理事務(wù)數)最大為：128MByte / 500KByte = 262。單個(gè)消費者調用單個(gè)服務(wù)提供者的 TPS(每秒處理事務(wù)數)最大為：7MByte / 500KByte = 14。如果能接受，可以考慮使用，否則網(wǎng)絡(luò )將成為瓶頸。
為什么采用異步單一長(cháng)連接?
因為服務(wù)的現狀大都是服務(wù)提供者少，通常只有幾臺機器，而服務(wù)的消費者多，可能整個(gè)網(wǎng)站都在訪(fǎng)問(wèn)該服務(wù)，比如 Morgan 的提供者只有 6 臺提供者，卻有上百臺消費者，每天有 1.5 億次調用，如果采用常規的 hessian 服務(wù)，服務(wù)提供者很容易就被壓跨，通過(guò)單一連接，保證單一消費者不會(huì )壓死提供者，長(cháng)連接，減少連接握手驗證等，并使用異步 IO，復用線(xiàn)程池，防止 C10K 問(wèn)題。
因為我們的消費者數量和提供者數量都不多，所以很可能是連接數不夠，導致網(wǎng)絡(luò )傳輸出現了瓶頸。以下我們通過(guò)詳細分析Dubbo協(xié)議和一些實(shí)驗來(lái)驗證我們的猜測。
二、Dubbo通信流程詳解
我們用的Dubbo版本比較老，是2.5.x的，它使用的netty版本是3.2.5，最新版的Dubbo在線(xiàn)程模型上有一些修改，我們以下的分析是以2.5.10為例。
以圖和部分代碼說(shuō)明Dubbo協(xié)議的調用過(guò)程，代碼只寫(xiě)了一些關(guān)鍵部分，使用的是netty3，dubbo線(xiàn)程池無(wú)隊列，同步調用，以下代碼包含了Dubbo和Netty的代碼。
1.請求入隊
我們通過(guò)Dubbo調用一個(gè)rpc服務(wù)，調用線(xiàn)程其實(shí)是把這個(gè)請求封裝后放入了一個(gè)隊列里。這個(gè)隊列是netty的一個(gè)隊列，這個(gè)隊列的定義如下，是一個(gè)Linked隊列，不限長(cháng)度。
class NioWorker implements Runnable { ... private final Queue<Runnable> writeTaskQueue = new LinkedTransferQueue<Runnable>(); ...}
主線(xiàn)程經(jīng)過(guò)一系列調用，最終通過(guò)NioClientSocketPipelineSink類(lèi)里的方法把請求放入這個(gè)隊列，放入隊列的請求，包含了一個(gè)請求ID，這個(gè)ID很重要。
2.調用線(xiàn)程等待
入隊后，netty會(huì )返回給調用線(xiàn)程一個(gè)Future，然后調用線(xiàn)程等待在Future上。這個(gè)Future是Dubbo定義的，名字叫DefaultFuture，主調用線(xiàn)程調用DefaultFuture.get(timeout)，等待通知，所以我們看與Dubbo相關(guān)的ThreadDump，經(jīng)常會(huì )看到線(xiàn)程停在這，這就是在等后臺返回。
public class DubboInvoker<T> extends AbstractInvoker<T> { ... @Override protected Result doInvoke(final Invocation invocation) throws Throwable { ... return (Result) currentClient.request(inv, timeout).get(); //currentClient.request(inv, timeout)返回了一個(gè)DefaultFuture } ...}
我們可以看一下這個(gè)DefaultFuture的實(shí)現，
public class DefaultFuture implements ResponseFuture {
private static final Map<Long, Channel> CHANNELS = new ConcurrentHashMap<Long, Channel>(); private static final Map<Long, DefaultFuture> FUTURES = new ConcurrentHashMap<Long, DefaultFuture>();
// invoke id. private final long id; //Dubbo請求的id，每個(gè)消費者都是一個(gè)從0開(kāi)始的long類(lèi)型 private final Channel channel; private final Request request; private final int timeout; private final Lock lock = new ReentrantLock(); private final Condition done = lock.newCondition(); private final long start = System.currentTimeMillis(); private volatile long sent; private volatile Response response; private volatile ResponseCallback callback; public DefaultFuture(Channel channel, Request request, int timeout) { this.channel = channel; this.request = request; this.id = request.getId(); this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT); // put into waiting map. FUTURES.put(id, this); //等待時(shí)以id為key把Future放入全局的Future Map中，這樣回復數據回來(lái)了可以根據id找到對應的Future通知主線(xiàn)程 CHANNELS.put(id, channel); }
3.IO線(xiàn)程讀取隊列里的數據
這個(gè)工作是由netty的IO線(xiàn)程池完成的，也就是NioWorker，對應的類(lèi)叫NioWorker。它會(huì )死循環(huán)的執行select，在select中，會(huì )一次性把隊列中的寫(xiě)請求處理完，select的邏輯如下：
public void run() { for (;;) { .... SelectorUtil.select(selector);
proce***egisterTaskQueue(); processWriteTaskQueue(); //先處理隊列里的寫(xiě)請求 processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫(xiě)都可能有 .... } } private void processWriteTaskQueue() throws IOException { for (;;) { final Runnable task = writeTaskQueue.poll();//這個(gè)隊列就是調用線(xiàn)程把請求放進(jìn)去的隊列 if (task == null) { break; } task.run(); //寫(xiě)數據 cleanUpCancelledKeys(); } }
4.IO線(xiàn)程把數據寫(xiě)到Socket緩沖區
這一步很重要，跟我們遇到的性能問(wèn)題相關(guān)，還是NioWorker，也就是上一步的task.run()，它的實(shí)現如下：
void writeFromTaskLoop(final NioSocketChannel ch) { if (!ch.writeSuspended) { //這個(gè)地方很重要，如果writeSuspended了，那么就直接跳過(guò)這次寫(xiě) write0(ch); } } private void write0(NioSocketChannel channel) { ...... final int writeSpinCount = channel.getConfig().getWriteSpinCount(); //netty可配置的一個(gè)參數，默認是16 synchronized (channel.writeLock) { channel.inWriteNowLoop = true; for (;;) {
for (int i = writeSpinCount; i > 0; i --) { //每次最多嘗試16次 localWrittenBytes = buf.transferTo(ch); if (localWrittenBytes != 0) { writtenBytes += localWrittenBytes; break; } if (buf.finished()) { break; } }
if (buf.finished()) { // Successful write - proceed to the next message. buf.release(); channel.currentWriteEvent = null; channel.currentWriteBuffer = null; evt = null; buf = null; future.setSuccess(); } else { // Not written fully - perhaps the kernel buffer is full. //重點(diǎn)在這，如果寫(xiě)16次還沒(méi)寫(xiě)完，可能是內核緩沖區滿(mǎn)了，writeSuspended被設置為true addOpWrite = true; channel.writeSuspended = true; ...... } ...... if (open) { if (addOpWrite) { setOpWrite(channel); } else if (removeOpWrite) { clearOpWrite(channel); } } ...... }
fireWriteComplete(channel, writtenBytes); }
正常情況下，隊列中的寫(xiě)請求要通過(guò)processWriteTaskQueue處理掉，但是這些寫(xiě)請求也同時(shí)注冊到了selector上，如果processWriteTaskQueue寫(xiě)成功，就會(huì )刪掉selector上的寫(xiě)請求。如果Socket的寫(xiě)緩沖區滿(mǎn)了，對于NIO，會(huì )立刻返回，對于BIO，會(huì )一直等待。Netty使用的是NIO，它嘗試16次后，還是不能寫(xiě)成功，它就把writeSuspended設置為true，這樣接下來(lái)的所有寫(xiě)請求都會(huì )被跳過(guò)。那什么時(shí)候會(huì )再寫(xiě)呢？這時(shí)候就得靠selector了，它如果發(fā)現
流量交易socket可寫(xiě)，就把這些數據寫(xiě)進(jìn)去。
下面是processSelectedKeys里寫(xiě)的過(guò)程，因為它是發(fā)現socket可寫(xiě)才會(huì )寫(xiě)，所以直接把writeSuspended設為false。
void writeFromSelectorLoop(final SelectionKey k) { NioSocketChannel ch = (NioSocketChannel) k.attachment(); ch.writeSuspended = false; write0(ch); }
5.數據從消費者的socket發(fā)送緩沖區傳輸到提供者的接收緩沖區
這個(gè)是操作系統和網(wǎng)卡實(shí)現的，應用層的write寫(xiě)成功了，并不代表對面能收到，當然tcp會(huì )通過(guò)重傳能機制盡量保證對端收到。
6.服務(wù)端IO線(xiàn)程從緩沖區讀取請求數據
這個(gè)是服務(wù)端的NIO線(xiàn)程實(shí)現的，在processSelectedKeys中。
public void run() { for (;;) { .... SelectorUtil.select(selector);
proce***egisterTaskQueue(); processWriteTaskQueue(); processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫(xiě)都可能有 .... } } private void processSelectedKeys(Set<SelectionKey> selectedKeys) throws IOException { for (Iterator<SelectionKey> i = selectedKeys.iterator(); i.hasNext();) { SelectionKey k = i.next(); i.remove(); try { int readyOps = k.readyOps(); if ((readyOps & SelectionKey.OP_READ) != 0 || readyOps == 0) { if (!read(k)) { // Connection already closed - no need to handle write. continue; } } if ((readyOps & SelectionKey.OP_WRITE) != 0) { writeFromSelectorLoop(k); } } catch (CancelledKeyException e) { close(k); }
if (cleanUpCancelledKeys()) { break; // break the loop to avoid ConcurrentModificationException } } } private boolean read(SelectionKey k) { ......
// Fire the event. fireMessageReceived(channel, buffer); //讀取完后，最終會(huì )調用這個(gè)函數，發(fā)送一個(gè)收到信息的事件 ......
}
7.IO線(xiàn)程把請求交給Dubbo線(xiàn)程池
按配置不同，走的Handler不同，配置dispatch為all，走的handler如下。下面IO線(xiàn)程直接交給一個(gè)ExecutorService來(lái)處理這個(gè)請求，出現了熟悉的報錯“Threadpool is exhausted"，業(yè)務(wù)線(xiàn)程池滿(mǎn)時(shí)，如果沒(méi)有隊列，就會(huì )報這個(gè)錯。
public class AllChannelHandler extends WrappedChannelHandler { ...... public void received(Channel channel, Object message) throws RemotingException { ExecutorService cexecutor = getExecutorService(); try { cexecutor.execute(new ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message)); } catch (Throwable t) { //TODO A temporary solution to the problem that the exception information can not be sent to the opposite end after the thread pool is full. Need a refactoring //fix The thread pool is full, refuses to call, does not return, and causes the consumer to wait for time out if(message instanceof Request && t instanceof RejectedExecutionException){ Request request = (Request)message; if(request.isTwoWay()){ String msg = "Server side(" + url.getIp() + "," + url.getPort() + ") threadpool is exhausted ,detail msg:" + t.getMessage(); Response response = new Response(request.getId(), request.getVersion()); response.setStatus(Response.SERVER_THREADPOOL_EXHAUSTED_ERROR); response.setErrorMessage(msg); channel.send(response); return; } } throw new ExecutionException(message, channel, getClass() + " error when process received event .", t); } } ......}
8.服務(wù)端Dubbo線(xiàn)程池處理完請求后，把返回報文放入隊列
線(xiàn)程池會(huì )調起下面的函數
public class HeaderExchangeHandler implements ChannelHandlerDelegate { ...... Response handleRequest(ExchangeChannel channel, Request req) throws RemotingException { Response res = new Response(req.getId(), req.getVersion()); ...... // find handler by message class. Object msg = req.getData(); try { // handle data. Object result = handler.reply(channel, msg); //真正的業(yè)務(wù)邏輯類(lèi) res.setStatus(Response.OK); res.setResult(result); } catch (Throwable e) { res.setStatus(Response.SERVICE_ERROR); res.setErrorMessage(StringUtils.toString(e)); } return res; }
public void received(Channel channel, Object message) throws RemotingException { ......
if (message instanceof Request) { // handle request. Request request = (Request) message;
if (request.isTwoWay()) { Response response = handleRequest(exchangeChannel, request); //處理業(yè)務(wù)邏輯，得到一個(gè)Response channel.send(response); //回寫(xiě)response } } ......
}
channel.send(response)最終調用了NioServerSocketPipelineSink里的方法把返回報文放入隊列。
9.服務(wù)端IO線(xiàn)程從隊列中取出數據
與流程3一樣
10.服務(wù)端IO線(xiàn)程把回復數據寫(xiě)入Socket發(fā)送緩沖區
IO線(xiàn)程寫(xiě)數據的時(shí)候，寫(xiě)入到TCP緩沖區就算成功了。但是如果緩沖區滿(mǎn)了，會(huì )寫(xiě)不進(jìn)去。對于阻塞和非阻塞IO，返回結果不一樣，阻塞IO會(huì )一直等，而非阻塞IO會(huì )立刻失敗，讓調用者選擇策略。
Netty的策略是嘗試最多寫(xiě)16次，如果不成功，則暫時(shí)停掉IO線(xiàn)程的寫(xiě)操作，等待連接可寫(xiě)時(shí)再寫(xiě)，writeSpinCount默認是16，可以通過(guò)參數調整。
for (int i = writeSpinCount; i > 0; i --) { localWrittenBytes = buf.transferTo(ch); if (localWrittenBytes != 0) { writtenBytes += localWrittenBytes; break; } if (buf.finished()) { break; } }
if (buf.finished()) { // Successful write - proceed to the next message. buf.release(); channel.currentWriteEvent = null; channel.currentWriteBuffer = null; evt = null; buf = null; future.setSuccess(); } else { // Not written fully - perhaps the kernel buffer is full. addOpWrite = true; channel.writeSuspended = true;
11.數據傳輸
數據在網(wǎng)絡(luò )上傳輸主要取決于帶寬和網(wǎng)絡(luò )環(huán)境。
12.客戶(hù)端IO線(xiàn)程把數據從緩沖區讀出
這個(gè)過(guò)程跟流程6是一樣的
13.IO線(xiàn)程把數據交給Dubbo業(yè)務(wù)線(xiàn)程池
這一步與流程7是一樣的，這個(gè)線(xiàn)程池名字為DubboClientHandler。
14.業(yè)務(wù)線(xiàn)程池根據消息ID通知主線(xiàn)程
先通過(guò)HeaderExchangeHandler的received函數得知是Response，然后調用handleResponse，
public class HeaderExchangeHandler implements ChannelHandlerDelegate { static void handleResponse(Channel channel, Response response) throws RemotingException { if (response != null && !response.isHeartbeat()) { DefaultFuture.received(channel, response); } } public void received(Channel channel, Object message) throws RemotingException { ...... if (message instanceof Response) { handleResponse(channel, (Response) message); } ......}
DefaultFuture根據ID獲取Future，通知調用線(xiàn)程
public static void received(Channel channel, Response response) { ...... DefaultFuture future = FUTURES.remove(response.getId()); if (future != null) { future.doReceived(response); } ...... }
至此，主線(xiàn)程獲取了返回數據，調用結束。
三、影響上述流程的關(guān)鍵參數
協(xié)議參數
我們在使用Dubbo時(shí)，需要在服務(wù)端配置協(xié)議，例如
<dubbo:protocol name="dubbo" port="20880" dispatcher="all" threadpool="fixed" threads="2000" />
下面是協(xié)議中與性能相關(guān)的一些參數，在我們的使用場(chǎng)景中，線(xiàn)程池選用了fixed，大小是500，隊列為0，其他都是默認值。
屬性
對應URL參數
類(lèi)型
是否必填
缺省值
作用
描述
name
<protocol>
string
必填
dubbo
性能調優(yōu)
協(xié)議名稱(chēng)
threadpool
threadpool
string
可選
fixed
性能調優(yōu)
線(xiàn)程池類(lèi)型，可選：fixed/cached。
threads
threads
int
可選
200
性能調優(yōu)
服務(wù)線(xiàn)程池大小(固定大小)
queues
queues
int
可選
0
性能調優(yōu)
線(xiàn)程池隊列大小，當線(xiàn)程池滿(mǎn)時(shí)，排隊等待執行的隊列大小，建議不要設置，當線(xiàn)程池滿(mǎn)時(shí)應立即失敗，重試其它服務(wù)提供機器，而不是排隊，除非有特殊需求。
iothreads
iothreads
int
可選
cpu個(gè)數+1
性能調優(yōu)
io線(xiàn)程池大小(固定大小)
accepts
accepts
int
可選
0
性能調優(yōu)
服務(wù)提供方最大可接受連接數，這個(gè)是整個(gè)服務(wù)端可以建的最大連接數，比如設置成2000，如果已經(jīng)建立了2000個(gè)連接，新來(lái)的會(huì )被拒絕，是為了保護服務(wù)提供方。
dispatcher
dispatcher
string
可選
dubbo協(xié)議缺省為all
性能調優(yōu)
協(xié)議的消息派發(fā)方式，用于指定線(xiàn)程模型，比如：dubbo協(xié)議的all, direct, message, execution, connection等。 這個(gè)主要牽涉到IO線(xiàn)程池和業(yè)務(wù)線(xiàn)程池的分工問(wèn)題，一般情況下，讓業(yè)務(wù)線(xiàn)程池處理建立連接、心跳等，不會(huì )有太大影響。
payload
payload
int
可選
8388608(=8M)
性能調優(yōu)
請求及響應數據包大小限制，單位：字節。 這個(gè)是單個(gè)報文允許的最大長(cháng)度，Dubbo不適合報文很長(cháng)的請求，所以加了限制。
buffer
buffer
int
可選
8192
性能調優(yōu)
網(wǎng)絡(luò )讀寫(xiě)緩沖區大小。注意這個(gè)不是TCP緩沖區，這個(gè)是在讀寫(xiě)網(wǎng)絡(luò )報文時(shí)，應用層的Buffer。
codec
codec
string
可選
dubbo
性能調優(yōu)
協(xié)議編碼方式
serialization
serialization
string
可選
dubbo協(xié)議缺省為hessian2，rmi協(xié)議缺省為java，http協(xié)議缺省為json
性能調優(yōu)
協(xié)議序列化方式，當協(xié)議支持多種序列化方式時(shí)使用，比如：dubbo協(xié)議的dubbo,hessian2,java,compactedjava，以及http協(xié)議的json等
transporter
transporter
string
可選
dubbo協(xié)議缺省為netty
性能調優(yōu)
協(xié)議的服務(wù)端和客戶(hù)端實(shí)現類(lèi)型，比如：dubbo協(xié)議的mina,netty等，可以分拆為server和client配置
server
server
string
可選
dubbo協(xié)議缺省為netty，http協(xié)議缺省為servlet
性能調優(yōu)
協(xié)議的服務(wù)器端實(shí)現類(lèi)型，比如：dubbo協(xié)議的mina,netty等，http協(xié)議的jetty,servlet等
client
client
string
可選
dubbo協(xié)議缺省為netty
性能調優(yōu)
協(xié)議的客戶(hù)端實(shí)現類(lèi)型，比如：dubbo協(xié)議的mina,netty等
charset
charset
string
可選
UTF-8
性能調優(yōu)
序列化編碼
heartbeat
heartbeat
int
可選
0
性能調優(yōu)
心跳間隔，對于長(cháng)連接，當物理層斷開(kāi)時(shí)，比如拔網(wǎng)線(xiàn)，TCP的FIN消息來(lái)不及發(fā)送，對方收不到斷開(kāi)事件，此時(shí)需要心跳來(lái)幫助檢查連接是否已斷開(kāi)
服務(wù)參數
針對每個(gè)Dubbo服務(wù)，都會(huì )有一個(gè)配置，全部的參數配置在這：
我們關(guān)注幾個(gè)與性能相關(guān)的。在我們的使用場(chǎng)景中，重試次數設置成了0，集群方式用的failfast，其他是默認值。
屬性
對應URL參數
類(lèi)型
是否必填
缺省值
作用
描述
兼容性
delay
delay
int
可選
0
性能調優(yōu)
延遲注冊服務(wù)時(shí)間(毫秒) ，設為-1時(shí)，表示延遲到Spring容器初始化完成時(shí)暴露服務(wù)
1.0.14以上版本
timeout
timeout
int
可選
1000
性能調優(yōu)
遠程服務(wù)調用超時(shí)時(shí)間(毫秒)
2.0.0以上版本
retries
retries
int
可選
2
性能調優(yōu)
遠程服務(wù)調用重試次數，不包括第一次調用，不需要重試請設為0
2.0.0以上版本
connections
connections
int
可選
1
性能調優(yōu)
對每個(gè)提供者的最大連接數，rmi、http、hessian等短連接協(xié)議表示限制連接數，dubbo等長(cháng)連接協(xié)表示建立的長(cháng)連接個(gè)數
2.0.0以上版本
loadbalance
loadbalance
string
可選
random
性能調優(yōu)
負載均衡策略，可選值：random,roundrobin,leastactive，分別表示：隨機，輪詢(xún)，最少活躍調用
2.0.0以上版本
async
async
boolean
可選
false
性能調優(yōu)
是否缺省異步執行，不可靠異步，只是忽略返回值，不阻塞執行線(xiàn)程
2.0.0以上版本
weight
weight
int
可選
性能調優(yōu)
服務(wù)權重
2.0.5以上版本
executes
executes
int
可選
0
性能調優(yōu)
服務(wù)提供者每服務(wù)每方法最大可并行執行請求數
2.0.5以上版本
proxy
proxy
string
可選
javassist
性能調優(yōu)
生成動(dòng)態(tài)代理方式，可選：jdk/javassist
2.0.5以上版本
cluster
cluster
string
可選
failover
性能調優(yōu)
集群方式，可選：failover/failfast/failsafe/failback/forking
2.0.5以上版本
這次擁堵的主要原因，應該就是服務(wù)的connections設置的太小，dubbo不提供全局的連接數配置，只能針對某一個(gè)交易做個(gè)性化的連接數配置。
四、連接數與Socket緩沖區對性能影響的實(shí)驗
通過(guò)簡(jiǎn)單的Dubbo服務(wù)，驗證一下連接數與緩沖區大小對傳輸性能的影響。
我們可以通過(guò)修改系統參數，調節TCP緩沖區的大小。
在 /etc/sysctl.conf 修改如下內容， tcp_rmem是發(fā)送緩沖區，tcp_wmem是接收緩沖區，三個(gè)數值表示最小值，默認值和最大值，我們可以都設置成一樣。
net.ipv4.tcp_rmem = 4096 873800 16777216net.ipv4.tcp_wmem = 4096 873800 16777216
然后執行sysctl –p 使之生效。
服務(wù)端代碼如下，接受一個(gè)報文，然后返回兩倍的報文長(cháng)度，隨機sleep 0-300ms，所以均值應該是150ms。服務(wù)端每10s打印一次tps和響應時(shí)間，這里的tps是指完成函數調用的tps，而不涉及傳輸，響應時(shí)間也是這個(gè)函數的時(shí)間。
//服務(wù)端實(shí)現 public String sayHello(String name) { counter.getAndIncrement(); long start = System.currentTimeMillis(); try { Thread.sleep(rand.nextInt(300)); } catch (InterruptedException e) { } String result = "Hello " + name + name + ", response form provider: " + RpcContext.getContext().getLocalAddress(); long end = System.currentTimeMillis(); timer.getAndAdd(end-start); return result; }
客戶(hù)端起N個(gè)線(xiàn)程，每個(gè)線(xiàn)程不停的調用Dubbo服務(wù)，每10s打印一次qps和響應時(shí)間，這個(gè)qps和響應時(shí)間是包含了網(wǎng)絡(luò )傳輸時(shí)間的。
for(int i = 0; i < N; i ++) { threads[i] = new Thread(new Runnable() { @Override public void run() { while(true) { Long start = System.currentTimeMillis(); String hello = service.sayHello(z); Long end = System.currentTimeMillis(); totalTime.getAndAdd(end-start); counter.getAndIncrement(); } }}); threads[i].start(); }
通過(guò)ss -it命令可以看當前tcp socket的詳細信息，包含待對端回復ack的數據Send-Q，最大窗口cwnd，rtt(round trip time)等。
(base) niuxinli@ubuntu:~$ ss -itState Recv-Q Send-Q Local Address:Port Peer Address:PortESTAB 0 36 192.168.1.7:ssh 192.168.1.4:58931 cubic wscale:8,2 rto:236 rtt:33.837/8.625 ato:40 mss:1460 pmtu:1500 rcvmss:1460 advmss:1460 cwnd:10 bytes_acked:559805 bytes_received:54694 segs_out:2754 segs_in:2971 data_segs_out:2299 data_segs_in:1398 send 3.5Mbps pacing_rate 6.9Mbps delivery_rate 44.8Mbps busy:36820ms unacked:1 rcv_rtt:513649 rcv_space:16130 rcv_ssthresh:14924 minrtt:0.112ESTAB 0 0 192.168.1.7:36666 192.168.1.7:2181 cubic wscale:7,7 rto:204 rtt:0.273/0.04 ato:40 mss:33344 pmtu:65535 rcvmss:536 advmss:65483 cwnd:10 bytes_acked:2781 bytes_received:3941 segs_out:332 segs_in:170 data_segs_out:165 data_segs_in:165 send 9771.1Mbps lastsnd:4960 lastrcv:4960 lastack:4960 pacing_rate 19497.6Mbps delivery_rate 7621.5Mbps app_limited busy:60ms rcv_space:65535 rcv_ssthresh:66607 minrtt:0.035ESTAB 0 27474 192.168.1.7:20880 192.168.1.5:60760 cubic wscale:7,7 rto:204 rtt:1.277/0.239 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:625 ssthresh:20 bytes_acked:96432644704 bytes_received:49286576300 segs_out:68505947 segs_in:36666870 data_segs_out:67058676 data_segs_in:35833689 send 5669.5Mbps pacing_rate 6801.4Mbps delivery_rate 627.4Mbps app_limited busy:1340536ms rwnd_limited:400372ms(29.9%) sndbuf_limited:433724ms(32.4%) unacked:70 retrans:0/5 rcv_rtt:1.308 rcv_space:336692 rcv_ssthresh:2095692 notsent:6638 minrtt:0.097
通過(guò)netstat -nat也能查看當前tcp socket的一些信息，比如Recv-Q, Send-Q。
(base) niuxinli@ubuntu:~$ netstat -natActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 0.0.0.0:20880 0.0.0.0:* LISTENtcp 0 36 192.168.1.7:22 192.168.1.4:58931 ESTABLISHEDtcp 0 0 192.168.1.7:36666 192.168.1.7:2181 ESTABLISHEDtcp 0 65160 192.168.1.7:20880 192.168.1.5:60760 ESTABLISHED
可以看以下Recv-Q和Send-Q的具體含義：
Recv-Q Established: The count of bytes not copied by the user program connected to this socket.
Send-Q Established: The count of bytes not acknowledged by the remote host.
Recv-Q是已經(jīng)到了接受緩沖區，但是還沒(méi)被應用代碼讀走的數據。Send-Q是已經(jīng)到了發(fā)送緩沖區，但是對方還沒(méi)有回復Ack的數據。這兩種數據正常一般不會(huì )堆積，如果堆積了，可能就有問(wèn)題了。
第一組實(shí)驗：?jiǎn)芜B接，改變TCP緩沖區
結果：
角色
Socket緩沖區
響應時(shí)間
服務(wù)端
32k/32k
150ms
客戶(hù)端(800并發(fā))
32k/32k
430ms
客戶(hù)端(1并發(fā))
32k/32k
150ms
繼續調大緩沖區
角色
Socket緩沖區
響應時(shí)間
CPU
服務(wù)端
64k/64k
150ms
user 2%, sys 9%
客戶(hù)端(800并發(fā))
64k/64k
275ms
user 4%, sys 13%
客戶(hù)端(1并發(fā))
64k/64k
150ms
user 4%, sys 13%
我們用netstat或者ss命令可以看到當前的socket情況，下面的第二列是Send-Q大小，是寫(xiě)入緩沖區還沒(méi)有被對端確認的數據，發(fā)送緩沖區最大時(shí)64k左右，說(shuō)明緩沖區不夠用。
繼續增大緩沖區，到4M，我們可以看到，響應時(shí)間進(jìn)一步下降，但是還是在傳輸上浪費了不少時(shí)間，因為服務(wù)端應用層沒(méi)有壓力。
角色
Socket緩沖區
響應時(shí)間
CPU
服務(wù)端
4M/4M
150ms
user 4%, sys 10%
客戶(hù)端(800并發(fā))
4M/4M
210ms
user 10%, sys 12%
客戶(hù)端(1并發(fā))
4M/4M
150ms
user 10%, sys 12%
服務(wù)端和客戶(hù)端的TCP情況如下，緩沖區都沒(méi)有滿(mǎn)
<center>服務(wù)端</center>
<center>客戶(hù)端</center>
這個(gè)時(shí)候，再怎么調大TCP緩沖區，也是沒(méi)用的，因為瓶頸不在這了，而在于連接數。因為在Dubbo中，一個(gè)連接會(huì )綁定到一個(gè)NioWorker線(xiàn)程上，讀寫(xiě)都由這一個(gè)連接完成，傳輸的速度超過(guò)了單個(gè)線(xiàn)程的讀寫(xiě)能力，所以我們看到在客戶(hù)端，大量的數據擠壓在接收緩沖區，沒(méi)被讀走，這樣對端的傳輸速率也會(huì )慢下來(lái)。
第二組實(shí)驗：多連接，固定緩沖區
服務(wù)端的純業(yè)務(wù)函數響應時(shí)間很穩定，在緩沖區較小的時(shí)候，調大連接數雖然能讓時(shí)間降下來(lái)，但是并不能到最優(yōu)，所以緩沖區不能設置太小，Linux一般默認是4M，在4M的時(shí)候，4個(gè)連接基本上已經(jīng)能把響應時(shí)間降到最低了。
角色
Socket緩沖區
響應時(shí)間
服務(wù)端
32k/32k
150ms
客戶(hù)端(800并發(fā),1連接)
32k/32k
430ms
客戶(hù)端(800并發(fā),2連接)
32k/32k
205ms
客戶(hù)端(800并發(fā),4連接)
32k/32k
160ms
客戶(hù)端(800并發(fā),6連接)
32k/32k
156ms
客戶(hù)端(800并發(fā),8連接)
32k/32k
156ms
客戶(hù)端(800并發(fā),2連接)
1M/1M
156ms
客戶(hù)端(800并發(fā),2連接)
4M/4M
156ms
客戶(hù)端(800并發(fā),4連接)
4M/4M
151ms
客戶(hù)端(800并發(fā),6連接)
4M/4M
151ms
結論
要想充分利用網(wǎng)絡(luò )帶寬， 緩沖區不能太小，如果太小有可能一次傳輸的報文就大于了緩沖區，嚴重影響傳輸效率。但是太大了也沒(méi)有用，還需要多個(gè)連接數才能夠充分利用CPU資源，連接數起碼要超過(guò)CPU核數。
