阿里IM技術(shù)分享(六)：閑魚億級IM消息系統(tǒng)的離線推送到達率優(yōu)化

本文由阿里閑魚技術(shù)團隊逸昂分享，原題“消息鏈路優(yōu)化之弱感知鏈路優(yōu)化”，有修訂和改動，感謝作者的分享。

創(chuàng)新互聯(lián)服務(wù)項目包括交口網(wǎng)站建設(shè)、交口網(wǎng)站制作、交口網(wǎng)頁制作以及交口網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，交口網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到交口省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

閑魚的IM消息系統(tǒng)作為買家與賣家的溝通工具，增進理解、促進信任，對閑魚的商品成交有重要的價值，是提升用戶體驗最關(guān)鍵的環(huán)節(jié)。

然而，隨著業(yè)務(wù)體量的快速增長，當前這套消息系統(tǒng)正面臨著諸多急待解決的問題。

以下幾個問題典型最為典型：

1） 在線消息的體驗提升；

2） 離線推送的到達率；

3） 消息玩法與消息底層系統(tǒng)的耦合過強。

經(jīng)過評估，我們認為現(xiàn)階段離線推送的到達率問題最為關(guān)鍵，對用戶體驗影響較大。

本文將要分享的是閑魚IM消息在解決離線推送的到達率方面的技術(shù)實踐，內(nèi)容包括問題分析和技術(shù)優(yōu)化思路等 ，希望能帶給你啟發(fā)。

（本文已同步發(fā)布于： ?）

本文是系列文章的第6篇，總目錄如下：

《 阿里IM技術(shù)分享(一)：企業(yè)級IM王者——釘釘在后端架構(gòu)上的過人之處 》

《 阿里IM技術(shù)分享(二)：閑魚IM基于Flutter的移動端跨端改造實踐 》

《 阿里IM技術(shù)分享(三)：閑魚億級IM消息系統(tǒng)的架構(gòu)演進之路 》

《 阿里IM技術(shù)分享(四)：閑魚億級IM消息系統(tǒng)的可靠投遞優(yōu)化實踐 》

《 阿里IM技術(shù)分享(五)：閑魚億級IM消息系統(tǒng)的及時性優(yōu)化實踐 》

《 阿里IM技術(shù)分享(六)：閑魚億級IM消息系統(tǒng)的離線推送到達率優(yōu)化 》（* 本文）

從數(shù)據(jù)通信鏈接的技術(shù)角度，我們根據(jù)閑魚客戶端是否在線，將整體消息鏈路大致分為強感知鏈路和弱感知鏈路。

強感知鏈路由以下子系統(tǒng)或模塊：

1） 發(fā)送方客戶端；

2） idleapi-message（閑魚的消息網(wǎng)關(guān)）；

3） heracles（閑魚的消息底層服務(wù)）；

4） accs（阿里自研的長連接通道）；

5） 接收方客戶端組成。

整條鏈路的核心指標在于端到端延遲和消息到達率。

強感知鏈路中的雙方都是在線的，消息到達客戶端就可以保證接收方感知到。強感知鏈路的主要痛點在消息的端到端延遲。

弱感知鏈路與強感知鏈路的主要不同在于： 弱感知鏈路的接收方是離線的，需要依賴離線推送這樣的方式送達。

因此弱感知鏈路的用戶感知度不強，其核心指標在于消息的到達率，而非延遲。

所以當前階段，優(yōu)化弱感知鏈路的重點也就是提升離線消息的到達率。換句話說， 提升離線消息到達率問題，也就是優(yōu)化弱感知鏈路本身 。

下圖一張整個IM消息系統(tǒng)的架構(gòu)圖，感受下整體鏈路：

如上圖所示，各主要組件和子系統(tǒng)分工如下：

1） HSF是一個遠程服務(wù)框架，是dubbo的內(nèi)部版本；

2） tair是阿里自研的分布式緩存框架，支持 memcached、Redis、LevelDB 等不同存儲引擎；

3） agoo是阿里的離線推送中臺，負責整合不同廠商的離線推送通道，向集團用戶提供一個統(tǒng)一的離線推送服務(wù)；

4） accs是阿里自研的長連接通道，為客戶端、服務(wù)端的實時雙向交互提供便利；

5） lindorm是阿里自研的NoSQL產(chǎn)品，與HBase有異曲同工之妙；

6） 域環(huán)是閑魚消息優(yōu)化性能的核心結(jié)構(gòu)，用來存儲用戶最新的若干條消息。

強感知鏈路和弱感知鏈路在通道選擇上是不同的：

1） 強感知鏈路使用accs這個在線通道；

2） 弱感知鏈路使用agoo這個離線通道。

通俗了說，弱感知鏈路指的就是離線消息推送系統(tǒng)。

相比較于在線消息和端內(nèi)推送（也就是上面說的強感知鏈路），離線推送難以確保被用戶感知到。

典型的情況包括：

1） 未發(fā)送到用戶設(shè)備：即推送未送達用戶設(shè)備，這種情況可以從通道的返回分析；

2） 發(fā)送到用戶設(shè)備但沒有展示到系統(tǒng)通知欄：閑魚曾遇到通道返回成功，但是用戶未看到推送的案例；

3） 展示到通知欄，并被系統(tǒng)折疊：不同安卓廠商對推送的折疊策略不同，被折疊后，需用戶主動展開才能看到內(nèi)容，觸達效果明顯變差；

4） 展示到通知欄，并被用戶忽略：離線推送的點擊率相比于在線推送更低。

針對“1）未發(fā)送到用戶設(shè)備”，原因有：

1） 離線通道的token失效；

