原文來源：51CTO技術棧公眾號，本文原題：NoSQL還是SQL？這一篇講清楚，收錄時有修訂和改動。
1、引言
隨著互聯網大數據時代的到來，越來越多的網站、應用系統都需要支撐大量甚至海量數據存儲，同時還伴有高并發、高可用、高可擴展等特性要求。
很多時候，傳統的關系型數據庫在應付這些已經顯得力不從心，并暴露了許多難以克服的問題。
由此，各種各樣的 NoSQL（Not Only SQL）數據庫作為傳統關系型數據的一個有力補充得到迅猛發展。
本文將分析傳統數據庫（即SQL數據庫）存在的一些問題，以及盤點目前市面上幾大類 NoSQL 特性、優缺點等，希望給大家提供一些在不同業務場景下存儲技術選型方面的參考。
點評：作為專業分享即時通訊開發知識的社區來說，很多IM開發者在進行架構設計和選型的第一時間想到的，就是該如何選擇數據庫，MySQL？Oracle？SQL Server？或者NoSQL？這顯然沒有標準答案，因為每個產品、每套系統、每個架構都有自身的用戶規模、適應場景、成本因素等等考量。本文可能無法給予同為即時通訊開發者的你一個確切答案，但當你在讀完本文，對市面上主要數據庫（包括NoSQL數據庫）的技術特性、適用場景、優缺點都有了解之后，相信你完全能夠根據自已產品或系統的特點，找到適合你的數據庫方案，這也正是本文的意義所在。
學習交流：
- 即時通訊/推送技術開發交流5群：215477170 [推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-2759-1-1.html）
2、關于作者
陳彩華（caison）：主要從事服務端開發、需求分析、系統設計、優化重構工作，主要開發語言是 Java，現任廣州貝聊服務端研發工程師。
陳彩華還分享過另幾篇技術文章，如有興趣可一并閱讀：
3、系列文章
▼ IM開發干貨系列文章（本文是其第18篇）：
如果您是IM開發初學者，強烈建議首先閱讀《新手入門一篇就夠：從零開發移動端IM》。4、傳統SQL數據庫的缺點
傳統的關系數據庫有如下幾個缺點。
1）大數據場景下 I/O 較高：因為數據是按行存儲，即使只針對其中某一列進行運算，關系型數據庫也會將整行數據從存儲設備中讀入內存，導致 I/O 較高。
2）存儲的是行記錄：無法存儲數據結構。
3）表結構 Schema 擴展不方便：如要修改表結構，需要執行 DDL(data definition language)，語句修改，修改期間會導致鎖表，部分服務不可用。
4）全文搜索功能較弱：關系型數據庫下只能夠進行子字符串的匹配查詢，當表的數據逐漸變大的時候，like 查詢的匹配會非常慢，即使在有索引的情況下。況且關系型數據庫也不應該對文本字段進行索引。
5）存儲和處理復雜關系型數據功能較弱：許多應用程序需要了解和導航高度連接數據之間的關系，才能啟用社交應用程序、推薦引擎、欺詐檢測、知識圖譜、生命科學和 IT/網絡等用例。然而傳統的關系數據庫并不善于處理數據點之間的關系。它們的表格數據模型和嚴格的模式使它們很難添加新的或不同種類的關聯信息。
5、NoSQL 解決方案
NoSQL（Not Only SQL），泛指非關系型的數據庫，可以理解為 SQL 的一個有力補充。
在 NoSQL 許多方面性能大大優于非關系型數據庫的同時，往往也伴隨一些特性的缺失，比較常見的是事務庫事務功能的缺失。
數據庫事務正確執行的四個基本要素 ACID 如下：
下面將分別介紹 5 大類 NoSQL 數據庫的技術特性，以及針對傳統關系型數據庫的缺點。
6、列式數據庫
列式數據庫是以列相關存儲架構進行數據存儲的數據庫，主要適合于批量數據處理和即時查詢。
相對應的是行式數據庫，數據以行相關的存儲體系架構進行空間分配，主要適合于小批量的數據處理，常用于聯機事務型數據處理。
基于列式數據庫的列列存儲特性，可以解決某些特定場景下關系型數據庫 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）存儲結構化和半結構化的數據。
7、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 數據庫中故障產生時不可以進行回滾。
8、文檔數據庫
文檔數據庫（也稱為文檔型數據庫）是旨在將半結構化數據存儲為文檔的一種數據庫。文檔數據庫通常以 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。
9、全文搜索引擎
傳統關系型數據庫主要通過索引來達到快速查詢的目的，在全文搜索的業務下，索引也無能為力。
主要體現在：
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、圖形數據庫
圖形數據庫應用圖形理論存儲實體之間的關系信息。最常見例子就是社會網絡中人與人之間的關系。
關系型數據庫用于存儲“關系型”數據的效果并不好，其查詢復雜、緩慢、超出預期。
而圖形數據庫的獨特設計恰恰彌補了這個缺陷，解決關系型數據庫存儲和處理復雜關系型數據功能較弱的問題。
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）二進制數據存儲。
11、本文小結
關系型數據庫和 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-2759-1-1.html）