區(qū)塊鏈快速入門（二）——分布式系統(tǒng)核心技術(shù)

一、分布式系統(tǒng)的一致性問題

1、分布式系統(tǒng)的一致性問題

隨著摩爾定律碰到瓶頸，越來越多情況下要依靠可擴展的分布式架構(gòu)來實現(xiàn)海量處理能力。單點結(jié)構(gòu)演變到分布式結(jié)構(gòu)，首要解決的問題就是數(shù)據(jù)的一致性。如果分布式集群中多個節(jié)點不能保證處理結(jié)果的一致性，建立在其上的業(yè)務系統(tǒng)將無法正常工作。區(qū)塊鏈系統(tǒng)是一個典型的分布式系統(tǒng)，在設(shè)計上必然也要考慮一致性問題。
在面向大規(guī)模復雜任務場景時，單點的服務往往難以解決可擴展(Scalability)和容錯(Fault-tolerance)兩方面的需求，就需要多臺服務器來組成集群系統(tǒng)，虛擬為更加強大和穩(wěn)定的“超級服務器”。
集群的規(guī)模越大，處理能力越強，管理的復雜度也就越高。目前在運行的大規(guī)模集群包括谷歌公司的搜索系統(tǒng)，通過數(shù)十萬臺服務器支持了對整個互聯(lián)網(wǎng)內(nèi)容的搜索服務。
通常情況下，集群系統(tǒng)中的不同節(jié)點可能處于不同的狀態(tài)，隨時收到不同的請求，要時刻保持對外響應的一致性。
一致性(Consistency)在分布式系統(tǒng)領(lǐng)域中是指對于多個服務節(jié)點，給定一系列操作，在約定協(xié)議的保障下使得多個節(jié)點對處理結(jié)果達成某種程度的協(xié)同。
理想情況(不考慮節(jié)點故障)下，如果各個服務節(jié)點嚴格遵循相同的處理協(xié)議(即構(gòu)成相同的狀態(tài)機邏輯)，則在給定相同的初始狀態(tài)和輸入序列時，可以確保處理過程中的每個步驟的執(zhí)行結(jié)果都相同。因此，傳統(tǒng)分布式系統(tǒng)中討論一致性，通常是指在外部任意發(fā)起請求(如向多個節(jié)點發(fā)送不同請求)的情況下，確保系統(tǒng)內(nèi)大部分節(jié)點實際處理請求序列的一致，即對請求進行全局排序。
一致性關(guān)注的是系統(tǒng)呈現(xiàn)的狀態(tài)，并不關(guān)注結(jié)果是否正確；例如，所有節(jié)點都對某請求達成否定狀態(tài)也是一種一致性。

成都創(chuàng)新互聯(lián)公司是一家專注于成都網(wǎng)站設(shè)計、網(wǎng)站制作與策劃設(shè)計,滎陽網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設(shè)十余年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務涵蓋:滎陽等地區(qū)。滎陽做網(wǎng)站價格咨詢:18982081108

2、分布式系統(tǒng)的挑戰(zhàn)

典型的分布式系統(tǒng)中存在如下挑戰(zhàn)：
A、節(jié)點之間只能通過消息來交互和同步，而網(wǎng)絡(luò)通訊是不可靠的，可能出現(xiàn)任意消息延遲、亂序和錯誤。
B、節(jié)點處理請求的時間無法保障，處理的結(jié)果可能是錯誤的，甚至節(jié)點自身隨時可能發(fā)生故障。
C、為了避免沖突，采用同步調(diào)用可以簡化設(shè)計，但會嚴重降低系統(tǒng)的可擴展性，甚至使其退化為單點系統(tǒng)。

3、分布式系統(tǒng)一致性的要求

分布式系統(tǒng)達成一致的過程應該滿足如下要求:
A、可終止性(Termination)
一致的結(jié)果在有限時間內(nèi)能完成。
B、約同性(Agreement)
不同節(jié)點最終完成決策的結(jié)果是相同的。為了確保協(xié)同性，分布式系統(tǒng)通常會把不同時空發(fā)生的多個事件進行全局唯一排序，并且順序必須是所有節(jié)點認可的。
C、合法性(Validity)
決策的結(jié)果必須是某個節(jié)點提出的提案。

