成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

FastDFS并發會有bug，其實我也不太信？- 一次并發問題的排查經歷

作者：純潔的微笑
開發 開發工具
前一段時間，業務部門同事反饋在一次生產服務器升級之后，POS消費上傳小票業務偶現異常，上傳小票業務有重試機制，有些重試三次也不會成功，他們排查了一下沒有找到原因，希望架構部幫忙解決。

前一段時間，業務部門同事反饋在一次生產服務器升級之后，POS消費上傳小票業務偶現異常，上傳小票業務有重試機制，有些重試三次也不會成功，他們排查了一下沒有找到原因，希望架構部幫忙解決。

公司使用的是FastDFS來做的圖片服務器，生產使用了六臺服務器外加一個存儲，集群采用的是：2個tracker+4個storage，storage分為兩個group，使用獨立的nginx做文件代理訪問。各軟件版本信息如下：

  • 操作系統：centos6.9
  • FastDFS ：5.05
  • libfastcommon：1.0.36
  • nginx ：1.7.9
  • fastdfs-nginx-module：1.16

為了盡可能的模擬生產，我在測試環境1:1搭建了一套和生產一樣的FastDFS集群，當時也寫了搭建過程：FastDFS 集群 安裝 配置

從日志中找線索

業務部門同事反饋，在一次生產服務器升級之后，重新搭建了一套FastDFS集群，然后過了幾天就開始出現上傳小票偶爾失敗的問題。根據這些信息的反饋，我懷疑是否是FastDFS搭建有問題？這個懷疑點差點把我帶到溝里去。

我拉取了FastDFS的日志，tracker服務器日志如下：

  1. [2017-09-19 09:13:52] ERROR - file: tracker_nio.c, line: 306, client ip: 192.168.0.1, pkg length: 15150 > max pkg size: 8192 
  2. [2017-09-19 10:34:57] ERROR - file: tracker_nio.c, line: 306, client ip: 192.168.0.1, pkg length: 16843 > max pkg size: 8192 
  3. [2017-09-19 10:34:57] ERROR - file: tracker_nio.c, line: 306, client ip: 192.168.0.1, pkg length: 16843 > max pkg size: 8192 
  4. [2017-09-19 11:31:08] ERROR - file: tracker_nio.c, line: 306, client ip: 192.168.03, pkg length: 23955 > max pkg size: 8192 
  5. [2017-09-19 11:42:56] ERROR - file: tracker_nio.c, line: 306, client ip: 192.168.01, pkg length: 12284 > max pkg size: 8192 
  6. [2017-09-19 12:10:28] ERROR - file: tracker_service.c, line: 2452, cmd=103, client ip: 192.168.0.3, package size 6258 is too long, exceeds 144 

根據tracker的日志信息可以看出，不時有一些小票文件的大小大于最大傳輸值8192，跟著這個線索順著上傳的那條線進行了排查，比如nginx上傳大小的限制，tracker上傳大小的限制，是不是生成的小票出現異常，大小突然變大。麻溜的整了半天得出結論，上傳小票失敗和這個異常沒有關系。

接下來看了下storaged的日志：

  1. [2017-09-25 14:22:38] WARNING - file: storage_service.c, line: 7135, client ip: 192.168.1.11, logic file: M00/D1/04/wKg5ZlnIoKWAAkNRAAAY86__WXA920.jpg-m not exist 
  2. [2017-09-25 14:22:39] WARNING - file: storage_service.c, line: 7135, client ip: 192.168.1.11, logic file: M00/D1/04/wKg5ZlnIoKuAUXeVAAAeASIvHGw673.jpg not exist 
  3. [2017-09-25 14:22:50] ERROR - file: storage_nio.c, line: 475, client ip: 192.168.1.13, recv failed, errno: 104, error info: Connection reset by peer 
  4. [2017-09-25 14:22:56] ERROR - file: tracker_proto.c, line: 48, server: 192.168.1.11:23001, response status 2 != 0 
  5. [2017-09-25 14:23:06] ERROR - file: tracker_proto.c, line: 48, server: 192.168.1.11:23001, response status 2 != 0 
  6. [2017-09-25 14:23:11] ERROR - file: storage_service.c, line: 3287, client ip:192.168.1.13, group_name: group2 not correct, should be: group1 

