解DBA之惑：數(shù)據(jù)庫承載能力評(píng)估及優(yōu)化手段-創(chuàng)新互聯(lián)

作為DBA，有時(shí)會(huì)被挑戰(zhàn)類似這樣的問題：

創(chuàng)新互聯(lián)長(zhǎng)期為成百上千客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為南岔企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)站制作，南岔網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

• 如果現(xiàn)有業(yè)務(wù)規(guī)模增加10倍、100倍，數(shù)據(jù)庫是否能夠支撐？
• 下個(gè)月我們搞大促，數(shù)據(jù)庫這邊沒問題吧？
• 計(jì)劃進(jìn)行去O工作，代碼邏輯不變，數(shù)據(jù)庫從Oracle切換到MySQL，MySQL能支撐業(yè)務(wù)嗎？
• 服務(wù)器采購選型，到底哪款服務(wù)器更適合我們呢？

面對(duì)諸如上面的這些質(zhì)疑，DBA應(yīng)該如何面對(duì)？

身為DBA該如何評(píng)估現(xiàn)有資源使用情況？

如果現(xiàn)有數(shù)據(jù)庫資源確實(shí)無法支撐，又該本著什么原則進(jìn)行改造呢？

本文是針對(duì)上面問題的一些經(jīng)驗(yàn)總結(jié)，供大家參考。

一、評(píng)估工作

面對(duì)這樣的問題，首先要進(jìn)行評(píng)估工作，可遵循下面的步驟：

1、建立性能基線

針對(duì)系統(tǒng)運(yùn)行現(xiàn)狀，建立性能基線。將業(yè)務(wù)指標(biāo)與性能指標(biāo)建立起對(duì)應(yīng)關(guān)系。這里所說的性能指標(biāo)包括CPU、MEM、DISK、NET等。在諸多資源中，肯定存在不均衡的情況，短板的資源最有可能成為業(yè)務(wù)增長(zhǎng)后的瓶頸。在具體操作上，可首先確定一個(gè)業(yè)務(wù)高峰時(shí)間段，通過監(jiān)控平臺(tái)或監(jiān)控工具收集系統(tǒng)各資源的使用情況。然后依據(jù)收集的信息，分析可能的性能短板在哪里。

對(duì)于DBA來說，對(duì)自己掌管系統(tǒng)的性能使用情況要了然于胸。通過對(duì)業(yè)務(wù)的了解，將業(yè)務(wù)指標(biāo)映射到性能指標(biāo)上，就可以很容易地推斷出現(xiàn)有系統(tǒng)可承載的大業(yè)務(wù)量。此外，對(duì)于可能影響承載業(yè)務(wù)增長(zhǎng)的短板，也會(huì)有比較清晰的認(rèn)識(shí)。

一般來說，數(shù)據(jù)庫類的應(yīng)用是重資源消耗類的應(yīng)用。對(duì)CPU、MEM、DISK、NET等，均有較大的消耗。但由于不同硬件發(fā)展水平不均衡，各數(shù)據(jù)庫資源消耗特點(diǎn)也不同，因此需要具體問題具體分析。

下面談?wù)勎覍?duì)硬件發(fā)展及與數(shù)據(jù)庫關(guān)系的一點(diǎn)個(gè)人觀點(diǎn):

• CPU

相對(duì)于其他硬件而言，CPU技術(shù)發(fā)展較快。隨著CPU主頻提高及多核CPU技術(shù)的發(fā)展，CPU提供的計(jì)算能力往往不會(huì)成為系統(tǒng)的性能瓶頸。但我們需要注意的是，有些數(shù)據(jù)庫是無法完全利用CPU的能力(例如MySQL就是這樣)。此時(shí)，為了充分利用CPU的資源，可以考慮諸如"多實(shí)例混跑"的方案，提高CPU利用率。

• MEM

