国产秋霞理论久久久电影-婷婷色九月综合激情丁香-欧美在线观看乱妇视频-精品国avA久久久久久久-国产乱码精品一区二区三区亚洲人-欧美熟妇一区二区三区蜜桃视频

突發(fā)流量引發(fā)的Dubbo擁堵,該怎么辦?

共 21043字,需瀏覽 43分鐘

 ·

2020-11-03 16:10

點(diǎn)擊上方藍(lán)色“小哈學(xué)Java”,選擇“設(shè)為星標(biāo)

回復(fù)“資源”獲取獨(dú)家整理的學(xué)習(xí)資料!

作者 |?nxlhero

來源 |?https://blog.51cto.com/nxlhero/2515849
文章內(nèi)容結(jié)構(gòu)

第一部分介紹生產(chǎn)上出現(xiàn)Dubbo服務(wù)擁堵的情況,以及Dubbo官方對(duì)于單個(gè)長(zhǎng)連接的使用建議。


第二部分介紹Dubbo在特定配置下的通信過程,輔以代碼。


第三部分介紹整個(gè)調(diào)用過程中與性能相關(guān)的一些參數(shù)。


第四部分通過調(diào)整連接數(shù)和TCP緩沖區(qū)觀察Dubbo的性能。


一、背景


生產(chǎn)擁堵回顧


近期在一次生產(chǎn)發(fā)布過程中,因?yàn)橥话l(fā)的流量,出現(xiàn)了擁堵。系統(tǒng)的部署圖如下,客戶端通過Http協(xié)議訪問到Dubbo的消費(fèi)者,消費(fèi)者通過Dubbo協(xié)議訪問服務(wù)提供者。這是單個(gè)機(jī)房,8個(gè)消費(fèi)者3個(gè)提供者,共兩個(gè)機(jī)房對(duì)外服務(wù)。

在發(fā)布的過程中,摘掉一個(gè)機(jī)房,讓另一個(gè)機(jī)房對(duì)外服務(wù),然后摘掉的機(jī)房發(fā)布新版本,然后再互換,最終兩個(gè)機(jī)房都以新版本對(duì)外服務(wù)。問題就出現(xiàn)單機(jī)房對(duì)外服務(wù)的時(shí)候,這時(shí)候單機(jī)房還是老版本應(yīng)用。以前不知道晚上會(huì)有一個(gè)高峰,結(jié)果當(dāng)晚的高峰和早上的高峰差不多了,單機(jī)房扛不住這么大的流量,出現(xiàn)了擁堵。這些流量的特點(diǎn)是并發(fā)比較高,個(gè)別交易返回報(bào)文較大,因?yàn)槭且粋€(gè)產(chǎn)品列表頁,點(diǎn)擊后會(huì)發(fā)送多個(gè)交易到后臺(tái)。


在問題發(fā)生時(shí),因?yàn)椴磺宄顟B(tài),先切到另外一個(gè)機(jī)房,結(jié)果也擁堵了,最后整體回退,折騰了一段時(shí)間沒有問題了。當(dāng)時(shí)有一些現(xiàn)象:


(1)提供者的CPU內(nèi)存等都不高,第一個(gè)機(jī)房的最高CPU 66%(8核虛擬機(jī)),第二個(gè)機(jī)房的最高CPU 40%(16核虛擬機(jī))。消費(fèi)者的最高CPU只有30%多(兩個(gè)消費(fèi)者結(jié)點(diǎn)位于同一臺(tái)虛擬機(jī)上)


(2)在擁堵的時(shí)候,服務(wù)提供者的Dubbo業(yè)務(wù)線程池(下面會(huì)詳細(xì)介紹這個(gè)線程池)并沒滿,最多到了300,最大值是500。但是把這個(gè)機(jī)房摘下后,也就是沒有外部的流量了,線程池反而滿了,而且好幾分鐘才把堆積的請(qǐng)求處理完。


(3)通過監(jiān)控工具統(tǒng)計(jì)的每秒進(jìn)入Dubbo業(yè)務(wù)線程池的請(qǐng)求數(shù),在擁堵時(shí),時(shí)而是0,時(shí)而特別大,在日間正常的時(shí)候,這個(gè)值不存在為0的時(shí)候。


事故原因猜測(cè)


當(dāng)時(shí)其他指標(biāo)沒有檢測(cè)到異常,也沒有打Dump,我們通過分析這些現(xiàn)象以及我們的Dubbo配置,猜測(cè)是在網(wǎng)絡(luò)上發(fā)生了擁堵,而影響擁堵的關(guān)鍵參數(shù)就是Dubbo協(xié)議的連接數(shù),我們默認(rèn)使用了單個(gè)連接,但是消費(fèi)者數(shù)量較少,沒能充分把網(wǎng)絡(luò)資源利用起來。


關(guān)注公眾號(hào):后端面試那些事兒,每天學(xué)一點(diǎn),一起進(jìn)大廠!


默認(rèn)的情況下,每個(gè)Dubbo消費(fèi)者與Dubbo提供者建立一個(gè)長(zhǎng)連接,Dubbo官方對(duì)此的建議是:

Dubbo 缺省協(xié)議采用單一長(zhǎng)連接和 NIO 異步通訊,適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用,以及服務(wù)消費(fèi)者機(jī)器數(shù)遠(yuǎn)大于服務(wù)提供者機(jī)器數(shù)的情況。


反之,Dubbo 缺省協(xié)議不適合傳送大數(shù)據(jù)量的服務(wù),比如傳文件,傳視頻等,除非請(qǐng)求量很低。


(http://dubbo.apache.org/zh-cn/docs/user/references/protocol/dubbo.html)


以下也是Dubbo官方提供的一些常見問題回答:

為什么要消費(fèi)者比提供者個(gè)數(shù)多?


因 dubbo 協(xié)議采用單一長(zhǎng)連接,假設(shè)網(wǎng)絡(luò)為千兆網(wǎng)卡,根據(jù)測(cè)試經(jīng)驗(yàn)數(shù)據(jù)每條連接最多只能壓滿 7MByte(不同的環(huán)境可能不一樣,供參考),理論上 1 個(gè)服務(wù)提供者需要 20 個(gè)服務(wù)消費(fèi)者才能壓滿網(wǎng)卡。


為什么不能傳大包?


因 dubbo 協(xié)議采用單一長(zhǎng)連接,如果每次請(qǐng)求的數(shù)據(jù)包大小為 500KByte,假設(shè)網(wǎng)絡(luò)為千兆網(wǎng)卡,每條連接最大 7MByte(不同的環(huán)境可能不一樣,供參考),單個(gè)服務(wù)提供者的 TPS(每秒處理事務(wù)數(shù))最大為:128MByte / 500KByte = 262。單個(gè)消費(fèi)者調(diào)用單個(gè)服務(wù)提供者的 TPS(每秒處理事務(wù)數(shù))最大為:7MByte / 500KByte = 14。如果能接受,可以考慮使用,否則網(wǎng)絡(luò)將成為瓶頸。


為什么采用異步單一長(zhǎng)連接?


因?yàn)榉?wù)的現(xiàn)狀大都是服務(wù)提供者少,通常只有幾臺(tái)機(jī)器,而服務(wù)的消費(fèi)者多,可能整個(gè)網(wǎng)站都在訪問該服務(wù),比如 Morgan 的提供者只有 6 臺(tái)提供者,卻有上百臺(tái)消費(fèi)者,每天有 1.5 億次調(diào)用,如果采用常規(guī)的 hessian 服務(wù),服務(wù)提供者很容易就被壓跨,通過單一連接,保證單一消費(fèi)者不會(huì)壓死提供者,長(zhǎng)連接,減少連接握手驗(yàn)證等,并使用異步 IO,復(fù)用線程池,防止 C10K 問題。

