<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    Dust Of Dream

    知識真的是一個圓么?

    轉(zhuǎn):學(xué)習(xí)如何為支持高用戶并發(fā)性的應(yīng)用程序?qū)崿F(xiàn)事務(wù)策略

    Mark Richards, 主管和高級技術(shù)架構(gòu)師, Collaborative Consulting, LLC

    2009 年 7 月 31 日

    事務(wù)策略系列文章的作者 Mark Richards 將討論如何在 Java? 平臺中為具有高吞吐量和高用戶并發(fā)性需求的應(yīng)用程序?qū)崿F(xiàn)事務(wù)策略。理解如何進(jìn)行折衷將幫助您確保高水平的數(shù)據(jù)完整性和一致性,并減少隨后開發(fā)流程中的重構(gòu)工作。

    我在本系列 的前幾篇文章中所介紹的 API 層和客戶端編排策略事務(wù)策略是應(yīng)用于大多數(shù)標(biāo)準(zhǔn)業(yè)務(wù)應(yīng)用程序的核心策略。它們簡單、可靠、相對易于實(shí)現(xiàn),并且提供了最高水平的數(shù)據(jù)完整性和一致性。但有時,您可能需要減小事務(wù)的作用域以獲取吞吐量、改善性能并提高數(shù)據(jù)庫的并發(fā)性。您如何才能實(shí)現(xiàn)這些目的,同時仍然維持高水平的數(shù)據(jù)完整性和一致性呢?答案是使用 High Concurrency 事務(wù)策略。

    High Concurrency 策略源自 API 層 策略。API 層策略雖然非常堅(jiān)固和可靠,但它存在一些缺點(diǎn)。始終在調(diào)用棧的最高層(API 層)啟動事務(wù)有時會效率低下,特別是對于具有高用戶吞吐量和高數(shù)據(jù)庫并發(fā)性需求的應(yīng)用程序。限制特定的業(yè)務(wù)需求,長時間占用事務(wù)和長時間鎖定都會消耗過多資源。

    與 API 層策略類似,High Concurrency 策略釋放了客戶機(jī)層的任何事務(wù)責(zé)任。但是,這還意味著,您只能通過客戶機(jī)層調(diào)用一次任何特定的邏輯工作單元(LUW)。High Concurrency 策略旨在減小事務(wù)的總體作用域,以便資源鎖定的時間更短,從而增加應(yīng)用程序的吞吐量、并發(fā)性以及性能。

    通過使用此策略所獲取的好處在一定程度上將由您所使用的數(shù)據(jù)庫以及它所采用的配置決定。一些數(shù)據(jù)庫(比如說使用 InnoDB 引擎的 Oracle 和 MySQL)不會保留讀取鎖,而其他數(shù)據(jù)庫(比如沒有 Snapshot Isolation Level 的 SQL Server)則與之相反。保留的鎖越多,無論它們是共享還是專用的,它們對數(shù)據(jù)庫(以及應(yīng)用程序)的并發(fā)性、性能和吞吐量的影響就越大。

    但是,獲取并在數(shù)據(jù)庫中保留鎖僅僅是高并發(fā)性任務(wù)的一個部分。并發(fā)性和吞吐量還與您釋放鎖的時間有關(guān)。無論您使用何種數(shù)據(jù)庫,不必要地長時間占用事務(wù)將更長地保留共享和專用鎖。在高并發(fā)性下,這可能會造成數(shù)據(jù)庫將鎖級別從低級鎖提高到頁面級鎖,并且在一些極端情況下,從頁面級鎖切換到表級鎖。在多數(shù)情況下,您無法控制數(shù)據(jù)引擎用于選擇何時升級鎖級別的啟發(fā)方法。一些數(shù)據(jù)庫(比如 SQL Server)允許您禁用頁面級鎖,以期它不會從行級鎖切換到表級鎖。有時,這種賭博有用,但大多數(shù)情況下,您都不會實(shí)現(xiàn)預(yù)期中的并發(fā)性改善。

    底線是,在高數(shù)據(jù)庫并發(fā)性的場景中,數(shù)據(jù)庫鎖定(共享或?qū)S茫┑臅r間越長,則越有可能出現(xiàn)以下問題:

    • 數(shù)據(jù)庫連接耗盡,從而造成應(yīng)用程序處于等待狀態(tài)
    • 由共享和專用鎖造成的死鎖,從而造成性能較差以及事務(wù)失敗
    • 從頁面級鎖升級到表級鎖

    換句話說,應(yīng)用程序在數(shù)據(jù)庫中所處的時間越長,應(yīng)用程序能處理的并發(fā)性就越低。我所列出的任何問題都會造成您的應(yīng)用程序運(yùn)行緩慢,并且將直接減少總體吞吐量和降低性能 - 以及應(yīng)用程序處理大型并發(fā)性用戶負(fù)載的能力。

    折衷

    High Concurrency 策略解決了高并發(fā)性需求,因?yàn)樗軐⑹聞?wù)在體系結(jié)構(gòu)中的作用域盡可能減小。其結(jié)果是,事務(wù)會比在 API 層事務(wù)策略中更快地完成(提交或回滾)。但是,就像您從 Vasa 中學(xué)到的(見參考資料),您不能同時擁有它們。生活中充滿了折衷,事務(wù)處理也不例外。您不能期望提供與 API 層策略同樣可靠的事務(wù)處理,同時提供最大的用戶并發(fā)性和最高的吞吐量。

    因此,您在使用 High Concurrency 事務(wù)策略時放棄了什么呢?根據(jù)您的應(yīng)用程序的設(shè)計(jì),您可能需要在事務(wù)作用域外部執(zhí)行讀取操作,即使讀取操作用于更新目的。"等一等!"您說:"您不能這樣做 - 您可能會更新在最后一次讀取之后發(fā)生了變化的數(shù)據(jù)!"這是合理的擔(dān)憂,并且也是需要開始考慮折衷的地方。通過此策略,由于您未對數(shù)據(jù)保持讀取鎖,因此在執(zhí)行更新操作時遇到失效數(shù)據(jù)異常的機(jī)率會增加。但是,與 Vasa 的情況一樣,所有這些都可以歸結(jié)為一個問題,即哪個特性更加重要:可靠、堅(jiān)固的事務(wù)策略(如 API 層策略),還是高用戶并發(fā)性和吞吐量。在高并發(fā)性情形中,同時實(shí)現(xiàn)兩者是極為困難的。如果您嘗試這樣做,則可能會適得其反。

    第二個折衷之處是事務(wù)可靠性的總體缺乏。此策略難以實(shí)現(xiàn),并且需要更長的時間進(jìn)行開發(fā)和測試,并且比 API 層或 Client Orchestration 策略更易于出錯??紤]到這些折衷,您首先應(yīng)該分析當(dāng)前的情形以確定使用此策略是否是正確的方法。由于 High Concurrency 策略派生自 API 層策略,因此一種比較好的方法是先使用 API 層策略,并使用較高的用戶負(fù)載對應(yīng)用程序執(zhí)行負(fù)載測試(比您預(yù)期的峰值負(fù)載更高)。如果您發(fā)現(xiàn)吞吐量較低、性能較第、等待次數(shù)非常多,或者甚至出現(xiàn)死鎖,則要準(zhǔn)備遷移到 High Concurrency 策略。

    在本文的其余部分,我將向您介紹 High Concurrency 事務(wù)策略的其他一些特性,以及實(shí)現(xiàn)它的兩種方法。


    基本結(jié)構(gòu)和特性

    圖 1 通過我在 事務(wù)策略系列中所使用的邏輯應(yīng)用程序棧展示了 High Concurrency 事務(wù)策略。包含事務(wù)邏輯的類顯示為紅色陰影。 圖 1 通過我在 事務(wù)策略系列中所使用的邏輯應(yīng)用程序棧展示了 High Concurrency 事務(wù)策略。包含事務(wù)邏輯的類顯示為紅色陰影。


    圖 1. 體系結(jié)構(gòu)層和事務(wù)邏輯
    圖 1. 體系結(jié)構(gòu)層和事務(wù)邏輯

    一些 API 層策略的特性和規(guī)則是有效的 - 但并非所有。注意,圖 1 中的客戶機(jī)層沒有事務(wù)邏輯,這意味著任何類型的客戶機(jī)都可以用于此事務(wù)策略,包括基于 Web 的客戶機(jī)、桌面、Web 服務(wù)和 Java Message Service (JMS)。并且事務(wù)策略遍布于客戶機(jī)下面的層中,但這不是絕對的。一些事務(wù)可能在 API 層中開始,一些在業(yè)務(wù)層中開始,還有一些甚至在 DAO 層中開始。這種一致性的缺乏是造成策略難以實(shí)現(xiàn)、維護(hù)和治理的原因之一。

    在大多數(shù)情況下,您會發(fā)現(xiàn)您需要使用Programmatic Transaction 模型 來減小事務(wù)作用域,但有時您仍然會使用Declarative Transaction 模型。但是,您通常不能在相同的應(yīng)用程序中混用 Programmatic 和 Declarative Transaction 模型。在使用這種事務(wù)策略時,不應(yīng)該堅(jiān)持使用這種 Programmatic Transaction 模型,這樣您就不會遇到各種問題。但是,如果您發(fā)現(xiàn)自己可以在此策略中使用 Declarative Transaction 模型,那么您應(yīng)該在使用 REQUIRED 事務(wù)屬性開始事務(wù)的層中標(biāo)記所有公共寫方法(插入、更新和刪除)。此屬性表示需要一個事務(wù),并且如果事務(wù)不存在,則由方法啟動。

    與其他事務(wù)策略一樣,無論您選擇開始事務(wù)的組件或?qū)邮鞘裁矗瑔邮聞?wù)的方法都被認(rèn)為是事務(wù)擁有者。只要可能,事務(wù)擁有者應(yīng)該是對事務(wù)執(zhí)行提交和回滾的唯一方法。


    事務(wù)策略實(shí)現(xiàn)

    您可以使用兩個主要技巧來實(shí)現(xiàn) High Concurrency 事務(wù)策略。先讀取(read-first)技巧涉及在盡可能高的應(yīng)用層(通常為 API 層)對事務(wù)作用域范圍外的讀取操作進(jìn)行分組。低級(lower-level)技巧涉及在體系結(jié)構(gòu)中盡可能低的層啟動事務(wù),同時仍然能夠更新操作的原子性和隔離。

    先讀取技巧

    先讀取技巧涉及重構(gòu)(或編寫)應(yīng)用程序邏輯和工作流,以便所有的處理和讀取操作在事務(wù)作用域的外部首先發(fā)生。這種方法消除了不必要的共享或讀取鎖,但是如果數(shù)據(jù)在您能夠提交工作之前更新或提交,則可能會引入失效數(shù)據(jù)異常。為了應(yīng)對可能的這種情況,如果在此事務(wù)策略中使用對象關(guān)系映射(ORM)框架,則應(yīng)確保使用了版本驗(yàn)證功能。

    為了演示這種先讀取技巧,我們從一些實(shí)現(xiàn) API 層事務(wù)策略的代碼入手。在清單 1 中,事務(wù)在 API 層中開始,并且包圍了整個工作單元,包括所有的讀取、處理和更新操作:


    清單 1. 使用 API 層策略

                               
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void processTrade(TradeData trade) throws Exception {
       try {
          //first validate and insert the trade
          TraderData trader = service.getTrader(trade.getTraderID());
          validateTraderEntitlements(trade, trader);
          verifyTraderLimits(trade, trader);
          performPreTradeCompliance(trade, trader);
          service.insertTrade(trade);
    
          //now adjust the account
          AcctData acct = service.getAcct(trade.getAcctId());
          verifyFundsAvailability(acct, trade);
          adjustBalance(acct, trade);
          service.updateAcct(trade);
    
          //post processing
          performPostTradeCompliance(trade, trader);
       } catch (Exception up) {
          ctx.setRollbackOnly();
          throw up;
       }
    }
    


    注意在 清單 1 中,所有的處理都包含在 Java Transaction API (JTA) 事務(wù)的作用域內(nèi),包括所有的確認(rèn)、驗(yàn)證和兼容性檢查(提前和事后)。如果您通過探查器工具來運(yùn)行 processTrade() 方法,那么就會看到每個方法調(diào)用的執(zhí)行時間將與表 1 相似:


    表 1. API 層方法探查 - 事務(wù)作用域

    方法名稱 執(zhí)行時間 (ms)
    service.getTrader() 100
    validateTraderEntitlements() 300
    verifyTraderLimits() 500
    performPreTradeCompliance() 2300
    service.insertTrade() 200
    service.getAcct() 100
    verifyFundsAvailability() 600
    adjustBalance() 100
    service.updateAcct() 100
    performPostTradeCompliance() 1800

    processTrade() 方法的持續(xù)時間稍微長于 6 秒 (6100 ms)。由于事務(wù)的起始時間與方法相同,因此事務(wù)的持續(xù)時間也是 6100 ms。根據(jù)您所使用的數(shù)據(jù)庫類型以及特定的配置設(shè)計(jì),您將在事務(wù)執(zhí)行過程中保持共享和專用鎖(從執(zhí)行讀取操作開始)。此外,在由 processTrade() 方法調(diào)用的方法中執(zhí)行的任何讀取操作也可以在數(shù)據(jù)庫中保持一個鎖。您可能會猜想,在本例中,在數(shù)據(jù)庫中保持鎖持續(xù) 6 秒以上將不能擴(kuò)展以支持高用戶負(fù)載。

    清單 1 中的代碼在沒有高用戶并發(fā)性或高吞吐量需求的環(huán)境中可能會非常出色地運(yùn)行。遺憾的是,這只是大多數(shù)人用于測試的一種環(huán)境。一旦此代碼進(jìn)入生產(chǎn)環(huán)境,其中數(shù)以百計(jì)的交易者(或者是全球的)都在進(jìn)行交易,則該系統(tǒng)最有可能會運(yùn)行得非常糟糕,并且極有可能會遇到數(shù)據(jù)庫死鎖(根據(jù)您所使用的數(shù)據(jù)庫而定)。

    現(xiàn)在,我將修復(fù) 清單 1 中的代碼,方法是應(yīng)用 High Concurrency 事務(wù)策略的先讀取技巧。在清單 1 所示的代碼中,第一個要注意的地方是總共只用了 300 ms 的更新操作(插入和更新)。(此處,我假定 processTrade() 方法調(diào)用的其他方法不執(zhí)行更新操作?;炯记墒窃谑聞?wù)作用域之外執(zhí)行讀取操作和非更新處理,并且僅將更新封裝在事務(wù)內(nèi)部。清單 2 中的代碼演示了減小事務(wù)作用域并仍然維持原子性的必要性:


    清單 2. 使用 High Concurrency 策略(先讀取技巧)

                               
    public void processTrade(TradeData trade) throws Exception {
       UserTransaction txn = null;
       try {
          //first validate the trade
          TraderData trader = service.getTrader(trade.getTraderID());
          validateTraderEntitlements(trade, trader);
          verifyTraderLimits(trade, trader);
          performPreTradeCompliance(trade, trader);
    
          //now adjust the account
          AcctData acct = service.getAcct(trade.getAcctId());
          verifyFundsAvailability(acct, trade);
          adjustBalance(acct, trade);
          performPostTradeCompliance(trade, trader);
    
          //start the transaction and perform the updates
          txn = (UserTransaction)ctx.lookup("UserTransaction");
          txn.begin();
          service.insertTrade(trade);
          service.updateAcct(trade);
          txn.commit();
       } catch (Exception up) {
          if (txn != null) {
             try {
                txn.rollback();
             } catch (Exception t) {
                throw up;
             }
          }
          throw up;
       }
    }
    


    注意,我將 insertTrade()updateAcct() 方法移動到了 processTrade() 方法的末尾,并將它們封裝在了一個編程事務(wù)中。通過這種方法,所有讀取操作和相應(yīng)的處理將在事務(wù)的上下文之外執(zhí)行,因此不會在事務(wù)持續(xù)時間內(nèi)在數(shù)據(jù)庫中保持鎖。在新代碼中,事務(wù)持續(xù)時間只有 300 ms,這顯著低于 清單 1 中的 6100 ms。再次,其目標(biāo)是減少在數(shù)據(jù)庫中花費(fèi)的時間,從而減少數(shù)據(jù)庫的總體并發(fā)性,以及應(yīng)用程序處理較大并發(fā)用戶負(fù)載的能力。通過使用 清單 2 中的代碼將數(shù)據(jù)庫占用時間減少至 300 ms,從理論上說,吞吐量將實(shí)現(xiàn) 20 倍的提升。

    如表 2 所示,在事務(wù)作用域中執(zhí)行的代碼至減少至 300 ms:


    表 2. API 層方法探查 - 修改后的事務(wù)作用域

    方法名稱 執(zhí)行時間 (ms)
    service.insertTrade() 200
    service.updateAcct() 100

    雖然這從數(shù)據(jù)庫并發(fā)性的角度來說是一種顯著的改善,但先讀取技巧帶來了一個風(fēng)險:由于為更新指定的對象上沒有任何鎖,因此任何人都可以在此 LUW 過程中更新這些未鎖定的實(shí)體。因此,您必須確保被插入或更新的對象一般情況下不會由多個用戶同時更新。在之前的交易場景中,我做了一個安全的假設(shè),即只有一個交易者會在特定的時間操作特定的交易和帳戶。但是,并非始終都是這種情況,并且可能會出現(xiàn)失效數(shù)據(jù)異常。

    另外需要注意:在使用 Enterprise JavaBeans (EJB) 3.0 時,您必須通知容器您計(jì)劃使用編程事務(wù)管理。為此,您可以使用 @TransactionManagement(TransactionManagementType.BEAN) 注釋。注意,這個注釋是類級的(而不是方法級的),這表示您不能在相同的類中結(jié)合 Declarative 和 Programmatic 事務(wù)模型。選擇并堅(jiān)持其中之一。

    低級技巧

    假設(shè)您希望堅(jiān)持使用 Declarative Transaction 模型來簡化事務(wù)處理,但是仍然能在高用戶并發(fā)性場景中增加吞吐量。同時,您應(yīng)該在這種事務(wù)策略中使用低級技巧。通過此技巧,您通常會遇到與先讀取技巧相同的折衷問題:讀取操作通常是在事務(wù)作用域的外部完成的。并且,實(shí)現(xiàn)這種技巧最有可能需要代碼重構(gòu)。

    我仍然從 清單 1 中的示例入手。不用在相同的方法中使用編程事務(wù),而是將更新操作移動到調(diào)用棧的另一個公共方法中。然后,完成讀取操作和處理時,您可以調(diào)用更新方法;它會開始一個事務(wù),調(diào)用更新方法并返回。清單 3 演示了這個技巧:


    清單 3. 使用 High Concurrency 策略(低級技巧)

                               
    @TransactionAttribute(TransactionAttributeType.SUPPORTS)
    public void processTrade(TradeData trade) throws Exception {
       try {
          //first validate the trade
          TraderData trader = service.getTrader(trade.getTraderID());
          validateTraderEntitlements(trade, trader);
          verifyTraderLimits(trade, trader);
          performPreTradeCompliance(trade, trader);
    
          //now adjust the account
          AcctData acct = service.getAcct(trade.getAcctId());
          verifyFundsAvailability(acct, trade);
          adjustBalance(acct, trade);
          performPostTradeCompliance(trade, trader);
    
          //Now perform the updates
          processTradeUpdates(trade, acct);
       } catch (Exception up) {
          throw up;
       }
    }
    
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void processTradeUpdates(TradeData trade, AcctData acct) throws Exception {
       try {
          service.insertTrade(trade);
          service.updateAcct(trade);
       } catch (Exception up) {
          ctx.setRollbackOnly();
          throw up;
       }
    }
    


    通過此技巧,您可以有效地在調(diào)用棧的較低層次開始事務(wù),從而減少花費(fèi)在數(shù)據(jù)庫中的時間。注意,processTradeUpdates() 方法僅更新在父方法(或以上)中修改中創(chuàng)建的實(shí)體。再次,保持事務(wù)的時間不再是 6 秒,您只需要 300 ms。

    現(xiàn)在是最難的部分。與 API 層策略或 Client Orchestration 策略不同,High Concurrency 策略并未使用一致的實(shí)現(xiàn)方法。這便是 圖 1 看上去為何像一名經(jīng)驗(yàn)豐富的曲棍球員(包括缺少的牙齒)的原因。對于一些 API 調(diào)用,事務(wù)可能會在 API 層的末端開始,而其他時候,它可能僅限于 DAO 層(特別是對于 LUW 中的單表更新)。技巧是確定在多個客戶機(jī)請求之間共享的方法,并確保如果某個事務(wù)是在較高級的方法中開始的,則它將在較低級的方法中使用。遺憾的是,此特性的效果是,作為非事務(wù)擁有者的較低級方法可以對異常執(zhí)行回滾。結(jié)果,開始事務(wù)的父方法不能對異常采取正確的措施,并且在嘗試回滾(或提交)已經(jīng)標(biāo)記為回滾的事務(wù)時會出現(xiàn)異常。


    實(shí)現(xiàn)指南

    有些情況僅需要稍微小些的事務(wù)作用域來滿足吞吐量和并發(fā)性需求,而另一些情況需要大大縮小事務(wù)作用域來實(shí)現(xiàn)所需的目的。不管具體情況如何,您都可以遵循以下的實(shí)現(xiàn)指導(dǎo),它們能夠幫助您設(shè)計(jì)和實(shí)現(xiàn) High Concurrency 策略:

    • 在著手使用低級別技術(shù)之前,首先要從先讀技術(shù)開始。這樣,事務(wù)至少包含在應(yīng)用程序架構(gòu)的 API 層,并且不擴(kuò)散到其他層中。

    • 當(dāng)使用聲明性事務(wù)時,經(jīng)常使用 REQUIRED 事務(wù)屬性而不是 MANDATORY 事務(wù)屬性來獲得保護(hù),避免啟動某個事務(wù)的方法調(diào)用另一個事務(wù)方法。

    • 在采用此事務(wù)策略之前,確保您在事務(wù)作用域外部執(zhí)行讀取操作時是相對安全的。查看您的實(shí)體模型并問自己多個用戶同時操作相同的實(shí)體是常見的、少見還是不可能的。舉例來說,兩個用戶可以同時修改相同的帳戶嗎?如果您的回答是常見,則面臨著極高的失效數(shù)據(jù)異常風(fēng)險,那么這個策略對于您的應(yīng)用程序探查來說是一個很差的選擇。

    • 并不需要讓所有 讀取操作都處于事務(wù)作用域之外。如果有一個特定的實(shí)體經(jīng)常會被多個用戶同時更改,則應(yīng)該想盡一切辦法將它添加到事務(wù)作用域中。但是應(yīng)該清楚,添加到事務(wù)作用域中的讀取操作和處理越多,吞吐量和用戶負(fù)載功能的下降就越大。


    結(jié)束語

    一切都?xì)w結(jié)于如何在問題之間取得折衷。為了在應(yīng)用程序或子系統(tǒng)中支持高吞吐量和高用戶并發(fā)性,您需要高數(shù)據(jù)庫并發(fā)性。要支持高數(shù)據(jù)庫并發(fā)性,則需要減少數(shù)據(jù)庫鎖,并盡可能縮短保持資源的時間。某些數(shù)據(jù)庫類型和配置可以處理一些這種工作,但在大多數(shù)情況下,解決方案最終歸結(jié)為如何設(shè)計(jì)代碼和事務(wù)處理。對這些問題有一些了解之后,您在稍后可以更加輕松地完成復(fù)雜的重構(gòu)工作。選擇正確的事務(wù)策略對應(yīng)用程序的成功至關(guān)重要。對于高用戶并發(fā)性需求,可以使用 High Concurrency 事務(wù)策略作為確保高水平數(shù)據(jù)完整性,同時維持高并發(fā)性和吞吐量需求的解決方案。



    參考資料

    學(xué)習(xí)


    討論

    • 參與 My developerWorks 社區(qū)。

    轉(zhuǎn)自:http://www.ibm.com/developerworks/cn/java/j-ts5/index.html?ca=drs-cn-0731

    posted on 2009-07-31 16:07 Anemone 閱讀(434) 評論(0)  編輯  收藏 所屬分類: 牧羊心得

    My Links

    Blog Stats

    News

    常用鏈接

    留言簿(1)

    隨筆分類

    隨筆檔案

    新聞檔案

    相冊

    常去網(wǎng)站

    搜索

    積分與排名

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲成a人片77777老司机| 免费黄网在线观看| 亚洲综合久久夜AV | 久久久久久亚洲av无码蜜芽| 免费看片在线观看| 亚洲国产成人资源在线软件| 亚洲美女免费视频| 亚洲伊人久久大香线焦| 成年人在线免费观看| 亚洲色大成网站WWW国产| 国产高清视频在线免费观看| 免费观看亚洲人成网站| 亚洲AV无码之国产精品| 国产精品无码免费视频二三区| WWW国产亚洲精品久久麻豆| 四虎亚洲国产成人久久精品| 又粗又长又爽又长黄免费视频| 亚洲无码精品浪潮| 日韩免费在线观看视频| 亚洲第一成年网站大全亚洲| 中国在线观看免费国语版| 亚洲色偷偷综合亚洲av78| 亚洲av再在线观看| 成人无码a级毛片免费| 色窝窝免费一区二区三区| 免费在线观看视频a| 香蕉免费看一区二区三区| 久久电影网午夜鲁丝片免费| 国产精品亚洲专区无码WEB| 精品国产香蕉伊思人在线在线亚洲一区二区| 久久精品国产亚洲AV电影| 久久午夜免费视频| 黄色免费在线网址| 亚洲无删减国产精品一区| jizz免费观看视频| 亚洲?V无码成人精品区日韩| 另类免费视频一区二区在线观看| 亚洲成AV人片久久| 亚洲精品无码专区久久同性男| 午夜视频在线免费观看| 亚洲a∨国产av综合av下载|