999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

一種分布式存儲索引中間件的設(shè)計(jì)與實(shí)現(xiàn)

2021-09-06 01:48:31黃靜,別要祥,謝宣
軟件工程 2021年8期

黃靜,別要祥,謝宣

摘? 要:HBase(分布式存儲數(shù)據(jù)庫)是大數(shù)據(jù)存儲領(lǐng)域的熱點(diǎn)技術(shù),為信息化快速發(fā)展帶來的存儲問題提供了有效的解決方案。針對HBase檢索低效以及企業(yè)對系統(tǒng)的低耦合、高擴(kuò)展性需求,通過分析HBase檢索困難的原因,設(shè)計(jì)一個(gè)索引中間件。利用Lucene(全文檢索引擎工具)技術(shù)構(gòu)建二級索引,以統(tǒng)一接口的形式提供服務(wù)。經(jīng)過實(shí)驗(yàn)驗(yàn)證,索引中間件在保證寫入需求的情況下,有效地改善了查詢性能,在千萬級數(shù)據(jù)量下仍然達(dá)到毫秒級檢索,并且耦合性低,易于部署,可以快速整合到已有系統(tǒng)中,具有較強(qiáng)的泛用性。

關(guān)鍵詞:HBase;Lucene;中間件;索引

中圖分類號:TP311.1? ? ?文獻(xiàn)標(biāo)識碼:A

Design and Implementation of a Distributed Storage Index Middleware

HUANG Jing, BIE Yaoxiang, XIE Xuan

(School of Information, Zhejiang Sci-Tech University, Hangzhou 310018, China)

syhj_sy@163.com; 1009214965@qq.com; 15951612952@163.com

Abstract: HBase (Distributed Storage Database), a hot technology in the field of big data storage, provides an effective solution to the storage problems brought about by the rapid development of information technology. Aiming at the low efficiency of HBase retrieval and the enterprise's needs for system with low coupling and high scalability, this paper proposes to design an indexing middleware by analyzing reasons for the difficulty of HBase retrieval. Lucene (a full-text search engine tool) technology is used to build a secondary index to provide service in the form of a unified interface. The experimental verification shows that the proposed indexing middleware can effectively improve the query performance while ensuring the writing requirements. It can still reach the millisecond level of retrieval under data volume of tens of millions. Besides, it has low coupling, easy deployment, and can be quickly integrated into the existing system with strong versatility.

Keywords: HBase; Lucene; middleware; index

1? ?引言(Introduction)

在云時(shí)代的背景下,計(jì)算機(jī)需要管理的數(shù)據(jù)呈指數(shù)級增長[1],龐大的數(shù)據(jù)規(guī)模給存儲和處理帶來了極大的挑戰(zhàn)。受單機(jī)存儲的性能瓶頸以及單點(diǎn)故障影響,分布式存儲應(yīng)運(yùn)而生[2]。HBase是一個(gè)面向列的高性能分布式存儲系統(tǒng)[3],其優(yōu)異的高并發(fā)讀寫性能受到眾多企業(yè)的青睞,甚至作為企業(yè)核心數(shù)據(jù)庫使用。但在大數(shù)據(jù)存儲情況下,HBase存在查詢慢的問題[4],并且相關(guān)檢索優(yōu)化措施實(shí)現(xiàn)復(fù)雜,容錯(cuò)性能低,與系統(tǒng)業(yè)務(wù)耦合緊密,不利于系統(tǒng)的擴(kuò)展和升級。

本文從低耦合性與高擴(kuò)展性出發(fā),設(shè)計(jì)索引中間件CFH (Coordinator for HBase)。該中間件作為一個(gè)協(xié)調(diào)器,承接客戶端HBase操作請求的處理與轉(zhuǎn)發(fā),通過Lucene技術(shù)構(gòu)建二級索引,在保證高效寫入與查詢的同時(shí),達(dá)到業(yè)務(wù)低侵入性、易于快速擴(kuò)展與部署的目的。

2 HBase檢索低效與優(yōu)化研究(Research on inefficiency and optimization of HBase retrieval)

HBase檢索低效的原因可以歸納為三種:

(1)HBase以鍵值對的方式存儲數(shù)據(jù),僅提供B+樹構(gòu)造的一級索引(也稱為主鍵)。因此,基于主鍵的查詢具有很高的效率,對非主鍵的查詢效率很低。雖然,針對非主鍵字段查詢,HBase通過MapReduce(分布式計(jì)算)進(jìn)行檢索,但這種方式的硬件資源消耗較高,時(shí)間損耗也不盡人意。

