CAP理論與MongoDB一致性、可用性的一些思考

大約在五六年前，第一次接觸到了當(dāng)時(shí)已經(jīng)是hot topic的NOSQL。不過那個(gè)時(shí)候?qū)W的用的都是MySQL，Nosql對于我而言還是新事物，并沒有真正使用，只是不明覺厲。但是印象深刻的是這么一張圖片（后來google到圖片來自這里）：

創(chuàng)新互聯(lián)建站是一家網(wǎng)站設(shè)計(jì)公司，集創(chuàng)意、互聯(lián)網(wǎng)應(yīng)用、軟件技術(shù)為一體的創(chuàng)意網(wǎng)站建設(shè)服務(wù)商，主營產(chǎn)品：響應(yīng)式網(wǎng)站設(shè)計(jì)、品牌網(wǎng)站設(shè)計(jì)、全網(wǎng)營銷推廣。我們專注企業(yè)品牌在網(wǎng)站中的整體樹立，網(wǎng)絡(luò)互動(dòng)的體驗(yàn)，以及在手機(jī)等移動(dòng)端的優(yōu)質(zhì)呈現(xiàn)。網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站、移動(dòng)互聯(lián)產(chǎn)品、網(wǎng)絡(luò)運(yùn)營、VI設(shè)計(jì)、云產(chǎn)品.運(yùn)維為核心業(yè)務(wù)。為用戶提供一站式解決方案，我們深知市場的競爭激烈，認(rèn)真對待每位客戶，為客戶提供賞析悅目的作品，網(wǎng)站的價(jià)值服務(wù)。

    這張圖片是講數(shù)據(jù)庫（包括傳統(tǒng)的關(guān)系型數(shù)據(jù)庫和NOSQL）與CAP理論的關(guān)系。由于并NoSql并沒有實(shí)踐經(jīng)驗(yàn)，也沒有去深入了解，對于CAP理論更是一知半解。因此，為什么某一款數(shù)據(jù)庫被劃分到哪一個(gè)陣營，并不清楚。

    工作之后對MongoDB使用得比較多，有了一定的了解，前段時(shí)間又看到了這張圖，于是想搞清楚，MongoDB是不是真的屬于CP陣營，又是為什么？懷疑這個(gè)問題的初衷是因?yàn)椋琈ongoDB的經(jīng)典（官方推薦）部署架構(gòu)中都會(huì)使用replica set，而replica set通過冗余和自動(dòng)failover提供高可用性（Availability），那么為什么上圖中說MongoDB犧牲了Avalability呢？而我在MongoDB的官方文檔中搜索“CAP”，并沒有搜索到任何內(nèi)容。于是我想自己搞清楚這個(gè)疑問，給自己一個(gè)答案。

本文先闡明什么是CAP理論，以及關(guān)于CAP理論的一些文章，然后討論MongoDB在一致性與可用性之間的折中與權(quán)衡。

本文地址：http://www.cnblogs.com/xybaby/p/6871764.html

 

CAP理論

回到頂部

對CAP理論我只知道這三個(gè)單詞的意思，其解釋也是來自網(wǎng)上的一些文章，并不一定準(zhǔn)確。所以首先得追根溯源，搞清楚這個(gè)理論的起源和準(zhǔn)確的解釋。我覺得最好的開始就是wikipedia，從上面可以看到比較準(zhǔn)確的介紹，更為重要的是可以看到很多有用的鏈接，比如CAP理論的出處，發(fā)展演變過程。

 

CAP理論是說對于分布式數(shù)據(jù)存儲(chǔ)，最多只能同時(shí)滿足一致性（C，Consistency）、可用性（A， Availability）、分區(qū)容錯(cuò)性（P，Partition Tolerance）中的兩者。

一致性，是指對于每一次讀操作，要么都能夠讀到最新寫入的數(shù)據(jù)，要么錯(cuò)誤。

可用性，是指對于每一次請求，都能夠得到一個(gè)及時(shí)的、非錯(cuò)的響應(yīng)，但是不保證請求的結(jié)果是基于最新寫入的數(shù)據(jù)。