4、分布式系統(tǒng)帶約束的一致性

要實現(xiàn)絕對理想的嚴格一致性(Strict Consistency)代價很大。除非系統(tǒng)不發(fā)生任何故障，并且所有節(jié)點之間的通信無需任何時間，此時整個系統(tǒng)其實就等價于單點系統(tǒng)。實際上，越強的一致性要求往往意味著帶來越弱的處理性能，以及越差的可擴展性。根據(jù)實際需求的不用，可以選擇不同強度的一致性，包括強一致性(Strong Consistency)和弱一致性(Weak Consistency)。
強一致性包括兩類：
A、順序一致性
順序一致性(Sequential Consistency):Leslie Lamport1979年經(jīng)典論文《How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs》中提出，是一種比較強的約束，保證所有進程看到的全局執(zhí)行順序(total order)一致，并且每個進程看自身的執(zhí)行順序(local order)跟實際發(fā)生順序一致。例如，某進程先執(zhí)行A，后執(zhí)行 B，則實際得到的全局結(jié)果中就應該為A在B前面，而不能反過來。同時所有其它進程在全局上也應該看到這個順序。順序一致性實際上限制了各進程內(nèi)指令的偏序關(guān)系，但不在進程間按照物理時間進行全局排序。
B、線性一致性
線性一致性(Linearizability Consistency):Maurice P. Herlihy與Jeannette M.Wing在1990年經(jīng)典論文《Linearizability: A Correctness Condition for Concurrent Objects》中共同提出，在順序一致性前提下加強了進程間的操作排序，形成唯一的全局順序(系統(tǒng)等價于是順序執(zhí)行，所有進程看到的所有操作的序列順序都一致，并且跟實際發(fā)生順序一致)，是很強的原子性保證。但比較難實現(xiàn)，目前基本上要么依賴于全局的時鐘或鎖，要么通過一些復雜算法實現(xiàn)，性能通常不高。
實現(xiàn)強一致性往往需要準確的計時設(shè)備。高精度的石英鐘的漂移率為10^-7,最準確的原子震蕩時鐘的漂移率為10^-13。Google曾在其分布式數(shù)據(jù)庫Spanner 中采用基于原子時鐘和GPS的TrueTime方案，能夠?qū)⒉煌瑪?shù)據(jù)中心的時間偏差控制在10ms以內(nèi)。在不考慮成本的前提下，TrueTime方案簡單、粗暴,但有效。
強一致的系統(tǒng)往往比較難實現(xiàn)，而且很多場景下對一致性的需求并沒有那么強。因此，可以適當放寬對一致性的要求，降低系統(tǒng)實現(xiàn)的難度。例如在一定約束下實現(xiàn)所謂最終一致性(Eventual Consistency)，即總會存在一個時刻(而不是立刻)，讓系統(tǒng)達到一致的狀態(tài)。
例如電商購物時將某物品放入購物車，但可能在最終付款時才提示物品已經(jīng)售罄。實際上，大部分的Web 系統(tǒng)為了保持服務的穩(wěn)定，實現(xiàn)的都是最終一致性。
弱一致性相對于強一致性，是在某些方面弱化的一致性，如最終一致性。

二、分布式共識算法簡介

1、分布式共識簡介

共識(Consensus)通常會與一致性(Consistency)術(shù)語放在一起討論。嚴謹?shù)刂v，兩者的含義并不完全相同。
一致性的含義比共識寬泛，在不同場景(基于事務的數(shù)據(jù)庫、分布式系統(tǒng)等)下意義不同。具體到分布式系統(tǒng)場景下，一致性指的是多個副本對外呈現(xiàn)的狀態(tài)。如順序一致性、線性一致性，描述了多節(jié)點對數(shù)據(jù)狀態(tài)的共同維護能力。而共識，則特指在分布式系統(tǒng)中多個節(jié)點之間對某個事情(例如多個事務請求的執(zhí)行順序)達成一致看法的過程。因此，達成某種共識并不意味著就保障了一致性。
實踐中，要保障系統(tǒng)滿足不同程度的一致性，往往需要通過共識算法來達成。
共識算法解決的是分布式系統(tǒng)中大部分節(jié)點對某個提案(Proposal)達成一致意見的過程。提案的含義在分布式系統(tǒng)中十分寬泛，如多個事件發(fā)生的順序、某個鍵對應的值等等。任何可以達成一致的信息都是一個提案。對于分布式系統(tǒng)，各個節(jié)點通常都是相同的確定性狀態(tài)機模型(又稱為狀態(tài)機復制問題，State-Machine Replication)，從相同初始狀態(tài)開始接收相同順序的指令，則可以保證相同的結(jié)果狀態(tài)。因此，分布式系統(tǒng)中多個節(jié)點達成共識的關(guān)鍵是對多個事件的順序進行共識，即排序。

