本篇內(nèi)容介紹了“如何實(shí)現(xiàn)一個(gè)延遲隊(duì)列”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

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

延遲隊(duì)列定義

首先，隊(duì)列這種數(shù)據(jù)結(jié)構(gòu)相信大家都不陌生，它是一種先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)。普通隊(duì)列中的元素是有序的，先進(jìn)入隊(duì)列中的元素會(huì)被優(yōu)先取出進(jìn)行消費(fèi)；

延時(shí)隊(duì)列相比于普通隊(duì)列最大的區(qū)別就體現(xiàn)在其延時(shí)的屬性上，普通隊(duì)列的元素是先進(jìn)先出，按入隊(duì)順序進(jìn)行處理，而延時(shí)隊(duì)列中的元素在入隊(duì)時(shí)會(huì)指定一個(gè)延遲時(shí)間，表示其希望能夠在經(jīng)過(guò)該指定時(shí)間后處理。從某種意義上來(lái)講，延遲隊(duì)列的結(jié)構(gòu)并不像一個(gè)隊(duì)列，而更像是一種以時(shí)間為權(quán)重的有序堆結(jié)構(gòu)。

應(yīng)用場(chǎng)景

我在開(kāi)發(fā)業(yè)務(wù)需求時(shí)遇到的使用場(chǎng)景是這樣的，用戶(hù)可以在小程序中訂閱不同的微信或者 QQ 的模板消息，產(chǎn)品同學(xué)可以在小程序的管理端新建消息推送計(jì)劃，當(dāng)?shù)竭_(dá)指定的時(shí)間節(jié)點(diǎn)的時(shí)候給所有訂閱模板消息的用戶(hù)進(jìn)行消息推送。

如果僅僅是服務(wù)單一的小程序，那也許起個(gè)定時(shí)任務(wù)，或者甚至人工的定時(shí)去執(zhí)行能夠最便捷最快速的去完成這項(xiàng)需求，但我們希望能夠抽象出一個(gè)消息訂閱的模塊服務(wù)出來(lái)給所有業(yè)務(wù)使用，這時(shí)候就需要一種通用的系統(tǒng)的解決方案，這時(shí)候便需要使用到延遲隊(duì)列了。

除了上述我所遇到的這樣的典型的需求以外，延遲隊(duì)列的應(yīng)用場(chǎng)景其實(shí)也非常的廣泛，比如說(shuō)以下的場(chǎng)景：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 新建的訂單，如果用戶(hù)在 15 分鐘內(nèi)未支付，則自動(dòng)取消。

3. 公司的會(huì)議預(yù)定系統(tǒng)，在會(huì)議預(yù)定成功后，會(huì)在會(huì)議開(kāi)始前半小時(shí)通知所有預(yù)定該會(huì)議的用戶(hù)。

4. 安全工單超過(guò) 24 小時(shí)未處理，則自動(dòng)拉企業(yè)微信群提醒相關(guān)責(zé)任人。

5. 用戶(hù)下單外賣(mài)以后，距離超時(shí)時(shí)間還有 10 分鐘時(shí)提醒外賣(mài)小哥即將超時(shí)。

對(duì)于數(shù)據(jù)量比較少并且時(shí)效性要求不那么高的場(chǎng)景，一種比較簡(jiǎn)單的方式是輪詢(xún)數(shù)據(jù)庫(kù)，比如每秒輪詢(xún)一下數(shù)據(jù)庫(kù)中所有數(shù)據(jù)，處理所有到期的數(shù)據(jù)，比如如果我是公司內(nèi)部的會(huì)議預(yù)定系統(tǒng)的開(kāi)發(fā)者，我可能就會(huì)采用這種方案，因?yàn)檎麄€(gè)系統(tǒng)的數(shù)據(jù)量必然不會(huì)很大并且會(huì)議開(kāi)始前提前 30 分鐘提醒與提前 29 分鐘提醒的差別并不大。

