建站
咨詢
售后
建站咨詢
新聞中心
IM系統(tǒng)已經(jīng)融入了現(xiàn)代人的生活中，對(duì)于人與人之間的溝通起到了至關(guān)重要的作用。IM系統(tǒng)中的數(shù)據(jù)庫(kù)設(shè)計(jì)關(guān)系到IM系統(tǒng)的性能和穩(wěn)定性。在數(shù)據(jù)庫(kù)設(shè)計(jì)之前，需要了解IM系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)的關(guān)鍵因素，針對(duì)這些關(guān)鍵因素進(jìn)行分析和研究。
一、性能和穩(wěn)定性要求
對(duì)于IM系統(tǒng)來(lái)說(shuō)，性能和穩(wěn)定性是系統(tǒng)設(shè)計(jì)中最基礎(chǔ)的需求。性能主要體現(xiàn)在響應(yīng)速度和吞吐量方面。隨著用戶規(guī)模的增加，系統(tǒng)的并發(fā)能力和響應(yīng)速度都需提高。因此在數(shù)據(jù)庫(kù)設(shè)計(jì)過(guò)程中，需要考慮到系統(tǒng)的性能監(jiān)測(cè)和優(yōu)化。例如，可以使用多個(gè)數(shù)據(jù)庫(kù)服務(wù)器進(jìn)行負(fù)載均衡、緩存技術(shù)等來(lái)提高性能。
穩(wěn)定性則是系統(tǒng)可靠運(yùn)行的基礎(chǔ)，對(duì)于IM系統(tǒng)的故障不能容忍。在數(shù)據(jù)庫(kù)設(shè)計(jì)中，需要避免數(shù)據(jù)重復(fù)、數(shù)據(jù)損壞等因素引起的數(shù)據(jù)不一致性。特別是在高并發(fā)壓力下，出現(xiàn)線程安全問(wèn)題等情況都會(huì)導(dǎo)致系統(tǒng)崩潰或者數(shù)據(jù)出現(xiàn)異常，因此需要進(jìn)行嚴(yán)格的并發(fā)控制和數(shù)據(jù)一致性保證。
二、數(shù)據(jù)安全性要求
IM系統(tǒng)中的數(shù)據(jù)安全性尤為重要，需要保證用戶的私密信息不被泄露。為了加強(qiáng)數(shù)據(jù)庫(kù)安全性，需要在系統(tǒng)設(shè)計(jì)過(guò)程中加入保密措施，比如對(duì)用戶信息進(jìn)行加密、設(shè)置訪問(wèn)權(quán)限控制、打補(bǔ)丁、加入數(shù)據(jù)備份機(jī)制等。
除此之外，需要考慮到安全審計(jì)，數(shù)據(jù)日志記錄和審計(jì)查詢。這些都是常規(guī)的安全要求，但對(duì)于IM系統(tǒng)來(lái)說(shuō)，這些安全功能的存在非常重要，因?yàn)樵跀?shù)據(jù)安全被破壞的時(shí)候，及時(shí)的數(shù)據(jù)找回可以避免破壞的順利進(jìn)行。
三、數(shù)據(jù)的擴(kuò)展性要求
IM系統(tǒng)在不斷更新的同時(shí)，需要考慮到數(shù)據(jù)的擴(kuò)展性，隨著系統(tǒng)的不斷升級(jí)，數(shù)據(jù)量不斷增加，因此需要進(jìn)行擴(kuò)展。在數(shù)據(jù)庫(kù)設(shè)計(jì)中，需要考慮數(shù)據(jù)的表結(jié)構(gòu)，這樣在后面的擴(kuò)展中，不會(huì)出現(xiàn)數(shù)據(jù)表層級(jí)不對(duì)稱、字段無(wú)法擴(kuò)展等情況。
提高數(shù)據(jù)的擴(kuò)展性，還可以采用分布式數(shù)據(jù)存儲(chǔ)技術(shù)，將數(shù)據(jù)分散到多個(gè)節(jié)點(diǎn)，這樣可以增加系統(tǒng)的可擴(kuò)展性，提高數(shù)據(jù)存取速度和數(shù)據(jù)容量。
四、數(shù)據(jù)維護(hù)和管理要求
IM系統(tǒng)中的數(shù)據(jù)維護(hù)和管理也是關(guān)鍵的因素。數(shù)據(jù)維護(hù)主要是指保證數(shù)據(jù)的完整性和準(zhǔn)確性，防止數(shù)據(jù)的丟失和損壞。開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)需要定期檢查和審查系統(tǒng)數(shù)據(jù)的狀態(tài)，并檢測(cè)是否存在異常，以及必要時(shí)對(duì)數(shù)據(jù)進(jìn)行修正和清理。
數(shù)據(jù)管理則是指對(duì)數(shù)據(jù)庫(kù)實(shí)例的管理，如備份、恢復(fù)、監(jiān)控、調(diào)優(yōu)等，需要經(jīng)常進(jìn)行。數(shù)據(jù)備份的頻率應(yīng)該根據(jù)具體情況來(lái)選擇，保證系統(tǒng)在遇到問(wèn)題后能夠及時(shí)地恢復(fù)數(shù)據(jù)，而對(duì)于數(shù)據(jù)庫(kù)的性能監(jiān)控和調(diào)優(yōu)，可以通過(guò)技術(shù)手段，如數(shù)據(jù)復(fù)制、數(shù)據(jù)緩存等，提高數(shù)據(jù)庫(kù)的性能。
IM系統(tǒng)數(shù)據(jù)庫(kù)的設(shè)計(jì)是非常重要的，因?yàn)樗P(guān)系到IM系統(tǒng)的性能、可靠性和安全性，設(shè)計(jì)不合理會(huì)帶來(lái)負(fù)面影響。以上分析了數(shù)據(jù)庫(kù)的性能和穩(wěn)定性、數(shù)據(jù)安全性、數(shù)據(jù)的擴(kuò)展性以及數(shù)據(jù)的維護(hù)和管理等因素。因此，設(shè)計(jì)合適的數(shù)據(jù)庫(kù)可以滿足IM系統(tǒng)的需求，并保證其良好的性能和穩(wěn)定性。
相關(guān)問(wèn)題拓展閱讀：
- 做混合的話Uniapp和Flutter我應(yīng)該學(xué)哪個(gè)??？
做混合的話Uniapp和Flutter我應(yīng)該學(xué)哪個(gè)??？
Uniapp目前比較成熟，而且用的是Vue語(yǔ)法桐埋，學(xué)習(xí)成畢知本比較低，而且行業(yè)里面用的也比較廣泛，而Flutter的話，學(xué)習(xí)成本略高，因?yàn)橐獙W(xué)習(xí)新的語(yǔ)言，還有就是目前生態(tài)不是特別完備，等他再發(fā)展手輪消發(fā)展吧。黑馬程序員官網(wǎng)有成套免費(fèi)視頻哦，有什么不懂的可以直接過(guò)去學(xué)習(xí)。您的采納是對(duì)我成長(zhǎng)的鞭策
?
本文由阿里閑魚(yú)技術(shù)團(tuán)隊(duì)祈晴分享，本次有修訂和改動(dòng)，感謝作者的技術(shù)分享。
1、內(nèi)容概述
本文總結(jié)了阿里閑魚(yú)技術(shù)團(tuán)隊(duì)使用Flutter在對(duì)閑魚(yú)IM進(jìn)行移動(dòng)端跨端改造過(guò)程中的技術(shù)實(shí)踐等，文中對(duì)比了傳統(tǒng)Native與現(xiàn)在大熱的Flutter跨端方案在一些主要技術(shù)實(shí)現(xiàn)上的差異，以及針對(duì)Flutter技術(shù)特點(diǎn)的具體技術(shù)實(shí)現(xiàn)，值得同樣準(zhǔn)備使用Flutter開(kāi)發(fā)IM的技術(shù)同行們借鑒和參考。
學(xué)習(xí)交流：
– 移動(dòng)端IM開(kāi)發(fā)入門(mén)文章：《新手入門(mén)一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》
– 開(kāi)源IM框架源碼：
（本文同步發(fā)布于：
2、閑魚(yú)IM現(xiàn)狀
閑魚(yú)IM的移動(dòng)端框架構(gòu)建于2023至2023年間，期間經(jīng)過(guò)多次迭代升級(jí)導(dǎo)致歷史包袱累積多，后面又經(jīng)歷IM界面的Flutter化，從而造成了客戶端架構(gòu)愈加復(fù)雜。
從開(kāi)發(fā)層面總結(jié)閑魚(yú)IM移動(dòng)端當(dāng)前架構(gòu)主要存在如下幾個(gè)問(wèn)題：
1）研發(fā)效率較低：當(dāng)前架構(gòu)涉及到Android/iOS雙端的邏輯代碼以及Flutter的UI代碼，定位問(wèn)題往往只能從Flutter UI表相倒查到Native邏輯層；
2）架構(gòu)層次較差：架構(gòu)設(shè)計(jì)上分層不清晰，業(yè)務(wù)邏輯夾雜在核心的邏輯層致使代碼變更風(fēng)險(xiǎn)大；
3）性能測(cè)試略差：核心數(shù)據(jù)源存儲(chǔ)Native內(nèi)存，需經(jīng)Flutter Plugin將數(shù)據(jù)源序列化上拋Flutter側(cè)，在大批量數(shù)據(jù)源情況下性能表現(xiàn)較差。
從產(chǎn)品層面總結(jié)閑魚(yú)IM移動(dòng)端當(dāng)前架構(gòu)的主要問(wèn)題如下：
1）定位問(wèn)題困難：線上輿情反饋千奇百怪，測(cè)試始終無(wú)法復(fù)現(xiàn)相關(guān)場(chǎng)景，因此很多時(shí)候只能靠現(xiàn)象猜測(cè)本質(zhì)；
2）疑難雜癥較多：架構(gòu)的不穩(wěn)定性造成出現(xiàn)的問(wèn)題反復(fù)出現(xiàn)，雹舉當(dāng)前疑難雜癥主要包括未讀紅點(diǎn)計(jì)數(shù)、iPhone5C低端機(jī)以及多媒體發(fā)送等多個(gè)問(wèn)題；
3）問(wèn)題差異性大：Android和iOS兩端邏輯代碼差異大，包括埋點(diǎn)邏輯都不盡相同，排查問(wèn)題根源時(shí)雙端都會(huì)有不同根因，解決方案也不相同。
3、業(yè)界的移動(dòng)端跨端方案
為解決當(dāng)前IM的技術(shù)痛點(diǎn)，閑魚(yú)今年特起關(guān)于IM架構(gòu)升級(jí)項(xiàng)目，重在解決客戶端中Andriod和iOS雙端一致性的痛點(diǎn)，初步設(shè)想方案就是實(shí)現(xiàn)跨端統(tǒng)一的Android/iOS邏輯架構(gòu)。
在當(dāng)前行業(yè)內(nèi)跨端方案可初步歸類如下圖架構(gòu)：
在GUI層面的跨端方案有Weex、ReactNative、H5、Uni-APP等，其內(nèi)存模型大多需要通過(guò)橋接到Native模式存儲(chǔ)。
在邏輯層面的跨端方案大致有C/C++等與虛擬機(jī)無(wú)關(guān)語(yǔ)言實(shí)現(xiàn)跨端，當(dāng)然匯編語(yǔ)言也可行。
此外有兩個(gè)獨(dú)立于上述體系之外的架構(gòu)就是Flutter和KMM（谷歌基于Kotlin實(shí)現(xiàn)類似Flutter架構(gòu)），其中Flutter運(yùn)行特定DartVM，將內(nèi)存數(shù)據(jù)掛載其自身的isolate中。
考慮閑魚(yú)是Flutter的前沿探索者，方案上優(yōu)先使用Flutter。然而Flutter的isolate更像一個(gè)進(jìn)程的概念（底層實(shí)現(xiàn)非使用進(jìn)程模式），相比Android，同一進(jìn)程場(chǎng)景中，Android的Dalvik虛擬機(jī)多個(gè)線程運(yùn)行共享一個(gè)內(nèi)存Heap，而DartVM的Isolate運(yùn)行隔離各自的Heap，因而isolate之間通訊方式比較繁瑣（需經(jīng)過(guò)序列化反序列化過(guò)程）。
整個(gè)模型如下圖所示：
若按官方混合架構(gòu)實(shí)現(xiàn)Flutter應(yīng)用，開(kāi)啟多個(gè)FlutterAcitivty/FlutterController，底層會(huì)生成多個(gè)Engine，對(duì)應(yīng)會(huì)存在多個(gè)isolate，而isolate通訊類似于進(jìn)程通訊（類似socket或AIDL），這里借鑒閑魚(yú)FlutterBoost的設(shè)計(jì)理念，F(xiàn)lutterIM架構(gòu)將多個(gè)頁(yè)面的Engine共享，則內(nèi)存模型就天然支持共享讀取。
原理圖如下：
4、閑魚(yú)IM基于首肆配Flutter的架構(gòu)設(shè)計(jì)
4.1 新老架構(gòu)對(duì)比
如下圖所示：
是一個(gè)老架構(gòu)方案，其核心問(wèn)題主要集中于者指Native邏輯抽象差，其中邏輯層面還設(shè)計(jì)到多線程并發(fā)使得問(wèn)題倍增，Android/iOS/Flutter交互繁雜，開(kāi)發(fā)維護(hù)成本高，核心層耦合較為嚴(yán)重，無(wú)插拔式概念.
考慮到歷史架構(gòu)的問(wèn)題，演進(jìn)如下新架構(gòu)設(shè)計(jì)：
如上圖所示，架構(gòu)從上至下依次為：
1）業(yè)務(wù)層；
2）分發(fā)層；
3）邏輯層；
4）數(shù)據(jù)源層。
數(shù)據(jù)源層來(lái)源于推送或網(wǎng)絡(luò)請(qǐng)求，其封裝于Native層，通過(guò)Flutter插件將消息協(xié)議數(shù)據(jù)上拋到Flutter側(cè)的核心邏輯層，處理完成后變成Flutter DB的Enitity實(shí)體，實(shí)體中掛載一些消息協(xié)議實(shí)體。
核心邏輯層將繁雜數(shù)據(jù)扁平化打包掛載到分發(fā)層中的會(huì)話內(nèi)存模型數(shù)據(jù)或消息內(nèi)存模型數(shù)據(jù)，最后通過(guò)觀察者模式的訂閱分發(fā)到業(yè)務(wù)邏輯中。
Flutter IM重點(diǎn)集中改造邏輯層和分發(fā)層，將IM核心邏輯和業(yè)務(wù)層面數(shù)據(jù)模型進(jìn)行封裝隔離，核心邏輯層和數(shù)據(jù)庫(kù)交互后將數(shù)據(jù)封裝到分發(fā)層的moduleData中，通過(guò)訂閱方式分發(fā)到業(yè)務(wù)層數(shù)據(jù)模型中。
此外在IM模型中DB也是重點(diǎn)依賴的，個(gè)人對(duì)DB數(shù)據(jù)庫(kù)管理進(jìn)行全面封裝解，實(shí)現(xiàn)一種輕量級(jí)，性能佳的Flutter DB管理框架。
4.2 DB存儲(chǔ)模型
Flutter IM架構(gòu)的DB存儲(chǔ)依賴數(shù)據(jù)庫(kù)插件，目前主流插件是Sqflite。
其存儲(chǔ)模型如下：
依據(jù)上圖Sqflite插件的DB存儲(chǔ)模型會(huì)有2個(gè)等待隊(duì)列：
一個(gè)是Flutter層同步執(zhí)行隊(duì)列；
一個(gè)是Native層的線程執(zhí)行隊(duì)列。
其Android實(shí)現(xiàn)機(jī)制是HandlerThread，因此Query/Save讀寫(xiě)在會(huì)同一線程隊(duì)列中，導(dǎo)致響應(yīng)速度慢，容易造成DB SQL堆積，此外缺失緩存模型。
于是個(gè)人定制如下改進(jìn)方案：
Flutter側(cè)通過(guò)表的主鍵設(shè)計(jì)查詢時(shí)候會(huì)優(yōu)先從Entity Cache層去獲取，若緩存不存在，則通過(guò)Sqflite插件查詢。
同時(shí)改造Sqflite插件成支持sync/Async同步異步兩種方式操作，對(duì)應(yīng)到Native側(cè)也會(huì)有同步線程隊(duì)列和異步線程隊(duì)列，保證數(shù)據(jù)吞吐率。但是這里建議查詢使用異步，存儲(chǔ)使用同步更穩(wěn)妥，主要怕出現(xiàn)多個(gè)相同的數(shù)據(jù)元model同一時(shí)間進(jìn)入異步線程池中，存儲(chǔ)先后順序無(wú)法有效的保證。
4.3 ORM數(shù)據(jù)庫(kù)方案
IM架構(gòu)重度依賴DB數(shù)據(jù)庫(kù)，而當(dāng)前業(yè)界還沒(méi)有一個(gè)完備的數(shù)據(jù)庫(kù)ORM管理方案，參考了Android的OrmLite/GreenDao，個(gè)人自行設(shè)計(jì)一套Flutter ORM數(shù)據(jù)庫(kù)管理方案。
其核心思想如下：
由于Flutter不支持反射，因此無(wú)法直接像Android的開(kāi)源數(shù)據(jù)庫(kù)方式操作，但可通過(guò)APT方式，將Entity和Orm Entity綁定于一身，操作OrmEntity即操作Entity，整個(gè)代碼風(fēng)格設(shè)計(jì)也和OrmLite極其相似。
參考代碼如下：
4.4 IM內(nèi)存數(shù)據(jù)模型
基于Flutter的IM移動(dòng)端架構(gòu)在內(nèi)存數(shù)據(jù)模型主要?jiǎng)澐譃闀?huì)話和消息兩個(gè)顆粒度：
1）會(huì)話內(nèi)存數(shù)據(jù)模型交托于SessionModuleData：會(huì)話內(nèi)存數(shù)據(jù)有一個(gè)根節(jié)點(diǎn)RootNotice，然后其掛載PSessionMessageNotice（這里PSessionMessageNotice是ORM映射的會(huì)話DB表模型）子節(jié)點(diǎn)。
2）消息內(nèi)存數(shù)據(jù)模型交托于MessageModuleData：消息內(nèi)存數(shù)據(jù)會(huì)有一個(gè)MessageConatiner容器管理，其內(nèi)部掛載此會(huì)話中的PMessage(PMessage是ORM映射的消息DB表模型)消息。
依據(jù)上一章節(jié)，PSessionMessageNotice設(shè)計(jì)了一個(gè)OrmEnitity Cache，考慮到IM中會(huì)話數(shù)是有限的，因此PSessionMessageNotice都是直接緩存到Cache中。
這種做法的好處是各地去拿會(huì)話數(shù)據(jù)元時(shí)候都是緩存中同一個(gè)對(duì)象，容易保證多次重復(fù)讀寫(xiě)的數(shù)據(jù)一致性。而PSessionMessageNotice考慮到其數(shù)量可以無(wú)限多的特殊性，因此這里將其掛載到MessageContainer的內(nèi)存管理中，在退出會(huì)話的時(shí)機(jī)會(huì)校驗(yàn)容器中PMessage的數(shù)量，適當(dāng)縮容可以減少內(nèi)存開(kāi)銷。
模型如下圖所示：
4.5 狀態(tài)管理方案
基于Flutter的IM移動(dòng)端架構(gòu)狀態(tài)管理方案比較簡(jiǎn)單，對(duì)數(shù)據(jù)源Session/Message維度使用觀察者模式的訂閱分發(fā)方式實(shí)現(xiàn)，架構(gòu)類似于EventBus模式，頁(yè)面級(jí)的狀態(tài)管理無(wú)論使用fish-redux、scopeModel或者provider幾乎影響面不大，核心還是需保留一種插拔式抽象更重要。
架構(gòu)如下圖：
4.6 IM同步模型方案
當(dāng)前現(xiàn)狀的消息同步模型：
如上圖所示是，模型中存在ACCS Thread/Main Thread/Region Thread等多線程并發(fā)場(chǎng)景，導(dǎo)致易出現(xiàn)多線程高并發(fā)的問(wèn)題。
native的推送和網(wǎng)絡(luò)請(qǐng)求同步的隔離方案通過(guò)Lock的鎖機(jī)制，并且通過(guò)隊(duì)列降頻等方式處理，流程繁瑣且易出錯(cuò)。整體通過(guò)Region Version Gap去判斷是否有域空洞，進(jìn)而執(zhí)行域同步補(bǔ)充數(shù)據(jù)。
改進(jìn)的同步模型如下：
如上圖所示，在Flutter側(cè)天然沒(méi)多線程場(chǎng)景，通過(guò)一種標(biāo)記位的轉(zhuǎn)化同步異步實(shí)現(xiàn)類似Handler消息隊(duì)列，架構(gòu)清晰簡(jiǎn)約了很多，避免鎖帶來(lái)的開(kāi)銷以及同步問(wèn)題。
5、本次改造進(jìn)展以及性能對(duì)比
1）針對(duì)架構(gòu)層面：
在基于Flutter的IM架構(gòu)中，重點(diǎn)將雙端邏輯差異性統(tǒng)一成同一份Dart代碼，完全磨平Android/iOS的代碼差異性帶來(lái)的問(wèn)題。
帶來(lái)的好處很明顯：
1）降低開(kāi)發(fā)維護(hù)、測(cè)試回歸、視覺(jué)驗(yàn)收的一半成本，極大提高研發(fā)效率；
2）架構(gòu)上進(jìn)行重構(gòu)分層，實(shí)現(xiàn)一種解耦合，插拔式的IM架構(gòu)；
3）同時(shí)Native到Flutter側(cè)的大量數(shù)據(jù)上拋序列化過(guò)程改造程Flutter引用傳遞，解決極限測(cè)試場(chǎng)景下的私聊卡頓問(wèn)題。
2）針對(duì)線上輿情：
1）補(bǔ)齊UT和TLog的集團(tuán)日志方式做到可追蹤，可排查；
2）針對(duì)于很多現(xiàn)存的疑難雜癥重點(diǎn)集中專項(xiàng)解決，比如iphone5C的架構(gòu)在Flutter側(cè)統(tǒng)一規(guī)劃；
3）未讀紅點(diǎn)計(jì)數(shù)等問(wèn)題也在架構(gòu)模型升級(jí)中修復(fù)；
4）此外多媒體音視頻發(fā)送模塊進(jìn)行改造升級(jí)。
3）性能數(shù)據(jù)對(duì)比：
當(dāng)IM架構(gòu)的邏輯層和UI層都切換成Flutter后，和原先架構(gòu)模式初步對(duì)比，整體內(nèi)存水位持平。
其中：
1）私聊場(chǎng)景下小米9測(cè)試結(jié)構(gòu)內(nèi)存下降40M，功耗降低4mah，CPU降低1%；
2）極限測(cè)試場(chǎng)景下新架構(gòu)內(nèi)存數(shù)據(jù)相比于舊架構(gòu)有一個(gè)較為明顯的改觀（主要由于兩個(gè)界面都使用Flutter場(chǎng)景下，頁(yè)面切換的開(kāi)銷降低很多）。
6、未來(lái)展望
跨端不安全，C++跨端成本有點(diǎn)高，F(xiàn)lutter會(huì)是一個(gè)較好選擇。彼時(shí)閑魚(yú)FlutterIM架構(gòu)升級(jí)根本目的從來(lái)不是因Flutter而Flutter，是由于歷史包袱的繁重，代碼層面的維護(hù)成本高，新業(yè)務(wù)的擴(kuò)展性差，人力配比不協(xié)調(diào)以及疑難雜癥的輿情持續(xù)反饋等等因素造成我們不得不去探索新方案。
經(jīng)過(guò)閑魚(yú)IM超復(fù)雜業(yè)務(wù)場(chǎng)景驗(yàn)證Flutter模式的邏輯跨端可行性，閑魚(yú)在Flutter路上會(huì)一直保持前沿探索，最后能反饋到生態(tài)圈。
總結(jié)一句話，探索過(guò)程在于你勇于邁出之一步，后面才會(huì)不斷驚喜發(fā)現(xiàn)。
（原文鏈接：點(diǎn)此進(jìn)入，本次有修訂和改動(dòng)）
附錄：更多文章匯總
更多阿里團(tuán)隊(duì)的文章分享：
《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過(guò)人之處》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》
《來(lái)自阿里OpenIM：打造安全可靠即時(shí)通訊服務(wù)的技術(shù)實(shí)踐分享》
《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺(tái)的技術(shù)挑戰(zhàn)(視頻+PPT) 》
《阿里技術(shù)結(jié)晶：《阿里巴巴Java開(kāi)發(fā)手冊(cè)(規(guī)約)-華山版》》
《重磅發(fā)布：《阿里巴巴Android開(kāi)發(fā)手冊(cè)(規(guī)約)》》
《作者談《阿里巴巴Java開(kāi)發(fā)手冊(cè)(規(guī)約)》背后的故事》
《《阿里巴巴Android開(kāi)發(fā)手冊(cè)(規(guī)約)》背后的故事》
《干了這碗雞湯：從理發(fā)店小弟到阿里P10技術(shù)大?！?/p>
《揭秘阿里、騰訊、華為、百度的職級(jí)和薪酬體系》
《淘寶技術(shù)分享：手淘億級(jí)移動(dòng)端接入層網(wǎng)關(guān)的技術(shù)演進(jìn)之路》
《難得干貨，揭秘支付寶的2維碼掃碼技術(shù)優(yōu)化實(shí)踐之路》
《淘寶直播技術(shù)干貨：高清、低延時(shí)的實(shí)時(shí)視頻直播技術(shù)解密》
《阿里技術(shù)分享：電商IM消息平臺(tái)，在群聊、直播場(chǎng)景下的技術(shù)實(shí)踐》
《阿里技術(shù)分享：閑魚(yú)IM基于Flutter的移動(dòng)端跨端改造實(shí)踐》
更多IM開(kāi)發(fā)綜合文章：
《新手入門(mén)一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》
《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》
《移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《從客戶端的角度來(lái)談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》
《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《移動(dòng)端IM開(kāi)發(fā)需要面對(duì)的技術(shù)問(wèn)題》
《開(kāi)發(fā)IM是自己設(shè)計(jì)協(xié)議用字節(jié)流好還是字符流好？》
《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》
《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》
《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》
《一個(gè)低成本確保IM消息時(shí)序的方法探討》
《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《談?wù)勔苿?dòng)端 IM 開(kāi)發(fā)中登錄請(qǐng)求的優(yōu)化》
《移動(dòng)端IM登錄時(shí)拉取數(shù)據(jù)如何作到省流量？》
《淺談移動(dòng)端IM的多點(diǎn)登錄和消息漫游原理》
《完全自已開(kāi)發(fā)的IM該如何設(shè)計(jì)“失敗重試”機(jī)制？》
《通俗易懂：基于集群的移動(dòng)端IM接入層負(fù)載均衡方案分享》
《微信對(duì)網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》
《開(kāi)源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場(chǎng)有始無(wú)終的開(kāi)源秀》
《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開(kāi)源》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》
《自已開(kāi)發(fā)IM有那么難嗎？手把手教你自擼一個(gè)Andriod版簡(jiǎn)易IM (有源碼)》
《融云技術(shù)分享：解密融云IM產(chǎn)品的聊天消息ID生成策略》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(六)：數(shù)據(jù)庫(kù)用NoSQL還是SQL？讀這篇就夠了！》
《適合新手：從零開(kāi)發(fā)一個(gè)IM服務(wù)端（基于Netty，有完整源碼）》
《拿起鍵盤(pán)就是干：跟我一起徒手開(kāi)發(fā)一套分布式IM系統(tǒng)》
《適合新手：手把手教你用Go快速搭建高性能、可擴(kuò)展的IM系統(tǒng)(有源碼)》
《IM里“附近的人”功能實(shí)現(xiàn)原理是什么？如何高效率地實(shí)現(xiàn)它？》
《IM“掃一掃”功能很好做？看看微信“掃一掃識(shí)物”的完整技術(shù)實(shí)現(xiàn)》
《IM消息ID技術(shù)專題(一)：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》
《IM消息ID技術(shù)專題(二)：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》
《IM消息ID技術(shù)專題(三)：解密融云IM產(chǎn)品的聊天消息ID生成策略》
《IM消息ID技術(shù)專題(四)：深度解密美團(tuán)的分布式ID生成算法》
《IM消息ID技術(shù)專題(五)：開(kāi)源分布式ID生成器UidGenerator的技術(shù)實(shí)現(xiàn)》
《IM消息ID技術(shù)專題(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
《IM開(kāi)發(fā)寶典：史上最全，微信各種功能參數(shù)和邏輯規(guī)則資料匯總》
《IM開(kāi)發(fā)干貨分享：我是如何解決大量離線消息導(dǎo)致客戶端卡頓的》
《零基礎(chǔ)IM開(kāi)發(fā)入門(mén)(一)：什么是IM系統(tǒng)？》
《零基礎(chǔ)IM開(kāi)發(fā)入門(mén)(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？》
《零基礎(chǔ)IM開(kāi)發(fā)入門(mén)(三)：什么是IM系統(tǒng)的可靠性？》
《零基礎(chǔ)IM開(kāi)發(fā)入門(mén)(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？》
《IM開(kāi)發(fā)干貨分享：如何優(yōu)雅的實(shí)現(xiàn)大量離線消息的可靠投遞》
《IM開(kāi)發(fā)干貨分享：有贊移動(dòng)端IM的組件化SDK架構(gòu)設(shè)計(jì)實(shí)踐》
《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》
《IM掃碼登錄技術(shù)專題(一)：微信的掃碼登錄功能技術(shù)原理調(diào)試分析》
《IM掃碼登錄技術(shù)專題(二)：市面主流的掃碼登錄技術(shù)原理調(diào)試分析》
《IM掃碼登錄技術(shù)專題(三)：通俗易懂，IM掃碼登錄功能詳細(xì)原理一篇就夠》
《理解IM消息“可靠性”和“一致性”問(wèn)題，以及解決方案探討》
《阿里技術(shù)分享：閑魚(yú)IM基于Flutter的移動(dòng)端跨端改造實(shí)踐》
>> 更多同類文章 ……
本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)。
同步發(fā)布鏈接是：
王紅元《Flutter從入門(mén)到實(shí)戰(zhàn)》（高清視頻）百度網(wǎng)盤(pán)
鏈接:
提取敏橋碼: j6z6 復(fù)制這段內(nèi)容后打開(kāi)百度網(wǎng)盤(pán)手機(jī)App，操作更方便哦
關(guān)于im系統(tǒng) 數(shù)據(jù)庫(kù)設(shè)計(jì)的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
成都創(chuàng)新互聯(lián)科技有限公司，是一家專注于互聯(lián)網(wǎng)、IDC服務(wù)、應(yīng)用軟件開(kāi)發(fā)、網(wǎng)站建設(shè)推廣的公司，為客戶提供互聯(lián)網(wǎng)基礎(chǔ)服務(wù)！
創(chuàng)新互聯(lián)（www.cdcxhl.com）提供簡(jiǎn)單好用，價(jià)格厚道的香港/美國(guó)云服務(wù)器和獨(dú)立服務(wù)器。創(chuàng)新互聯(lián)——四川成都IDC機(jī)房服務(wù)器托管/機(jī)柜租用。為您精選優(yōu)質(zhì)idc數(shù)據(jù)中心機(jī)房租用、服務(wù)器托管、機(jī)柜租賃、大帶寬租用，高電服務(wù)器托管，算力服務(wù)器租用，可選線路電信、移動(dòng)、聯(lián)通機(jī)房等。
網(wǎng)頁(yè)名稱：IM系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)的關(guān)鍵因素來(lái)分析(im系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì))
網(wǎng)站鏈接：http://www.dlmjj.cn/article/ccicjci.html