因?yàn)槲覀兊南M(fèi)者數(shù)量和提供者數(shù)量都不多,所以很可能是連接數(shù)不夠,導(dǎo)致網(wǎng)絡(luò)傳輸出現(xiàn)了瓶頸。以下我們通過詳細(xì)分析Dubbo協(xié)議和一些實(shí)驗(yàn)來驗(yàn)證我們的猜測(cè)。


二、Dubbo通信流程詳解


我們用的Dubbo版本比較老,是2.5.x的,它使用的netty版本是3.2.5,最新版的Dubbo在線程模型上有一些修改,我們以下的分析是以2.5.10為例。


以圖和部分代碼說明Dubbo協(xié)議的調(diào)用過程,代碼只寫了一些關(guān)鍵部分,使用的是netty3,dubbo線程池?zé)o隊(duì)列,同步調(diào)用,以下代碼包含了Dubbo和Netty的代碼。


整個(gè)Dubbo一次調(diào)用過程如下:

1.請(qǐng)求入隊(duì)


我們通過Dubbo調(diào)用一個(gè)rpc服務(wù),調(diào)用線程其實(shí)是把這個(gè)請(qǐng)求封裝后放入了一個(gè)隊(duì)列里。這個(gè)隊(duì)列是netty的一個(gè)隊(duì)列,這個(gè)隊(duì)列的定義如下,是一個(gè)Linked隊(duì)列,不限長(zhǎng)度。

class NioWorker implements Runnable {    ...    private final Queue writeTaskQueue = new LinkedTransferQueue();    ...}

主線程經(jīng)過一系列調(diào)用,最終通過NioClientSocketPipelineSink類里的方法把請(qǐng)求放入這個(gè)隊(duì)列,放入隊(duì)列的請(qǐng)求,包含了一個(gè)請(qǐng)求ID,這個(gè)ID很重要。


2.調(diào)用線程等待


入隊(duì)后,netty會(huì)返回給調(diào)用線程一個(gè)Future,然后調(diào)用線程等待在Future上。這個(gè)Future是Dubbo定義的,名字叫DefaultFuture,主調(diào)用線程調(diào)用DefaultFuture.get(timeout),等待通知,所以我們看與Dubbo相關(guān)的ThreadDump,經(jīng)常會(huì)看到線程停在這,這就是在等后臺(tái)返回。

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í)現(xiàn),

public class DefaultFuture implements ResponseFuture {
private static final Map CHANNELS = new ConcurrentHashMap(); private static final Map FUTURES = new ConcurrentHashMap();
// invoke id. private final long id; //Dubbo請(qǐng)求的id,每個(gè)消費(fèi)者都是一個(gè)從0開始的long類型 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中,這樣回復(fù)數(shù)據(jù)回來了可以根據(jù)id找到對(duì)應(yīng)的Future通知主線程 CHANNELS.put(id, channel); }

3.IO線程讀取隊(duì)列里的數(shù)據(jù)


這個(gè)工作是由netty的IO線程池完成的,也就是NioWorker,對(duì)應(yīng)的類叫NioWorker。它會(huì)死循環(huán)的執(zhí)行select,在select中,會(huì)一次性把隊(duì)列中的寫請(qǐng)求處理完,select的邏輯如下:

public void run() {????for?(;;)?{       ....????????????SelectorUtil.select(selector);
????????????proce***egisterTaskQueue();????????????processWriteTaskQueue();?//先處理隊(duì)列里的寫請(qǐng)求 processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫都可能有 .... }}
private void processWriteTaskQueue() throws IOException { for (;;) { final Runnable task = writeTaskQueue.poll();//這個(gè)隊(duì)列就是調(diào)用線程把請(qǐng)求放進(jìn)去的隊(duì)列 if (task == null) { break; } task.run(); //寫數(shù)據(jù) cleanUpCancelledKeys(); }}

4.IO線程把數(shù)據(jù)寫到Socket緩沖區(qū)


這一步很重要,跟我們遇到的性能問題相關(guān),還是NioWorker,也就是上一步的task.run(),它的實(shí)現(xiàn)如下:

void writeFromTaskLoop(final NioSocketChannel ch) {    if (!ch.writeSuspended) { //這個(gè)地方很重要,如果writeSuspended了,那么就直接跳過這次寫        write0(ch);    }}
private void write0(NioSocketChannel channel) { ...... final int writeSpinCount = channel.getConfig().getWriteSpinCount(); //netty可配置的一個(gè)參數(shù),默認(rèn)是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)在這,如果寫16次還沒寫完,可能是內(nèi)核緩沖區(qū)滿了,writeSuspended被設(shè)置為true addOpWrite = true; channel.writeSuspended = true; ...... } ...... if (open) { if (addOpWrite) { setOpWrite(channel); } else if (removeOpWrite) { clearOpWrite(channel); } } ...... } fireWriteComplete(channel, writtenBytes); }

正常情況下,隊(duì)列中的寫請(qǐng)求要通過processWriteTaskQueue處理掉,但是這些寫請(qǐng)求也同時(shí)注冊(cè)到了selector上,如果processWriteTaskQueue寫成功,就會(huì)刪掉selector上的寫請(qǐng)求。如果Socket的寫緩沖區(qū)滿了,對(duì)于NIO,會(huì)立刻返回,對(duì)于BIO,會(huì)一直等待。Netty使用的是NIO,它嘗試16次后,還是不能寫成功,它就把writeSuspended設(shè)置為true,這樣接下來的所有寫請(qǐng)求都會(huì)被跳過。那什么時(shí)候會(huì)再寫呢?這時(shí)候就得靠selector了,它如果發(fā)現(xiàn)socket可寫,就把這些數(shù)據(jù)寫進(jìn)去。


關(guān)注公眾號(hào):程序猿DD,與一線架構(gòu)師共成長(zhǎng)!


下面是processSelectedKeys里寫的過程,因?yàn)樗前l(fā)現(xiàn)socket可寫才會(huì)寫,所以直接把writeSuspended設(shè)為false。

void writeFromSelectorLoop(final SelectionKey k) {        NioSocketChannel ch = (NioSocketChannel) k.attachment();        ch.writeSuspended = false;        write0(ch);    }

5.數(shù)據(jù)從消費(fèi)者的socket發(fā)送緩沖區(qū)傳輸?shù)教峁┱叩慕邮站彌_區(qū)


這個(gè)是操作系統(tǒng)和網(wǎng)卡實(shí)現(xiàn)的,應(yīng)用層的write寫成功了,并不代表對(duì)面能收到,當(dāng)然tcp會(huì)通過重傳能機(jī)制盡量保證對(duì)端收到。


6.服務(wù)端IO線程從緩沖區(qū)讀取請(qǐng)求數(shù)據(jù)


這個(gè)是服務(wù)端的NIO線程實(shí)現(xiàn)的,在processSelectedKeys中。

public void run() {????for?(;;)?{        ....????????SelectorUtil.select(selector);
proce***egisterTaskQueue(); processWriteTaskQueue(); processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫都可能有 .... }}
private void processSelectedKeys(Set selectedKeys) throws IOException { for (Iterator 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ì)調(diào)用這個(gè)函數(shù),發(fā)送一個(gè)收到信息的事件 ......
}

7.IO線程把請(qǐng)求交給Dubbo線程池


按配置不同,走的Handler不同,配置dispatch為all,走的handler如下。下面IO線程直接交給一個(gè)ExecutorService來處理這個(gè)請(qǐng)求,出現(xiàn)了熟悉的報(bào)錯(cuò)“Threadpool is exhausted",業(yè)務(wù)線程池滿時(shí),如果沒有隊(duì)列,就會(huì)報(bào)這個(gè)錯(cuò)。

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線程池處理完請(qǐng)求后,把返回報(bào)文放入隊(duì)列


線程池會(huì)調(diào)起下面的函數(shù)

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ù)邏輯類            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); //回寫response } } ......
}

channel.send(response)最終調(diào)用了NioServerSocketPipelineSink里的方法把返回報(bào)文放入隊(duì)列。


9.服務(wù)端IO線程從隊(duì)列中取出數(shù)據(jù)


與流程3一樣


10.服務(wù)端IO線程把回復(fù)數(shù)據(jù)寫入Socket發(fā)送緩沖區(qū)


IO線程寫數(shù)據(jù)的時(shí)候,寫入到TCP緩沖區(qū)就算成功了。但是如果緩沖區(qū)滿了,會(huì)寫不進(jìn)去。對(duì)于阻塞和非阻塞IO,返回結(jié)果不一樣,阻塞IO會(huì)一直等,而非阻塞IO會(huì)立刻失敗,讓調(diào)用者選擇策略。


Netty的策略是嘗試最多寫16次,如果不成功,則暫時(shí)停掉IO線程的寫操作,等待連接可寫時(shí)再寫,writeSpinCount默認(rèn)是16,可以通過參數(shù)調(diào)整。

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.數(shù)據(jù)傳輸


數(shù)據(jù)在網(wǎng)絡(luò)上傳輸主要取決于帶寬和網(wǎng)絡(luò)環(huán)境。

12.客戶端IO線程把數(shù)據(jù)從緩沖區(qū)讀出


這個(gè)過程跟流程6是一樣的

13.IO線程把數(shù)據(jù)交給Dubbo業(yè)務(wù)線程池


這一步與流程7是一樣的,這個(gè)線程池名字為DubboClientHandler。


14.業(yè)務(wù)線程池根據(jù)消息ID通知主線程


先通過HeaderExchangeHandler的received函數(shù)得知是Response,然后調(diào)用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根據(jù)ID獲取Future,通知調(diào)用線程

 public static void received(Channel channel, Response response) {         ......         DefaultFuture future = FUTURES.remove(response.getId());         if (future != null) {            future.doReceived(response);         }         ......    }

至此,主線程獲取了返回?cái)?shù)據(jù),調(diào)用結(jié)束。


三、影響上述流程的關(guān)鍵參數(shù)


協(xié)議參數(shù)


我們?cè)谑褂肈ubbo時(shí),需要在服務(wù)端配置協(xié)議,例如