2） 參數(shù)錯誤；

3） 用戶關(guān)閉應(yīng)用通知；

4） 用戶已卸載等。

針對“3）展示到通知欄，并被系統(tǒng)折疊”，原因有：

1） 通知的點擊率；

2） 應(yīng)用在廠商處的權(quán)重；

3） 推送的數(shù)量等。

針對“4）展示到通知欄，并被用戶忽略”，原因有：

1） 用戶不愿意查看推送；

2） 用戶看到了推送，但是對內(nèi)容不感興趣；

3） 用戶在忙別的事，無暇處理。

總之： 以上這些離線消息推送場景，對于用戶來說感知度不高，我們也便稱之為弱感知鏈路。

我們的弱感知鏈路分為3部分，即：

1） 系統(tǒng)；

2） 通道；

3） 用戶。

共包含了Hermes、agoo、廠商、設(shè)備、用戶、承接頁這幾個環(huán)節(jié)。具體如下圖所示。

從推送的產(chǎn)生到用戶最終進入APP，共分為如下幾個步驟：

步驟1 ：Hermes是閑魚的用戶觸達系統(tǒng)，負責人群管理、內(nèi)容管理、時機把控，是整個弱感知鏈路的起點。；

步驟2 ：agoo是阿里內(nèi)部承接離線推送的中臺，是閑魚離線推送能力的基礎(chǔ)；

步驟3 ：agoo實現(xiàn)離線推送依靠的是廠商的推送通道（如：蘋果的 apns通道 、Google的fcm通道、及 國內(nèi)各廠商的自建通道 。；

步驟4 ：通過廠商的通道，推送最終出現(xiàn)在用戶的設(shè)備上，這是用戶能感知到推送的前提條件；

步驟5 ：如果用戶剛巧看到這條推送，推送的內(nèi)容也很有趣，在用戶的主動點擊下會喚起APP，打開承接頁，進而給用戶展示個性化的商品。

經(jīng)過以上5個步驟，至此弱感知鏈路就完成了使命。

弱感知鏈路的核心問題在于：

1） 推送的消息是否投遞給了用戶；

2） 已投遞到的消息用戶是否有感知。

這對應(yīng)推送的兩個階段：

1） 推送消息是否已到達設(shè)備；

2） 用戶是否查看推送并點擊。

其中： 到達設(shè)備這個階段是最基礎(chǔ)的，也是本次優(yōu)化的核心。

我們可以將每一步的消息處理量依次平鋪，展開為一張漏斗圖，從而直觀的查看鏈路的瓶頸。

漏斗圖斜率最大的地方是優(yōu)化的重點，差異小的地方不需要優(yōu)化：

通過分析以上漏斗圖，弱感知鏈路的優(yōu)化重點在三個方面：

1） agoo受理率：是指我們發(fā)送推送請到的數(shù)量到可以通過agoo（阿里承接離線推送的中臺）轉(zhuǎn)發(fā)到廠商通道的數(shù)量之間的漏斗；

2） 廠商受理率：是指agoo中臺受理的量到廠商返回成功的量之間的漏斗；

3） Push點擊率：也就通過以上通道最終已送到到用戶終端的消息，是否最終轉(zhuǎn)化為用戶的主動“點擊”。

有了優(yōu)化方向，我們來看看優(yōu)化手段吧。

跟隨推送的視角，順著鏈路看一下我們是如何進行優(yōu)化的。

用戶的推送，從 Hermes 站點搭乘“班車”，駛向下一站：? agoo 。

這是推送經(jīng)歷的第一站。到站一看，傻眼了，只有不到一半的推送到站下車了。這是咋回事嘞？

這就要先說說 agoo 了，調(diào)用 agoo 有兩種方式：

1） 指定設(shè)備和客戶端，agoo直接將推送投遞到相應(yīng)的設(shè)備；

2） 指定用戶和客戶端，agoo根據(jù)內(nèi)部的轉(zhuǎn)換表，找到用戶對應(yīng)的設(shè)備，再進行投遞。

我們的系統(tǒng)不保存用戶的設(shè)備信息。因此，是按照用戶來調(diào)用agoo的。

同時： 由于沒有用戶的設(shè)備信息，并不知道用戶是 iOS 客戶端還是 Android 客戶端。工程側(cè)不得不向 iOS 和 Android 都發(fā)送一遍推送。雖然保證了到達，但是，一半的調(diào)用都是無效的。

為了解這個問題： 我們使用了agoo的設(shè)備信息。將用戶轉(zhuǎn)換設(shè)備這一階段提前到了調(diào)用 agoo 之前，先明確用戶對應(yīng)的設(shè)備，再指定設(shè)備調(diào)用 agoo，從而避免無效調(diào)用。

agoo調(diào)用方式優(yōu)化后，立刻剔除了無效調(diào)用，agoo受理率有了明顯提升。

至此： 我們總算能對 agoo 受理失敗的真正原因做一個高大上的分析了。

根據(jù)統(tǒng)計： 推送被 agoo 拒絕的主要原因是——用戶關(guān)閉了通知權(quán)限。同時，我們對 agoo 調(diào)用數(shù)據(jù)的進一步分析發(fā)現(xiàn)——有部分用戶找不到對應(yīng)的設(shè)備。 優(yōu)化到此，我們猛然發(fā)現(xiàn)多了兩個問題。

那就繼續(xù)優(yōu)化唄：

1） 通知體驗優(yōu)化，引導打開通知權(quán)限；

2） 與agoo共建設(shè)備庫，解決設(shè)備轉(zhuǎn)換失敗的問題。

這兩個優(yōu)化方向又是一片新天地，我們擇日再聊。