但是如果需要處理的數(shù)據(jù)量比較大實(shí)時(shí)性要求比較高，比如淘寶每天的所有新建訂單 15 分鐘內(nèi)未支付的自動(dòng)超時(shí)，數(shù)量級(jí)高達(dá)百萬(wàn)甚至千萬(wàn)，這時(shí)候如果你還敢輪詢(xún)數(shù)據(jù)庫(kù)怕是要被你老板打死，不被老板打死估計(jì)也要被運(yùn)維同學(xué)打死。

這種場(chǎng)景下，就需要使用到我們今天的主角 —— 延遲隊(duì)列了。延遲隊(duì)列為我們提供了一種高效的處理大量需要延遲消費(fèi)消息的解決方案。那么話不多說(shuō)，下面我們就來(lái)看一下幾種常見(jiàn)的延遲隊(duì)列的解決方案以及他們各自的優(yōu)缺點(diǎn)。

實(shí)現(xiàn)方案

redis ZSet

我們知道 Redis 有一個(gè)有序集合的數(shù)據(jù)結(jié)構(gòu) ZSet，ZSet 中每個(gè)元素都有一個(gè)對(duì)應(yīng) Score，ZSet 中所有元素是按照其 Score 進(jìn)行排序的。

那么我們可以通過(guò)以下這幾個(gè)操作使用 Redis 的 ZSet 來(lái)實(shí)現(xiàn)一個(gè)延遲隊(duì)列：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 入隊(duì)操作： ZADD KEY timestamp task , 我們將需要處理的任務(wù)，按其需要延遲處理時(shí)間作為 Score 加入到 ZSet 中。Redis 的 ZAdd 的時(shí)間復(fù)雜度是 O(logN) ， N 是 ZSet 中元素個(gè)數(shù)，因此我們能相對(duì)比較高效的進(jìn)行入隊(duì)操作。

3. 起一個(gè)進(jìn)程定時(shí)（比如每隔一秒）通過(guò) ZREANGEBYSCORE 方法查詢(xún) ZSet 中 Score 最小的元素，具體操作為： ZRANGEBYSCORE KEY -inf +inf limit 0 1 WITHSCORES 。查詢(xún)結(jié)果有兩種情況： 
   a. 查詢(xún)出的分?jǐn)?shù)小于等于當(dāng)前時(shí)間戳，說(shuō)明到這個(gè)任務(wù)需要執(zhí)行的時(shí)間了，則去異步處理該任務(wù)； 
   b. 查詢(xún)出的分?jǐn)?shù)大于當(dāng)前時(shí)間戳，由于剛剛的查詢(xún)操作取出來(lái)的是分?jǐn)?shù)最小的元素，所以說(shuō)明 ZSet 中所有的任務(wù)都還沒(méi)有到需要執(zhí)行的時(shí)間，則休眠一秒后繼續(xù)查詢(xún)； 
   同樣的， ZRANGEBYSCORE 操作的時(shí)間復(fù)雜度為 O(logN + M) ，其中 N 為 ZSet 中元素個(gè)數(shù)， M 為查詢(xún)的元素個(gè)數(shù)，因此我們定時(shí)查詢(xún)操作也是比較高效的。

這里從網(wǎng)上搬運(yùn)了一套 Redis 實(shí)現(xiàn)延遲隊(duì)列的后端架構(gòu)，其在原來(lái) Redis 的 ZSet 實(shí)現(xiàn)上進(jìn)行了一系列的優(yōu)化，使得整個(gè)系統(tǒng)更穩(wěn)定、更健壯，能夠應(yīng)對(duì)高并發(fā)場(chǎng)景，并且具有更好的可擴(kuò)展性，是一個(gè)挺不錯(cuò)的架構(gòu)設(shè)計(jì)，其整體架構(gòu)圖如下：