2、分布式共識的挑戰(zhàn)

分布式系統(tǒng)達成共識都要解決兩個基本的問題:
A、如何提出一個待共識的提案，如通過令牌傳遞、隨機選取、權(quán)重比較、求解難題等。
B、如何讓多個節(jié)點對提案達成共識(同意或拒絕)，如投票、規(guī)則驗證等。
在實際應用的分布式系統(tǒng)中，不同節(jié)點之間通信存在延遲(光速物理限制、通信處理延遲)，并且任意環(huán)節(jié)都可能存在故障(系統(tǒng)規(guī)模越大，發(fā)生故障可能性越高)。如通信網(wǎng)絡(luò)會發(fā)生中斷、節(jié)點會發(fā)生故障、甚至存在被***的節(jié)點故意偽造消息，破壞正常的共識過程。
通常，把出現(xiàn)故障(Crash或Fail-stop，即不響應)但不會偽造信息的情況稱為“非拜占庭錯誤(Non-Byzantine Fault)”或“故障錯誤(Crash Fault)”；偽造信息惡意響應的情況稱為“拜占庭錯誤”(Byzantine Fault)，對應節(jié)點為拜占庭節(jié)點。拜占庭錯誤場景中因為存在搗亂者更難達成共識。

3、常見分布式共識算法

根據(jù)解決的場景是否允許拜占庭錯誤情況，共識算法可以分為CFT(CrashFault Tolerance)和BFT(Byzantine Fault Tolerance)兩類。
對于非拜占庭錯誤的情況，經(jīng)典的共識算法包括Paxos(1990年)、Raft(2014年)及其變種等。CFT類容錯算法通常性能比較好，處理較快，容忍不超過一半的故障節(jié)點。
對于要能容忍拜占庭錯誤的情況，包括PBFT(Practical Byzantine Fault Tolerance，1999年)為代表的確定性系列算法、PoW(1997年)為代表的概率算法等。確定性算法一旦達成共識就不可逆轉(zhuǎn)，即共識是最終結(jié)果；而概率類算法的共識結(jié)果則是臨時的，隨著時間推移或某種強化，共識結(jié)果被推翻的概率越來越小，最終成為事實上結(jié)果。拜占庭類容錯算法通常性能較差，容忍不超過1/3的故障節(jié)點。
此外，XFT(Cross Fault Tolerance，2015年)等最近提出的改進算法可以提供類似CFT的處理響應速度，并能在大多數(shù)節(jié)點正常工作時提供BFT保障。
Algorand算法(2017年)基于PBFT進行改進，通過引入可驗證隨機函數(shù)解決了提案選擇的問題，理論上可以在容忍拜占庭錯誤的前提下實現(xiàn)更好的性能(1000+TPS)。
實踐中，通常客戶端要拿到共識結(jié)果需要自行驗證，典型地，可以訪問足夠多個服務節(jié)點來比對結(jié)果，確保獲取結(jié)果的準確性。

三、FLP不可能原理

1、FLP原理簡介

FLP不可能原理:在網(wǎng)絡(luò)可靠，但允許節(jié)點失效(即便只有一個)的最小化異步模型系統(tǒng)中，不存在一個可以解決一致性問題的確定性共識算法。
FLP不可能原理在1985年由Fischer，Lynch和Patterson三位科學家在《Impossibility of Distributed Consensus with One Faulty Process》論文中提出并證明。
FLP不可能原理表明，不要浪費時間，去試圖為異步分布式系統(tǒng)設(shè)計面向任意場景的共識算法。