推送到達 agoo ，分機型搭乘廠商“專列”，駛向下一站：用戶設(shè)備。

這是推送經(jīng)歷的第二站。出站查票，發(fā)現(xiàn)竟然超員了。

于是乎： 我們每天有大量推送因為超過廠商設(shè)定的限額被攔截。

為什么會這樣呢？

實際上： 提供推送通道的廠商（沒錯， 各手機廠商的自家推送通道良莠不齊 ），為了保證用戶體驗，會對每個應(yīng)用能夠推送的消息總量進行限制。

對于廠商而言，這個限制會根據(jù)推送的類型和應(yīng)用的用戶規(guī)模設(shè)定——推送主要分為產(chǎn)品類的推送和營銷類的推送。

廠商推送通道對于不同類型消息的限制是：

1） 對于產(chǎn)品類推送，廠商會保證到達；

2） 對于營銷類推送，廠商會進行額度限制；

3） 未標記的推送，默認作為營銷類推送對待。

我們剛好沒有對推送進行標記，因此觸發(fā)了廠商的推送限制。

這對我們的用戶來說，會帶來困擾。閑魚的交易，很依賴買賣家之間的消息互動。這部分消息是需要確保到達的。

同樣： 訂單類的消息、用戶的關(guān)注，也需要保證推送給用戶。

根據(jù)主流廠商的接口協(xié)議，我們將推送的消息分為以下幾類，并進行相應(yīng)標記：

1） 即時通訊消息；

2） 訂單狀態(tài)變化；

3） 用戶關(guān)注內(nèi)容；

4） 營銷消息這幾類。

同時，在業(yè)務(wù)上，我們也進行了推送的治理——將用戶關(guān)注度不高的消息，取消推送，避免打擾。

經(jīng)過這些優(yōu)化，因為超過廠商限額而被攔截的推送實現(xiàn)了清零。

通過優(yōu)化agoo受理率、廠商受理率，我們解決了推送到達量的瓶頸。但即使消息被最終送達，用戶到底點擊了沒有？這才是消息推送的根本意義所在。

于是，在日常的開發(fā)測試過程中，我們發(fā)現(xiàn)了推送的兩個體驗問題：

1） 用戶點擊Push有開屏廣告；

2） 營銷Push也有權(quán)限校驗，更換用戶登陸后無法點擊。

對于開屏廣告功能，我們增加了Push點擊跳過廣告的能力。

針對Push的權(quán)限校驗功能，閑魚根據(jù)場景做了細分：

1） 涉及個人隱私的推送，保持權(quán)限校驗不變；

2） 營銷類的推送，放開權(quán)限校驗。

以上是點擊體驗的優(yōu)化，我們還需要考慮用戶的點擊意愿。

用戶點擊量與推送的曝光量、推送素材的有趣程度相關(guān)。推送的曝光量又和推送的到達量、推送的到達時機有關(guān)。

具體的優(yōu)化手段是：

1） 在推送內(nèi)容上：我們需要優(yōu)化的是推送的時機和相應(yīng)的素材；

2） 在推送時機上：算法會根據(jù)用戶的偏好和個性化行為數(shù)據(jù)，計算每個用戶的個性化推送時間，在用戶空閑的時間推送（避免在不合適的時間打擾用戶，同時也能提升用戶看到推送的可能性）。

3） 在推送素材上：算法會根據(jù)素材的實時點擊反饋，對素材做實時賽馬。只發(fā)用戶感興趣的素材，提高用戶點擊意愿。

通過以上我們的分析和技術(shù)優(yōu)化手段，整體弱推送鏈路鏈路有了不錯的提升，離線消息的到達率相對提升了兩位數(shù)。

本篇主要和大家聊的是只是IM消息系統(tǒng)鏈路中的一環(huán)——弱感知鏈路的優(yōu)化，落地到到具體的業(yè)務(wù)也就是離線消息送達率問題。

整體IM消息系統(tǒng)，還是一個比較復雜的領(lǐng)域。

我們在消息系統(tǒng)的發(fā)展過程中，面臨著如下問題：

1） 如何進行消息的鏈路追蹤；

2） 如何保證IM消息的快速到達（見《 閑魚億級IM消息系統(tǒng)的及時性優(yōu)化實踐 》)；

3） 如何將消息的玩法和底層能力分離；

4） 離線推送中如何通過用戶找到對應(yīng)的設(shè)備。

這些問題，我們在以前的文章中有所分享，以后也會陸續(xù)分享更多，敬請期待。

[1]? Android P正式版即將到來：后臺應(yīng)用保活、消息推送的真正噩夢

[2]? 一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計實踐

[3]? 一套億級用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等

[4]? 一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等

[5]? 從新手到專家：如何設(shè)計一套億級消息量的分布式IM系統(tǒng)

[6]? 企業(yè)微信的IM架構(gòu)設(shè)計揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等

[7]? 融云技術(shù)分享：全面揭秘億級IM消息的可靠投遞機制

[8]? 移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？

[9]? 現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討

[10]? 新手入門一篇就夠：從零開發(fā)移動端IM

[11]? 移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”

[12]? 移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)

[13]? IM消息送達保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞

[14]? IM消息送達保證機制實現(xiàn)(二)：保證離線消息的可靠投遞

[15]? 零基礎(chǔ)IM開發(fā)入門(一)：什么是IM系統(tǒng)？

[16]? 零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實時性？

[17]? 零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？

[18]? 零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時序一致性？

（本文已同步發(fā)布于： ?）

消息中間件（一）MQ詳解及四大MQ比較

一、消息中間件相關(guān)知識

1、概述