<dubbo:protocol name="dubbo" port="20880" dispatcher="all" threadpool="fixed" threads="2000" />


下面是協(xié)議中與性能相關(guān)的一些參數(shù),在我們的使用場(chǎng)景中,線程池選用了fixed,大小是500,隊(duì)列為0,其他都是默認(rèn)值。

屬性對(duì)應(yīng)URL參數(shù)類型是否必填缺省值作用描述
namestring必填dubbo性能調(diào)優(yōu)協(xié)議名稱
threadpoolthreadpoolstring可選fixed性能調(diào)優(yōu)線程池類型,可選:fixed/cached。
threadsthreadsint可選200性能調(diào)優(yōu)服務(wù)線程池大小(固定大小)
queuesqueuesint可選0性能調(diào)優(yōu)線程池隊(duì)列大小,當(dāng)線程池滿時(shí),排隊(duì)等待執(zhí)行的隊(duì)列大小,建議不要設(shè)置,當(dāng)線程池滿時(shí)應(yīng)立即失敗,重試其它服務(wù)提供機(jī)器,而不是排隊(duì),除非有特殊需求。
iothreadsiothreadsint可選cpu個(gè)數(shù)+1性能調(diào)優(yōu)io線程池大小(固定大小)
acceptsacceptsint可選0性能調(diào)優(yōu)服務(wù)提供方最大可接受連接數(shù),這個(gè)是整個(gè)服務(wù)端可以建的最大連接數(shù),比如設(shè)置成2000,如果已經(jīng)建立了2000個(gè)連接,新來的會(huì)被拒絕,是為了保護(hù)服務(wù)提供方。
dispatcherdispatcherstring可選dubbo協(xié)議缺省為all性能調(diào)優(yōu)協(xié)議的消息派發(fā)方式,用于指定線程模型,比如:dubbo協(xié)議的all, direct, message, execution, connection等。這個(gè)主要牽涉到IO線程池和業(yè)務(wù)線程池的分工問題,一般情況下,讓業(yè)務(wù)線程池處理建立連接、心跳等,不會(huì)有太大影響。
payloadpayloadint可選8388608(=8M)性能調(diào)優(yōu)請(qǐng)求及響應(yīng)數(shù)據(jù)包大小限制,單位:字節(jié)。這個(gè)是單個(gè)報(bào)文允許的最大長(zhǎng)度,Dubbo不適合報(bào)文很長(zhǎng)的請(qǐng)求,所以加了限制。
bufferbufferint可選8192性能調(diào)優(yōu)網(wǎng)絡(luò)讀寫緩沖區(qū)大小。注意這個(gè)不是TCP緩沖區(qū),這個(gè)是在讀寫網(wǎng)絡(luò)報(bào)文時(shí),應(yīng)用層的Buffer。
codeccodecstring可選dubbo性能調(diào)優(yōu)協(xié)議編碼方式
serializationserializationstring可選dubbo協(xié)議缺省為hessian2,rmi協(xié)議缺省為java,http協(xié)議缺省為json性能調(diào)優(yōu)協(xié)議序列化方式,當(dāng)協(xié)議支持多種序列化方式時(shí)使用,比如:dubbo協(xié)議的dubbo,hessian2,java,compactedjava,以及http協(xié)議的json等
transportertransporterstring可選dubbo協(xié)議缺省為netty性能調(diào)優(yōu)協(xié)議的服務(wù)端和客戶端實(shí)現(xiàn)類型,比如:dubbo協(xié)議的mina,netty等,可以分拆為server和client配置
serverserverstring可選dubbo協(xié)議缺省為netty,http協(xié)議缺省為servlet性能調(diào)優(yōu)協(xié)議的服務(wù)器端實(shí)現(xiàn)類型,比如:dubbo協(xié)議的mina,netty等,http協(xié)議的jetty,servlet等
clientclientstring可選dubbo協(xié)議缺省為netty性能調(diào)優(yōu)協(xié)議的客戶端實(shí)現(xiàn)類型,比如:dubbo協(xié)議的mina,netty等
charsetcharsetstring可選UTF-8性能調(diào)優(yōu)序列化編碼
heartbeatheartbeatint可選0性能調(diào)優(yōu)心跳間隔,對(duì)于長(zhǎng)連接,當(dāng)物理層斷開時(shí),比如拔網(wǎng)線,TCP的FIN消息來不及發(fā)送,對(duì)方收不到斷開事件,此時(shí)需要心跳來幫助檢查連接是否已斷開

