為什么只有阿里云和AWS擁有自研云數(shù)據(jù)庫的能力？

很多國產(chǎn)數(shù)據(jù)庫乘風(fēng)破浪

為迎澤等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及迎澤網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站設(shè)計、做網(wǎng)站、迎澤網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

我們正處在一個數(shù)據(jù)庫技術(shù)大爆炸的時代。

這幾年，NoSQL數(shù)據(jù)庫、NewSQL數(shù)據(jù)庫、時序數(shù)據(jù)庫、圖數(shù)據(jù)庫、分布式數(shù)據(jù)庫、超融合數(shù)據(jù)庫等專業(yè)數(shù)據(jù)庫技術(shù)發(fā)展勢頭很猛，國產(chǎn)數(shù)據(jù)庫的表現(xiàn)也相當(dāng)亮眼。

過去十年，是互聯(lián)網(wǎng)發(fā)展的黃金十年。與此對應(yīng)的是業(yè)務(wù)系統(tǒng)訪問并發(fā)呈指數(shù)級上升，海量數(shù)據(jù)計算和分析需求越來越普遍，傳統(tǒng)單機系統(tǒng)在業(yè)務(wù)支撐、成本、開放性等方面均面臨巨大挑戰(zhàn)，數(shù)據(jù)庫垂直擴展模式難以維護等困境。

眼看著數(shù)據(jù)庫性能瓶頸快要扼住發(fā)展的喉嚨，擺在這些長久依賴Oracle、IBM等傳統(tǒng)數(shù)據(jù)庫的巨頭們面前的，只有兩條路：要么開啟無限加量的PLUS模式，即更換更多更強的服務(wù)器、硬盤、內(nèi)存、CPU等，要么自研能滿足業(yè)務(wù)發(fā)展需求的數(shù)據(jù)庫。

開拓者們的眼光一開始就聚焦在更長遠的未來，他們發(fā)現(xiàn)即便是系統(tǒng)變成真正的“傻大粗”，也只是解了燃眉之急，不能從源頭解決問題。

再看一眼像Oracle、IBM等傳統(tǒng)數(shù)據(jù)庫高昂的拓容價格，像阿里這樣的富一代也吃不消哇！

那么，自研數(shù)據(jù)庫，走起！

2010年后，云計算和開源社區(qū)興起，國產(chǎn)數(shù)據(jù)庫開始了彎道超車。

2019年被認為是國產(chǎn)數(shù)據(jù)庫的元年。

這一年，眾多國產(chǎn)數(shù)據(jù)庫產(chǎn)品闖入了我們的視線，熱度不斷攀升；這一年，OceanBase登頂TPCC，并于一年后再次刷新自己的記錄。

從刀耕火種到摘下Oracle在數(shù)據(jù)庫領(lǐng)域的皇冠，國產(chǎn)數(shù)據(jù)庫經(jīng)歷的是一段不被理解和不被看好的歲月。

在國外數(shù)據(jù)庫先驅(qū)長期占據(jù)市場優(yōu)勢的情況下，國產(chǎn)數(shù)據(jù)庫要想殺出重圍，一是要付出多倍努力，二是要拿出更強的產(chǎn)品才能在客戶面前更有底氣。

當(dāng)然，國產(chǎn)數(shù)據(jù)庫發(fā)展至今，已然是百花齊放。未來，國產(chǎn)數(shù)據(jù)庫的發(fā)展趨勢相對也比較明顯，即往云原生和分布式發(fā)展。

金融級分布式數(shù)據(jù)庫應(yīng)運而生

數(shù)字時代，數(shù)據(jù)成為各家必爭之地。

在金融應(yīng)用場景下，國內(nèi)數(shù)據(jù)庫市場于近幾年開始發(fā)生變化。

隨著應(yīng)用層和業(yè)務(wù)層的壓力加大，金融機構(gòu)對分布式技術(shù)架構(gòu)轉(zhuǎn)型的需求應(yīng)運而生。

作為軟件系統(tǒng)的三大底層技術(shù)（操作系統(tǒng)、中間件、數(shù)據(jù)庫）之一，數(shù)據(jù)庫成為系統(tǒng)往分布式架構(gòu)轉(zhuǎn)型的樞紐。

不過，在早年國外傳統(tǒng)數(shù)據(jù)庫廠商盤根錯節(jié)的“蠶食”下，這個核心變得又硬又難啃！

面對如今市場的需求變化，傳統(tǒng)數(shù)據(jù)庫系統(tǒng)呈現(xiàn)出一個通病：又笨重又貴。

再是，隨著諸如2013年“棱鏡門”事件的爆發(fā)，各界越來越重視數(shù)據(jù)安全和技術(shù)自主可控。