消息隊列已經(jīng)逐漸成為企業(yè)IT系統(tǒng)內(nèi)部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發(fā)RocketMQ等。

2、消息中間件的組成

2.1 Broker

消息服務(wù)器，作為server提供消息核心服務(wù)

2.2 Producer

消息生產(chǎn)者，業(yè)務(wù)的發(fā)起方，負責生產(chǎn)消息傳輸給broker，

2.3 Consumer

消息消費者，業(yè)務(wù)的處理方，負責從broker獲取消息并進行業(yè)務(wù)邏輯處理

2.4 Topic

2.5 Queue

2.6 Message

消息體，根據(jù)不同通信協(xié)議定義的固定格式進行編碼的數(shù)據(jù)包，來封裝業(yè)務(wù)數(shù)據(jù)，實現(xiàn)消息的傳輸

3 消息中間件模式分類

3.1 點對點

PTP點對點:使用queue作為通信載體

說明：

消息生產(chǎn)者生產(chǎn)消息發(fā)送到queue中，然后消息消費者從queue中取出并且消費消息。

消息被消費以后，queue中不再存儲，所以消息消費者不可能消費到已經(jīng)被消費的消息。 Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。

說明：

queue實現(xiàn)了負載均衡，將producer生產(chǎn)的消息發(fā)送到消息隊列中，由多個消費者消費。但一個消息只能被一個消費者接受，當沒有消費者可用時，這個消息會被保存直到有一個可用的消費者。

4 消息中間件的優(yōu)勢

4.1 系統(tǒng)解耦

交互系統(tǒng)之間沒有直接的調(diào)用關(guān)系，只是通過消息傳輸，故系統(tǒng)侵入性不強，耦合度低。

4.2 提高系統(tǒng)響應(yīng)時間

例如原來的一套邏輯，完成支付可能涉及先修改訂單狀態(tài)、計算會員積分、通知物流配送幾個邏輯才能完成；通過MQ架構(gòu)設(shè)計，就可將緊急重要（需要立刻響應(yīng)）的業(yè)務(wù)放到該調(diào)用方法中，響應(yīng)要求不高的使用消息隊列，放到MQ隊列中，供消費者處理。

4.3 為大數(shù)據(jù)處理架構(gòu)提供服務(wù)

通過消息作為整合，大數(shù)據(jù)的背景下，消息隊列還與實時處理架構(gòu)整合，為數(shù)據(jù)處理提供性能支持。

4.4 Java消息服務(wù)——JMS

Java消息服務(wù)（Java Message Service，JMS）應(yīng)用程序接口是一個Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進行異步通信。

5 消息中間件應(yīng)用場景

5.1 異步通信

有些業(yè)務(wù)不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

5.2 解耦

降低工程間的強依賴程度，針對異構(gòu)系統(tǒng)進行適配。在項目啟動之初來預(yù)測將來項目會碰到什么需求，是極其困難的。通過消息系統(tǒng)在處理過程中間插入了一個隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實現(xiàn)這一接口，當應(yīng)用發(fā)生變化時，可以獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

5.3 冗余

有些情況下，處理數(shù)據(jù)的過程會失敗。除非數(shù)據(jù)被持久化，否則將造成丟失。消息隊列把數(shù)據(jù)進行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風險。許多消息隊列所采用的”插入-獲取-刪除”范式中，在把一個消息從隊列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。

5.4 擴展性

因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。便于分布式擴容。

5.5 過載保護

在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量無法提取預(yù)知；如果以為了能處理這類瞬間峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會因為突發(fā)的超負荷的請求而完全崩潰。

5.6 可恢復性

系統(tǒng)的一部分組件失效時，不會影響到整個系統(tǒng)。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統(tǒng)恢復后被處理。

5.7 順序保證

在大多使用場景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。

5.8 緩沖

在任何重要的系統(tǒng)中，都會有需要不同的處理時間的元素。消息隊列通過一個緩沖層來幫助任務(wù)最高效率的執(zhí)行，該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。以調(diào)節(jié)系統(tǒng)響應(yīng)時間。

5.9 數(shù)據(jù)流處理

分布式系統(tǒng)產(chǎn)生的海量數(shù)據(jù)流，如：業(yè)務(wù)日志、監(jiān)控數(shù)據(jù)、用戶行為等，針對這些數(shù)據(jù)流進行實時或批量采集匯總，然后進行大數(shù)據(jù)分析是當前互聯(lián)網(wǎng)的必備技術(shù)，通過消息隊列完成此類數(shù)據(jù)收集是最好的選擇。

6 消息中間件常用協(xié)議

6.1 AMQP協(xié)議