其核心設(shè)計(jì)思路：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 將延遲的消息任務(wù)通過(guò) hash 算法路由至不同的 Redis Key 上，這樣做有兩大好處： 
   a. 避免了當(dāng)一個(gè) KEY 在存儲(chǔ)了較多的延時(shí)消息后，入隊(duì)操作以及查詢(xún)操作速度變慢的問(wèn)題（兩個(gè)操作的時(shí)間復(fù)雜度均為 O(logN) ）。 
   b. 系統(tǒng)具有了更好的橫向可擴(kuò)展性，當(dāng)數(shù)據(jù)量激增時(shí)，我們可以通過(guò)增加 Redis Key 的數(shù)量來(lái)快速的擴(kuò)展整個(gè)系統(tǒng)，來(lái)抗住數(shù)據(jù)量的增長(zhǎng)。

3. 每個(gè) Redis Key 都對(duì)應(yīng)建立一個(gè)處理進(jìn)程，稱(chēng)為 Event 進(jìn)程，通過(guò)上述步驟 2 中所述的 ZRANGEBYSCORE 方法輪詢(xún) Key，查詢(xún)是否有待處理的延遲消息。

4. 所有的 Event 進(jìn)程只負(fù)責(zé)分發(fā)消息，具體的業(yè)務(wù)邏輯通過(guò)一個(gè)額外的消息隊(duì)列異步處理，這么做的好處也是顯而易見(jiàn)的： 
   a. 一方面，Event 進(jìn)程只負(fù)責(zé)分發(fā)消息，那么其處理消息的速度就會(huì)非常快，就不太會(huì)出現(xiàn)因?yàn)闃I(yè)務(wù)邏輯復(fù)雜而導(dǎo)致消息堆積的情況。 
   b. 另一方面，采用一個(gè)額外的消息隊(duì)列后，消息處理的可擴(kuò)展性也會(huì)更好，我們可以通過(guò)增加消費(fèi)者進(jìn)程數(shù)量來(lái)擴(kuò)展整個(gè)系統(tǒng)的消息處理能力。

5. Event 進(jìn)程采用 Zookeeper 選主單進(jìn)程部署的方式，避免 Event 進(jìn)程宕機(jī)后，Redis Key 中消息堆積的情況。一旦 Zookeeper 的 leader 主機(jī)宕機(jī)，Zookeeper 會(huì)自動(dòng)選擇新的 leader 主機(jī)來(lái)處理 Redis Key 中的消息。

從上述的討論中我們可以看到，通過(guò) Redis Zset 實(shí)現(xiàn)延遲隊(duì)列是一種理解起來(lái)較為直觀，可以快速落地的方案。并且我們可以依賴(lài) Redis 自身的持久化來(lái)實(shí)現(xiàn)持久化，使用 Redis 集群來(lái)支持高并發(fā)和高可用，是一種不錯(cuò)的延遲隊(duì)列的實(shí)現(xiàn)方案。

RabbitMQ

RabbitMQ 本身并不直接提供對(duì)延遲隊(duì)列的支持，我們依靠 RabbitMQ 的 TTL 以及 死信隊(duì)列功能，來(lái)實(shí)現(xiàn)延遲隊(duì)列的效果。那就讓我們首先來(lái)了解一下，RabbitMQ 的死信隊(duì)列以及 TTL 功能。

死信隊(duì)列

死信隊(duì)列實(shí)際上是一種 RabbitMQ 的消息處理機(jī)制，當(dāng) RabbmitMQ 在生產(chǎn)和消費(fèi)消息的時(shí)候，消息遇到如下的情況，就會(huì)變成“死信”：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 消息被拒絕 basic.reject/ basic.nack 并且不再重新投遞 requeue=false

3. 消息超時(shí)未消費(fèi)，也就是 TTL 過(guò)期了

4. 消息隊(duì)列到達(dá)最大長(zhǎng)度