分區(qū)容錯(cuò)性，是指由于節(jié)點(diǎn)之間的網(wǎng)絡(luò)問題，即使一些消息對包或者延遲，整個(gè)系統(tǒng)能繼續(xù)提供服務(wù)（提供一致性或者可用性）。

 

一致性、可用性都是使用非常寬泛的術(shù)語，在不同的語義環(huán)境下具體所指是不一樣的，比如在cap-twelve-years-later-how-the-rules-have-changed一文中Brewer就指出“CAP中的一致性與ACID中的一致性并不是同一個(gè)問題”，因此后文中除非特別說明，所提到的一致性、可用性都是指在CAP理論中的定義。只有明確了大家都是在同樣的上下文環(huán)境，討論才有意義。

    

對于分布式系統(tǒng)，網(wǎng)絡(luò)分區(qū)（network partition）這種情況是難以避免的，節(jié)點(diǎn)間的數(shù)據(jù)復(fù)制一定存在延遲，如果需要保證一致性（對所有讀請求都能夠讀到最新寫入的數(shù)據(jù)），那么勢必在一定時(shí)間內(nèi)是不可用的（不能讀取），即犧牲了可用性，反之亦然。

按照維基百科上的描述，CAP之間的相互關(guān)系大約起源于1998年，Brewer在2000年的PODC（Symposium on Principles of Distributed Computing）上展示了CAP猜想[3]，在2002年，由另外兩名科學(xué)家Seth Gilbert、Nancy Lynch證明了Brewer的猜想，從而從猜想變成了定理[4]。

CAP理論起源

在Towards Robust Distributed Systems 中，CAP理論的提出者Brewer指出：在分布式系統(tǒng)中，計(jì)算是相對容易的，真正困難的是狀態(tài)的維護(hù)。那么對于分布式存儲(chǔ)或者說數(shù)據(jù)共享系統(tǒng)，數(shù)據(jù)的一致性保證也是比較困難的。對于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，優(yōu)先考慮的是一致性而不是可用性，因此提出了事務(wù)的ACID特性。而對于許多分布式存儲(chǔ)系統(tǒng)，則是更看重可用性而不是一致性，一致性通過BASE（Basically Available, Soft state, Eventual consistency）來保證。下面這張圖展示了ACID與BASE的區(qū)別：

簡而言之：BASE通過最終一致性來盡量保證服務(wù)的可用性。注意圖中最后一句話“But I think it‘s a spectrum”，就是說ACID BASE只是一個(gè)度的問題，并不是對立的兩個(gè)極端。

2002年，在Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services中，兩位作者通過異步網(wǎng)絡(luò)模型論證了CAP猜想，從而將Brewer的猜想升級成了理論（theorem）。但實(shí)話說，我也沒有把文章讀得很明白。

2009年的這篇文章brewers-cap-theorem，作者給出了一個(gè)比較簡單的證明：

如上圖所示，N1，N2兩個(gè)節(jié)點(diǎn)存儲(chǔ)同一份數(shù)據(jù)V，當(dāng)前的狀態(tài)是V0。在節(jié)點(diǎn)N1上運(yùn)行的是安全可靠的寫算法A，在節(jié)點(diǎn)N2運(yùn)行的是同樣可靠的讀算法B，即N1節(jié)點(diǎn)負(fù)責(zé)寫操作，N2節(jié)點(diǎn)負(fù)責(zé)讀操作。N1節(jié)點(diǎn)寫入的數(shù)據(jù)也會(huì)自動(dòng)向N2同步，同步的消息稱之為M。如果N1，N2之間出現(xiàn)分區(qū)，那么就沒法保證消息M在一定的時(shí)間內(nèi)到達(dá)N2。

從事務(wù)的角度來看這各問題

 　　α這個(gè)事務(wù)由操作α1， α2組成，其中α1是寫數(shù)據(jù)，α2是讀數(shù)據(jù)。如果是單點(diǎn)，那么很容易保證α2能讀到α1寫入的數(shù)據(jù)。如果是分布式的情況的情況，除非能控制 α2的發(fā)生時(shí)間，否則無法保證 α2能讀到 α1寫入的數(shù)據(jù)，但任何的控制（比如阻塞，數(shù)據(jù)集中化等）要么破壞了分區(qū)容錯(cuò)性，要么損失了可用性。