AMQP即Advanced Message Queuing Protocol,一個提供統(tǒng)一消息服務(wù)的應(yīng)用層標準高級消息隊列協(xié)議,是應(yīng)用層協(xié)議的一個開放標準,為面向消息的中間件設(shè)計?；诖藚f(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同開發(fā)語言等條件的限制。

優(yōu)點：可靠、通用

6.2 MQTT協(xié)議

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發(fā)的一個即時通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，被用來當做傳感器和致動器（比如通過Twitter讓房屋聯(lián)網(wǎng)）的通信協(xié)議。

優(yōu)點：格式簡潔、占用帶寬小、移動端通信、PUSH、嵌入式系統(tǒng)

6.3 STOMP協(xié)議

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協(xié)議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設(shè)計的簡單文本協(xié)議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進行交互。

優(yōu)點：命令模式（非topic\queue模式）

6.4 XMPP協(xié)議

XMPP（可擴展消息處理現(xiàn)場協(xié)議，Extensible Messaging and Presence Protocol）是基于可擴展標記語言（XML）的協(xié)議，多用于即時消息（IM）以及在線現(xiàn)場探測。適用于服務(wù)器之間的準即時操作。核心是基于XML流傳輸，這個協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何人發(fā)送即時消息，即使其操作系統(tǒng)和瀏覽器不同。

優(yōu)點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式占用帶寬大

6.5 其他基于TCP/IP自定義的協(xié)議

有些特殊框架（如：redis、kafka、zeroMq等）根據(jù)自身需要未嚴格遵循MQ規(guī)范，而是基于TCP\IP自行封裝了一套協(xié)議，通過網(wǎng)絡(luò)socket接口進行傳輸，實現(xiàn)了MQ的功能。

7 常見消息中間件MQ介紹

7.1 RocketMQ

阿里系下開源的一款分布式、隊列模型的消息中間件，原名Metaq，3.0版本名稱改為RocketMQ，是阿里參照kafka設(shè)計思想使用java實現(xiàn)的一套mq。同時將阿里系內(nèi)部多款mq產(chǎn)品（Notify、metaq）進行整合，只維護核心功能，去除了所有其他運行時依賴，保證核心功能最簡化，在此基礎(chǔ)上配合阿里上述其他開源產(chǎn)品實現(xiàn)不同場景下mq的架構(gòu)，目前主要多用于訂單交易系統(tǒng)。

具有以下特點：

官方提供了一些不同于kafka的對比差異：

7.2 RabbitMQ

使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級，更適合于企業(yè)級的開發(fā)。同時實現(xiàn)了Broker架構(gòu)，核心思想是生產(chǎn)者不會將消息直接發(fā)送給隊列，消息在發(fā)送給客戶端時先在中心隊列排隊。對路由(Routing)，負載均衡(Load balance)、數(shù)據(jù)持久化都有很好的支持。多用于進行企業(yè)級的ESB整合。

7.3 ActiveMQ

Apache下的一個子項目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn)，少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景。可插拔的傳輸協(xié)議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

7.4 Redis

使用C語言開發(fā)的一個Key-Value的NoSQL數(shù)據(jù)庫，開發(fā)維護很活躍，雖然它是一個Key-Value數(shù)據(jù)庫存儲系統(tǒng)，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務(wù)來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時間。測試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個不同大小的數(shù)據(jù)。實驗表明：入隊時，當數(shù)據(jù)比較小時Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊時，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

7.5 Kafka

Apache下的一個子項目，使用scala實現(xiàn)的一個高性能分布式Publish/Subscribe消息隊列系統(tǒng)，具有以下特性：

7.6 ZeroMQ

號稱最快的消息隊列系統(tǒng)，專門為高吞吐量/低延遲的場景開發(fā)，在金融界的應(yīng)用中經(jīng)常使用，偏重于實時數(shù)據(jù)通信場景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級/復雜的隊列，但是開發(fā)人員需要自己組合多種技術(shù)框架，開發(fā)成本高。因此ZeroMQ具有一個獨特的非中間件的模式，更像一個socket library，你不需要安裝和運行一個消息服務(wù)器或中間件，因為你的應(yīng)用程序本身就是使用ZeroMQ API完成邏輯服務(wù)的角色。但是ZeroMQ僅提供非持久性的隊列，如果down機，數(shù)據(jù)將會丟失。如：Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸。

ZeroMQ套接字是與傳輸層無關(guān)的：ZeroMQ套接字對所有傳輸層協(xié)議定義了統(tǒng)一的API接口。默認支持 進程內(nèi)(inproc) ，進程間(IPC) ，多播，TCP協(xié)議，在不同的協(xié)議之間切換只要簡單的改變連接字符串的前綴。可以在任何時候以最小的代價從進程間的本地通信切換到分布式下的TCP通信。ZeroMQ在背后處理連接建立，斷開和重連邏輯。

特性：

二、主要消息中間件的比較

NoSQL在少量數(shù)據(jù)的存儲上，與傳統(tǒng)關(guān)系型數(shù)據(jù)庫相比有什么劣勢嗎？

個人不認為nosql在少量數(shù)據(jù)存儲上有啥優(yōu)勢。nosql主要解決的是auto sharding的問題,你不需要sharding,搞啥nosql. 作者：方圓 鏈接：

通過阿里來看大型應(yīng)用數(shù)據(jù)庫是選擇Oracle MySQL 還是 NoSQL

肯定是Oracle，因為從簡單查詢性能角度來比較：Oracle MySQL NoSQL，NoSQL 產(chǎn)品不支持 Join，MySQL 的查詢優(yōu)化器由于所基于的統(tǒng)計信息相對少很多，當Query 復雜度很高的時候容易出現(xiàn)執(zhí)行計劃不是最優(yōu)選擇的問題，而 Oracle 由于大量的統(tǒng)計信息支持，使得其查詢優(yōu)化器更為智能，對復雜查詢有更優(yōu)的表現(xiàn)。

阿里云分布式數(shù)據(jù)庫服務(wù)DRDS？誰使用過 簡單講講！

淘寶開源的TDDL和cobar的結(jié)合，放到了阿里云上就是DRDS，是商品，服務(wù)，可以購買使用的。可以在阿里云官網(wǎng)上注冊免費試用。

=====================================================

隨著互聯(lián)網(wǎng)時代的到來，計算機要管理的數(shù)據(jù)量呈指數(shù)級別地飛速上漲，而我們卻完全無法對用戶數(shù)做出準確預(yù)估。我們的系統(tǒng)所需要支持的用戶數(shù)，很可能在短短的一個月內(nèi)突然爆發(fā)式地增長幾千倍，數(shù)據(jù)也很可能快速地從原來的幾百GB飛速上漲到了幾百個TB。如果在這爆發(fā)的關(guān)鍵時刻，系統(tǒng)不穩(wěn)定或無法訪問，那么對于業(yè)務(wù)將會是毀滅性的打擊。