(2)海量的數(shù)據(jù)對檢索也會(huì)產(chǎn)生影響。大規(guī)模數(shù)據(jù)會(huì)建立更多的索引表,同時(shí),非索引查詢會(huì)觸發(fā)全文掃描,對海量數(shù)據(jù)進(jìn)行全文檢索,資源消耗非常巨大[5]。

(3)HBase在檢索時(shí),需要將數(shù)據(jù)加載到內(nèi)存中,與CPU的處理速度相比,磁盤的讀寫操作非常慢。索引表過大、過多,可能會(huì)造成頻繁的磁盤I/O操作,這會(huì)極大增加查詢的時(shí)間[6]。

針對HBase查詢慢的問題,華為技術(shù)公司基于Coprocessor(協(xié)處理器)開發(fā)的hindex框架支持二級索引,但hindex基于HBase 0.94版本開發(fā),如今版本老舊,也不再維護(hù)。徐江峰等[7]提出New-Grid框架,此方案擴(kuò)展性較差,也未作負(fù)載均衡,容易產(chǎn)生性能瓶頸。黨鵬[8]提出LBIndexer機(jī)制,利用最小均方差(Least Mean Square, LMS)模型管理索引數(shù)據(jù),增強(qiáng)了索引的可用性,但基于LMS設(shè)計(jì)的索引,其性能易受長久不使用的大索引文件影響,會(huì)降低索引文件的讀寫與查詢速度。王惟一[9]也基于LMS提出CFIDM數(shù)據(jù)模型,根據(jù)列族存儲特點(diǎn)縮小待查詢的存儲文件數(shù)量,從而提高查詢效率。黃璨等[10]通過分片計(jì)數(shù)布隆過濾器,利用哈希映射的方式建立二級索引,但在分片數(shù)據(jù)量大的情況下優(yōu)化效果并不明顯。葉奇明等[11]將Hive(數(shù)據(jù)倉庫工具)作為HBase的查詢?nèi)肟冢欢讷@得查詢效率提升的同時(shí)增加了系統(tǒng)的不穩(wěn)定性。朱松杰等[12]通過協(xié)處理器實(shí)現(xiàn)二級索引的快速構(gòu)建,并根據(jù)HBase表的變化自動(dòng)更新索引,由于該方案對所有列建立索引且索引文件與HBase處于同一服務(wù)器,這會(huì)增大內(nèi)存資源的消耗,嚴(yán)重時(shí)甚至可能使服務(wù)器癱瘓。

HBase查詢優(yōu)化的方案有很多,其探索腳步也從未停止,但實(shí)現(xiàn)方式大多較為復(fù)雜,局限性大,并且代碼耦合性強(qiáng),無法進(jìn)行廣泛應(yīng)用,造成資源的重復(fù)建設(shè)。

3? ?CFH設(shè)計(jì)(Design of CFH)

建立一個(gè)獨(dú)立于業(yè)務(wù)系統(tǒng)、支持多級索引構(gòu)建的協(xié)調(diào)機(jī)制,對HBase查詢優(yōu)化與系統(tǒng)維護(hù)具有十分重要的意義。為了達(dá)到這樣的目的,本節(jié)基于Lucene技術(shù)設(shè)計(jì)索引中間件CFH。

3.1? ?CFH介紹

CFH服務(wù)端基于Netty(網(wǎng)絡(luò)應(yīng)用程序框架)開發(fā),Netty的NIO(Non-blocking,同步非阻塞I/O)機(jī)制以及零拷貝技術(shù)具有優(yōu)異的性能[13]。服務(wù)端打包后通過jar文件啟動(dòng),僅在配置文件中進(jìn)行HBase鏈接地址等少量設(shè)置,即可快速啟動(dòng),易于部署。通過CFH,可以按需建立索引,區(qū)分出冷熱數(shù)據(jù),加速查詢。下面從不同的數(shù)據(jù)操作類型闡述CFH的業(yè)務(wù)邏輯,主要是針對二級索引、中間件進(jìn)行的輔助操作。

(1)查詢操作。CFH會(huì)判斷查詢操作是否基于索引,如果不是,則先通過Lucene查詢出符合條件的主鍵值,然后創(chuàng)建新的查詢語句,通過主鍵值在HBase中查詢數(shù)據(jù)。調(diào)用Lucene技術(shù)時(shí),如果發(fā)生索引覆蓋,則直接返回查詢結(jié)果。查詢流程如圖1所示。