另外，這邊文章指出很多情況下 availability比consistency重要，比如對于facebook google這樣的網(wǎng)站，短暫的不可用就會(huì)帶來巨大的損失。

2010年的這篇文章brewers-cap-theorem-on-distributed-systems/，用了三個(gè)例子來闡述CAP，分別是example1：單點(diǎn)的mysql；example2：兩個(gè)mysql，但不同的mysql存儲(chǔ)不同的數(shù)據(jù)子集（類似sharding）；example3：兩個(gè)mysql，對A的一個(gè)insert操作，需要在B上執(zhí)行成功才認(rèn)為操作完成（類似復(fù)制集）。作者認(rèn)為在example1和example2上 都能保證強(qiáng)一致性，但不能保證可用性；在example3這個(gè)例子，由于分區(qū)（partition）的存在，就需要在一致性與可用性之間權(quán)衡。

于我看來，討論CAP理論最好是在“分布式存儲(chǔ)系統(tǒng)”這個(gè)大前提下，可用性也不是說整體服務(wù)的可用性，而是分布式系統(tǒng)中某個(gè)子節(jié)點(diǎn)的可用性。因此感覺上文的例子并不是很恰當(dāng)。

CAP理論發(fā)展

 　  到了2012年，CAP理論的發(fā)明人 Brewer就CAP理論再次撰文《CAP Twelve Years Later: How the "Rules" Have Changed》，這篇文章比較長，但思路清晰，高屋建瓴，非常值得一讀。網(wǎng)上也有對用的中文譯文《CAP理論十二年回顧："規(guī)則"變了》，翻譯還不錯(cuò)。

文章中，最主要的觀點(diǎn)是CAP理論并不是說三者不需選擇兩者。首先，雖然只要是分布式系統(tǒng)，就可能存在分區(qū)，但分區(qū)出現(xiàn)的概率是很小的（否則就需要去優(yōu)化網(wǎng)絡(luò)或者硬件），CAP在大多數(shù)時(shí)候允許完美的C和A；只有在分區(qū)存在的時(shí)間段內(nèi)，才需要在C與A之間權(quán)衡。其次，一致性和可用性都是一個(gè)度的問題，不是0或者1的問題，可用性可以在0%到100%之間連續(xù)變化，一致性分為很多級別（比如在casandra，可以設(shè)置consistency level）。因此，當(dāng)代CAP實(shí)踐的目標(biāo)應(yīng)該是針對具體的應(yīng)用，在合理范圍內(nèi)最大化數(shù)據(jù)一致性和可用性的效力。

 

文章中還指出，分區(qū)是一個(gè)相對的概念，當(dāng)超過了預(yù)定的通信時(shí)限，即系統(tǒng)如果不能在時(shí)限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。

從收入目標(biāo)以及合約規(guī)定來講，系統(tǒng)可用性是首要目標(biāo)，因而我們常規(guī)會(huì)使用緩存或者事后校核更新日志來優(yōu)化系統(tǒng)的可用性。因此，當(dāng)設(shè)計(jì)師選擇可用性的時(shí)候，因?yàn)樾枰诜謪^(qū)結(jié)束后恢復(fù)被破壞的不變性約。

實(shí)踐中，大部分團(tuán)體認(rèn)為（位于單一地點(diǎn)的）數(shù)據(jù)中心內(nèi)部是沒有分區(qū)的，因此在單一數(shù)據(jù)中心之內(nèi)可以選擇CA；CAP理論出現(xiàn)之前，系統(tǒng)都默認(rèn)這樣的設(shè)計(jì)思路，包括傳統(tǒng)數(shù)據(jù)庫在內(nèi)。

分區(qū)期間，獨(dú)立且能自我保證一致性的節(jié)點(diǎn)子集合可以繼續(xù)執(zhí)行操作，只是無法保證全局范圍的不變性約束不受破壞。數(shù)據(jù)分片（sharding）就是這樣的例子，設(shè)計(jì)師預(yù)先將數(shù)據(jù)劃分到不同的分區(qū)節(jié)點(diǎn)，分區(qū)期間單個(gè)數(shù)據(jù)分片多半可以繼續(xù)操作。相反，如果被分區(qū)的是內(nèi)在關(guān)系密切的狀態(tài)，或者有某些全局性的不變性約束非保持不可，那么最好的情況是只有分區(qū)一側(cè)可以進(jìn)行操作，最壞情況是操作完全不能進(jìn)行。