伴隨著這種對于系統(tǒng)性能、成本以及擴展性的新需要，以HBase、MongoDB為代表的NoSQL數(shù)據(jù)庫和以阿里DRDS、VoltDB、ScaleBase為代表的分布式NewSQL數(shù)據(jù)庫如雨后春筍般不斷涌現(xiàn)出來。

本文將會介紹阿里DRDS的技術(shù)理念、發(fā)展歷程、技術(shù)特性等內(nèi)容。

DRDS設(shè)計理念

從20世紀70年代關(guān)系數(shù)據(jù)庫創(chuàng)立開始，其實大家在數(shù)據(jù)庫上的追求就從未發(fā)生過變化：更快的存取數(shù)據(jù)，可以按需擴縮以承載更大的訪問量和更大的數(shù)據(jù)量，開發(fā)容易，硬件成本低，我們可以把這叫做數(shù)據(jù)庫領(lǐng)域的圣杯。

為了支撐更大的訪問量和數(shù)據(jù)量，我們必然需要分布式數(shù)據(jù)庫系統(tǒng)，然而分布式系統(tǒng)又必然會面對強一致性所帶來的延遲提高的問題，因為網(wǎng)絡(luò)通信本身比單機內(nèi)通信代價高很多，這種通信的代價就會直接增加系統(tǒng)單次提交的延遲。延遲提高會導致數(shù)據(jù)庫鎖持有時間變長，使得高沖突條件下分布式事務(wù)的性能不升反降（這個具體可以了解一下Amdahl定律），甚至性能距離單機數(shù)據(jù)庫都還有明顯的差距。

從上面的說明，我們可以發(fā)現(xiàn)，問題的關(guān)鍵并不是分布式事務(wù)做不出來，而是做出來了卻因為性能太差而沒有什么卵用。數(shù)據(jù)庫領(lǐng)域的高手們努力了40年，但至今仍然沒有人能夠很好地解決這個問題，Google Spanner的開發(fā)負責人就經(jīng)常在他的Blog上談?wù)撗舆t的問題，相信也是飽受這個問題的困擾。

面對這個難題，傳統(tǒng)的關(guān)系數(shù)據(jù)庫選擇了放棄分布式的方案，因為在20世紀70~80年代，我們的數(shù)據(jù)庫主要被用來處理企業(yè)內(nèi)的各類數(shù)據(jù)，面對的用戶不過幾千人，而數(shù)據(jù)量最多也就是TB級別。用單臺機器來處理事務(wù)，用個磁盤陣列處理一下磁盤容量不夠的問題，基本上就能解決一切問題了。

然而，信息化和互聯(lián)網(wǎng)的浪潮改變了這一切，我們突然發(fā)現(xiàn)，我們服務(wù)的對象發(fā)生了根本性變化，從原來的幾千人，變成了現(xiàn)在的幾億人，數(shù)據(jù)量也從TB級別到了PB級別甚至更多。存在單點的單機系統(tǒng)無論如何努力，都會面對系統(tǒng)處理能力的天花板。原來的這條路，看起來是走不下去了，我們必須想辦法換一條路來走。

可是，分布式數(shù)據(jù)庫所面對的強一致性難題卻像一座高山，人們努力了無數(shù)個日日夜夜，但能翻越這座山的日子看來仍然遙遙無期。

于是，有一群人認為，強一致性這件事看來不怎么靠譜，那徹底繞開這個問題是不是個更好的選擇？他們發(fā)現(xiàn)確實有那么一些場景是不需要強一致事務(wù)的，甚至連SQL都可以不要，最典型的就是日志流水的記錄與分析這類場景。而去掉了事務(wù)和SQL，接口簡單了，性能就更容易得到提升，擴展性也更容易實現(xiàn)，這就是NoSQL系統(tǒng)的起源。

雖然NoSQL解決了性能和擴展性問題，但這種繞開問題的方法給用戶帶來了很多困擾，系統(tǒng)的開發(fā)成本也大大提升。這時候就有另外一群人，他們覺得用戶需要SQL，覺得用戶也需要事務(wù)，問題的關(guān)鍵在于我們要努力地往圣杯的方向不斷前進。在保持系統(tǒng)的擴展性和性能的前提下，付出盡可能小的代價來滿足業(yè)務(wù)對數(shù)據(jù)庫的需要。這就是NewSQL這個理念的由來。

DRDS也是一個NewSQL的系統(tǒng)，它與ScaleBase、VoltDB等系統(tǒng)類似，都希望能夠找到一條既能保持系統(tǒng)的高擴展性和高性能，又能盡可能保持傳統(tǒng)數(shù)據(jù)庫的ACID事務(wù)和SQL特性的分布式數(shù)據(jù)庫系統(tǒng)。

DRDS發(fā)展歷程

在一開始，TDDL的主要功能就是做數(shù)據(jù)庫切分，一個或一組SQL請求提交到TDDL，TDDL進行規(guī)則運算后得知SQL應(yīng)該被分發(fā)到哪個機器，直接將SQL轉(zhuǎn)發(fā)到對應(yīng)機器即可（如圖1）。

圖1 TDDL數(shù)據(jù)庫切分

開始的時候，這種簡單的路由策略能夠滿足用戶的需要，我們開始的那些應(yīng)用，就是通過這樣非常簡單的方式完成了他所有的應(yīng)用請求。我們也認為，這種方案簡單可靠，已經(jīng)足夠好用了。