隨著內(nèi)存技術(shù)的發(fā)揮，內(nèi)存的價(jià)格越來越便宜?，F(xiàn)在我們?cè)谏a(chǎn)環(huán)境中，可以見到128、256GB，甚至TB級(jí)的內(nèi)存也不罕見。一般來說，數(shù)據(jù)庫通常會(huì)利用內(nèi)存作為緩沖區(qū)，大內(nèi)存的配置對(duì)數(shù)據(jù)庫的性能有著比較明顯的提升。此外，數(shù)據(jù)庫自身技術(shù)也在適應(yīng)著大內(nèi)存的場(chǎng)景，通常采用的策略是劃分子池。將管理的單位進(jìn)一步細(xì)分，例如Oracle中的Sub Pool、MySQL中的多instance buffer pool。

• NET

隨著GigE、10GbE、InfiniBand技術(shù)的飛速發(fā)展，低延遲、高帶寬的服務(wù)品質(zhì)給數(shù)據(jù)庫乃至整個(gè)IT系統(tǒng)帶來了很多變化。常見的應(yīng)用領(lǐng)域有：

• 加速分布式數(shù)據(jù)庫，例如Oracle RAC。

• 加速大數(shù)據(jù)處理，例如提升Hadoop MapReduce處理。

• 存儲(chǔ)架構(gòu)的變革，從Scale-Up向Scale-Out演變。

• 容災(zāi)方案，主備策略…

• DISK

相對(duì)于其他硬件技術(shù)發(fā)展而言，傳統(tǒng)的機(jī)械式磁盤是相對(duì)而言發(fā)展最慢的，其往往也是最容易成為數(shù)據(jù)庫的性能瓶頸。隨著閃存技術(shù)的橫空出世，為存儲(chǔ)技術(shù)帶來的一種變革。下面我們來看看主要性能指標(biāo)的對(duì)比：

從上述指標(biāo)來看，使用閃存技術(shù)后，存儲(chǔ)能力大大提高，消除了系統(tǒng)大的瓶頸。這也是為什么很多DBA都在不同場(chǎng)合，大力推薦使用閃存，其對(duì)于數(shù)據(jù)庫性能的提升會(huì)帶來質(zhì)的飛躍。但與此同時(shí)，我們也應(yīng)該注意到，傳統(tǒng)關(guān)系型數(shù)據(jù)庫是按照磁盤IO模型設(shè)計(jì)的，沒有考慮到閃存技術(shù)，現(xiàn)在屬于軟件落后于硬件的階段；相對(duì)而言，閃存技術(shù)對(duì)于非關(guān)系型模型更有優(yōu)勢(shì)。

很多基于傳統(tǒng)設(shè)計(jì)的優(yōu)化理論發(fā)生了變化，例如: 索引聚簇因子的問題。這一點(diǎn)是需要我們?cè)诳紤]數(shù)據(jù)庫優(yōu)化時(shí)，主要注意的。此外，NoSQL的性能優(yōu)勢(shì)因?yàn)閭鹘y(tǒng)數(shù)據(jù)庫結(jié)合閃存技術(shù)，而變得不明顯。需要在架構(gòu)選擇時(shí)加以分析。

2、建立業(yè)務(wù)壓力模型

根據(jù)業(yè)務(wù)特征，建立業(yè)務(wù)壓力模型。簡(jiǎn)單理解就是將業(yè)務(wù)模擬抽象出來，便于后面進(jìn)行壓力放大測(cè)試。要做到這一步，需要對(duì)業(yè)務(wù)有著充分的了解和評(píng)估。

下面通過一個(gè)小例子說明一下:

這個(gè)表格模擬了某個(gè)類電商的業(yè)務(wù)，其包含的主要模塊及模塊中的主要操作。針對(duì)不同的操作其交易復(fù)雜度不同 （交易復(fù)雜度可理解為執(zhí)行SQL語句的個(gè)數(shù)）。根據(jù)不同的讀寫情況，區(qū)分是數(shù)據(jù)讀還是數(shù)據(jù)寫。在估算了業(yè)務(wù)總量(交易量)的情況下，很容易推算出數(shù)據(jù)操作的量。通過這種方式將業(yè)務(wù)壓力模型轉(zhuǎn)化為數(shù)據(jù)壓力模型。此處的難點(diǎn)在于對(duì)業(yè)務(wù)邏輯的抽象能力及對(duì)模塊業(yè)務(wù)量的比例評(píng)估。