上面摘錄中下選線部分跟MongoDB的sharding情況就很相似，MongoDB的sharded cluste模式下，shard之間在正常情況下，是無需相互通信的。

 

在13年的文章中《better-explaining-cap-theorem》，作者指出“it is really just A vs C！”，因?yàn)?/p>

（1）可用性一般是在不同的機(jī)器之間通過數(shù)據(jù)的復(fù)制來實(shí)現(xiàn)

（2）一致性需要在允許讀操作之間同時(shí)更新幾個(gè)節(jié)點(diǎn)

（3）temporary partion，即幾點(diǎn)之間的通信延遲是可能發(fā)生了，此時(shí)就需要在A 和 C之間權(quán)衡。但只有在發(fā)生分區(qū)的時(shí)候才需要考慮權(quán)衡。

在分布式系統(tǒng)中，網(wǎng)絡(luò)分區(qū)一定會(huì)發(fā)生，因此“it is really just A vs C！”

 

MongoDB與CAP

回到頂部

在《通過一步步創(chuàng)建sharded cluster來認(rèn)識(shí)MongoDB》一文中，對MongoDB的特性做了一些介紹，包括高性能、高可用、可擴(kuò)展（水平伸縮），其中，MongoDB的高可用性依賴于replica set的復(fù)制與自動(dòng)failover。對MongoDB數(shù)據(jù)庫的使用有三種模式：standalone，replica set， shareded cluster，在前文中詳細(xì)介紹了shared cluster的搭建過程。

standalone就是單個(gè)mongod，應(yīng)用程序直接連接到這個(gè)Mongod，在這種情況下無分區(qū)容錯(cuò)性可言，也一定是強(qiáng)一致性的。對于sharded cluster，每一個(gè)shard也都推薦是一個(gè)replica set。MongoDB中的shards維護(hù)的是獨(dú)立的數(shù)據(jù)子集，因此shards之間出現(xiàn)了分區(qū)影響不大（在chunk遷移的過程可能還是有影響），因此也主要考慮的是shard內(nèi)部replica set的分區(qū)影響。所以，本文中討論MongoDB的一致性、可用性問題，針對的也是MongoDB的replica set。

對于replica set，只有一個(gè)primary節(jié)點(diǎn)，接受寫請求和讀請求，其他的secondary節(jié)點(diǎn)接受讀請求。這是一個(gè)單寫、多讀的情況，比多讀、多寫的情況還是簡化了許多。后文為了討論，也是假設(shè)replica set由三個(gè)基點(diǎn)組成，一個(gè)primary，兩個(gè)secondary，且所有節(jié)點(diǎn)都持久化數(shù)據(jù)（data-bearing）

MongoDB關(guān)于一致性、可用性的權(quán)衡，取決于三者：write-concern、read-concern、read-preference。下面主要是MongoDB3.2版本的情況，因?yàn)閞ead-concern是在MongoDB3.2版本中才引入的。

 

write-concern：

write concern表示對于寫操作，MongoDB在什么情況下給予客戶端響應(yīng)。包括下面三個(gè)字段：

{ w: <value>, j: <boolean>, wtimeout: <number> }

w: 表示當(dāng)寫請求在value個(gè)MongoDB實(shí)例處理之后才向客戶端返回。取值范圍：

1：默認(rèn)值，表示數(shù)據(jù)寫入到standalone的MongoDB或者replica set的primary之后返回

0：不用寫入就直接向客戶端返回，性能高，但可能丟數(shù)據(jù)。不過可以配合j：True來增加數(shù)據(jù)的可持久性（durability）

>1: 只有在replica set環(huán)境下才有用，如果value大于的replica set中節(jié)點(diǎn)的數(shù)目，那么可能導(dǎo)致阻塞

‘majority’： 當(dāng)數(shù)據(jù)寫入到replica set的大多數(shù)節(jié)點(diǎn)之后向客戶端返回，對于這種情況，一般是配合read-concern使用：