然而，當我們服務(wù)的應(yīng)用從十幾個增長到幾百個的時候，大量的中小應(yīng)用加入，大家紛紛表示，原來的方案限制太大，很多應(yīng)用其實只是希望做個讀寫分離，希望能有更好的SQL兼容性。

于是，我們做了第一次重大升級，在這次升級里，我們提出了一個重要的概念就是三層架構(gòu)，Matrix對應(yīng)數(shù)據(jù)庫切分場景，對SQL有一定限制，Group對應(yīng)讀寫分離和高可用場景，對SQL幾乎沒有限制。如圖2所示。

圖2 數(shù)據(jù)庫升級為三層架構(gòu)

這種做法立刻得到了大家的認可，TDDL所提供的讀寫分離、分庫分表等核心功能，也成為了阿里集團內(nèi)數(shù)據(jù)庫領(lǐng)域的標配組件，在阿里的幾乎所有應(yīng)用上都有應(yīng)用。最為難得的是，這些功能從上線后，到現(xiàn)在已經(jīng)經(jīng)歷了多年雙11的嚴酷考驗，從未出現(xiàn)過嚴重故障（p0、p1級別故障屬于嚴重故障）。數(shù)據(jù)庫體系作為整個應(yīng)用系統(tǒng)的重中之重，能做到這件事，真是非常不容易。

隨著核心功能的穩(wěn)定，自2010年開始，我們集中全部精力開始關(guān)注TDDL后端運維系統(tǒng)的完善與改進性工作。在DBA團隊的給力配合下，圍繞著TDDL，我們成功做到了在線數(shù)據(jù)動態(tài)擴縮、異步索引等關(guān)鍵特征，同時也比較成功地構(gòu)建了一整套分布式數(shù)據(jù)庫服務(wù)管控體系，用戶基本上可以完全自助地完成整套數(shù)據(jù)庫環(huán)境的搭建與初始化工作。

大概是2012年，我們在阿里云團隊的支持下，開始嘗試將TDDL這套體系輸出到阿里云上，也有了個新的名字：阿里分布式數(shù)據(jù)庫服務(wù)（DRDS），希望能夠用我們的技術(shù)服務(wù)好更多的人。

不過當我們滿懷自信地把自己的軟件拿到云上的時候，卻發(fā)現(xiàn)我們的軟件距離用戶的要求差距很大。在內(nèi)部因為有DBA的同學們幫助進行SQL review，所以SQL的復雜度都是可控的。然而到了云上，看了各種渠道提過來的兼容性需求，我們經(jīng)常是不自覺地發(fā)出這樣的感嘆：“啊？原來這種語法MySQL也是可以支持的？”

于是，我們又進行了架構(gòu)升級，這次是以兼容性為核心目標的系統(tǒng)升級工作，希望能夠在分布式場景下支持各類復雜的SQL，同時也將阿里這么多年來在分布式事務(wù)上的積累都帶到了DRDS里面。

這次架構(gòu)升級，我們的投入史無前例，用了三年多才將整個系統(tǒng)落地完成。我們先在內(nèi)部以我們自己的業(yè)務(wù)作為首批用戶上線，經(jīng)過了內(nèi)部幾百個應(yīng)用的嚴酷考驗以后，我們才敢拿到云上，給到我們的最終用戶使用。

目前，我們正在將TDDL中更多的積累輸出到云上，同時也努力優(yōu)化我們的用戶界面。PS：其實用戶界面優(yōu)化對我們這種專注于高性能后端技術(shù)的團隊來說，才是最大的技術(shù)挑戰(zhàn)，連我也去學了AngularJS，參與了用戶UI編。

DRDS主要功能介紹

發(fā)展歷史看完了，下面就由我來介紹一下目前我們已經(jīng)輸出到云上的主要功能。

【分布式SQL執(zhí)行引擎】

分布式SQL引擎主要的目的，就是實現(xiàn)與單機數(shù)據(jù)庫SQL引擎的完全兼容。目前我們的SQL引擎能夠做到與MySQL的SQL引擎全兼容，包括各類join和各類復雜函數(shù)等。他主要包含SQL解析、優(yōu)化、執(zhí)行和合并四個流程，如圖3中綠色部分。

圖3 SQL引擎實現(xiàn)的主要流程

雖然SQL是兼容的，但是分布式SQL執(zhí)行算法與單機SQL的執(zhí)行算法卻完全不同，原因也很簡單，網(wǎng)絡(luò)通信的延遲比單機內(nèi)通信的延遲大得多。舉個例子說明一下，我們有份文件要從一張紙A上謄寫到另外一張紙B上，單機系統(tǒng)就好比兩張紙都在同一個辦公室里，而分布式數(shù)據(jù)庫則就像是一張紙在北京，一張紙在杭州。

自然地，如果兩張紙在同一個辦公室，因為傳輸距離近，逐行謄寫的效率是可以接受的。而如果距離是北京到杭州，用逐行謄寫的方式，就立刻顯得代價太高了，我們總不能看一行，就打個“飛的”去杭州寫下來吧。在這種情況下，還是把紙A上的信息拍個照片，【一整批的】帶到杭州去處理，明顯更簡單一些。這就是分布式數(shù)據(jù)庫特別強調(diào)吞吐調(diào)優(yōu)的原因，只要是涉及到跨機的所有查詢，都必須盡可能的積攢一批后一起發(fā)送，以減少系統(tǒng)延遲提高帶來的不良影響。

【按需數(shù)據(jù)庫集群平滑擴縮】