有了上述概覽的表格后，針對(duì)每一種業(yè)務(wù)操作，可細(xì)化其操作。最終將其抽象成SQL語句及對(duì)應(yīng)的訪問特征。其偽代碼可描述為

可依據(jù)上述偽代碼，編制壓力測(cè)試代碼。通過一些工具調(diào)用測(cè)試代碼，產(chǎn)生模擬測(cè)試的壓力。例如我經(jīng)常使用的oradbtest/mydbtest(原阿里樓方鑫的一個(gè)測(cè)試工具)或sysbench等，都是不錯(cuò)的壓力測(cè)試工具。

建議企業(yè)根據(jù)自身情況，整理出自己的業(yè)務(wù)壓力模型。這在系統(tǒng)改造、升級(jí)、擴(kuò)容評(píng)估、新硬件選型等多種場(chǎng)合都很有用處。它要比廠商提供的類似TPCC測(cè)試報(bào)告，更有意義。據(jù)我了解，很多規(guī)模較大的公司都有比較成熟的壓力模型。

3、模擬壓力測(cè)試

要想考察現(xiàn)有數(shù)據(jù)庫能否承載增長(zhǎng)后的業(yè)務(wù)壓力，最好的方式就是模擬壓力測(cè)試。觀察在近似真實(shí)的壓力下，數(shù)據(jù)庫的表現(xiàn)。重點(diǎn)觀察，數(shù)據(jù)庫的承載力變化、主要性能瓶頸等。通常可以有兩種方式，一種是從真實(shí)環(huán)境導(dǎo)流（并可根據(jù)需要放大流量，可利用類似TCPCOPY等工具）;一種是根據(jù)前面整理的業(yè)務(wù)壓力模型，通過壓力工具模擬壓力。前者適用于已有項(xiàng)目的擴(kuò)容評(píng)估、系統(tǒng)改造評(píng)估等，后者適用于新上項(xiàng)目原型方案評(píng)估、性能基準(zhǔn)測(cè)試等場(chǎng)景。

上述模擬壓力測(cè)試結(jié)果中，暴露出的性能瓶頸點(diǎn)，就是我們后面需要著重改進(jìn)、優(yōu)化的方向。

二、優(yōu)化層次及步驟

針對(duì)上面的評(píng)估結(jié)果，來確定后面的改進(jìn)、優(yōu)化方案?？勺裱缦乱恍┎襟E：

1、分析瓶頸點(diǎn)

根據(jù)上面的評(píng)測(cè)結(jié)果，分析性能瓶頸點(diǎn)。針對(duì)不同瓶頸點(diǎn)，可采取不同的一些策略。有時(shí)候性能測(cè)試時(shí)全流程的，對(duì)于一個(gè)復(fù)雜系統(tǒng)來說，要明確定位到性能瓶頸點(diǎn)比較困難。此時(shí)，可借助一些APM工具，量化整個(gè)訪問路徑，協(xié)助找到瓶頸。也可以類似上面的做法，做好抽象工作，只對(duì)數(shù)據(jù)庫端施加壓力，觀察數(shù)據(jù)庫行為，判讀數(shù)據(jù)庫是否為瓶頸。如判斷就是數(shù)據(jù)庫的承載能力不夠，可按照不同層次進(jìn)行考慮。

在整個(gè)評(píng)估數(shù)據(jù)庫承載能力中，這一步驟是最復(fù)雜的、也是最難的一部分。要區(qū)分清楚是否是數(shù)據(jù)庫承載能力不足，還是其他組件的問題。即使明確是數(shù)據(jù)庫的問題，也要分清楚是整體or局部的問題；是單一業(yè)務(wù)功能慢，還是整體都比較慢；是偶爾會(huì)慢，還是一直都很慢等等。這些問題的界定有助于后面明確問題層次，采取不同的策略進(jìn)行解決。