　　　　After the write operation returns with a w: "majority" acknowledgement to the client, the client can read the result of that write with a "majority" readConcern

j：表示當(dāng)寫請求在寫入journal之后才向客戶端返回，默認(rèn)為False。兩點(diǎn)注意：

如果在對于未開啟journaling的MongoDB實(shí)例使用j:True，會(huì)報(bào)錯(cuò)

在MongoDB3.2及之后，對于w>1, 需要所有實(shí)例都寫到j(luò)ournal之后才返回

wtimeout：表示寫入的超時(shí)時(shí)間，即在指定的時(shí)間（number），如果還不能向客戶端返回（w大于1的情況），那么返回錯(cuò)誤

默認(rèn)為0，相當(dāng)于沒有設(shè)置該選項(xiàng)

 

在MongoDB3.4中，加入了writeConcernMajorityJournalDefault.這么一個(gè)選項(xiàng)，使得w，j在不同的組合下情況下不同:

read-reference:

在前文已經(jīng)講解過，一個(gè)replica set由一個(gè)primary和多個(gè)secondary組成。primary接受寫操作，因此數(shù)據(jù)一定是最新的，secondary通過oplog來同步寫操作，因此數(shù)據(jù)有一定的延遲。對于時(shí)效性不是很敏感的查詢業(yè)務(wù)，可以從secondary節(jié)點(diǎn)查詢，以減輕集群的壓力。

 

MongoDB指出在不同的情況下選用不同的read-reference，非常靈活。MongoDB driver支持一下幾種read-reference：

primary：默認(rèn)模式，一切讀操作都路由到replica set的primary節(jié)點(diǎn)

primaryPreferred：正常情況下都是路由到primary節(jié)點(diǎn)，只有當(dāng)primary節(jié)點(diǎn)不可用（failover）的時(shí)候，才路由到secondary節(jié)點(diǎn)。

secondary：一切讀操作都路由到replica set的secondary節(jié)點(diǎn)

secondaryPreferred：正常情況下都是路由到secondary節(jié)點(diǎn)，只有當(dāng)secondary節(jié)點(diǎn)不可用的時(shí)候，才路由到primary節(jié)點(diǎn)。

nearest：從延時(shí)最小的節(jié)點(diǎn)讀取數(shù)據(jù)，不管是primary還是secondary。對于分布式應(yīng)用且MongoDB是多數(shù)據(jù)中心部署，nearest能保證最好的data locality。

 

如果使用secondary或者secondaryPreferred，那么需要意識(shí)到：

(1) 因?yàn)檠訒r(shí)，讀取到的數(shù)據(jù)可能不是最新的，而且不同的secondary返回的數(shù)據(jù)還可能不一樣；

(2) 對于默認(rèn)開啟了balancer的sharded collection，由于還未結(jié)束或者異常終止的chunk遷移，secondary返回的可能是有缺失或者多余的數(shù)據(jù)

(3) 在有多個(gè)secondary節(jié)點(diǎn)的情況下，選擇哪一個(gè)secondary節(jié)點(diǎn)呢，簡單來說是“closest”即平均延時(shí)最小的節(jié)點(diǎn)，具體參加Server Selection Algorithm 

 

read-concern:

read concern是在MongoDB3.2中才加入的新特性，表示對于replica set（包括sharded cluster中使用復(fù)制集的shard）返回什么樣的數(shù)據(jù)。不同的存儲(chǔ)引擎對read-concern的支持情況也是不一樣的

read concern有以下三個(gè)level：

local：默認(rèn)值，返回當(dāng)前節(jié)點(diǎn)的最新數(shù)據(jù)，當(dāng)前節(jié)點(diǎn)取決于read reference。

majority：返回的是已經(jīng)被確認(rèn)寫入到多數(shù)節(jié)點(diǎn)的最新數(shù)據(jù)。該選項(xiàng)的使用需要以下條件： WiredTiger存儲(chǔ)引擎，且使用election protocol version 1；啟動(dòng)MongoDB實(shí)例的時(shí)候指定 --enableMajorityReadConcern選項(xiàng)。

linearizable：3.4版本中引入，這里略過了，感興趣的讀者參考文檔。

 

