IM開發基礎知識補課(六)：數據庫用NoSQL仍是SQL？讀這篇就夠了！
原文來源：51CTO技術棧公衆號，本文原題：NoSQL仍是SQL？這一篇講清楚，收錄時有修訂和改動。html
一、引言
隨着互聯網大數據時代的到來，愈來愈多的網站、應用系統都須要支撐大量甚至海量數據存儲，同時還伴有高併發、高可用、高可擴展等特性要求。算法
不少時候，傳統的關係型數據庫在應付這些已經顯得力不從心，並暴露了許多難以克服的問題。數據庫
由此，各類各樣的 NoSQL（Not Only SQL）數據庫做爲傳統關係型數據的一個有力補充獲得迅猛發展。編程
本文將分析傳統數據庫（即SQL數據庫）存在的一些問題，以及盤點目前市面上幾大類 NoSQL 特性、優缺點等，但願給你們提供一些在不一樣業務場景下存儲技術選型方面的參考。後端
點評：做爲專業分享即時通信開發知識的社區來講，不少IM開發者在進行架構設計和選型的第一時間想到的，就是該如何選擇數據庫，MySQL？Oracle？SQL Server？或者NoSQL？這顯然沒有標準答案，由於每一個產品、每套系統、每一個架構都有自身的用戶規模、適應場景、成本因素等等考量。本文可能沒法給予同爲即時通信開發者的你一個確切答案，但當你在讀完本文，對市面上主要數據庫（包括NoSQL數據庫）的技術特性、適用場景、優缺點都有了解以後，相信你徹底可以根據自已產品或系統的特色，找到適合你的數據庫方案，這也正是本文的意義所在。緩存
學習交流：安全
- 即時通信/推送技術開發交流5羣：215477170 [推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發佈於：http://www.52im.net/thread-27...）服務器
二、關於做者
陳彩華（caison）：主要從事服務端開發、需求分析、系統設計、優化重構工做，主要開發語言是 Java，現任廣州貝聊服務端研發工程師。微信
陳彩華還分享過另幾篇技術文章，若有興趣可一併閱讀：網絡
《新手入門：目前爲止最透徹的的Netty高性能原理和框架架構解析》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
三、系列文章
▼ IM開發乾貨系列文章（本文是其第18篇）：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的「時序性」與「一致性」？》
《IM單聊和羣聊中的在線狀態同步應該用「推」仍是「拉」？》
《IM羣聊消息如此複雜，如何保證不丟不重？》
《一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）》
《移動端IM登陸時拉取數據如何做到省流量？》
《通俗易懂：基於集羣的移動端IM接入層負載均衡方案分享》
《淺談移動端IM的多點登錄和消息漫遊原理》
《IM開發基礎知識補課(一)：正確理解前置HTTP SSO單點登錄接口的原理》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《IM羣聊消息的已讀回執功能該怎麼實現？》
《IM羣聊消息到底是存1份(即擴散讀)仍是存多份(即擴散寫)？》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《一個低成本確保IM消息時序的方法探討》
《IM開發基礎知識補課(六)：數據庫用NoSQL仍是SQL？讀這篇就夠了！》（本文）
若是您是IM開發初學者，強烈建議首先閱讀《新手入門一篇就夠：從零開發移動端IM》。
四、傳統SQL數據庫的缺點
傳統的關係數據庫有以下幾個缺點。
1）大數據場景下 I/O 較高：由於數據是按行存儲，即便只針對其中某一列進行運算，關係型數據庫也會將整行數據從存儲設備中讀入內存，致使 I/O 較高。
2）存儲的是行記錄：沒法存儲數據結構。
3）表結構 Schema 擴展不方便：如要修改表結構，須要執行 DDL(data definition language)，語句修改，修改期間會致使鎖表，部分服務不可用。
4）全文搜索功能較弱：關係型數據庫下只可以進行子字符串的匹配查詢，當表的數據逐漸變大的時候，like 查詢的匹配會很是慢，即便在有索引的狀況下。何況關係型數據庫也不該該對文本字段進行索引。
5）存儲和處理複雜關係型數據功能較弱：許多應用程序須要瞭解和導航高度鏈接數據之間的關係，才能啓用社交應用程序、推薦引擎、欺詐檢測、知識圖譜、生命科學和 IT/網絡等用例。然而傳統的關係數據庫並不善於處理數據點之間的關係。它們的表格數據模型和嚴格的模式使它們很難添加新的或不一樣種類的關聯信息。
五、NoSQL 解決方案
NoSQL（Not Only SQL），泛指非關係型的數據庫，能夠理解爲 SQL 的一個有力補充。
在 NoSQL 許多方面性能大大優於非關係型數據庫的同時，每每也伴隨一些特性的缺失，比較常見的是事務庫事務功能的缺失。
數據庫事務正確執行的四個基本要素 ACID 以下：
下面將分別介紹 5 大類 NoSQL 數據庫的技術特性，以及針對傳統關係型數據庫的缺點。
六、列式數據庫
列式數據庫是以列相關存儲架構進行數據存儲的數據庫，主要適合於批量數據處理和即時查詢。
相對應的是行式數據庫，數據以行相關的存儲體系架構進行空間分配，主要適合於小批量的數據處理，經常使用於聯機事務型數據處理。
基於列式數據庫的列列存儲特性，能夠解決某些特定場景下關係型數據庫 I/O 較高的問題。
6.1 基本原理
傳統關係型數據庫是按照行來存儲數據庫，稱爲「行式數據庫」，而列式數據庫是按照列來存儲數據。
將表放入存儲系統中有兩種方法，而咱們絕大部分是採用行存儲的。行存儲法是將各行放入連續的物理位置，這很像傳統的記錄和文件系統。
列存儲法是將數據按照列存儲到數據庫中，與行存儲相似。
下圖是兩種存儲方法的圖形化解釋：
6.2 常見列式數據庫
HBase：是一個開源的非關係型分佈式數據庫（NoSQL），它參考了谷歌的 BigTable 建模，實現的編程語言爲 Java。
它是 Apache 軟件基金會的 Hadoop 項目的一部分，運行於 HDFS 文件系統之上，爲 Hadoop 提供相似於 BigTable 規模的服務。所以，它能夠容錯地存儲海量稀疏的數據。
BigTable：是一種壓縮的、高性能的、高可擴展性的，基於 Google 文件系統（Google File System，GFS）的數據存儲系統，用於存儲大規模結構化數據，適用於雲端計算。
6.3 相關特性
1）優勢以下：
高效的儲存空間利用率：列式數據庫因爲其針對不一樣列的數據特徵而發明的不一樣算法使其每每有比行式數據庫高的多的壓縮率。
普通的行式數據庫通常壓縮率在 3：1 到 5：1 左右，而列式數據庫的壓縮率通常在 8：1 到 30：1 左右。
比較常見的，經過字典表壓縮數據： 下面中才是那張表原本的樣子。通過字典表進行數據壓縮後，表中的字符串才都變成數字了。
正由於每一個字符串在字典表裏只出現一次了，因此達到了壓縮的目的(有點像規範化和非規範化 Normalize 和 Denomalize)。
查詢效率高：讀取多條數據的同一列效率高，由於這些列都是存儲在一塊兒的，一次磁盤操做能夠把數據的指定列所有讀取到內存中。
下圖經過一條查詢的執行過程說明列式存儲(以及數據壓縮)的優勢：
執行步驟以下：
a. 去字典表裏找到字符串對應數字(只進行一次字符串比較)；
b. 用數字去列表裏匹配，匹配上的位置設爲 1。；
c. 把不一樣列的匹配結果進行位運算獲得符合全部條件的記錄下標；
d. 使用這個下標組裝出最終的結果集。
列式數據庫還適合作聚合操做，適合大量的數據而不是小數據。
2）缺點以下：
不適合掃描小量數據；
不適合隨機的更新；
不適合作含有刪除和更新的實時操做；
單行的數據是 ACID 的，多行的事務時，不支持事務的正常回滾，支持 I(Isolation)隔離性(事務串行提交)，D(Durability)持久性，不能保證 A(Atomicity)原子性， C(Consistency)一致性。
6.3 使用場景
以 HBase 爲例說明：
1）大數據量（100s TB級數據），且有快速隨機訪問的需求；
2）寫密集型應用，天天寫入量巨大，而相對讀數量較小的應用，好比 IM 的歷史消息，遊戲的日誌等等；
3）不須要複雜查詢條件來查詢數據的應用，HBase 只支持基於 rowkey 的查詢，對於 HBase 來講，單條記錄或者小範圍的查詢是能夠接受的。大範圍的查詢因爲分佈式的緣由，可能在性能上有點影響，HBase 不適用於有 join，多級索引，表關係複雜的數據模型；
4）對性能和可靠性要求很是高的應用，因爲 HBase 自己沒有單點故障，可用性很是高；
5）數據量較大並且增加量沒法預估的應用，須要進行優雅的數據擴展的 HBase 支持在線擴展，即便在一段時間內數據量呈井噴式增加，也能夠經過 HBase 橫向擴展來知足功能；
6）存儲結構化和半結構化的數據。
七、K-V 數據庫
指的是使用鍵值(key-value)存儲的數據庫，其數據按照鍵值對的形式進行組織、索引和存儲。
K-V 存儲很是適合不涉及過多數據關係業務關係的數據，同時能有效減小讀寫磁盤的次數，比 SQL 數據庫存儲擁有更好的讀寫性能，可以解決關係型數據庫沒法存儲數據結構的問題。
7.1 常見 K-V 數據庫
Redis：是一個使用 ANSI C 編寫的開源、支持網絡、基於內存、可選持久性的鍵值對存儲數據庫。
從 2015 年 6 月開始，Redis 的開發由 Redis Labs 贊助，而 2013 年 5 月至 2015 年 6 月期間，其開發由 Pivotal 贊助。
在 2013 年 5 月以前，其開發由 VMware 贊助。根據月度排行網站 DB-Engines.com 的數據顯示，Redis 是最流行的鍵值對存儲數據庫。
Cassandra：Apache Cassandra（社區內通常簡稱爲C*）是一套開源分佈式 NoSQL 數據庫系統。
它最初由 Facebook 開發，用於儲存收件箱等簡單格式數據，集 Google BigTable 的數據模型與 Amazon Dynamo 的徹底分佈式架構於一身。
Facebook 於 2008 將 Cassandra 開源，此後，因爲 Cassandra 良好的可擴展性和性能。
它被 Apple，Comcas，Instagram，Spotify，eBay，Rackspace，Netflix 等知名網站所採用，成爲了一種流行的分佈式結構化數據存儲方案。
LevelDB：是一個由 Google 公司所研發的鍵／值對（Key/Value Pair）嵌入式數據庫管理系統編程庫， 以開源的 BSD 許可證發佈。
7.2 相關特性
以 Redis 爲例，K-V 數據庫優勢以下：
1）性能極高：Redis 能支持超過 10W 的 TPS；
2）豐富的數據類型：Redis 支持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperloglog；
3）豐富的特性：Redis 還支持 publish/subscribe，通知，key 過時等等特性。
缺點以下：
針對 ACID，Redis 事務不能支持原子性和持久性(A 和 D)，只支持隔離性和一致性(I 和 C) 。
特別說明一下：這裏所說的沒法保證原子性，是針對 Redis 的事務操做，由於事務是不支持回滾（roll back），而由於 Redis 的單線程模型，Redis 的普通操做是原子性的。
大部分業務不須要嚴格遵循 ACID 原則，例如遊戲實時排行榜，粉絲關注等場景，即便部分數據持久化失敗，其實業務影響也很是小。所以在設計方案時，須要根據業務特徵和要求來作選擇。
7.3 使用場景
適用場景：
儲存用戶信息(好比會話)、配置文件、參數、購物車等等。這些信息通常都和 ID（鍵）掛鉤。
不適用場景：
1）須要經過值來查詢，而不是鍵來查詢：Key-Value 數據庫中根本沒有經過值查詢的途徑；
2）須要儲存數據之間的關係：在 Key-Value 數據庫中不能經過兩個或以上的鍵來關聯數據；
3）須要事務的支持：在 Key-Value 數據庫中故障產生時不能夠進行回滾。
八、文檔數據庫
文檔數據庫（也稱爲文檔型數據庫）是旨在將半結構化數據存儲爲文檔的一種數據庫。文檔數據庫一般以 JSON 或 XML 格式存儲數據。
因爲文檔數據庫的 no-schema 特性，能夠存儲和讀取任意數據。
因爲使用的數據格式是 JSON 或者 BSON，由於 JSON 數據是自描述的，無需在使用前定義字段，讀取一個 JSON 中不存在的字段也不會致使 SQL 那樣的語法錯誤，能夠解決關係型數據庫表結構 Schema 擴展不方便的問題。
8.1 常見文檔數據庫
MongoDB：是一種面向文檔的數據庫管理系統，由 C++ 撰寫而成，以此來解決應用程序開發社區中的大量現實問題。2007 年 10 月，MongoDB 由 10gen 團隊所發展。2009 年 2 月首度推出。
CouchDB：Apache CouchDB 是一個開源數據庫，專一於易用性和成爲"徹底擁抱 Web 的數據庫"。
它是一個使用 JSON 做爲存儲格式，JavaScript 做爲查詢語言，MapReduce 和 HTTP 做爲 API 的 NoSQL 數據庫。
其中一個顯著的功能就是多主複製。CouchDB 的第一個版本發佈在 2005 年，在 2008 年成爲了 Apache 的項目。
8.2 相關特性
以 MongoDB 爲例進行說明，文檔數據庫優勢以下：
1）新增字段簡單，無需像關係型數據庫同樣先執行 DDL 語句修改表結構，程序代碼直接讀寫便可；
2）容易兼容歷史數據，對於歷史數據，即便沒有新增的字段，也不會致使錯誤，只會返回空值，此時代碼兼容處理便可；
3）容易存儲複雜數據，JSON 是一種強大的描述語言，可以描述複雜的數據結構。
相比傳統關係型數據庫，文檔數據庫的缺點主要是對多條數據記錄的事務支持較弱，具體體現以下：
1）Atomicity(原子性)，僅支持單行/文檔級原子性，不支持多行、多文檔、多語句原子性；
2）Solation(隔離性)，隔離級別僅支持已提交讀（Read committed）級別，可能致使不可重複讀，幻讀的問題；
3）不支持複雜查詢，例如 join 查詢，若是須要 join 查詢，須要屢次操做數據庫。
MongonDB 還支持多文檔事務的 Consistency(一致性)和 Durability(持久性)，雖然官方宣佈 MongoDB 將在 4.0 版本中正式推出多文檔 ACID 事務支持，最後落地狀況還有待見證。
8.3 使用場景
適用場景：
1）數據量很大或者將來會變得很大；
2）表結構不明確，且字段在不斷增長，例如內容管理系統，信息管理系統。
不適用場景：
1）在不一樣的文檔上須要添加事務。Document-Oriented 數據庫並不支持文檔間的事務；
2）多個文檔之間須要複雜查詢，例如 join。
九、全文搜索引擎
傳統關係型數據庫主要經過索引來達到快速查詢的目的，在全文搜索的業務下，索引也無能爲力。
主要體如今：
1）全文搜索的條件能夠隨意排列組合，若是經過索引來知足，則索引的數量很是多；
2）全文搜索的模糊匹配方式，索引沒法知足，只能用 like 查詢，而 like 查詢是整表掃描，效率很是低。
而全文搜索引擎的出現，正是解決關係型數據庫全文搜索功能較弱的問題。
9.1 基本原理
全文搜索引擎的技術原理稱爲「倒排索引」（inverted index），是一種索引方法，其基本原理是創建單詞到文檔的索引。與之相對的是「正排索引」，其基本原理是創建文檔到單詞的索引。
如今有以下文檔集合：
正排索引獲得索引以下：
由上可見，正排索引適用於根據文檔名稱查詢文檔內容。
簡單的倒排索引以下：
帶有單詞頻率信息的倒排索引以下：
由上可見，倒排索引適用於根據關鍵詞來查詢文檔內容。
9.2 常見全文搜索引擎
Elastic search：是一個基於 Lucene 的搜索引擎。它提供了一個分佈式，多租戶，可以全文搜索與發動機 HTTP Web 界面和無架構 JSON 文件。
Elastic search 是用 Java 開發的，並根據 Apache License 的條款做爲開源發佈。
根據 DB-Engines 排名，Elasticsearch 是最受歡迎的企業搜索引擎，後面是基於 Lucene 的 Apache Solr。
Solr：是 Apache Lucene 項目的開源企業搜索平臺。其主要功能包括全文檢索、命中標示、分面搜索、動態聚類、數據庫集成，以及富文本（如 Word、PDF）的處理。Solr 是高度可擴展的，並提供了分佈式搜索和索引複製。
9.3 相關特性
以 Elasticsearch 爲例，全文搜索引擎優勢以下：
1）查詢效率高，對海量數據進行近實時的處理；
2）可擴展性，基於集羣環境能夠方便橫向擴展，能夠承載 PB 級數據；
3）高可用，Elasticsearch 集羣彈性，他們將發現新的或失敗的節點，重組和從新平衡數據，確保數據是安全的和可訪問的。
缺點以下：
1）ACID 支持不足，單一文檔的數據是 ACID 的，包含多個文檔的事務時不支持事務的正常回滾，支持 I(Isolation)隔離性（基於樂觀鎖機制的），D(Durability)持久性，不支持 A(Atomicity)原子性，C(Consistency)一致性；
2）對相似數據庫中經過外鍵的複雜的多表關聯操做支持較弱；
3）讀寫有必定延時，寫入的數據，最快 1s 中能被檢索到；
4）更新性能較低，底層實現是先刪數據，再插入新數據；
5）內存佔用大，由於 Lucene 將索引部分加載到內存中。
9.4 使用場景
適用場景以下：
1）分佈式的搜索引擎和數據分析引擎；
2）全文檢索，結構化檢索，數據分析；
3）對海量數據進行近實時的處理，能夠將海量數據分散到多臺服務器上去存儲和檢索。
不適用場景以下：
1）數據須要頻繁更新；
2）須要複雜關聯查詢。
十、圖形數據庫
圖形數據庫應用圖形理論存儲實體之間的關係信息。最多見例子就是社會網絡中人與人之間的關係。
關係型數據庫用於存儲「關係型」數據的效果並很差，其查詢複雜、緩慢、超出預期。
而圖形數據庫的獨特設計偏偏彌補了這個缺陷，解決關係型數據庫存儲和處理複雜關係型數據功能較弱的問題。
10.1 常見圖形數據庫
Neo4j：是由 Neo4j，Inc. 開發的圖形數據庫管理系統。由其開發人員描述爲具備原生圖存儲和處理的符合 ACID 的事務數據庫，根據 DB-Engines 排名，Neo4j 是最流行的圖形數據庫。
ArangoDB：是由 triAGENS GmbH 開發的原生多模型數據庫系統。數據庫系統支持三個重要的數據模型（鍵/值，文檔，圖形），其中包含一個數據庫核心和統一查詢語言 AQL（ArangoDB 查詢語言）。
查詢語言是聲明性的，容許在單個查詢中組合不一樣的數據訪問模式。ArangoDB 是一個 NoSQL 數據庫系統，但 AQL 在不少方面與 SQL 相似。
Titan：是一個可擴展的圖形數據庫，針對存儲和查詢包含分佈在多機羣集中的數百億個頂點和邊緣的圖形進行了優化。
Titan 是一個事務性數據庫，能夠支持數千個併發用戶實時執行復雜的圖形遍歷。
10.2 相關特性
以 Neo4j 爲例，Neo4j 使用數據結構中圖（graph）的概念來進行建模。Neo4j 中兩個最基本的概念是節點和邊。
節點表示實體，邊則表示實體之間的關係。節點和邊均可以有本身的屬性。不一樣實體經過各類不一樣的關係關聯起來，造成複雜的對象圖。
針對關係數據，兩種數據庫的存儲結構不一樣：
Neo4j 中，存儲節點時使用了「index-free adjacency」，即每一個節點都有指向其鄰居節點的指針，可讓咱們在 O(1) 的時間內找到鄰居節點。
另外，按照官方的說法，在 Neo4j 中邊是最重要的，即「first-class entities」，因此單獨存儲，這有利於在圖遍歷的時候提升速度，也能夠很方便地以任何方向進行遍歷。
優勢以下：
1）高性能表現，圖的遍歷是圖數據結構所具備的獨特算法，即從一個節點開始，根據其鏈接的關係，能夠快速和方便地找出它的鄰近節點。
這種查找數據的方法並不受數據量的大小所影響，由於鄰近查詢始終查找的是有限的局部數據，不會對整個數據庫進行搜索。
2）設計的靈活性，數據結構的天然伸展特性及其非結構化的數據格式，讓圖數據庫設計能夠具備很大的伸縮性和靈活性。
由於隨着需求的變化而增長的節點、關係及其屬性並不會影響到原來數據的正常使用。
3）開發的敏捷性，直觀明瞭的數據模型，從需求的討論開始，到程序開發和實現，以及最終保存在數據庫中的樣子，它的模樣彷佛沒有什麼變化，甚至能夠說原本就是如出一轍的。
4）徹底支持 ACID，不像別的 NoSQL 數據庫，Neo4j 還具備徹底事務管理特性，徹底支持 ACID 事務管理。
缺點以下：
1）具備支持節點，關係和屬性的數量的限制；
2）不支持拆分。
10.3 使用場景
適用場景以下：
1）在一些關係性強的數據中，例如社交網絡；
2）推薦引擎。若是咱們將數據以圖的形式表現，那麼將會很是有益於推薦的制定。
不適用場景以下：
1）記錄大量基於事件的數據（例如日誌條目或傳感器數據）；
2）對大規模分佈式數據進行處理，相似於 Hadoop；
3）適合於保存在關係型數據庫中的結構化數據；
4）二進制數據存儲。
十一、本文小結
關係型數據庫和 NoSQL 數據庫的選型，每每須要考慮幾個指標：
1）數據量；
2）併發量；
3）實時性；
4）一致性要求；
5）讀寫分佈和類型；
6）安全性；
7）運維成本。
常見軟件系統數據庫選型參考以下：
1）內部使用的管理型系統，如運營系統，數據量少，併發量小，首選考慮關係型；
2）大流量系統，如電商單品頁，後臺考慮選關係型，前臺考慮選內存型；
3）日誌型系統，原始數據考慮選列式，日誌搜索考慮選倒排索引；
4）搜索型系統，例如站內搜索，非通用搜索，如商品搜索，後臺考慮選關係型，前臺考慮選倒排索引；
5）事務型系統，如庫存，交易，記帳，考慮選關係型+緩存+一致性型協議；
6）離線計算，如大量數據分析，考慮選列式或者關係型也能夠；
7）實時計算，如實時監控，能夠考慮選內存型或者列式數據庫。
在設計實踐中，咱們要基於需求、業務驅動架構，不管選用 RDB/NoSQL/DRDB，必定是以需求爲導向，最終數據存儲方案必然是各類權衡的綜合性設計。
附錄：更多IM架構及其它熱門問題文章彙總
[1] 有關IM架構設計的文章：
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分佈式即時通信(IM)系統理論架構方案》
《從零到卓越：京東客服即時通信系統的技術架構演進歷程》
《蘑菇街即時通信/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大後臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模羣消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《微信朋友圈千億訪問量背後的技術挑戰和實踐總結》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《以微博類應用場景爲例，總結海量社交系統的架構設計步驟》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
《一套高可用、易伸縮、高併發的IM羣聊、單聊架構方案設計實踐》
《阿里技術分享：深度揭祕阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背後的技術細節》
《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高併發的》
《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(七)：支付寶紅包的海量高併發技術實踐》
《社交軟件紅包技術解密(八)：全面解密微博紅包技術方案》
《社交軟件紅包技術解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構等》
《即時通信新手入門：一文讀懂什麼是Nginx？它可否實現IM的負載均衡？》
《即時通信新手入門：快速理解RPC技術——基本概念、原理和用途》
《多維度對比5款主流分佈式MQ消息隊列，媽媽不再擔憂個人技術選型了》
《從游擊隊到正規軍：馬蜂窩旅遊網的IM系統架構演進之路》
《IM開發基礎知識補課(六)：數據庫用NoSQL仍是SQL？讀這篇就夠了！》
更多同類文章 ……
[2] 更多其它架構設計相關文章：
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
《阿里技術分享：深度揭祕阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《達達O2O後臺架構演進實踐：從0到4000高併發請求背後的努力》
《優秀後端架構師必會知識：史上最全MySQL大表優化方案總結》
《小米技術分享：解密小米搶購系統千萬高併發架構的演進和實踐》
《一篇讀懂分佈式架構下的負載均衡技術：分類、原理、算法、常見方案等》
《通俗易懂：如何設計能支撐百萬併發的數據庫架構？》
《多維度對比5款主流分佈式MQ消息隊列，媽媽不再擔憂個人技術選型了》
《重新手到架構師，一篇就夠：從100到1000萬高併發的架構演進之路》
《美團技術分享：深度解密美團的分佈式ID生成算法》
更多同類文章 ……
[3] IM開發綜合文章：
《新手入門一篇就夠：從零開發移動端IM》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》
《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》
《小白必讀：閒話HTTP短鏈接中的Session和Token》
《IM開發基礎知識補課：正確理解前置HTTP SSO單點登錄接口的原理》
《移動端IM中大規模羣消息的推送如何保證效率、實時性？》
《移動端IM開發須要面對的技術問題》
《開發IM是本身設計協議用字節流好仍是字符流好？》
《請問有人知道語音留言聊天的主流實現方式嗎？》
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的「時序性」與「一致性」？》
《一個低成本確保IM消息時序的方法探討》
《IM單聊和羣聊中的在線狀態同步應該用「推」仍是「拉」？》
《IM羣聊消息如此複雜，如何保證不丟不重？》
《談談移動端 IM 開發中登陸請求的優化》
《移動端IM登陸時拉取數據如何做到省流量？》
《淺談移動端IM的多點登錄和消息漫遊原理》
《徹底自已開發的IM該如何設計「失敗重試」機制？》
《通俗易懂：基於集羣的移動端IM接入層負載均衡方案分享》
《微信對網絡影響的技術試驗及分析（論文全文）》
《即時通信系統的原理、技術和應用（技術論文）》
《開源IM工程「蘑菇街TeamTalk」的現狀：一場虎頭蛇尾的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基於社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(音視頻技術篇)》
《字符編碼那點事：快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移動端主流圖片格式的特色、性能、調優等》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《自已開發IM有那麼難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《融雲技術分享：解密融雲IM產品的聊天消息ID生成策略》
《IM開發基礎知識補課(六)：數據庫用NoSQL仍是SQL？讀這篇就夠了！》
更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-27...）
- 1. IM開發基礎知識補課(六)：數據庫用NoSQL仍是SQL？讀這篇就夠了！
- 2. 文件系統基礎知識，看這一篇就夠了！
- 3. 聚類基礎知識,看這一篇就足夠了！
- 4. SQL數據庫開發知識總結：基礎篇
- 5. NoSQL仍是SQL？這一篇講清楚
- 6. NoSQL 仍是 SQL ？這一篇講清楚
- 7. NoSQL數據庫的基礎知識
- 8. IM開發基礎知識補課(九)：想開發IM集羣？先搞懂什麼是RPC！
- 9. ROS基礎看這篇就夠了
- 10. css基礎，這一篇就夠了
- 更多相關文章...
- • NoSQL數據庫有哪些？ - NoSQL教程
- • Spring使用AspectJ開發AOP：基於XML和基於Annotation - Spring教程
- • PHP開發工具
- • JDK13 GA發佈：5大特性解讀
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 融合阿里雲，牛客助您找到心儀好工作
- 2. 解決jdbc(jdbctemplate)在測試類時不報錯在TomCatb部署後報錯
- 3. 解決PyCharm GoLand IntelliJ 等 JetBrains 系列 IDE無法輸入中文
- 4. vue+ant design中關於圖片請求不顯示的問題。
- 5. insufficient memory && Native memory allocation (malloc) failed
- 6. 解決IDEA用Maven創建的Web工程不能創建Java Class文件的問題
- 7. [已解決] Error: Cannot download ‘https://start.spring.io/starter.zip?
- 8. 在idea讓java文件夾正常使用
- 9. Eclipse啓動提示「subversive connector discovery」
- 10. 帥某-技巧-快速轉帖博主文章（article_content）