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