針對(duì)數(shù)據(jù)庫承載能力不足，我將常見出現(xiàn)問題進(jìn)行了層次劃分，可簡(jiǎn)單分為語句級(jí)、對(duì)象級(jí)、數(shù)據(jù)庫級(jí)、數(shù)據(jù)庫架構(gòu)級(jí)、應(yīng)用架構(gòu)級(jí)、業(yè)務(wù)架構(gòu)級(jí)。不同層次采取的方式也有所不同，下面分別描述一下。

2、層次-語句級(jí)

如性能核心問題，只是某條SQL語句的問題，可有針對(duì)性地進(jìn)行優(yōu)化。這種方式是侵入性比較小的一種優(yōu)化方式，其影響范圍也比較小。下面對(duì)比常見的語句級(jí)優(yōu)化方法。說明一下，下面方法已經(jīng)排除了諸如統(tǒng)計(jì)信息不準(zhǔn)確等其他因素，僅從SQL語句本身優(yōu)化方式考慮。

• 改寫SQL

通過改寫語句，達(dá)到調(diào)整執(zhí)行計(jì)劃，提高運(yùn)行效率的目的。這種方式的缺點(diǎn)是需要研發(fā)人員修改原代碼，然后再進(jìn)行部署上線的過程。此外，有些使用O/R Mapping工具產(chǎn)生的SQL，無法直接修改語句，也無法使用此方法。

• 使用Hint

很多種數(shù)據(jù)庫都提供了提示（Hint）的功能。通過這種方式來指定語句的執(zhí)行過程。這種方式同樣需要修改源代碼，經(jīng)歷部署上線的過程。此外，這種修改方式還存在適應(yīng)性較差的問題。因?yàn)槠渲付颂赜械膱?zhí)行過程，隨著數(shù)據(jù)規(guī)模、數(shù)據(jù)特征的變化，固化的執(zhí)行過程可能不是最佳方式了。這種方式實(shí)際上是放棄了優(yōu)化器可能產(chǎn)生的最優(yōu)路徑。

• 存儲(chǔ)概要、SQL概要、計(jì)劃基線

在Oracle中還內(nèi)置了一些功能，它們可以固化某一條語句的執(zhí)行方式，從本質(zhì)上來講，其原理和上面使用Hint差不多。其缺點(diǎn)也類似上面。

• 調(diào)整參數(shù)

有時(shí)也可通過調(diào)整某些參數(shù)，進(jìn)而改變語句的執(zhí)行計(jì)劃。但是這種方式要注意適用范圍，不要在全局使用，避免影響較多的語句。在會(huì)話級(jí)使用也要控制范圍，避免產(chǎn)生較大影響。

3、層次-對(duì)象級(jí)

如性能核心問題，在SQL層面無法解決，需要考慮對(duì)象層面的調(diào)整。這種情況要比較慎重，需要充分評(píng)估可能帶來的風(fēng)險(xiǎn)及收益。一個(gè)對(duì)象的結(jié)構(gòu)修改，可以涉及到數(shù)百條、甚至數(shù)千條和此相關(guān)語句的執(zhí)行計(jì)劃變更。如不做充分測(cè)試的情況下，很難保證不出問題。如果是Oracle數(shù)據(jù)庫，可考慮使用SPA評(píng)估一下。其他數(shù)據(jù)庫的話，可提前手工收集一下相關(guān)語句，模擬修改后重放上述語句，評(píng)估性能變化。

1）影響因素

在對(duì)象級(jí)進(jìn)行調(diào)整，除了考慮對(duì)其他語句的性能影響外，還需要考慮其他因素。常見的以下這些：

• 數(shù)據(jù)庫維護(hù)成本

常見的例如索引。通過添加索引，往往可以起到加速查詢的目的；但是增加索引，會(huì)導(dǎo)致數(shù)據(jù)DML成本的增加。

• 運(yùn)維成本