2、分布式系統(tǒng)的同步與異步

分布式系統(tǒng)中同步和異步的定義如下：
同步是指系統(tǒng)中的各個節(jié)點的時鐘誤差存在上限，并且消息傳遞必須在一定時間內(nèi)完成，否則認為失??；同時各個節(jié)點完成處理消息的時間是一定的。因此同步系統(tǒng)中可以很容易地判斷消息是否丟失。
異步是指系統(tǒng)中各個節(jié)點可能存在較大的時鐘差異，同時消息傳輸時間是任意長的；各節(jié)點對消息進行處理的時間也可能是任意長的。因此，無法判斷某個消息遲遲沒有被響應的原因(節(jié)點故障或傳輸故障)。
現(xiàn)實生活中的分布式系統(tǒng)通常都是異步系統(tǒng)。

3、FLP原理的意義

FLP不可能原理實際上說明對于允許節(jié)點失效情況下，純粹異步系統(tǒng)無法確保共識在有限時間內(nèi)完成。即便對于非拜占庭錯誤的前提下，包括Paxos、Raft等算法也都存在無法達成共識的極端情況，只是在工程實踐中出現(xiàn)的概率很小。
FLP不可能原理并不意味著研究共識算法沒有意義。學術(shù)研究通?？紤]地是數(shù)學和物理意義上理想化的情形，很多時候現(xiàn)實世界要穩(wěn)定得多；工程實現(xiàn)上某次共識失敗，再嘗試幾次，很大可能就成功。

四、CAP原理

1、CAP原理簡介

CAP原理最早出現(xiàn)在2000年，由加州大學伯克利分校的Eric Brewer教授在ACM組織的Principles of Distributed Computing(PODC)研討會上提出猜想，后來麻省理工學院的Nancy Lynch等學者進行了理論證明。
CAP原理被認為是分布式系統(tǒng)領(lǐng)域的重要原理之一，深刻影響了分布式計算與系統(tǒng)設(shè)計的發(fā)展。
CAP原理:分布式系統(tǒng)無法同時確保一致性(Consistency)、可用性(Availability)和分區(qū)容忍性(Partition)，設(shè)計中往往需要弱化對某個特性的需求。
一致性(Consistency):任何事務應該都是原子的，所有副本上的狀態(tài)都是事務成功提交后的結(jié)果，并保持強一致。
可用性(Availability):系統(tǒng)(非失敗節(jié)點)能在有限時間內(nèi)完成對操作請求的應答。
分區(qū)容忍性(Partition):系統(tǒng)中的網(wǎng)絡(luò)可能發(fā)生分區(qū)故障(成為多個子網(wǎng)，甚至出現(xiàn)節(jié)點上線和下線)，即節(jié)點之間的通信無法保障。而網(wǎng)絡(luò)故障不應該影響到系統(tǒng)正常服務。
CAP原理認為，分布式系統(tǒng)最多只能保證三項特性中的兩項特性。當網(wǎng)絡(luò)可能出現(xiàn)分區(qū)時，系統(tǒng)是無法同時保證一致性和可用性的。要么，節(jié)點收到請求后因為沒有得到其它節(jié)點的確認而不應答(犧牲可用性)，要么節(jié)點只能應答非一致的結(jié)果(犧牲一致性)。
由于大部分時候網(wǎng)絡(luò)被認為是可靠的，因此系統(tǒng)可以提供一致可靠的服務；當網(wǎng)絡(luò)不可靠時，系統(tǒng)要么犧牲掉一致性(多數(shù)場景下)，要么犧牲掉可用性。
網(wǎng)絡(luò)分區(qū)是可能存在的，出現(xiàn)分區(qū)情況后很可能會導致發(fā)生腦裂，多個新出現(xiàn)的主節(jié)點可能會嘗試關(guān)閉其它主節(jié)點。

2、CAP原理應用場景