在文章中有這么一句話：

Regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.

就是說，即便使用了read concern：majority， 返回的也不一定是最新的數(shù)據(jù)，這個(gè)和NWR理論并不是一回事。究其根本原因，在于最終返回的數(shù)值只來源于一個(gè)MongoDB節(jié)點(diǎn)，該節(jié)點(diǎn)的選擇取決于read reference。

在這篇文章中，對readconcern的引入的意義以及實(shí)現(xiàn)有詳細(xì)介紹，在這里只引用核心部分：

readConcern 的初衷在于解決『臟讀』的問題，比如用戶從 MongoDB 的 primary 上讀取了某一條數(shù)據(jù)，但這條數(shù)據(jù)并沒有同步到大多數(shù)節(jié)點(diǎn)，然后 primary 就故障了，重新恢復(fù)后 這個(gè)primary 節(jié)點(diǎn)會(huì)將未同步到大多數(shù)節(jié)點(diǎn)的數(shù)據(jù)回滾掉，導(dǎo)致用戶讀到了『臟數(shù)據(jù)』。

當(dāng)指定 readConcern 級別為 majority 時(shí)，能保證用戶讀到的數(shù)據(jù)『已經(jīng)寫入到大多數(shù)節(jié)點(diǎn)』，而這樣的數(shù)據(jù)肯定不會(huì)發(fā)生回滾，避免了臟讀的問題。

 一致性 or 可用性？

回顧一下CAP理論中對一致性 可用性的問題：
　　一致性，是指對于每一次讀操作，要么都能夠讀到最新寫入的數(shù)據(jù)，要么錯(cuò)誤。
　　可用性，是指對于每一次請求，都能夠得到一個(gè)及時(shí)的、非錯(cuò)的響應(yīng)，但是不保證請求的結(jié)果是基于最新寫入的數(shù)據(jù)。

　　前面也提到，本文對一致性 可用性的討論是基于replica set的，是否是shared cluster并不影響。另外，討論是基于單個(gè)客戶端的情況，如果是多個(gè)客戶端，似乎是隔離性的問題，不屬于CAP理論范疇。基于對write concern、read concern、read reference的理解，我們可以得出以下結(jié)論。

• 默認(rèn)情況（w：1、readconcern：local）如果read preference為primary，那么是可以讀到最新的數(shù)據(jù)，強(qiáng)一致性；但如果此時(shí)primary故障，那么這個(gè)時(shí)候會(huì)返回錯(cuò)誤，可用性得不到保證

• 默認(rèn)情況（w：1、readconcern：local）如果read preference為secondary（secondaryPreferred、primaryPreferred），雖然可能讀到過時(shí)的數(shù)據(jù)，但能夠立刻得到數(shù)據(jù)，可用性比較好

• writeconern：majority保證寫入的數(shù)據(jù)不會(huì)被回滾; readconcern：majority保證讀到的一定是不會(huì)被回滾的數(shù)據(jù)

• 若（w：1、readconcern；majority）即使是從primary讀取，也不能保證一定返回最新的數(shù)據(jù)，因此是弱一致性

• 若（w: majority、readcocern：majority），如果是從primary讀取，那么一定能讀到最新的數(shù)據(jù)，且這個(gè)數(shù)據(jù)一定不會(huì)被回滾，但此時(shí)寫可用性就差一些；如果是從secondary讀取，不能保證讀到最新的數(shù)據(jù)，弱一致性。

　　回過來來看，MongoDB所說的高可用性是更普世意義上的可用性：通過數(shù)據(jù)的復(fù)制和自動(dòng)failover，即使發(fā)生物理故障，整個(gè)集群還是能夠在短時(shí)間內(nèi)回復(fù)，繼續(xù)工作，何況恢復(fù)也是自動(dòng)的。在這個(gè)意義上，確實(shí)是高可用的。

網(wǎng)頁標(biāo)題：CAP理論與MongoDB一致性、可用性的一些思考
標(biāo)題鏈接：http://m.kartarina.com/article44/pphcee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、小程序開發(fā)、用戶體驗(yàn)、App開發(fā)、建站公司、外貿(mào)網(wǎng)站建設(shè)

廣告

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