常見的例如全局分區(qū)索引。全局分區(qū)索引在進(jìn)行分區(qū)維護(hù)動(dòng)作后，會(huì)導(dǎo)致索引失效，需要自動(dòng)或手動(dòng)進(jìn)行維護(hù)索引動(dòng)作。

• 存儲(chǔ)成本

常見的索引，索引結(jié)構(gòu)是數(shù)據(jù)庫中真實(shí)占據(jù)空間的結(jié)構(gòu)。在以往的一些案例中，甚至出現(xiàn)過索引總大小超過表大小的情況，因此新增時(shí)要評(píng)估其空間使用。

2）全生命周期管理

這里還有另外一個(gè)很重要的概念——“對(duì)象全生命周期管理”，簡(jiǎn)單來說就是對(duì)象的生老病死。在很多系統(tǒng)中，對(duì)象從新建開始，數(shù)據(jù)不斷增加、膨脹，當(dāng)數(shù)據(jù)規(guī)模達(dá)到一定量級(jí)后，各種性能問題就出現(xiàn)了。對(duì)一個(gè)百萬級(jí)的表和億萬級(jí)的表，其查詢性能肯定不能同日而語。因此，在對(duì)象設(shè)計(jì)初期，就要考慮相關(guān)的歸檔、清理、轉(zhuǎn)儲(chǔ)、壓縮策略，將存儲(chǔ)空間的評(píng)估與生命周期管理一起考慮。

很多性能問題，在做了數(shù)據(jù)清理后都迎刃而解。但數(shù)據(jù)清理往往是需要代價(jià)的，必須在設(shè)計(jì)之初就考慮這個(gè)問題。在做數(shù)據(jù)庫評(píng)審的時(shí)候，除了常規(guī)的結(jié)構(gòu)評(píng)審、語句評(píng)審?fù)猓惨紤]這部分因素。

4、層次-數(shù)據(jù)庫級(jí)

到了這個(gè)層面，問題往往已經(jīng)比較嚴(yán)重了。一般情況下，數(shù)據(jù)庫的初始配置都是基于其上面運(yùn)行系統(tǒng)的負(fù)載類型進(jìn)行專門配置的。如果運(yùn)行一段時(shí)間后，出現(xiàn)性能問題，經(jīng)評(píng)估是屬于全局性問題的，可以考慮進(jìn)行數(shù)據(jù)庫級(jí)別的調(diào)整。但是這種配置往往代價(jià)也比較大，例如需要專門的停機(jī)窗口操作等。而且這種操作的風(fēng)險(xiǎn)性也比較大，有可能會(huì)帶來很多不確定因素，因此要慎而又慎。

5、層次-數(shù)據(jù)庫架構(gòu)級(jí)

如性能核心問題，無法在上述層面解決，可能就需要調(diào)整數(shù)據(jù)庫架構(gòu)。常見的例如采取讀寫分離的訪問方式、分庫分表存儲(chǔ)方式等。這種對(duì)應(yīng)用的侵入性很強(qiáng)了，有些情況下甚至不亞于重構(gòu)整個(gè)系統(tǒng)。

例如，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)的數(shù)據(jù)量或訪問量超出了預(yù)期，通過單一數(shù)據(jù)庫無法滿足空間或性能要求。此時(shí)，可能就需要考慮采用一種分庫分表策略，來滿足這部分的需求。但其改造難度，往往比重新開發(fā)一套系統(tǒng)還要大。

比如，我們可能需要一個(gè)數(shù)據(jù)中間層，來屏蔽后面的分庫分表細(xì)節(jié)。這個(gè)中間層可能需要完成語句解析、訪問路由、數(shù)據(jù)聚合、事務(wù)處理等一系列功能。即使使用了中間層產(chǎn)品，對(duì)于應(yīng)用來說，數(shù)據(jù)庫的功能也會(huì)相對(duì)“弱化”，應(yīng)用級(jí)代碼不得不進(jìn)行很多的調(diào)整來適應(yīng)這種變化。此外，如何把一個(gè)線上正在運(yùn)行的系統(tǒng)，順利平穩(wěn)地遷移到新的結(jié)構(gòu)下，這無疑又是一個(gè)給飛馳的跑車換輪胎的問題等等。