服務(wù)參數(shù)


針對(duì)每個(gè)Dubbo服務(wù),都會(huì)有一個(gè)配置,全部的參數(shù)配置在這:http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-service.html。


我們關(guān)注幾個(gè)與性能相關(guān)的。在我們的使用場(chǎng)景中,重試次數(shù)設(shè)置成了0,集群方式用的failfast,其他是默認(rèn)值。

屬性對(duì)應(yīng)URL參數(shù)類型是否必填缺省值作用描述兼容性
delaydelayint可選0性能調(diào)優(yōu)延遲注冊(cè)服務(wù)時(shí)間(毫秒) ,設(shè)為-1時(shí),表示延遲到Spring容器初始化完成時(shí)暴露服務(wù)1.0.14以上版本
timeouttimeoutint可選1000性能調(diào)優(yōu)遠(yuǎn)程服務(wù)調(diào)用超時(shí)時(shí)間(毫秒)2.0.0以上版本
retriesretriesint可選2性能調(diào)優(yōu)遠(yuǎn)程服務(wù)調(diào)用重試次數(shù),不包括第一次調(diào)用,不需要重試請(qǐng)?jiān)O(shè)為02.0.0以上版本
connectionsconnectionsint可選1性能調(diào)優(yōu)對(duì)每個(gè)提供者的最大連接數(shù),rmi、http、hessian等短連接協(xié)議表示限制連接數(shù),dubbo等長(zhǎng)連接協(xié)表示建立的長(zhǎng)連接個(gè)數(shù)2.0.0以上版本
loadbalanceloadbalancestring可選random性能調(diào)優(yōu)負(fù)載均衡策略,可選值:random,roundrobin,leastactive,分別表示:隨機(jī),輪詢,最少活躍調(diào)用2.0.0以上版本
asyncasyncboolean可選false性能調(diào)優(yōu)是否缺省異步執(zhí)行,不可靠異步,只是忽略返回值,不阻塞執(zhí)行線程2.0.0以上版本
weightweightint可選
性能調(diào)優(yōu)服務(wù)權(quán)重2.0.5以上版本
executesexecutesint可選0性能調(diào)優(yōu)服務(wù)提供者每服務(wù)每方法最大可并行執(zhí)行請(qǐng)求數(shù)2.0.5以上版本
proxyproxystring可選javassist性能調(diào)優(yōu)生成動(dòng)態(tài)代理方式,可選:jdk/javassist2.0.5以上版本
clusterclusterstring可選failover性能調(diào)優(yōu)集群方式,可選:failover/failfast/failsafe/failback/forking2.0.5以上版本

這次擁堵的主要原因,應(yīng)該就是服務(wù)的connections設(shè)置的太小,dubbo不提供全局的連接數(shù)配置,只能針對(duì)某一個(gè)交易做個(gè)性化的連接數(shù)配置。


四、連接數(shù)與Socket緩沖區(qū)對(duì)性能影響的實(shí)驗(yàn)


通過簡(jiǎn)單的Dubbo服務(wù),驗(yàn)證一下連接數(shù)與緩沖區(qū)大小對(duì)傳輸性能的影響。


我們可以通過修改系統(tǒng)參數(shù),調(diào)節(jié)TCP緩沖區(qū)的大小。


在 /etc/sysctl.conf 修改如下內(nèi)容, tcp_rmem是發(fā)送緩沖區(qū),tcp_wmem是接收緩沖區(qū),三個(gè)數(shù)值表示最小值,默認(rèn)值和最大值,我們可以都設(shè)置成一樣。

net.ipv4.tcp_rmem = 4096 873800 16777216net.ipv4.tcp_wmem = 4096 873800 16777216

然后執(zhí)行sysctl –p 使之生效。


服務(wù)端代碼如下,接受一個(gè)報(bào)文,然后返回兩倍的報(bào)文長(zhǎng)度,隨機(jī)sleep 0-300ms,所以均值應(yīng)該是150ms。服務(wù)端每10s打印一次tps和響應(yīng)時(shí)間,這里的tps是指完成函數(shù)調(diào)用的tps,而不涉及傳輸,響應(yīng)時(shí)間也是這個(gè)函數(shù)的時(shí)間。

   //服務(wù)端實(shí)現(xiàn)   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;    }

客戶端起N個(gè)線程,每個(gè)線程不停的調(diào)用Dubbo服務(wù),每10s打印一次qps和響應(yīng)時(shí)間,這個(gè)qps和響應(yīng)時(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();        }

通過ss -it命令可以看當(dāng)前tcp socket的詳細(xì)信息,包含待對(duì)端回復(fù)ack的數(shù)據(jù)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


通過netstat -nat也能查看當(dāng)前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)到了接受緩沖區(qū),但是還沒被應(yīng)用代碼讀走的數(shù)據(jù)。Send-Q是已經(jīng)到了發(fā)送緩沖區(qū),但是對(duì)方還沒有回復(fù)Ack的數(shù)據(jù)。這兩種數(shù)據(jù)正常一般不會(huì)堆積,如果堆積了,可能就有問題了。

第一組實(shí)驗(yàn):?jiǎn)芜B接,改變TCP緩沖區(qū)


結(jié)果:

繼續(xù)調(diào)大緩沖區(qū)

我們用netstat或者ss命令可以看到當(dāng)前的socket情況,下面的第二列是Send-Q大小,是寫入緩沖區(qū)還沒有被對(duì)端確認(rèn)的數(shù)據(jù),發(fā)送緩沖區(qū)最大時(shí)64k左右,說明緩沖區(qū)不夠用。


繼續(xù)增大緩沖區(qū),到4M,我們可以看到,響應(yīng)時(shí)間進(jìn)一步下降,但是還是在傳輸上浪費(fèi)了不少時(shí)間,因?yàn)榉?wù)端應(yīng)用層沒有壓力。

服務(wù)端和客戶端的TCP情況如下,緩沖區(qū)都沒有滿


服務(wù)端

客戶端