此外，金融機構(gòu)對快速、靈活、可伸縮性、創(chuàng)新、敏捷等開發(fā)能力需求大大提升，出于對長期IT建設(shè)的成本考慮，自主可控更是成為他們出于自身長遠發(fā)展考量的剛需。

數(shù)字化時代，金融機構(gòu)的整體架構(gòu)正處于往分布式、云原生、微服務(wù)等方向發(fā)展的關(guān)鍵時刻，數(shù)據(jù)庫的選型便顯得至關(guān)重要。

根據(jù)中國人民銀行發(fā)布的《金融 科技 （FinTech）發(fā)展規(guī)劃（2019-2021年）》，我國將有計劃、分步驟地穩(wěn)妥推動分布式數(shù)據(jù)庫產(chǎn)品先行先試，形成可借鑒、能推廣的典型案例和解決方案，為分布式數(shù)據(jù)庫在金融領(lǐng)域的全面應(yīng)用探明路徑，確保分布式數(shù)據(jù)庫在金融領(lǐng)域穩(wěn)妥應(yīng)用。

目前已有不少業(yè)界實踐證明了分布式數(shù)據(jù)庫應(yīng)用于金融場景的可靠性。同時，金融級分布式數(shù)據(jù)庫云化已經(jīng)在路上。

你覺得數(shù)據(jù)庫這個課怎么樣？

普通。就是學(xué)習(xí)數(shù)據(jù)庫的操作而已。讀取,編輯,刪除這三種操作邏輯。只要記憶力好,把那幾種命令語句背下來,基本的操作就沒問題。這對今后的其他課程尤其是編程是有幫助的,因為有些軟件會設(shè)計到數(shù)據(jù)庫的讀寫操作。尤其是一些網(wǎng)站,肯定會連接數(shù)據(jù)庫。不會數(shù)據(jù)庫操作,就沒辦法制作動態(tài)網(wǎng)站。

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

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

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

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

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

隨著互聯(lián)網(wǎng)時代的到來，計算機要管理的數(shù)據(jù)量呈指數(shù)級別地飛速上漲，而我們卻完全無法對用戶數(shù)做出準(zhǔn)確預(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世紀(jì)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)單次提交的延遲。延遲提高會導(dǎo)致數(shù)據(jù)庫鎖持有時間變長，使得高沖突條件下分布式事務(wù)的性能不升反降（這個具體可以了解一下Amdahl定律），甚至性能距離單機數(shù)據(jù)庫都還有明顯的差距。

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

面對這個難題，傳統(tǒng)的關(guān)系數(shù)據(jù)庫選擇了放棄分布式的方案，因為在20世紀(jì)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)足夠好用了。

然而，當(dā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)域的標(biāo)配組件，在阿里的幾乎所有應(yīng)用上都有應(yīng)用。最為難得的是，這些功能從上線后，到現(xiàn)在已經(jīng)經(jīng)歷了多年雙11的嚴(yán)酷考驗，從未出現(xiàn)過嚴(yán)重故障（p0、p1級別故障屬于嚴(yán)重故障）。數(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ù)好更多的人。

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

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

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

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

DRDS主要功能介紹

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

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

分布式SQL引擎主要的目的，就是實現(xiàn)與單機數(shù)據(jù)庫SQL引擎的完全兼容。目前我們的SQL引擎能夠做到與MySQL的SQL引擎全兼容，包括各類join和各類復(fù)雜函數(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，這批機器就會下線。

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

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

【小表廣播】

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

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

圖5 小表廣播場景

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

這時候，為了提升性能，我們就必須要減少跨機join的網(wǎng)絡(luò)代價。我們比較推薦應(yīng)用做如下處理，將左表復(fù)制到右表的每一個庫上。這樣，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ù)庫的使用習(xí)慣的前提下，享受到分布式數(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ù)專家。目前主要負責(zé)阿里的分布式數(shù)據(jù)庫DRDS（TDDL）和阿里的分布式消息服務(wù)ONS（RocketMQ/Notify）兩個系統(tǒng)。

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

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

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

然而，隨著業(yè)務(wù)體量的快速增長，當(dāng)前這套消息系統(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） 接收方客戶端組成。

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

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

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

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

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

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

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

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

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

3） agoo是阿里的離線推送中臺，負責(zé)整合不同廠商的離線推送通道，向集團用戶提供一個統(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)，負責(zé)人群管理、內(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)化，引導(dǎo)打開通知權(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） 未標(biāo)記的推送，默認作為營銷類推送對待。

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

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

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

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

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)，還是一個比較復(fù)雜的領(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ā)布于： ?）