如果項(xiàng)目在運(yùn)行中，出現(xiàn)了數(shù)據(jù)庫架構(gòu)級(jí)的調(diào)整，很有可能說明在前期項(xiàng)目設(shè)計(jì)規(guī)劃階段出現(xiàn)了失誤，或者對(duì)項(xiàng)目的業(yè)務(wù)預(yù)期出現(xiàn)了偏差。因此，這兩點(diǎn)一定在初始階段進(jìn)行充分的評(píng)估，并在設(shè)計(jì)上保留有充分的“彈性”。

6、層次-應(yīng)用架構(gòu)級(jí)

有些情況下，單純依靠數(shù)據(jù)庫是無法解決的，需要綜合考慮整個(gè)應(yīng)用架構(gòu)。在整個(gè)系統(tǒng)架構(gòu)中，數(shù)據(jù)庫往往處于系統(tǒng)的最末端，其擴(kuò)展性是最差的。因此，在應(yīng)用架構(gòu)設(shè)計(jì)初期，就應(yīng)該本著盡量不要對(duì)數(shù)據(jù)庫產(chǎn)生壓力的原則進(jìn)行設(shè)計(jì)。或者即使有大的壓力，系統(tǒng)可以采取自動(dòng)降級(jí)等方式保證數(shù)據(jù)庫的平穩(wěn)運(yùn)行。

常見的例如增加緩存、通過MQ實(shí)現(xiàn)削峰填谷等。通過增加緩存，可以大幅度減少對(duì)數(shù)據(jù)庫的訪問壓力，提高整體系統(tǒng)的吞吐能力。引入MQ，則可以將對(duì)數(shù)據(jù)庫的壓力以“穩(wěn)態(tài)”的形式，向數(shù)據(jù)庫持續(xù)施壓，而不至于被某個(gè)異常高峰壓死。

7、層次-業(yè)務(wù)架構(gòu)級(jí)

最后一種情況是從業(yè)務(wù)角度進(jìn)行一些調(diào)整。這往往是一種妥協(xié)，通過做適當(dāng)?shù)臏p法保證系統(tǒng)的整體運(yùn)行。甚至不排除犧牲一部分用戶體驗(yàn)等方式，來滿足大部分用戶的可用性。這就需要我們的架構(gòu)師對(duì)系統(tǒng)能提供的能力要很清楚，對(duì)業(yè)務(wù)也要有充分的了解。對(duì)于承載什么樣的業(yè)務(wù)，及為了承載業(yè)務(wù)所需要花費(fèi)的代價(jià)成本有充分的認(rèn)知，才可以做出一些取舍。

這里要避免一些誤區(qū)，認(rèn)為技術(shù)是“萬能”的。技術(shù)可以解決一定的問題，但不能解決所有問題，或者解決所有問題的成本代價(jià)是難以接受的。這個(gè)時(shí)候，從業(yè)務(wù)角度稍作調(diào)整，就可以達(dá)到“退一步海闊天空”的結(jié)果。

拓展閱讀：自制小工具大大加速M(fèi)ySQL SQL語句優(yōu)化(附源碼)

全面解析Oracle等待事件的分類、發(fā)現(xiàn)及優(yōu)化

循序漸進(jìn)解讀Oracle AWR性能分析報(bào)告

SQL優(yōu)化：一篇文章說清楚Oracle Hint的正確使用姿勢(shì)

性能優(yōu)化利器：數(shù)據(jù)庫審核平臺(tái)Themis的選型與實(shí)踐

作者：韓鋒

來源：宜信技術(shù)學(xué)院

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

當(dāng)前題目：解DBA之惑：數(shù)據(jù)庫承載能力評(píng)估及優(yōu)化手段-創(chuàng)新互聯(lián)
文章地址：http://muchs.cn/article14/cedhde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、商城網(wǎng)站、動(dòng)態(tài)網(wǎng)站、用戶體驗(yàn)、搜索引擎優(yōu)化、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)