除了看到一些文件不存在的警告和響應狀態不對的錯誤外，也沒有發現其它的異常。

最后來看應用中的錯誤日志，其中有兩段錯誤日志引起了我的注意：

第一段日志如下：

  1. org.csource.common.MyException: body length: 0 <= 16 
  2.    at org.csource.fastdfs.StorageClient.do_upload_file(StorageClient.java:799) 
  3.    at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:208) 
  4.    at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:226) 
  5.    at com.xxx.neo.fastdfs.FileManager.upload(FileManager.java:86) 
  6.    at com.xxx.neo.controller.QpayUploadSignController.saveSign(QpayUploadSignController.java:84) 
  7.    at com.xxx.neo.controller.QpayUploadSignController.uploadSign(QpayUploadSignController.java:65) 
  8.    at com.xxx.neo.controller.QpayUploadSignController$$FastClassByCGLIB$$5debf81b.invoke(<generated>) 
  9.    at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) 
  10.    at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689) 
  11.    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) 

跟了一下fastdfs-client-java中的源碼的douploadfile方法，有這么一段：

  1. ProtoCommon.RecvPackageInfo pkgInfo = ProtoCommon.recvPackage(storageSocket.getInputStream(), 
  2.              ProtoCommon.STORAGE_PROTO_CMD_RESP, -1); 
  3. //省略中間代碼               
  4. if (pkgInfo.body.length <= ProtoCommon.FDFS_GROUP_NAME_MAX_LEN) { 
  5.    throw new MyException("body length: " + pkgInfo.body.length + " <= " + ProtoCommon.FDFS_GROUP_NAME_MAX_LEN); 
  6.  } 

pkgInfo是封裝好的文件流信息，ProtoCommon是fastdfs-client-java中封裝好的參數類，其中FDFSGROUPNAMEMAXLEN的值為16，代碼的意思就是當讀取的大小小于16字節的時候，拋出MyException異常。

第二段日志如下：

  1. [ INFO] [http://*:8083-69096 2017-09-25 14:07:32] (FileManager.java:upload:92) upload_file time used:76 ms 
  2. [ INFO] [http://*:8083-69096 2017-09-25 14:07:32] (FileManager.java:upload:103) upload file successfully!!!group_name:group2, remoteFileName: M00/3C/A8/wKg5Z1nInSOAaHSNAAAdNipAyrQ611.jpg 
  3. upload file successfully!!!group_name:group2, remoteFileName: M00/3C/A8/wKg5Z1nInSOAaHSNAAAdNipAyrQ611.jpg 
  4. [Ljava.lang.String;@17584701 
  5. [ERROR] [http://*:8083-69087 2017-09-25 14:07:32] (FileManager.java:upload:90) Non IO Exception when uploadind the file:520 
  6. java.lang.NullPointerException 
  7.    at org.csource.fastdfs.StorageClient.do_upload_file(StorageClient.java:842) 
  8.    at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:208) 
  9.    at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:226) 
  10.    at com.xxx.neo.fastdfs.FileManager.upload(FileManager.java:86) 
  11.    at com.xxx.neo.controller.QpayUploadSignController.saveSign(QpayUploadSignController.java:84) 
  12.    at com.xxx.neo.controller.QpayUploadSignController.uploadSign(QpayUploadSignController.java:65) 
  13.    at com.xxx.neo.controller.QpayUploadSignController$$FastClassByCGLIB$$5debf81b.invoke(<generated>) 
  14.    at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) 
  15.    at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689) 

日志中關于空指針的異常最多，跟蹤了fastdfs-client-java的源碼，空指針都出現在以下幾段代碼：

第一處：

  1. ... 
  2. storageSocket = this.storageServer.getSocket(); 
  3. ext_name_bs = new byte[ProtoCommon.FDFS_FILE_EXT_NAME_MAX_LEN]; 
  4. Arrays.fill(ext_name_bs, (byte) 0); 
  5. ... 
  6. ​ 