消息一旦變成一條死信，便會(huì)被重新投遞到死信交換機(jī)（Dead-Letter-Exchange），然后死信交換機(jī)根據(jù)綁定規(guī)則轉(zhuǎn)發(fā)到對(duì)應(yīng)的死信隊(duì)列上，監(jiān)聽(tīng)該隊(duì)列就可以讓消息被重新消費(fèi)。

消息生存時(shí)間 TTL

TTL（Time-To-Live）是 RabbitMQ 的一種高級(jí)特性，表示了一條消息的最大生存時(shí)間，單位為毫秒。如果一條消息在 TTL 設(shè)置的時(shí)間內(nèi)沒(méi)有被消費(fèi)，那么它就會(huì)變成一條死信，進(jìn)入我們上面所說(shuō)的死信隊(duì)列。

有兩種不同的方式可以設(shè)置消息的 TTL 屬性，一種方式是直接在創(chuàng)建隊(duì)列的時(shí)候設(shè)置整個(gè)隊(duì)列的 TTL 過(guò)期時(shí)間，所有進(jìn)入隊(duì)列的消息，都被設(shè)置成了統(tǒng)一的過(guò)期時(shí)間，一旦消息過(guò)期，馬上就會(huì)被丟棄，進(jìn)入死信隊(duì)列，參考代碼如下：

Map<String, Object> args = new HashMap<String, Object>(); args.put("x-message-ttl", 6000); channel.queueDeclare(queueName, durable, exclusive, autoDelete, args);

在延遲隊(duì)列的延遲時(shí)間為固定值的時(shí)候，比較適合使用這種方式。

另一種方式是針對(duì)單條消息設(shè)置，參考代碼如下，該消息被設(shè)置了 6 秒的過(guò)期時(shí)間：

AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder(); builder.expiration("6000"); AMQP.BasicProperties properties = builder.build(); channel.basicPublish(exchangeName, routingKey, mandatory, properties, "msg content".getBytes());

如果需要不同的消息設(shè)置不同的延遲時(shí)間，上面針對(duì)隊(duì)列的 TTL 設(shè)置便無(wú)法滿(mǎn)足我們的需求，需要使用這種針對(duì)單個(gè)消息的 TTL 設(shè)置。

不過(guò)需要注意的是，使用這種方式設(shè)置的 TTL，消息可能不會(huì)按時(shí)死亡，因?yàn)?RabbitMQ 只會(huì)檢查第一個(gè)消息是否過(guò)期。比如這種情況，第一個(gè)消息設(shè)置了 20s 的 TTL，第二個(gè)消息設(shè)置了 10s 的 TTL，那么 RabbitMQ 會(huì)等到第一個(gè)消息過(guò)期之后，才會(huì)讓第二個(gè)消息過(guò)期。

解決這個(gè)問(wèn)題的方法也很簡(jiǎn)單，只需要安裝 RabbitMQ 的一個(gè)插件即可：

https://www.rabbitmq.com/community-plugins.html

安裝好這個(gè)插件后，所有的消息就都能按照被設(shè)置的 TTL 過(guò)期了。

RabbitMQ 實(shí)現(xiàn)延遲隊(duì)列

好了，介紹完 RabbitMQ 的死信隊(duì)列以及 TTL 這兩種特性之后，我們離實(shí)現(xiàn)延遲隊(duì)列就只差一步之遙了。

聰明的讀者可能已經(jīng)發(fā)現(xiàn)了，TTL 不就是延遲隊(duì)列中消息要延遲的時(shí)間么？如果我們把需要延遲的消息，將 TTL 設(shè)置為其延遲時(shí)間，投遞到 RabbitMQ 的普通隊(duì)列中，一直不去消費(fèi)它，那么經(jīng)過(guò) TTL 的時(shí)間后，消息就會(huì)自動(dòng)被投遞到死信隊(duì)列，這時(shí)候我們使用消費(fèi)者進(jìn)程實(shí)時(shí)地去消費(fèi)死信隊(duì)列中的消息，不就實(shí)現(xiàn)了延遲隊(duì)列的效果。