DRDS允許應(yīng)用按需將新的單機存儲加入或移出集群，DRDS則能夠保證應(yīng)用在遷移流程中實現(xiàn)不停機擴容縮容。

圖4 DRDS按需進行平滑擴縮

在內(nèi)部的數(shù)據(jù)庫使用實踐中，這個功能的一個最重要應(yīng)用場景就是雙11了。在雙11之前，我們會將大批的機器加入到我們的數(shù)據(jù)庫集群中，抗過了雙11，這批機器就會下線。

當DRDS來到云上，我們發(fā)現(xiàn)雙11其實不僅僅只影響阿里內(nèi)部的系統(tǒng)。在下游的各類電商輔助性系統(tǒng)其實也面對巨大壓力。在雙11前5天，網(wǎng)聚寶的熊總就找到我說，擔心撐不過雙11的流量，怕系統(tǒng)掛。于是我們就給他介紹了這個自動擴容的功能怎么用，他買了一個月的數(shù)據(jù)庫，掛接在DRDS上。數(shù)據(jù)庫能力立刻翻倍，輕松抗過了雙11，也算是我印象比較深刻的一個案例了。

因為我們完全無法預(yù)測在什么時間點系統(tǒng)會有爆發(fā)性的增長，而如果在這時候系統(tǒng)因為技術(shù)原因不能使用，就會給整個業(yè)務(wù)帶來毀滅性的影響，風口一旦錯過，就追悔莫及了。我想這就是云計算特別強調(diào)可擴展能力的原因吧。

【小表廣播】

小表廣播也是我們在分布式數(shù)據(jù)庫領(lǐng)域內(nèi)最常用的工具之一，他的核心目的其實都是一個——盡可能讓查詢只發(fā)生在單機。

讓我們用一個例子來說明，小表廣播的一般使用場景。

圖5 小表廣播場景

圖5中，如果我想知道買家id等于0的用戶在商城里面買了哪些商品，我們一般會先將這兩個表join起來，然后再用where平臺名=”商城” and buyerID = 0找到符合要求的數(shù)據(jù)。然而這種join的方式，會導致大量的針對左表的網(wǎng)絡(luò)I/O。如果要取出的數(shù)據(jù)量比較大，系統(tǒng)延遲會明顯上升。

這時候，為了提升性能，我們就必須要減少跨機join的網(wǎng)絡(luò)代價。我們比較推薦應(yīng)用做如下處理，將左表復制到右表的每一個庫上。這樣，join操作就由分布式j(luò)oin一下變回到本地join，系統(tǒng)的性能就有很大的提升了，如圖6所示。

圖6

【分布式事務(wù)套件】

在阿里巴巴的業(yè)務(wù)體系中存在非常多需要事務(wù)類的場景，下單減庫存，賬務(wù)，都是事務(wù)場景最集中的部分。

而我們處理事務(wù)的方法卻和傳統(tǒng)應(yīng)用處理事務(wù)的方案不大一樣，我們非常強調(diào)事務(wù)的最終一致性和異步化。利用這種方式，能夠極大地降低分布式系統(tǒng)中鎖持有的時間，從而極大地提升系統(tǒng)性能。

圖7 DRDS分布式事務(wù)解決套件

這種處理機制，是我們分布式事務(wù)能夠以極低成本大量運行的最核心法門。在DRDS平臺內(nèi)，我們將這些方案產(chǎn)品化，為了DRDS的分布式事務(wù)解決套件。

利用他們，能夠讓你以比較低的成本，實現(xiàn)低延遲，高吞吐的分布式事務(wù)場景。

DRDS的未來

阿里分布式數(shù)據(jù)庫服務(wù)DRDS上線至今，大家對這款產(chǎn)品的熱情超出了我們的預(yù)期，短短半年內(nèi)已經(jīng)有幾千個申請。

盡管還在公測期，但是大家就已經(jīng)把關(guān)系到身家性命的寶貴在線數(shù)據(jù)業(yè)務(wù)放到了DRDS上，我能夠感受到這份沉甸甸的信賴，也不想辜負這份信賴。

經(jīng)過阿里內(nèi)部幾千個應(yīng)用的不斷歷練，DRDS已經(jīng)積累出一套強大的分布式SQL執(zhí)行引擎和和一整套分布式事務(wù)套件。

我也相信，這些積累能夠讓用戶在基本保持單機數(shù)據(jù)庫的使用習慣的前提下，享受到分布式數(shù)據(jù)庫高性能可擴展的好處。

在平時的DRDS支持過程中，我面對最多的問題就是，DRDS能不能夠在不改變?nèi)魏卧袠I(yè)務(wù)邏輯和代碼的前提下，實現(xiàn)可自由伸縮和擴展呢？十分可惜的是，關(guān)系數(shù)據(jù)庫發(fā)展至今，還沒有找到既能保留傳統(tǒng)數(shù)據(jù)庫一切特性，又能實現(xiàn)高性能可擴展數(shù)據(jù)庫的方法。

然而，雖不能至，吾心向往之！我們會以“可擴展，高性能”為產(chǎn)品核心，堅定地走在追尋圣杯的路上，并堅信最終我們一定能夠找尋到它神圣的所在。

作者簡介：王晶昱，花名沈詢，阿里巴巴資深技術(shù)專家。目前主要負責阿里的分布式數(shù)據(jù)庫DRDS（TDDL）和阿里的分布式消息服務(wù)ONS（RocketMQ/Notify）兩個系統(tǒng)。

網(wǎng)站名稱：阿里開發(fā)的nosql,阿里開發(fā)的搜索引擎
網(wǎng)站網(wǎng)址：http://jinyejixie.com/article22/dsdgsjc.html

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

廣告

聲明：本網(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)