CAP三種特性不可同時得到保障，因此設(shè)計系統(tǒng)時候必然要弱化對某個特性的支持。根據(jù)CAP原理可以定義三種應用場景：
A、弱化一致性
對結(jié)果一致性不敏感的應用，可以允許在新版本上線后過一段時間才最終更新成功，期間不保證一致性。例如網(wǎng)站靜態(tài)頁面內(nèi)容、實時性較弱的查詢類數(shù)據(jù)庫等，簡單分布式同步協(xié)議如Gossip，以及CouchDB、Cassandra數(shù)據(jù)庫等都弱化了一致性。
B、弱化可用性
對結(jié)果一致性很敏感的應用，例如銀行取款機，當系統(tǒng)故障時候會拒絕服務。MongoDB、redis、MapReduce等都弱化了可用性。
Paxos、Raft等共識算法主要處理對于一致性敏感的情況。在Paxos類算法中，可能存在著無法提供可用結(jié)果的情形，同時允許少數(shù)節(jié)點離線。
C、弱化分區(qū)容忍性
現(xiàn)實中，網(wǎng)絡(luò)分區(qū)出現(xiàn)概率較小，但很難完全避免。
兩階段的提交算法，某些關(guān)系型數(shù)據(jù)庫以及ZooKeeper 主要考慮了這種設(shè)計。
實踐中，網(wǎng)絡(luò)可以通過雙通道等機制增強可靠性，實現(xiàn)高穩(wěn)定的網(wǎng)絡(luò)通信。

五、ACID原則與多階段提交

1、ACID原則簡介

ACID，即Atomicity(原子性)、Consistency(一致性)、Isolation(隔離性)、
Durability(持久性)四種特性的縮寫。
ACID 是一種比較出名的描述一致性的原則，通常出現(xiàn)在分布式數(shù)據(jù)庫等基于事務過程的系統(tǒng)中。
ACID 原則描述了分布式數(shù)據(jù)庫需要滿足的一致性需，同時允許付出可用性的代價。
Atomicity:每次事務是原子的，事務包含的所有操作要么全部成功，要么全部不執(zhí)行。一旦有操作失敗，則需要回退狀態(tài)到執(zhí)行事務前。
Consistency:數(shù)據(jù)庫的狀態(tài)在事務執(zhí)行前后的狀態(tài)是一致的和完整的，無中間狀態(tài)。即只能處于成功事務提交后的狀態(tài)。
Isolation:各種事務可以并發(fā)執(zhí)行，但彼此之間互相不影響。按照標準SQL規(guī)范，從弱到強可以分為未授權(quán)讀取、授權(quán)讀取、可重復讀取和串行化四種隔離等級。
Durability:狀態(tài)的改變是持久的，不會失效。一旦某個事務提交，則它造成的狀態(tài)變更就是永久性的。
與ACID 相對的一個原則是eBay技術(shù)專家Dan Pritchett 提出的BASE(Basic Availability，Soft-state，Eventual Consistency)原則。BASE原則面向大型高可用分布式系統(tǒng)，主張犧牲掉對強一致性的追求，而實現(xiàn)最終一致性，來換取一定的可用性。
ACID和BASE兩種原則實際是對 CAP原理三種特性的不同取舍。
對于分布式事務一致性的研究成果包括著名的兩階段提交算法(Two-phaseCommit,2PC)和三階段提交算法(Three-phase Commit,3PC)。

2、兩階段提交算法

兩階段提交算法最早由Jim Gray于1979年在論文《Notes on Database Operating Systems》中提出。其基本思想十分簡單，既然在分布式場景下，直接提交事務可能出現(xiàn)各種故障和沖突，那么可將其分解為預提交和正式提交兩個階段，規(guī)避沖突的風險。
預提交:協(xié)調(diào)者(Coordinator)發(fā)起提交某個事務的申請，各參與執(zhí)行者
(Participant)需要嘗試進行提交并反饋是否能完成。
正式提交:協(xié)調(diào)者如果得到所有執(zhí)行者的成功答復，則發(fā)出正式提交請求。如果成功完成，則算法執(zhí)行成功。
在此過程中任何步驟出現(xiàn)問題(例如預提交階段有執(zhí)行者回復預計無法完成提交)，則需要回退。
兩階段提交算法因為簡單容易實現(xiàn)的優(yōu)點，在關(guān)系型數(shù)據(jù)庫等系統(tǒng)中被廣泛應用。兩階段提交算法的缺點是整個過程需要同步阻塞導致性能通常較差；同時存在單點問題，較壞情況下可能一直無法完成提交；可能產(chǎn)生數(shù)據(jù)不一致的情況(例如協(xié)調(diào)者和執(zhí)行者在第二個階段出現(xiàn)故障)。