從下圖可以直觀的看出使用 RabbitMQ 實(shí)現(xiàn)延遲隊(duì)列的整體流程：

使用 RabbitMQ 來(lái)實(shí)現(xiàn)延遲隊(duì)列，我們可以很好的利用一些 RabbitMQ 的特性，比如消息可靠發(fā)送、消息可靠投遞、死信隊(duì)列來(lái)保障消息至少被消費(fèi)一次以及未被正確處理的消息不會(huì)被丟棄。另外，通過(guò) RabbitMQ 集群的特性，可以很好的解決單點(diǎn)故障問(wèn)題，不會(huì)因?yàn)閱蝹€(gè)節(jié)點(diǎn)掛掉導(dǎo)致延遲隊(duì)列不可用或者消息丟失。

TimeWheel

TimeWheel 時(shí)間輪算法，是一種實(shí)現(xiàn)延遲隊(duì)列的巧妙且高效的算法，被應(yīng)用在 Netty，Zookeeper，Kafka 等各種框架中。

時(shí)間輪

如上圖所示，時(shí)間輪是一個(gè)存儲(chǔ)延遲消息的環(huán)形隊(duì)列，其底層采用數(shù)組實(shí)現(xiàn)，可以高效循環(huán)遍歷。這個(gè)環(huán)形隊(duì)列中的每個(gè)元素對(duì)應(yīng)一個(gè)延遲任務(wù)列表，這個(gè)列表是一個(gè)雙向環(huán)形鏈表，鏈表中每一項(xiàng)都代表一個(gè)需要執(zhí)行的延遲任務(wù)。

時(shí)間輪會(huì)有表盤(pán)指針，表示時(shí)間輪當(dāng)前所指時(shí)間，隨著時(shí)間推移，該指針會(huì)不斷前進(jìn)，并處理對(duì)應(yīng)位置上的延遲任務(wù)列表。

添加延遲任務(wù)

由于時(shí)間輪的大小固定，并且時(shí)間輪中每個(gè)元素都是一個(gè)雙向環(huán)形鏈表，我們可以在 O(1) 的時(shí)間復(fù)雜度下向時(shí)間輪中添加延遲任務(wù)。

如下圖，例如我們有一個(gè)這樣的時(shí)間輪，在表盤(pán)指針指向當(dāng)前時(shí)間為 2 時(shí)，我們需要新添加一個(gè)延遲 3 秒的任務(wù)，我們可以快速計(jì)算出延遲任務(wù)在時(shí)間輪中所對(duì)應(yīng)的位置為 5，并添加到位置 5 上任務(wù)列表尾部。

多層時(shí)間輪

到現(xiàn)在為止一切都非常棒，但是細(xì)心的同學(xué)可能發(fā)現(xiàn)了，上面的時(shí)間輪的大小是固定的，只有 12 秒。如果此時(shí)我們有一個(gè)需要延遲 200 秒的任務(wù)，我們應(yīng)該怎么處理呢？直接擴(kuò)充整個(gè)時(shí)間輪的大小嗎？這顯然不可取，因?yàn)檫@樣做的話我們就需要維護(hù)一個(gè)非常非常大的時(shí)間輪，內(nèi)存是不可接受的，而且底層數(shù)組大了之后尋址效率也會(huì)降低，影響性能。

為此，Kafka 引入了多層時(shí)間輪的概念。其實(shí)多層時(shí)間輪的概念和我們的機(jī)械表上時(shí)針、分針、秒針的概念非常類(lèi)似，當(dāng)僅使用秒針無(wú)法表示當(dāng)前時(shí)間時(shí)，就使用分針結(jié)合秒針一起表示。同樣的，當(dāng)任務(wù)的到期時(shí)間超過(guò)了當(dāng)前時(shí)間輪所表示的時(shí)間范圍時(shí)，就會(huì)嘗試添加到上層時(shí)間輪中，如下圖所示：