(2)修改操作。重點(diǎn)在于判斷索引字段是否發(fā)生修改,如果未修改索引字段,則無須操作二級索引文檔,僅調(diào)用HBase服務(wù)處理原數(shù)據(jù)。

(3)新增操作。此操作需要客戶端告知中間件建立索引的字段。除了把新數(shù)據(jù)添加到HBase中,HBase還會(huì)將需建立索引的字段與數(shù)據(jù)的主鍵添加到二級索引文檔中,便于后續(xù)檢索。寫入流程如圖2所示。

(4)刪除操作。若刪除的數(shù)量比較大,CFH會(huì)檢查索引記錄數(shù),如果剩余索引數(shù)據(jù)比較少,CFH會(huì)將剩余數(shù)據(jù)建立新的索引,并啟動(dòng)定時(shí)任務(wù),在不影響業(yè)務(wù)運(yùn)轉(zhuǎn)的情況下,定期刪除數(shù)據(jù)。若刪除的數(shù)據(jù)較少,則直接刪除Lucene索引文檔中的數(shù)據(jù)。

3.2? ?CFH架構(gòu)設(shè)計(jì)

CFH涉及服務(wù)端與客戶端,建立一套有效的通信機(jī)制非常重要。CFH的工作流程可以劃分為八個(gè)步驟,包括:

(1)客戶端與服務(wù)器端建立連接;

(2)客戶端對數(shù)據(jù)序列化并傳輸;

(3)服務(wù)端接收數(shù)據(jù),完成反序列化并驗(yàn)證操作權(quán)限;

(4)服務(wù)端根據(jù)請求類型,選擇對應(yīng)的解析器解析請求參數(shù);

(5)對請求進(jìn)行拆分,完成請求重寫;

(6)本地查詢以及通過RPC(遠(yuǎn)程過程調(diào)用)調(diào)用Lucene或HBase服務(wù);

(7)封裝數(shù)據(jù)、序列化以及回寫客戶端;

(8)客戶端接收數(shù)據(jù),反序列化。

中間件的服務(wù)端采用Zookeeper(分布式協(xié)調(diào)工具)進(jìn)行集群部署,采用一主多從結(jié)構(gòu),CFH集群的主節(jié)點(diǎn)負(fù)責(zé)處理HBase寫操作,讀操作由從節(jié)點(diǎn)進(jìn)行。CFH架構(gòu)示意圖如圖3所示。

由圖3可知,CFH服務(wù)端包含七個(gè)部分,各部分功能如下:

(1)連接器:管理與客戶端的連接,通信方式采用Http

(Hypertext Transfer Protocol,超文本傳輸協(xié)議)+JSON

(JavaScript Object Notation,JS對象簡譜)的形式,網(wǎng)絡(luò)I/O模型為Netty。

(2)安全管理:負(fù)責(zé)數(shù)據(jù)信息的加密以及連接權(quán)限的管理。

(3)序列化與反序列化:數(shù)據(jù)傳輸前后,控制對象與字節(jié)序列之間的轉(zhuǎn)化,CFH采用FastJson工具包進(jìn)行JSON數(shù)據(jù)的解析與生成。

(4)解析器:解析請求,針對不同的請求類型,調(diào)用相關(guān)解析器以及本地業(yè)務(wù)。

(5)本地業(yè)務(wù):業(yè)務(wù)邏輯增強(qiáng),對客戶端請求進(jìn)行重構(gòu)以及生成本地索引。

(6)同步器:采用原生Lucene服務(wù)包建立索引時(shí),集群節(jié)點(diǎn)進(jìn)行索引文檔同步。

(7)遠(yuǎn)程調(diào)用:調(diào)用HBase等服務(wù)、操作索引以及獲取客戶端需要的數(shù)據(jù)。