3、三階段提交算法

三階段提交針對兩階段提交算法第一階段中可能阻塞部分執(zhí)行者的情況進行了優(yōu)化，即將預提交階段進一步拆成兩個步驟:嘗試預提交和預提交。
完整過程如下:
嘗試預提交:協(xié)調(diào)者詢問執(zhí)行者是否能進行某個事務的提交。執(zhí)行者需要返回答復，但無需執(zhí)行提交，可以避免出現(xiàn)部分執(zhí)行者被無效阻塞住的情況。
預提交:協(xié)調(diào)者檢查收集到的答復，如果全部為，,則發(fā)起提交事務請求。各參與執(zhí)行者(Participant)需要嘗試進行提交并反饋是否能完成。
正式提交:協(xié)調(diào)者如果得到所有執(zhí)行者的成功答復，則發(fā)出正式提交請求。如果成功完成，則算法執(zhí)行成功。
無論兩階段提交還是三階段提交，都只是一定程度上緩解了提交沖突的問題，并無法一定保證系統(tǒng)的一致性。多階段提交首個有效算法是Paxos算法。

六、可靠性指標

1、可靠性指標簡介

可靠性(Availability，可用性)是描述系統(tǒng)可以提供服務能力的重要指標。高可靠的分布式系統(tǒng)通常需要各種復雜的機制來進行保障。
通常情況下，服務的可用性可以用服務承諾(Service Level Agreement,SLA)、服務指標(Service Level Indicator,SLI)、服務目標(Service Level Objective,SLO)等方面進行衡量。每年允許服務出現(xiàn)不可用時間的可靠性指標參考值如下：

通常，單點的服務器系統(tǒng)至少應能滿足兩個9；普通企業(yè)信息系統(tǒng)三個9就足夠；系統(tǒng)能達到四個9已經(jīng)是領(lǐng)先水平(參考AWS等云計算平臺)；電信級的應用一般需要能達到五個9，一年里面最多允許出現(xiàn)五分鐘左右的服務不可用；六個9以及以上的系統(tǒng)較為少見，要實現(xiàn)往往意味著極高的代價。

2、兩個核心時間

一般地，描述系統(tǒng)出現(xiàn)故障的可能性和故障出現(xiàn)后的恢復能力，有兩個基礎(chǔ)的指標:MTBF和 MTTR。
MTBF（Mean Time Between Failures），即平均故障間隔時間，是系統(tǒng)可以無故障運行的預期時間。
MTTR（Mean Time To Repair），即平均修復時間，是發(fā)生故障后系統(tǒng)可以恢復到正常運行的預期時間。
MTBF衡量了系統(tǒng)發(fā)生故障的頻率，如果一個系統(tǒng)的MTBF很短，則意味著系統(tǒng)可用性低；而MTTR則反映了系統(tǒng)碰到故障后服務的恢復能力，如果系統(tǒng)的 MTTR 過長，則說明系統(tǒng)一旦發(fā)生故障需要較長時間才能恢復服務。
一個高可用的系統(tǒng)應該是具有盡量長的MTBF和盡量短的MTTR。

3、提高可靠性

由兩種方法可以提高可靠性:一是讓系統(tǒng)中的單個組件都變得更可靠；二是消滅單點。
依靠單點實現(xiàn)的可靠性畢竟有限，要想進一步的提升系統(tǒng)的可靠性，就只好消滅單點，通過主從、多活等模式讓多個節(jié)點集體完成原先單點的工作（分布式），可以從概率意義上改善服務對外整體的可靠性。

當前名稱：區(qū)塊鏈快速入門（二）——分布式系統(tǒng)核心技術(shù)
分享網(wǎng)址：http://jinyejixie.com/article0/ppedio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導航、域名注冊、搜索引擎優(yōu)化、網(wǎng)站收錄、標簽優(yōu)化、外貿(mào)建站

廣告

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