這個(gè)時(shí)候,再怎么調(diào)大TCP緩沖區(qū),也是沒用的,因?yàn)槠款i不在這了,而在于連接數(shù)。因?yàn)樵贒ubbo中,一個(gè)連接會(huì)綁定到一個(gè)NioWorker線程上,讀寫都由這一個(gè)連接完成,傳輸?shù)乃俣瘸^了單個(gè)線程的讀寫能力,所以我們看到在客戶端,大量的數(shù)據(jù)擠壓在接收緩沖區(qū),沒被讀走,這樣對(duì)端的傳輸速率也會(huì)慢下來。


第二組實(shí)驗(yàn):多連接,固定緩沖區(qū)


服務(wù)端的純業(yè)務(wù)函數(shù)響應(yīng)時(shí)間很穩(wěn)定,在緩沖區(qū)較小的時(shí)候,調(diào)大連接數(shù)雖然能讓時(shí)間降下來,但是并不能到最優(yōu),所以緩沖區(qū)不能設(shè)置太小,Linux一般默認(rèn)是4M,在4M的時(shí)候,4個(gè)連接基本上已經(jīng)能把響應(yīng)時(shí)間降到最低了。

# 結(jié)論


要想充分利用網(wǎng)絡(luò)帶寬, 緩沖區(qū)不能太小,如果太小有可能一次傳輸?shù)膱?bào)文就大于了緩沖區(qū),嚴(yán)重影響傳輸效率。但是太大了也沒有用,還需要多個(gè)連接數(shù)才能夠充分利用CPU資源,連接數(shù)起碼要超過CPU核數(shù)。

END


有熱門推薦?

1.?MySQL 5.7 vs 8.0,哪個(gè)性能更牛?

2.?太火了!MyBatis Plus 為啥這么牛?

3.?一個(gè)技術(shù)總監(jiān)的忠告:精通那么多技術(shù),你為何還是受不到重用?

4.?22 款終端生產(chǎn)力工具,效率飛起!

最近面試BAT,整理一份面試資料Java面試BATJ通關(guān)手冊(cè),覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。

獲取方式:點(diǎn)“在看”,關(guān)注公眾號(hào)并回復(fù)?Java?領(lǐng)取,更多內(nèi)容陸續(xù)奉上。

文章有幫助的話,在看,轉(zhuǎn)發(fā)吧。

謝謝支持喲 (*^__^*)


瀏覽 55
點(diǎn)贊
評(píng)論
收藏
分享

手機(jī)掃一掃分享

分享
舉報(bào)
評(píng)論
圖片
表情
推薦
點(diǎn)贊
評(píng)論
收藏
分享

手機(jī)掃一掃分享

分享
舉報(bào)

感谢您访问我们的网站,您可能还对以下资源感兴趣:

国产秋霞理论久久久电影-婷婷色九月综合激情丁香-欧美在线观看乱妇视频-精品国avA久久久久久久-国产乱码精品一区二区三区亚洲人-欧美熟妇一区二区三区蜜桃视频 波多野结衣久久| 亚洲精品一二三| 久久学生妹| 黄色片国产| www.热久久| 黑巨茎大战欧美白妞小说| 激情国产| 欧美中文字幕在线视频| 国产av天堂| 操逼在线观看| 麻豆免费版在线观看| 精品无码一区二区三区四区久久久软件 | 日韩黄网站| 国产一级片网站| 日韩中文字码无砖| 日本一级黄色电影| 91精品国产综合久久久蜜臀酒店| 黄页网站在线观看| 西西444大胆无码视频| 日韩无码123区| 蜜臀久久99久久久久久宅男| 丁香六月婷婷综合缴| 国产精品S色| 婷婷五月开心五月| 国产综合久久777777麻豆| 中文字幕麻豆| 国产高清在线视频| 按摩忍不住BD中文字幕| 夜夜撸天天日| 成人免费黄色网| 色网站在线| 操逼电影网| 日韩精品人妻中文字幕蜜乳| 2015中文字幕黄色视频| 亚洲99热| 人人看人人澡| 久久久黄色视频| 一本色道久久综合熟妇| 国产A片| 欧美成人不卡| 另类BBwBBw| 91九色91蝌蚪91成人| 日韩欧美小视频| 蜜桃免费视频| av操逼网| 伊人激情五月| 中文字幕在线不卡视频| 一级黄色电影免费看| 久久久一区二区三区四区免费听 | 色五月综合网| 成人毛片网| 色色网站视频| 国产久久久久久久久| JLZZJLZZ亚洲女人| 亚洲AV成人无码| 亚洲婷婷小说| 日本黄A三级三级三级| 亚洲AV网址| 高清免费无码视频| 看国产AA免费| 北条麻妃亚洲无码| 五月天AV在线| 日韩二区三区| 火淫玖玖免费精品| 地表最强网红八月未央道具大秀| 久久新视频| 亚洲精品福利| 欧美视频综合网| 精品一二三四| 国产精品无码成人AV在线播放| 欧美精品一区二区三区使用方法| 豆花视频一区| 9热精品| 精品人妻一区| 亚洲精品乱码久久久久久蜜桃欧美| 中文在线A∨在线| 日韩a级毛片| 九九99久久| 久久久久中文字幕| 日韩无码性爱视频| 成人做爰A片一区二区| 最好看2019中文在线播放电影| 天天日,天天干,天天操| 中文字幕第八页| 国产三级片网| 91色逼| 91久久视频| 国产在线在线| 九九精品在线视频| 狠狠狠狠操| 麻豆精品一区二区三区| 51妺嘿嘿午夜福利在线| 91精品国产欧美一区二区成人| 五月天丁香成人| 日本精品黄色视频| 777777视频| 成人一区二区电影| 男人亚洲天堂| 日韩黄片| 熟女人妻一区二区| 爱爱视频免费| 波多野结衣福利视频| 国产精品久久毛片A片| 操逼逼视频| 国产亚洲99久久精品熟女| 中文字幕免费高清在线观看| 婷婷欧美色图| 国产男女无套免费视频| 91欧美| 欧洲三级网观看| EEUSS| 家庭乱伦影视| 亚洲精品国产精品国自产曰本| 欧美特级黄片| 国产精品高潮无套内谢| 动图综合亚洲综合欧美男男 | 亚洲电影无码| 尹人香蕉久久| AV黄色片| 国产精品18在线| 日韩免费中文字幕A片| 成人在线视频观看| 国产精品美女毛片j酒店| 天天操天天看| av女人的天堂| 午夜操| 操逼视频网站免费| 在线国产视频| 五月天黄色片| 黄片网站免费| 人妻少妇精品无码| 国产你懂的| 国产成人精品777777| 大鸡巴在线视频| 操逼去| 一区亚洲| 人妻九九九| 中文无码熟妇人妻AV在线| 亚州性爱| 嫩草在线精品| 伊人操逼| 成人激情视频A极| 欧美成人高清视频| 国产乱码在线| 欧美日韩爱爱| 俺也色俺也干| 久久精品大香蕉| 影音先锋久久久久AV综合网成人| 91插逼| 日一区二区| 青娱乐偷拍| 91在线不卡| 久久综合久久鬼色| 天堂中文在线观看| 91内射视频| 97人人操人人干| 中文字幕免费视频在线观看| 狼人综合视频| 久久人妻中文字幕| 免费自拍视频| 国产性交网站| 黄色直播在线观看| 欧洲AV片| 国产夫妻在线| 河南乱子伦视频国产| 99极品视频| 操逼福利| 无码秘蜜桃一区二区三区| 黄色大片在线免费观看| 中文字幕成人网站| 日韩精品一区二区三区四区蜜桃视频| 黄色一级免费看| 人妻丰满熟妇| 一级片A片| 少妇无码在线观看| 久久久久久久三级片| 欧美日韩性爱| 91热爆在线| 久久黄色视频| 黄色片一级| 人人操人人人| 丁香五月在线| 麻豆射区| 特黄特色免费视频| 午夜无码视频| 欧美精品日韩在线观看| 久久久久亚洲精品| 乳揉みま痴汉电车羽月希免费观看 | 亚洲无码另类| 高清无码免费在线| 大荫蒂视频另类XX| 久久精品性爱| 露脸丨91丨九色露脸| 天天干妹子| 人人草人人看人人摸| 蜜臀久久99精品久久久电影| 国产女人18毛片水18精品| 久久精品三级视频| 亚洲一区二区三区无码| 欧美精品成人免码在线| 欧美亚洲成人在线观看| 欧美亚洲黄色| 中文字幕一区二区三区四区50岁 | a视频免费| 夜夜撸天天操| 午夜日韩乱伦| 精品欧美无人区乱码毛片| 69国产精品成人无码视频色| 伊人久久AV| 午夜无码在线观看视频| 99黄片| 日韩无码91| 国产成人AV在线| 99热在线观看免费精品| 无码一区二区区| 中文字幕日韩无码电影| 亚洲精品偷拍| 北条麻妃在线一区| 91极品视觉盛宴| 99九九99九九九99九他書對| 国产综合激情| 乱伦无码视频| 国产又爽又黄免费网站在| 一级成人电影| 亚洲无码精品视频| 色呦呦中文字幕| 中文字幕区| 影音先锋三级资源| 亚洲人妻电影一区| 奇米影视亚洲春色| 日韩成人在线免费观看| 黄色在线免费观看网站| 色婷婷成人网| 苍井空精毛片精品久久久| 蜜臀AⅤ在线| 无码人妻精品一区二区三区蜜桃91 | V天堂| 大香蕉玖玖| 中文字幕日本欧美| 国产精品内射| 国产精品扒开腿做爽爽爽A片唱戏 中文字幕一区二区三区精华液 | 夜夜嗨老熟女AV一区二区三区 | 免费在线观看黄色视频| 国产灬性灬淫灬欲水灬| 无码中文字幕在线视频| 九九热这里有精品| 91亚洲精华国产精华精华液| 成人网站视频在线免费观看| 青草福利视频| 久久草在线观看| www欧美日韩| 国产豆花视频| 天天天天天天天操| 亚洲中字幕| 精品国产123| 亚洲日韩中文无码| 成人激情视频A极| 中文字幕AV在线播放| www.插插插| 日韩欧美午夜成人无码| 美日韩免费视频| 亚洲码无人客一区二区三区| 色国产在线视频| 乱伦一区二区三区| 人妻丰满熟妇| 久久久久久亚洲精品| 亚洲中文字幕在线观看| 91白浆| 天天干天天添| 国语对白做受欧美| 成人视频在线观看免费| 黄色成人网站在线观看免费| 四虎成人网址| 这里只有精品久久| 日韩成人精品在线| 国产精品成人无码专区| 特黄av| 天天爽天天爽夜夜爽毛片| 丰满熟妇人妻无码视频| 99热精品免费观看| 九七在线视频| 亚洲国产精品精JIZZ老师 | 在线观看欧美日韩视频| 免费毛片视频| 国产精品视频播放| 伊人网成人| 成人黄色免费| 亚洲AV秘无码一区二三月夜| 久久福利导航| 91人人操| 国产三级在线| 日本成人视频在线免费播放| 无码一区二区三区四区| 天天做| 超碰在线91| 黄色内射在线播放| 天天爽夜夜爽精品成人免费| 麻豆videos| 北条麻妃精品青青久久价格| 一道本激情视频| 色婷婷在线视频播放| 五月激情久久| 456成人| 欧美成人电影在线观看| jlzzzjlzzz国产免费观看| 学生妹一级片内射视频| 亚洲乱伦小说网| AV2014天堂网| 中文字幕乱码中文字幕电视剧| 国产不卡一区| 91插逼| 国产熟女视频| 蜜桃在线视频| 久久99精品国产麻豆婷婷洗澡| 国产在线久久久| 91AV免费看| 西西人体444www| P站免费版-永久免费的福利视频平台| 日韩人妻在线播放| 91麻豆免费视频| 在线无码一区二区三区| 日韩精品一二三区| www.麻豆网91成人久久久| 99在线精品视频| 人人操AV在线| 国产一级黄色A片| av播播| 无码在线免费播放| 国产在线毛片| 亚洲视频中文| 色五月丁香婷婷| 日本老妇操屄视频| 天天干网址| 午夜私人福利| 成人免费一区| 2025国产成人精品一区| 丁香五月婷婷色| 国产操b| 四虎无码丰满人妻| 亚洲免费视频在线看| 亚洲一级a| 人人看人人摸人人搞| 亚洲黄视频| 日韩一二区| 亚洲va综合va国产va中文| 爱爱中文字幕| 亚洲XXXXX| 国产AV资源网| 欧美老妇操逼| 九九九精品| 亚洲色男人天堂| 操逼视频电影| 成人在线黄色| 99操| 日韩欧美性爱网站| 草草影院CCYYCOM屁屁影院合集限制影院 | 国产18禁网站| 九九热av| 最新中文字幕777私人在线| 狼人香蕉在线视频| 在线播放高清无码| 一级黄色电影免费观看| 天天操网站| 俺来了俺去了www色官网| 国产乱子伦真实精品!| 九九午夜| 亚洲日韩高清无码| 免费一级婬片AAA片毛片A级| 国产精品秘国产精品88| 国产在线观看免费| 特级黄色毛片| 一本色道久久综合狠狠| 久久免费视频6| 亚洲中文字幕一区二区| 很很日| 人妻18无码人伦一区二区三区精品| 成人欧美在线观看| 国产怡红院| 中文字幕66页| 成人做爰黄A片免费看| 国产成人av网站| 日韩高清国产一区在线| 草比网站| 精品国产成人a在线观看| 无码成人片| 天天爱夜夜爱| 天天摸天天日| 无码一区二区三| 一级片免费观看视频| AV在线影院| 国产成人Av| 蜜桃精品一区二区| 大香蕉伊人AV| 中文字幕乱码免费综合久久| 亚洲天堂在线观看免费视频| 91人妻无码成人精品一区二区| 4080yy午夜理论片成人| 91无码人妻精品一区二区蜜桃| 成年人观看视频| 熟女人妻一区二区三区免费看| 欧美伊人久久| 人人妻人人澡人人爽人人| 性欧美丰满熟妇XXXX性久久久| 人人操人人操人人操人人| 国产福利小视频| 国产一区二区在线播放| 狠狠干狠狠色| 黄色激情AV| 啊啊啊av| 麻豆成人91精品二区三区| 苍井空视频| 毛片在线观看网站| 自拍偷拍一区二区三区| 色999日韩| 大香蕉久久视频| 亚洲欧美在线视频观看| 五月天福利视频| 无码在线播放观看| 蜜桃视频一区二区| 国产AV无遮挡| 一级性爽A√毛片| 免费AV网站| 伊人久久香蕉网| 国产无码激情视频| 国产精品人妻无码久久久郑州天气网| 东方成人av| 久久艹精品视频| 性插视频| 在线aⅴ| 亚洲电影中文字幕| 日本视频爱爱| 三级无码在线| 久9久9| 老骚逼| 欧美黄色a片| 久久草大香蕉| 亚洲国产视频在线观看| 91麻豆精品国产91久久久吃药| 美女黄色视频永费在线观看网站| 青娱乐91视频| 无码东京热国产| 东京热视频免费观看| 操一炮在线视频| 欧洲成人午夜精品无码区久久| 2025av中文字幕| 七六十路の高齢熟妇无码| 欧美激情色色| 亚洲欧美日韩色图| 麻豆91精品91久久久停运原因| 99久久99九九九99九他书对| 精品国产精品国产精品国产网站| 亚洲无码影片| AAA亚洲| 东京热视频一区| 无码欧精品亚洲日韩一区| 97人人妻| 爆操网站| 成人片成人网久久蜜桃臀| 一本久久精品一区二区| 一級免費网站| 久久女人视频| 北条麻妃99精品青青久久| 在线无码免费| www.俺去| 99久久久久久久无码| AV片在线观看| 日本中文字幕网| 中文字幕免费在线观看| 欧美a片在线观看| 久久久精品国产视频| 欧美成人在线网站| 超碰成人欧美| 国产婷婷久久Av免费高清| 亚洲无码字幕| av网站导航| 97精品| 日本中文字幕免费| 亚洲成人免费在线视频| 91人妻无码精品一区二区| 91妻人人澡人人爽人人精品| 中文字幕免费视频| 久久久精品亚洲| 成年人免费网站| 97成人视频| av资源在线看| 人人射人人摸| 欧美成人网站在线观看| 日本高清无码在线观看| 午夜久久福利| 蜜桃传媒一区二区| 亚欧洲精品在线视频免费观看| 国产福利在线导航| 黄色一级网站| 特大妓女BBwBBWBBw| 99精品网站| 精品久久久久久久| 中文日韩字幕| 免费黄色视频网站在线观看| 18SAV| 日韩久久网| 国产老熟女久久久| 天天射网站| 好吊视频一区二区三区| 亚洲图片欧美另类| 国产精品久久久久久婷婷天堂| 欧美色视频在线观| 国产在线视频你懂的| 大伊香蕉在线| 亚洲精品视频在线观看免费| 国产久久久| 精品久久久久久久久久久| 视频你懂的| 日本成人电影在线观看| 亚洲天堂自拍| 韩国AV在线| www.水蜜桃| 三级网站在线| 一级Aa视频免费看| 精品一区二区三区无码| AⅤ中文字幕在线免费观看| 成人亚洲AV日韩AV无码| 欧美日韩一区视频| 人妻北条麻妃在线| 无码一区二区三区四区五区| 337p西西人体大胆瓣开下部| 免费无码婬片AAAA片在线蜜芽 | 免费无码毛片| 亚洲男人的天堂AV| 宅男噜| 国产精品久久久久久久久久| 欧美日韩中文字幕| 国产成人大香蕉| 性性性性性XXXXX| 日韩中文字幕在线观看| 婷婷五月在线观看| 欧美日韩国产激情| 一区二区免费在线观看| 汇聚全球淫荡熟女| 色猫av| 91麻豆精品国产91久久久吃药| 人人摸人人看人人草| 亚洲a级毛片| 五月婷婷综合网| 激情五月天影院| 操比视频在线观看| 秋霞午夜福利影院| 伊人久综合| 美女被操免费网站| wwwxxx18| 免费在线观看视频黄| 亚洲精品色婷婷| 欧美夜夜草视频| 国产suv精品一区二区| 91久久久久国产一区二区| 日中国老太太B| 日本人妻在线播放| 亚州毛多色色精品| 大香蕉伊人在线观看| 国产一级操逼视频| 男女无套在线观看免费| 777米奇视频| 亚洲视频456| 91视频亚洲| 女生自慰网站在线观看| 丁香社区五月天| 蜜臀久久精品久久久久| 一本色道久久88综合无码| 中文字幕在线观看第一页| 在线观看欧美日韩| 大香蕉做爱| 色图15p| 久久久在线视频| 天天射夜夜骑| 黄色片免费观看| 日韩黄色av| 黄色一级免费看| 久久久精品网站| 欧美一级片免费观看| 999国产精品视频| 无码高清视频| 亚洲资源在线观看| 性满足BBWBBWBBW| av网站在线免费观看| 超碰免费99| 国产午夜成人视频| 亚欧成人在线视频| 亚洲性爱在线| 午夜在线观看视频18| 91内射视频| 北条麻妃性爱视频| 成人做爰黄片视频免费| 久久不雅视频| 99久久久国产精品免费蜜臀| 亚洲AV官方网站| 91成人亚洲| 国产h在线观看| 先锋影音麻豆| 蜜臀AV在线播放| 麻豆精品国产传媒| 超碰人人人人人人人人| 青青草婷婷| 女人卖婬视频播放| 亚洲高清在线视频| 日本黄网站| 中文字幕一区二区三区四区五区六区| 亚洲第一视频在线观看| 天天操夜夜干| 黄色小说在线看| 国产AV美女| 国产美女一级特黄大片| 欧美一级a| 操逼的网站| 欧美色图另类| 欧美午夜精品成人片在线播放| 少妇bbb| 摸BBB搡BBB搡BBBB| 人人爱人人操人人干| 综合视频一区| 欧美精品无码一区二区| 大香蕉最新国产2025| 免费毛片视频| 久久久久久久久久久高清毛片一级 | 大香焦草久| 国产免费视频69| 日韩精品成人| 国产少妇| 好吊看视频| 日韩无码动漫| 国产熟妇毛多久久久久一区| 色色播播| 人人爱人人摸人人操| 七十路の高齢熟女千代子下载| 日韩欧美在线一区| 日日摸日日添日日躁AV| 五月天激情啪啪| 国产精品无码一区二区三| 久久久999精品视频| 日韩无码网站| 日韩性爱在线| 伊人网址| 综合久久网| 五月天婷婷在线观看| 亚洲精品日韩无码| www.一区二区三区| 黄片免费在线播放| 欧美狂操| 国产一二区| 超碰免费人妻| 国产在线视频91| 91无码人妻精品一区二区蜜桃| 黄色视频在线免费观看网站| 亚洲精品国产精品国自产A片同性 丰满人妻一区二区三区四区不卡 国产1级a毛a毛1级a毛1级 | 欧美熟女在线| 亚洲第一中文字幕| 国产女人在线视频| 成人一区二区在线观看| 午夜福利在线播放| 日韩毛片一区二区| 国产精品视频在线播放| 狠狠干B| 久久久在线视频| 性性性性性XXXXX| 91精品国产综合久久久蜜臀粉嫩| 92自拍视频| 国产成人综合亚洲| 噜噜色av| 中文字幕高清视频| 性欧美一区二区| 日韩一级中文字幕| 一区无码视频| 日韩中文无码一级A片| 亚洲国产精品欧美久久| 丁香五月一区二区| 黄色插逼视频| 日皮视频网站| 在线看黄网| 91久久精品国产91久久公交车| 色老板在线精品免费观看| 成人午夜视频精品一区| av天天av无码av天天爽| 人人插人人澡| 精品免费黄色视频| 欧美51精品| 日韩v亚洲| 一区二区三区高清不卡| 日本高清免费视频| 人妻九九九| 99爱爱视频| 四季AV之日韩人妻无码| 韩日av| 夜夜骚av.一区二区三区四区| 亚洲一级二级三级片| 久久久久久久久久久国产| 日韩性爱小说| 三级片高清无码| 色九九九九| 亚洲秘无码一区二区三区蜜桃中文 | a网站在线| 99操逼网| 粗长哭叫打桩H体育生| 日本欧美在线播放中文| 青青草原无码| 黄色网页在线免费观看| 夜夜夜影院| 超碰在线看| 日本中文字幕在线视频| 丰满的人妻一区二区三区果冻| 欧美不卡一区| 国产激情av| 欧美日韩在线观看视频| 韩国深夜福利视频| 天天爽夜夜爽精品成人免费| 精品九九九九九九| 性爱AV网| 中国AV网| 性久久久久久久久久| 九九九九九九精品| 中文字幕操逼| 蜜桃av无码一区二区三区| 性爱视频无码| 久久93| 亚洲图片欧美色图| 国产欧美一区二区| 欧美成人伦理片网| 国产欧美一区二区三区国产幕精品 | 欧美香蕉在线| 欧美日韩字幕| 国产成人大香蕉| 日日操日日| 第一福利成人AV导航| 色婷婷狠狠| 欧美日韩小视频| 色婷婷视频在线观看| Al激情欧美| 欧美高清国产| 一级婬片A片AAAAA毛片| 男女成人视频| 日韩成人一级片| 九九福利| 国产精品视频福利| 成人一级视频| 亚洲高清中文字幕| 特黄AAAAAAAA片视频| 一二三区| 亚洲综合中文字幕在线播放| 精品一二三四| 亚洲无码视频专区| 日韩欧美国产精品| 成人中文字幕在线| 免费一级电影| 日韩TV| 91免费在线视频观看| 香蕉污视频| 性爱91视频| 天天躁日日躁狠狠| AV东方在线| 国产1区2区| 强开小嫩苞一区二区三区视频| 国产三级日本三级国产三级| 未满十八18禁止免费无码网站| 亚洲中文字幕在线无码| 伊人操逼| 簧片网站在线观看| www.五月婷婷| 丰满人妻一区二区三区| 88海外华人免费一区| 日韩成人无码影片| 欧美性爱成人| 国产经典午夜福利视频合集| 激情小视频| 日韩人妻精品无码久久| 人妻japanesewoman| 日皮视频在线观看免费| 中文字幕亚洲天堂| 午夜福利91| 99久久99久久精品免费看蜜桃| av黄色| 9191久久| 成人影视在线免费观看| 综合大香蕉| 你懂的在线观看| 伊人97| 久久网一区| 嫩BBB槡BBBB槡BBBB免费视频| 欧美一级视频在线观看| 人妻少妇无码视频| 超碰人人在线| 欧美亚洲小说| 超碰一区二区三区| 国产毛片在线视频| 大香蕉三级片| 女人特级毛片18| 黄色一级电影网| 丰满人妻一区二区三区四区54 | 波多野结衣无码一区二区| 中文字幕国产视频| 巨い巨乳の少妇あジed2k| www亚洲| 影音先锋乱伦| 国产九九九九| 欧美午夜精品| 天堂在线观看AV| 欧美一级一区| 日韩操B视频| 亚洲色诱| 人妻少妇中文字幕久久牛牛| 7x7x7x人成免费观学生视频| 天天看天天摸| 精品AV| 久久无码免费| 好吊妞在线观看| 99热er| 天天干天天日天天干| 香蕉视频免费| 婷婷五月天激情电影| 毛片91| 婷婷天堂| 爱爱高清视频| 亚洲AV无码成人精品区在线欢看 | 午夜福利大香蕉| 影音先锋三级片| 免费V片在线观看| 欧美性生交18XXXXX无码| 囯产精品久久久久久久久久辛辛| 玉米地一级婬片A片| 四虎在线视频观看96| 免费尻屄视频| 人妻熟女一区二区| 九九无码| 国产99久久久精品| 麻豆传媒一区二区| 色日韩| 免费看毛片中文字幕| 四虎www| 一区二区三区视频在线| 人妻精品| 亚洲五月六月| 久久精品视频一区| 2021无码| 北条麻妃在线播放一区| 亚洲天堂在线视频播放| 婷婷综合五月天| 一区二区三区国产| 成年人AV| 中文字幕在线免费播放| 3D动漫啪啪精品一区二| 国内一级黄片| 欧美色逼逼| 嫩BBB搡BBB槡BBB小号| 国产精品HongKong麻豆| 69av网站| 爱操逼网| 日韩欧美高清| 国产一区二区波多野结衣| 国产高清色| 亚洲日韩精品秘在线观看| 日韩AV资源网| 国产男女无套免费视频| 婷婷六月天| 日韩无码黄色电影| 日本高清视频免费观看| 人人妻人人澡人人爽人人欧美一区 | 午夜试看120秒体验区的特点| 欧美久久精品| 成人视频网站18| 操屄视频免费观看| 欧美性爱福利视频| 91成人做爰A片| 九色丨蝌蚪丨老版熟女| 久久丝袜视频| 亚洲无码久久| 亚洲高清无码中字| 亚洲第一免费视频| 欧美一二三区黄色免费视屏| 影音先锋AV资源在线| 六月婷婷久久| 日韩在线观看网站| 日韩在线观看网址| 亚洲三级片在线视频| 成人AV在线一区二区| 中文字幕av免费观看| 99视频在线播放| av免费观看网站| 黄色视频在线观看免费网站| 国产乱子伦-区二区三区| 在线成人毛片| 免费黄色三级片| 国产黄色电影| 亚洲A∨无码无在线观看| 五月天av在线| 女同一区二区三区| 熟妇一区二区| 欧美精产国品一二三产品在哪买| 影音先锋亚洲无码| 99人妻在线| 久久婷婷五月天| 日本中文字幕网| 亚洲激情综合网| 人人草人人看人人摸| 亚洲日韩成人在线|