為了增強(qiáng)可用性,服務(wù)端設(shè)置了兩種創(chuàng)建索引的方式。第一種通過CFH原生集成的Lucene服務(wù)包實(shí)現(xiàn),此方法生成的索引文件在中間件所在的服務(wù)器上。由于CFH可以進(jìn)行分布式部署,集群節(jié)點(diǎn)需要對索引進(jìn)行同步,從而保證數(shù)據(jù)的一致性,這在一定程度上會(huì)增加系統(tǒng)資源消耗。索引同步通過操作日志進(jìn)行,CFH集群中非查詢操作由主節(jié)點(diǎn)處理,將操作記錄保存到同步日志中,主節(jié)點(diǎn)會(huì)定時(shí)往其他節(jié)點(diǎn)發(fā)送同步日志,從節(jié)點(diǎn)接收到日志文件后更新索引文檔。第二種是利用ES(Elasticsearch)。ES是一種基于Lucene技術(shù)的分布式搜索引擎,有著較為成熟的索引構(gòu)建以及檢索方法,但這種方式需要更多的服務(wù)器資源。如果通過ES構(gòu)建二級索引,需要在服務(wù)端啟動(dòng)之前,在配置文件中做出相應(yīng)的設(shè)置。采用ES的情況下,可以經(jīng)Kibana(可視化平臺)工具對索引進(jìn)行可視化管理。在代碼實(shí)現(xiàn)中,根據(jù)配置參數(shù),利用JNDI(Java Naming and Directory Interface,Java命名和目錄接口)機(jī)制,CFH會(huì)加載不同的索引創(chuàng)建工具包,即采用本地生成或者ES生成索引的方式。

CFH客戶端包括連接器、序列化與反序列化以及轉(zhuǎn)發(fā)器三部分。連接器會(huì)從Zookeeper中獲取CFH的集群信息,轉(zhuǎn)發(fā)器則根據(jù)讀寫請求選擇CFH集群節(jié)點(diǎn)??蛻舳瞬僮鞣绞讲蛔鲞^多新的設(shè)計(jì),在已有開發(fā)包的基礎(chǔ)上進(jìn)行封裝。CFH客戶端操作基于org.apache.HBaseHBase-client包中提供的API,對其中的部分API進(jìn)行了擴(kuò)展,通過新的API告知CFH是否需要操作二級索引,默認(rèn)服務(wù)端會(huì)對所有字段建立索引。客戶端利用Spring Boot(服務(wù)開發(fā)框架)的自動(dòng)裝配機(jī)制降低配置復(fù)雜度,通過系統(tǒng)的配置文件導(dǎo)入CFH外部配置。

3.3? ?CFH故障處理

引入中間件會(huì)增加系統(tǒng)的不穩(wěn)定性。如果中間件服務(wù)發(fā)生故障,會(huì)導(dǎo)致該鏈路服務(wù)不可用[14]。為了避免中間件故障造成的服務(wù)不可用,CFH服務(wù)端以Zookeeper作為注冊中心進(jìn)行集群部署。通過集群部署可以降低服務(wù)不可用的概率,同時(shí)增強(qiáng)系統(tǒng)的吞吐量。此外,在CFH客戶端設(shè)置了故障、超時(shí)重試機(jī)制。如果重試達(dá)到一定次數(shù)仍未獲得響應(yīng),客戶端將越過中間件直接訪問HBase,在HBase正常的情況下保證提供服務(wù),但客戶端對HBase服務(wù)器信息的獲取仍通過中間件??蛻舳藭?huì)設(shè)置定時(shí)任務(wù),持久化最新的服務(wù)信息到本地,客戶端本身不需要對HBase進(jìn)行配置。

4? ?性能測試(Performance testing)

為了方便查看二級索引信息,實(shí)驗(yàn)所采用的索引構(gòu)建方式為ES,通過Kibana可視化界面操作索引,構(gòu)建索引時(shí)采用的分詞器為IKAnalyzer(中文分詞工具包)。測試用的主機(jī)為CentOS系統(tǒng),CPU為Intel(R) Core(TM) i9-7900X CPU @ 3.30 GHz,64 GB內(nèi)存,通過VMWare15軟件搭建三臺CentOS7虛擬機(jī),每臺分配8 GB內(nèi)存。測試軟件采用集群方式部署,版本信息如表1所示。HBase與ES內(nèi)存分配為4 GB。測試軟件未做其他優(yōu)化措施,均為默認(rèn)設(shè)置。客戶端在另一臺物理機(jī)上,Windows 10操作系統(tǒng),配置為Intel(R) Core(TM) i5-9600K CPU @ 3.70 GHz,16 GB內(nèi)存。實(shí)驗(yàn)準(zhǔn)備過程中,利用Python腳本批量生產(chǎn)了1,000萬條實(shí)驗(yàn)數(shù)據(jù),每條數(shù)據(jù)約76 字節(jié),包含用戶個(gè)人信息共7 個(gè)字段,分別為姓名、年齡、性別、學(xué)歷、電話、郵箱和國籍,每個(gè)字段由字母、數(shù)字或特殊字符組成。