第一層時(shí)間輪整個(gè)時(shí)間輪所表示時(shí)間范圍是 0-12 秒，第二層時(shí)間輪每格能表示的時(shí)間范圍是整個(gè)第一層時(shí)間輪所表示的范圍也就是 12 秒，所以整個(gè)第二層時(shí)間輪能表示的時(shí)間范圍即 12*12=144 秒，依次類(lèi)推第三層時(shí)間輪能表示的范圍是 1728 秒，第四層為 20736 秒等等。

比如現(xiàn)在我們需要添加一個(gè)延時(shí)為 200 秒的延遲消息，我們發(fā)現(xiàn)其已經(jīng)超過(guò)了第一層時(shí)間輪能表示的時(shí)間范圍，我們就需要繼續(xù)往上層時(shí)間輪看，將其添加在第二層時(shí)間輪 200/12 = 17 的位置，然后我們發(fā)現(xiàn) 17 也超過(guò)了第二次時(shí)間輪的表示范圍，那么我們就需要繼續(xù)往上層看，將其添加在第三層時(shí)間輪的 17/12 = 2 的位置。

Kafka 中時(shí)間輪算法添加延遲任務(wù)以及推動(dòng)時(shí)間輪滾動(dòng)的核心流程如下，其中 Bucket 即時(shí)間輪中的延遲任務(wù)隊(duì)列，并且 Kafka 引入的 DelayQueue 解決了多數(shù) Bucket 為空導(dǎo)致的時(shí)間輪滾動(dòng)效率低下的問(wèn)題：

使用時(shí)間輪實(shí)現(xiàn)的延遲隊(duì)列，能夠支持大量任務(wù)的高效觸發(fā)。并且在 Kafka 的時(shí)間輪算法的實(shí)現(xiàn)方案中，還引入了 DelayQueue，使用 DelayQueue 來(lái)推送時(shí)間輪滾動(dòng)，而延遲任務(wù)的添加與刪除操作都放在時(shí)間輪中，這樣的設(shè)計(jì)大幅提升了整個(gè)延遲隊(duì)列的執(zhí)行效率。

總結(jié)

延遲隊(duì)列在我們?nèi)粘ｉ_(kāi)發(fā)中應(yīng)用非常廣泛，本文介紹了三種不同的實(shí)現(xiàn)延遲隊(duì)列的方案，三種方案各自有各自的特點(diǎn)，例如 Redis 的實(shí)現(xiàn)方案理解起來(lái)最為簡(jiǎn)單，能夠快速落地，但 Redis 畢竟是基于內(nèi)存的，雖然有數(shù)據(jù)持久化方案，但還是有數(shù)據(jù)丟失的可能性。而 RabbitMQ 的實(shí)現(xiàn)方案，由于 RabbitMQ 本身的消息可靠發(fā)送、消息可靠投遞、死信隊(duì)列等特性，可以保障消息至少被消費(fèi)一次以及未被正確處理的消息不會(huì)被丟棄，讓消息的可靠性有了保障。最后 Kafka 的時(shí)間輪算法，個(gè)人覺(jué)得是三種實(shí)現(xiàn)方案中最難理解但也不失為一種非常巧妙實(shí)現(xiàn)方案。

“如何實(shí)現(xiàn)一個(gè)延遲隊(duì)列”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

網(wǎng)頁(yè)名稱(chēng)：如何實(shí)現(xiàn)一個(gè)延遲隊(duì)列
網(wǎng)站網(wǎng)址：http://chinadenli.net/article22/gpdhjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊(cè)、網(wǎng)站收錄、營(yíng)銷(xiāo)型網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站導(dǎo)航、網(wǎng)站營(yíng)銷(xiāo)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(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í)需注明來(lái)源： 創(chuàng)新互聯(lián)