第二處：

  1. if (!bNewConnection) { 
  2.    try { 
  3.      this.storageServer.close(); 
  4.    } catch (IOException ex1) { 
  5.      ex1.printStackTrace(); 
  6.    } finally { 
  7.      this.storageServer = null; 
  8. } 

第三處：

  1. if (bNewConnection) { 
  2.    try { 
  3.      this.storageServer.close(); 
  4.    } catch (IOException ex1) { 
  5.      ex1.printStackTrace(); 
  6.    } finally { 
  7.      this.storageServer = null; 
  8.    } 
  9.  } 

大家有沒有發現這三段代碼都有一個共同之處？就是存在storageServer變量的使用，并且在調用的地方出現了空指針異常，難道fastdfs-client-java有bug？覺得不太可能，畢竟那么多人使用，會不會是我們使用的版本太舊或者使用方式不對呢?

日志中的IP地址和公司信息均已進行脫敏

FastDFS提供的Jar包有問題？

帶著上面的懷疑我準備搞個多線程壓測一下，看是不是并發的時候產生的問題。使用CountDownLatch讓線程集中執行，代碼如下：

  1. private static void latchTest() throws InterruptedException { 
  2.        final CountDownLatch start = new CountDownLatch(1); 
  3.        final CountDownLatch end = new CountDownLatch(poolSize); 
  4.        ExecutorService exce = Executors.newFixedThreadPool(poolSize); 
  5.        for (int i = 0; i < poolSize; i++) { 
  6.            Runnable run = new Runnable() { 
  7.                @Override 
  8.                public void run() { 
  9.                    try { 
  10.                        start.await(); 
  11.                        testLoad(); 
  12.                    } catch (InterruptedException e) { 
  13.                        e.printStackTrace(); 
  14.                    } finally { 
  15.                        end.countDown(); 
  16.                    } 
  17.                } 
  18.            }; 
  19.            exce.submit(run); 
  20.        } 
  21.        start.countDown(); 
  22.        end.await(); 
  23.        exce.shutdown(); 
  24.    } 

CountDownLatch是Java多線程同步器的四大金剛之一，CountDownLatch能夠使一個線程等待其他線程完成各自的工作后再執行。

使用Executors.newFixedThreadPool創建固定大小的線程池，剛開始設置的是12，每個線程執行一萬次上傳請求。

  1. public static void testLoad() { 
  2.    String filePath="C:\\Users\\xxx\\Pictures\\xz.jpg"; 
  3.    File file=new File(filePath); 
  4.    String serverUrl="http://localhost:8080/uploadSign"; 
  5.    for (int i=0;i<10000;i++){ 
  6.        HttpClientUtils.uploadFile(file,serverUrl); 
  7.    } 
  8. } 

Controller層接到請求后，組裝FastDFSFile進行上傳

  1. .... 
  2. byte[] file_buff = null; 
  3.    if(inputStream!=null){ 
  4.        int len1 = inputStream.available(); 
  5.        file_buff = new byte[len1]; 
  6.        inputStream.read(file_buff); 
  7.    } 
  8. FastDFSFile file = new FastDFSFile("520", file_buff, "jpg"); 
  9. try { 
  10.     fileAbsolutePath = FileManager.upload(file);  //上傳到分布式文件系統 
  11.    System.out.println(fileAbsolutePath); 
  12. } catch (Exception e1) { 
  13.    e1.printStackTrace(); 
  14. } 
  15. ... 

再進行一些封裝之后，最終調用fastdfs-client-java的 upload_file()方法

  1. .... 
  2. uploadResults = storageClient.upload_file(file.getContent(), file.getExt(), meta_list); 
  3. .... 
  4. ​ 

壓測代碼寫完之后，迫不及待的運行了起來，準備驗證一把，結果非常出意料，剛一啟動就不斷的報空指針異常，看到這個空指針異常我卻一陣歡喜，這個異常和我在生產看到的異常一模一樣。平時最棘手的問題，就是生產偶現測試環境又不能復現的問題，很難定位異常的原因，一旦可以在測試環境復現問題，那就意味著問題解決了一半。

接下來，我將線程池的個數減少到6個，啟動測試后還是狂報異常；接著將線程數減到2個，每個線程數執行的數量由以前的10000改為100個，修改后再進行測試還是報錯；沒辦法改成一個線程來運行，果然程序可以正常上傳小票了，確認是并發導致的問題。

這樣可以得出預判，在業務高峰期間產生并發導致部分小票上傳業務失敗，那為什么這個問題一直沒有發現呢？有兩方面的因素：第一，可能業務初期并發量并不是很高，上傳小票也不是主干業務，偶爾出現一兩筆失敗也有重試機制來后補；第二，生產環境使用了六臺服務器做負載，請求被均勻分發到六臺服務器中，在某種程度上也避免了單臺服務器的并發量，只有業務并發量進一步擴大才出現明顯的異常。

嘗試著去解決

既然異常都發生在upload_file方法storageServer出現的地方，那么我們就研究研究這個storageServer是個什么鬼？storageServer根據屬性名可以看出來，storageServer是上傳文件的storage存儲節點，每次上傳文件的時候從trackerServer中獲取。

跟蹤源碼可以發現，storageServer會在兩個地方進行初始化：第一，在初始化storageClient的時候

  1. storageClient = new StorageClient(trackerServer, storageServer);​ 

這里的storageServer可以為空；如果為空會自動從trackerServer中獲取，如果需要指定具體的storage可以在這里進行初始化。

第二，在調用 do_upload_file()方法開頭中，下面代碼截取于 do_upload_file()方法。

  1. bUploadSlave = ((group_name != null && group_name.length() > 0) && 
  2.        (master_filename != null && master_filename.length() > 0) && 
  3.        (prefix_name != null)); 
  4. if (bUploadSlave) { 
  5.  bNewConnection = this.newUpdatableStorageConnection(group_name, master_filename); 
  6. } else { 
  7.  bNewConnection = this.newWritableStorageConnection(group_name); 
  8. } 
  9. try { 
  10.  storageSocket = this.storageServer.getSocket(); 
  11. ... 

在 do_upload_file()方法的開頭，會根據條件運行 this.newUpdatableStorageConnection(group_name,master_filename)方法或者 this.newWritableStorageConnection(group_name)方法，在這兩個方法中都會有對storageServer進行初始化。我們來看 newWritableStorageConnection(group_name)方法的源碼：

  1. /** 
  2. * check storage socket, if null create a new connection 
  3. * 
  4. * @param group_name the group name to upload file to, can be empty 
  5. * @return true if create a new connection 
  6. */ 
  7. protected boolean newWritableStorageConnection(String group_name) throws IOException, MyException { 
  8. if (this.storageServer != null) { 
  9.  return false; 
  10. } else { 
  11.  TrackerClient tracker = new TrackerClient(); 
  12.  this.storageServer = tracker.getStoreStorage(this.trackerServer, group_name); 
  13.  if (this.storageServer == null) { 
  14.    throw new MyException("getStoreStorage fail, errno code: " + tracker.getErrorCode()); 
  15.  } 
  16.  return true; 
  17. } 
  18. } 

這個方法比較簡單，首先判斷storageServer是否進行過初始化，如果沒有初始化，則從tracker中獲取一個可用的storageServer進行初始化。初始化之后douploadfile()方法會根據拿到的storageServer進行文件上傳操作。

接下來到了全文最關鍵的地方的了，douploadfile()方法會在上傳文件結束的時候，將storageServer關閉并賦值為空，相關代碼如下：

  1. } catch (IOException ex) { 
  2.  if (!bNewConnection) { 
  3.    try { 
  4.      this.storageServer.close(); 
  5.    } catch (IOException ex1) { 
  6.      ex1.printStackTrace(); 
  7.    } finally { 
  8.      this.storageServer = null; 
  9.    } 
  10.  } 
  11.  throw ex; 
  12. } finally { 
  13.  if (bNewConnection) { 
  14.    try { 
  15.      this.storageServer.close(); 
  16.    } catch (IOException ex1) { 
  17.      ex1.printStackTrace(); 
  18.    } finally { 
  19.      this.storageServer = null; 
  20.    } 
  21.  } 
  22. } 

當然這個邏輯是沒有問題的，每次方法執行的時候獲取一個可用的storageServer，結束的時候進行回收，避免多次請求使用同一個storage。如果程序沒有任何并發這段代碼是沒有問題的，如果出現并發呢，出現小的并發也不一定會出現問題，當并發量稍微大一點的時候就一定會出現問題，這是為什么呢？

我們來繼續跟蹤storageServer，發現storageServer是StorageClient類的一個全局屬性，當并發特別大的時候就有可能出現這樣一個現象：第一個線程進這個方法的時候，看到storageServer沒有初始化于是進行賦值并繼續往下執行；這時候第二個線程又開始進入這個方法，發現storageServer已經進行了初始化，就不再初始化，繼續往下執行；當第一個線程執行結束的時候，將storageServer關閉并賦值為null，然后拍屁股走人了；這個時候可苦逼第二個線程了，方法剛剛執行了一半，當需要使用storageServer的時候，才發現storageServer已經被置為了null，于是在使用storageServer的地方都有可能會出現空指針異常，第二個線程，在掛掉的時候一定在想，真XX的坑爹。

于是上面的這個故事，過一段時間就偷偷的在我們生產環境中上演。

后面我繼續看了一下StorageClient源碼，不但是douploadfile()會存在此問題，StorageClient類中只要這樣使用storageServer的地方都會出現類似的并發問題，如：domodifyfile方法、delete_file方法等等。

那么既然找到了問題的根因，到底如何解決這個問題呢？解決這個問題的本質就是解決共享變量的并發問題，那解決共享變量并發有哪些手段呢？最常用有加鎖或者使用Threadlocal，看了一下使用Threadlocal進行改造工作量比較大，因此我最后選擇使用了Synchronized同步鎖來解決這個問題，就是在每個使用storageServer方法上面添加一個Synchronized關鍵字。

  1. protected Synchronized  String[] do_upload_file()​ 

在github上面將源碼down下來 fastdfs-client-java，修改完之后再進行壓測，妥妥的再不會報空指針異常類了。

峰回路轉

大家以為這樣就結束了嗎？當時我也是這樣認為的。后來回頭一想，這樣雖然解決了問題，但是并發數卻急劇降低，FastDFS不會這么傻吧！肯定還是自己出了問題，第二天將項目中FastDFS使用的代碼又擼了一遍，果然發現問題了。

FileManager是我們封裝好的FastDFS工具類，在啟動的時候會對storageClient進行初始化，這樣每次項目調研的時候都會復用storageClient實例。

  1. public class FileManager implements FileManagerConfig { 
  2.  private static StorageClient storageClient; 
  3.  static { 
  4.      try { 
  5.      //省略一部分代碼 
  6.      trackerClient = new TrackerClient(); 
  7.      trackerServer = trackerClient.getConnection(); 
  8.      storageClient = new StorageClient(trackerServer, storageServer); 
  9.    } catch (Exception e) { 
  10.      logger.error(e); 
  11.    } 
  12.  } 
  13. } 

upload()方法每次會從全局變量中獲取storageClient進行調用，也就意味著每次請求使用的是同一個storageClient實例，當然也包括實例中的變量storageServer。

  1. public static String[] upload(FastDFSFile file) { 
  2.    try { 
  3.      uploadResults = storageClient.upload_file(file.getContent(), file.getExt(), meta_list); 
  4.    } catch (Exception e) { 
  5.      logger.error("Exception when uploadind the file:" + file.getName(), e); 
  6.    } 
  7.    //省略一部分代碼 
  8.    return uploadResults; 
  9.  } 

如果我將上面的 upload()方法改造成下面這樣呢：

  1. public static String[] upload(FastDFSFile file) { 
  2.    try { 
  3.      StorageClient  storageClient = new StorageClient(trackerServer, storageServer); 
  4.      uploadResults = storageClient.upload_file(file.getContent(), file.getExt(), meta_list); 
  5.    } catch (Exception e) { 
  6.      logger.error("Exception when uploadind the file:" + file.getName(), e); 
  7.    } 
  8.    //省略一部分代碼 
  9.    return uploadResults; 
  10.  } 
  11. ​ 

重點是添加了這段代碼： StorageClientstorageClient=newStorageClient(trackerServer,storageServer);

也就是說，每次調用的時候會重新new一個StorageClient()實例，這樣每次請求拿到的就是不同的StorageClient，也就意味著每個請求會獲取到不同的storageServer，這樣就不存在共享變量，也就避免了出現并發的空指針問題。

根據上面的分析可以看出，最好的解決方案就是每次調用的時候new一個新的實例去使用。也提醒大家在使用FastDFS的時候，盡量不要重用StorageClient！

后來我在github上面給FastDFS提交了pull來說明這個問題，有一個網友也給出了同樣的理解：解決并發空指針問題 (https://github.com/happyfish100/fastdfs-client-java/pull/28)；文中的測試代碼我放到了這里：(https://github.com/ityouknow/spring-examples)，感興趣的同學可以繼續去了解。

最后

問題終于解決了，雖然走了彎路，卻讓我對FastDFS有了更深的認識。平時解決問題也經常會這樣，有時候排查了整整一天，才發現原來是某個非常低級錯誤導致的，這就是程序員的正常工作。其實淘寶也有一個版本的FastDFS客戶端，地址在這里(https://github.com/tobato/FastDFS_Client)。并且提供了更多的功能支持，比如斷點續傳、連接池等，推薦大家使用這個版本。

研究發現，在所有報告的錯誤中，大約有95%是由程序員造成的，2%是由系統軟件（編譯器和操作系統）造成的，2%是由其他軟件造成的，1%是由硬件造成的。因此不要懷疑人生、出現什么奇跡、發生某些詭異的事情，那是不會發生的。

要相信編程的第一法則：永遠都是你的錯！

你應該知道那種感覺。我們所有人都曾碰到過這樣的事情：已經盯著代碼看了無數遍，但還是沒有發現任何問題。然而，有個故障或者錯誤始終揮之不去。于是你開始懷疑，可能是你開發程序所用的那臺機器出了問題，也可能是操作系統的問題，或者是你使用的工具和庫出了問題。肯定是它們的原因！

然而，無論你多么絕望，都不要往那條路上走。沿著那條路下去就是薛定諤的貓和靠運氣編程。

總是要處理一些困難的、捉摸不透的問題，這是一件令人絕望的事情，但是不要讓絕望領著你誤入歧途。作為一名謙遜的程序員，最基本的要求就是要有意識：你寫的代碼在任何時候出了問題，那一定都是你的錯。

【本文為51CTO專欄作者“純潔的微笑”的原創稿件，轉載請通過微信公眾號聯系作者獲取授權】

戳這里，看該作者更多好文

責任編輯：武曉燕 來源： 51CTO專欄
FastDFS排查并發
相關推薦

2025-03-17 10:01:07

2022-07-13 08:31:18

React問題排查

2013-04-01 10:27:37

程序員失業

2023-10-23 08:12:34

并發問題有鎖和無鎖

2022-09-07 09:09:13

高并發架構

2012-07-12 14:35:31

面試經歷

2009-11-25 13:33:39

并發

2022-09-13 13:49:05

數據庫隔離

2012-02-02 15:57:09

HibernateJava

2021-05-13 08:51:20

GC問題排查

2023-04-06 07:53:56

Redis連接問題K8s

2012-08-28 09:21:59

Ajax查錯經歷Web

2022-11-03 16:10:29

groovyfullGC

2020-10-27 10:35:38

優化代碼項目

2021-12-06 19:29:17

LRU內存算法

2023-03-29 09:36:32

2021-11-23 21:21:07

線上排查服務

2021-05-31 10:08:44

工具腳本主機

2021-03-29 12:35:04

Kubernetes環境TCP

2021-07-01 19:31:50

并發JavaCPU
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 99精品欧美一区二区三区综合在线 | 亚洲国产精品精华素 | 午夜成人免费视频 | www久久久| 日韩在线h | 欧美日韩亚洲系列 | 伊人狠狠| 综合精品在线 | 欧美一卡二卡在线观看 | 精品日韩一区二区 | 人人做人人澡人人爽欧美 | 欧美中文字幕一区 | 亚洲36d大奶网| 97人人澡人人爽91综合色 | 特级黄一级播放 | 成人网在线观看 | 天天天操操操 | 国产欧美一区二区三区免费 | 日韩在线播放中文字幕 | 午夜码电影 | 久草在线在线精品观看 | 欧美区在线 | 日本手机看片 | 亚洲欧美日韩精品久久亚洲区 | 日韩精品四区 | 国产精品国产成人国产三级 | 欧美激情va永久在线播放 | 亚洲第一黄色网 | 久久久精品一区 | 欧美日韩精品久久久免费观看 | 成年人在线观看视频 | 99免费在线观看 | 日韩视频在线观看一区二区 | 在线观看第一页 | 亚洲精品电影网在线观看 | 狠狠狠 | 在线观看国产91 | 亚洲麻豆 | 精品免费 | 视频二区在线观看 | 久久久久久久久久久久久久av |