表2表示數(shù)據(jù)量與所需建立二級索引字段數(shù)不同組合情況下的寫入耗時(shí)(字段值為0表示無任何字段需要建立二級索引,但數(shù)據(jù)仍經(jīng)CFH中轉(zhuǎn)),單位為秒。

從表2可以看出,建立索引以及需建立索引的字段數(shù)增加都會(huì)增加存儲耗時(shí),因?yàn)橹虚g件重構(gòu)請求并維護(hù)索引數(shù)據(jù)結(jié)構(gòu)需要消耗額外的時(shí)間。此外,隨著數(shù)據(jù)量的增加,寫入時(shí)間也以近似線性的趨勢增加。表2中的實(shí)驗(yàn)均為10,000 條數(shù)據(jù)的批寫入,由于未作其他優(yōu)化,高頻提交小數(shù)據(jù)會(huì)導(dǎo)致HBase頻繁創(chuàng)建線程并進(jìn)行資源回收,浪費(fèi)服務(wù)器資源,嚴(yán)重時(shí)會(huì)出現(xiàn)宕機(jī),因而采用批寫入的方式。當(dāng)CFH不可用時(shí),客戶端直連HBase,此時(shí)寫入效率為1.3 秒/萬條,未建立任何二級索引。

查詢時(shí),提取數(shù)據(jù)所有字段信息,即先通過ES獲取主鍵,繼而經(jīng)主鍵查詢數(shù)據(jù)信息,不考慮索引覆蓋的優(yōu)化效果。表3為不同條件下經(jīng)CFH的查詢耗時(shí)(模糊匹配字段數(shù)與HBase數(shù)據(jù)量的組合),單位為秒。

檢索時(shí),測試100 條記錄取均值。由表3可知,數(shù)據(jù)量與模糊匹配的字段數(shù)增加,都會(huì)增加查詢的時(shí)間,但經(jīng)CFH與ES的配合,CFH檢索仍達(dá)毫秒級查詢。由此可見,此方案實(shí)現(xiàn)了快速查詢。

5? ?結(jié)論(Conclusion)

本文設(shè)計(jì)了分布式存儲索引中間件CFH,通過Lucene技術(shù)構(gòu)建二級索引,實(shí)現(xiàn)快速檢索。經(jīng)過實(shí)驗(yàn)驗(yàn)證,CFH在保證大規(guī)模數(shù)據(jù)并發(fā)寫入需求的同時(shí),有效地改善了HBase的檢索效率,對千萬級數(shù)據(jù)查詢可達(dá)毫秒級檢索。CFH獨(dú)立于業(yè)務(wù)系統(tǒng),基于已有的HBase客戶端工具包進(jìn)行開發(fā),易于整合到已有系統(tǒng)中,支持集群部署。然而,中間件對復(fù)雜查詢的支持還不夠完善,采用原生Lucene工具包構(gòu)建索引,集群節(jié)點(diǎn)同步也可能會(huì)發(fā)生數(shù)據(jù)丟失的問題。

參考文獻(xiàn)(References)

[1] 周淳,李賢慧.一種實(shí)時(shí)數(shù)據(jù)庫的分布式存儲方法[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2019,28(04):125-130.

[2] 周逸文.分布式存儲技術(shù)和應(yīng)用淺析[J].數(shù)碼世界,2017(12):49.

[3] 田勝利.針對HBase的MapReduce數(shù)據(jù)訪問方式的優(yōu)化[D].長沙:國防科學(xué)技術(shù)大學(xué),2012.

[4] YE F, ZHU S J, LOU Y S, et al. Research on index mechanism of HBase based on coprocessor for sensor data[C]// REISMANS. 2019 IEEE 43rd Annual Computer Software and Applications Conference(COMPSAC). Los Alamitos, CA: IEEE Computer Society, 2019: 598-603.

[5] 吳國泉.基于HBase的全文索引及檢索技術(shù)的研究[D].武漢:華中科技大學(xué),2015.

[6] 石磊,黃高攀,喬雄.基于內(nèi)存數(shù)據(jù)庫的索引算法研究[J].信息技術(shù),2016,40(11):139-142.

[7] 徐江峰,譚玉龍.基于HBase的多維索引查詢機(jī)制的優(yōu)化[J].計(jì)算機(jī)應(yīng)用,2020,40(02):571-577.

[8] 黨鵬.HBase層次化輔助索引系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].西安:西安電子科技大學(xué),2019.

[9] 王惟一.基于存儲模型的HBase查詢優(yōu)化技術(shù)研究[D].南京:南京大學(xué),2018.

[10] 黃璨,方旭昇,張朝泉.分片計(jì)數(shù)布隆過濾器及其在HBase二級索引的應(yīng)用[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2016,25(03):119-123.

[11] 葉奇明,陳俊宇.Hive over HBase框架查詢性能研究[J].廣東石油化工學(xué)院學(xué)報(bào),2018,28(06):36-38,42.

[12] 朱松杰,婁淵勝,葉楓,等.基于協(xié)處理器的HBase內(nèi)存索引機(jī)制的研究[J].計(jì)算機(jī)工程與應(yīng)用,2020,56(01):98-105.

[13] 朱炯名.基于智慧水務(wù)的供水大數(shù)據(jù)采集架構(gòu)分析研究[J].軟件工程,2018,21(09):5-7.

[14] CIAVOTTA M, ALGE M, MENATO S, et al. A microservice-based middleware for the digital factory[J]. Procedia Manufacturing, 2017, 11(05):931-938.

作者簡介:

黃? 靜(1965-),女,博士,教授.研究領(lǐng)域:通信工程,大數(shù)據(jù),深度學(xué)習(xí).

別要祥(1996-),男,碩士生.研究領(lǐng)域:軟件工程,大數(shù)據(jù).

謝? ?宣(1995-),男,碩士生.研究領(lǐng)域:軟件工程,圖像處理.

主站蜘蛛池模板: 国产欧美日韩在线一区| 啊嗯不日本网站| 国产在线91在线电影| 在线va视频| 国产清纯在线一区二区WWW| 99视频在线看| 欧美日韩国产在线观看一区二区三区| 色爽网免费视频| 在线观看av永久| 国产欧美日韩91| 无码日韩视频| 啪啪啪亚洲无码| 国产一级视频久久| 人妻中文字幕无码久久一区| 亚洲熟妇AV日韩熟妇在线| 人人91人人澡人人妻人人爽| 日韩一级毛一欧美一国产 | 亚洲天堂高清| 精久久久久无码区中文字幕| 99精品伊人久久久大香线蕉| 亚洲日本中文字幕乱码中文| 亚洲第一黄色网址| 手机在线国产精品| 成人综合久久综合| 伊人久久久久久久久久| 久久久久青草线综合超碰| 精品无码日韩国产不卡av| 色欲色欲久久综合网| 国产精品亚洲一区二区三区在线观看| 欧美激情视频二区三区| 亚洲综合极品香蕉久久网| 国产一级视频在线观看网站| 国产一在线| 国产在线一区视频| 日本高清有码人妻| 国产aaaaa一级毛片| 日韩精品一区二区三区swag| 午夜a级毛片| 亚洲成aⅴ人在线观看| 亚洲欧洲日韩综合| 国产爽爽视频| 直接黄91麻豆网站| 一区二区午夜| 在线免费亚洲无码视频| 日韩欧美国产成人| 毛片大全免费观看| 国产麻豆精品在线观看| 亚洲综合片| www.91中文字幕| 成人久久18免费网站| 国内精品视频区在线2021| 亚洲欧美不卡| 偷拍久久网| 亚洲一区二区日韩欧美gif| 亚洲国产精品无码久久一线| 丰满人妻中出白浆| 国产精品网址在线观看你懂的| 天天操精品| 97久久精品人人| 久久黄色一级视频| 无码AV动漫| 99热这里只有免费国产精品| 婷婷综合亚洲| 欧美成在线视频| 无码区日韩专区免费系列| 国产久操视频| 麻豆a级片| 国产欧美专区在线观看| 国产剧情一区二区| 欧美在线视频不卡第一页| 国产鲁鲁视频在线观看| 曰AV在线无码| 国产1区2区在线观看| 亚洲最大福利网站| а∨天堂一区中文字幕| 国内精品伊人久久久久7777人| 天堂在线www网亚洲| 亚洲一区二区三区国产精华液| 无码国产偷倩在线播放老年人| www.亚洲国产| 成人夜夜嗨| 亚洲一级毛片免费观看|