IM開發基礎知識補課(六)：資料庫用NoSQL還是SQL？讀這篇就 ...

本文將分析傳統資料庫（即SQL資料庫）存在的一些問題，以及盤點目前市面上幾大類NoSQL 特性、優缺點等，希望給大家提供一些在不同業務場景下儲存技術 ... MdEditor IM開發基礎知識補課(六)：資料庫用NoSQL還是SQL？讀這篇就夠了！ 語言:CN/TW/HK 時間 2019-09-2614:16:00 BlogJava-專家區 主題: NoSql SQL 原文來源：51CTO技術棧公眾號，本文原題：NoSQL還是SQL？這一篇講清楚，收錄時有修訂和改動。

1、引言 隨著網際網路大資料時代的到來，越來越多的網站、應用系統都需要支撐大量甚至海量資料儲存，同時還伴有高併發、高可用、高可擴充套件等特性要求。

很多時候，傳統的關係型資料庫在應付這些已經顯得力不從心，並暴露了許多難以克服的問題。

由此，各種各樣的NoSQL（NotOnlySQL）資料庫作為傳統關係型資料的一個有力補充得到迅猛發展。

本文將分析傳統資料庫（即SQL資料庫）存在的一些問題，以及盤點目前市面上幾大類NoSQL特性、優缺點等，希望給大家提供一些在不同業務場景下儲存技術選型方面的參考。

點評：作為專業分享即時通訊開發知識的社群來說，很多IM開發者在進行架構設計和選型的第一時間想到的，就是該如何選擇資料庫，MySQL？Oracle？SQLServer？或者NoSQL？這顯然沒有標準答案，因為每個產品、每套系統、每個架構都有自身的使用者規模、適應場景、成本因素等等考量。

本文可能無法給予同為即時通訊開發者的你一個確切答案，但當你在讀完本文，對市面上主要資料庫（包括NoSQL資料庫）的技術特性、適用場景、優缺點都有了解之後，相信你完全能夠根據自已產品或系統的特點，找到適合你的資料庫方案，這也正是本文的意義所在。

學習交流： -即時通訊/推送技術開發交流5群：215477170[推薦] -移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》 （本文同步釋出於：http://www.52im.net/thread-2759-1-1.html） 2、關於作者 陳彩華（caison）：主要從事服務端開發、需求分析、系統設計、優化重構工作，主要開發語言是Java，現任廣州貝聊服務端研發工程師。

陳彩華還分享過另幾篇技術文章，如有興趣可一併閱讀： 《新手入門：目前為止最透徹的的Netty高效能原理和框架架構解析》 《高效能網路程式設計(五)：一文讀懂高效能網路程式設計中的I/O模型》 《高效能網路程式設計(六)：一文讀懂高效能網路程式設計中的執行緒模型》 3、系列文章 ▼ IM開發乾貨系列文章（本文是其第18篇）： 《IM訊息送達保證機制實現(一)：保證線上實時訊息的可靠投遞》 《IM訊息送達保證機制實現(二)：保證離線訊息的可靠投遞》 《如何保證IM實時訊息的“時序性”與“一致性”？》 《IM單聊和群聊中的線上狀態同步應該用“推”還是“拉”？》 《IM群聊訊息如此複雜，如何保證不丟不重？》 《一種Android端IM智慧心跳演算法的設計與實現探討（含樣例程式碼）》 《移動端IM登入時拉取資料如何作到省流量？》 《通俗易懂：基於叢集的移動端IM接入層負載均衡方案分享》 《淺談移動端IM的多點登陸和訊息漫遊原理》 《IM開發基礎知識補課(一)：正確理解前置HTTPSSO單點登陸介面的原理》 《IM開發基礎知識補課(二)：如何設計大量圖片檔案的服務端儲存架構？》 《IM開發基礎知識補課(三)：快速理解服務端資料庫讀寫分離原理及實踐建議》 《IM開發基礎知識補課(四)：正確理解HTTP短連線中的Cookie、Session和Token》 《IM群聊訊息的已讀回執功能該怎麼實現？》 《IM群聊訊息究竟是存1份(即擴散讀)還是存多份(即擴散寫)？》 《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ訊息佇列》 《一個低成本確保IM訊息時序的方法探討》 《IM開發基礎知識補課(六)：資料庫用NoSQL還是SQL？讀這篇就夠了！》（本文） 如果您是IM開發初學者，強烈建議首先閱讀《新手入門一篇就夠：從零開發移動端IM》。

4、傳統SQL資料庫的缺點 傳統的關係資料庫有如下幾個缺點。

1）大資料場景下I/O較高：因為資料是按行儲存，即使只針對其中某一列進行運算，關係型資料庫也會將整行資料從儲存裝置中讀入記憶體，導致I/O較高。

2）儲存的是行記錄：無法儲存資料結構。

3）表結構Schema擴充套件不方便：如要修改表結構，需要執行DDL(datadefinitionlanguage)，語句修改，修改期間會導致鎖表，部分服務不可用。

4）全文搜尋功能較弱：關係型資料庫下只能夠進行子字串的匹配查詢，當表的資料逐漸變大的時候，like查詢的匹配會非常慢，即使在有索引的情況下。

況且關係型資料庫也不應該對文字欄位進行索引。

5）儲存和處理複雜關係型資料功能較弱：許多應用程式需要了解和導航高度連線資料之間的關係，才能啟用社交應用程式、推薦引擎、欺詐檢測、知識圖譜、生命科學和IT/網路等用例。

然而傳統的關係資料庫並不善於處理資料點之間的關係。

它們的表格資料模型和嚴格的模式使它們很難新增新的或不同種類的關聯資訊。

5、NoSQL解決方案 NoSQL（NotOnlySQL），泛指非關係型的資料庫，可以理解為SQL的一個有力補充。

在NoSQL許多方面效能大大優於非關係型資料庫的同時，往往也伴隨一些特性的缺失，比較常見的是事務庫事務功能的缺失。

資料庫事務正確執行的四個基本要素ACID如下： 下面將分別介紹5大類NoSQL資料庫的技術特性，以及針對傳統關係型資料庫的缺點。

6、列式資料庫 列式資料庫是以列相關儲存架構進行資料儲存的資料庫，主要適合於批量資料處理和即時查詢。

相對應的是行式資料庫，資料以行相關的儲存體系架構進行空間分配，主要適合於小批量的資料處理，常用於聯機事務型資料處理。

基於列式資料庫的列列儲存特性，可以解決某些特定場景下關係型資料庫I/O較高的問題。

6.1基本原理 傳統關係型資料庫是按照行來儲存資料庫，稱為“行式資料庫”，而列式資料庫是按照列來儲存資料。

將表放入儲存系統中有兩種方法，而我們絕大部分是採用行儲存的。

行儲存法是將各行放入連續的物理位置，這很像傳統的記錄和檔案系統。

列儲存法是將資料按照列儲存到資料庫中，與行儲存類似。

下圖是兩種儲存方法的圖形化解釋： 6.2常見列式資料庫 HBase：是一個開源的非關係型分散式資料庫（NoSQL），它參考了谷歌的BigTable建模，實現的程式語言為Java。

它是Apache軟體基金會的Hadoop專案的一部分，運行於HDFS檔案系統之上，為Hadoop提供類似於BigTable規模的服務。

因此，它可以容錯地儲存海量稀疏的資料。

BigTable：是一種壓縮的、高效能的、高可擴充套件性的，基於Google檔案系統（GoogleFileSystem，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）大資料量（100sTB級資料），且有快速隨機訪問的需求； 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：是一個使用ANSIC編寫的開源、支援網路、基於記憶體、可選永續性的鍵值對儲存資料庫。

從2015年6月開始，Redis的開發由RedisLabs贊助，而2013年5月至2015年6月期間，其開發由Pivotal贊助。

在2013年5月之前，其開發由VMware贊助。

根據月度排行網站DB-Engines.com的資料顯示，Redis是最流行的鍵值對儲存資料庫。

Cassandra：ApacheCassandra（社群內一般簡稱為C*）是一套開源分散式NoSQL資料庫系統。

它最初由Facebook開發，用於儲存收件箱等簡單格式資料，集GoogleBigTable的資料模型與AmazonDynamo的完全分散式架構於一身。

Facebook於2008將Cassandra開源，此後，由於Cassandra良好的可擴充套件性和效能。

它被Apple，Comcas，Instagram，Spotify，eBay，Rackspace，Netflix等知名網站所採用，成為了一種流行的分散式結構化資料儲存方案。

LevelDB：是一個由Google公司所研發的鍵／值對（Key/ValuePair）嵌入式資料庫管理系統程式設計庫，以開源的BSD許可證釋出。

7.2相關特性 以Redis為例，K-V資料庫優點如下：  1）效能極高：Redis能支援超過10W的TPS； 2）豐富的資料型別：Redis支援包括String，Hash，List，Set，SortedSet，Bitmap和Hyperloglog； 3）豐富的特性：Redis還支援publish/subscribe，通知，key過期等等特性。

缺點如下： 針對ACID，Redis事務不能支援原子性和永續性(A和D)，只支援隔離性和一致性(I和C)。

特別說明一下：這裡所說的無法保證原子性，是針對Redis的事務操作，因為事務是不支援回滾（rollback），而因為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：ApacheCouchDB是一個開源資料庫，專注於易用性和成為"完全擁抱Web的資料庫"。

它是一個使用JSON作為儲存格式，JavaScript作為查詢語言，MapReduce和HTTP作為API的NoSQL資料庫。

其中一個顯著的功能就是多主複製。

CouchDB的第一個版本釋出在2005年，在2008年成為了Apache的專案。

8.2相關特性 以MongoDB為例進行說明，文件資料庫優點如下：  1）新增欄位簡單，無需像關係型資料庫一樣先執行DDL語句修改表結構，程式程式碼直接讀寫即可； 2）容易相容歷史資料，對於歷史資料，即使沒有新增的欄位，也不會導致錯誤，只會返回空值，此時程式碼相容處理即可； 3）容易儲存複雜資料，JSON是一種強大的描述語言，能夠描述複雜的資料結構。

相比傳統關係型資料庫，文件資料庫的缺點主要是對多條資料記錄的事務支援較弱，具體體現如下： 1）Atomicity(原子性)，僅支援單行/文件級原子性，不支援多行、多文件、多語句原子性； 2）Solation(隔離性)，隔離級別僅支援已提交讀（Readcommitted）級別，可能導致不可重複讀，幻讀的問題； 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基本原理 全文搜尋引擎的技術原理稱為“倒排索引”（invertedindex），是一種索引方法，其基本原理是建立單詞到文件的索引。

與之相對的是“正排索引”，其基本原理是建立文件到單詞的索引。

現在有如下文件集合： 正排索引得到索引如下： 由上可見，正排索引適用於根據文件名稱查詢文件內容。

簡單的倒排索引如下： 帶有單詞頻率資訊的倒排索引如下：  由上可見，倒排索引適用於根據關鍵詞來查詢文件內容。

9.2常見全文搜尋引擎 Elasticsearch：是一個基於Lucene的搜尋引擎。

它提供了一個分散式，多租戶，能夠全文搜尋與發動機HTTPWeb介面和無架構JSON檔案。

Elasticsearch是用Java開發的，並根據ApacheLicense的條款作為開源釋出。

根據DB-Engines排名，Elasticsearch是最受歡迎的企業搜尋引擎，後面是基於Lucene的ApacheSolr。

Solr：是ApacheLucene專案的開源企業搜尋平臺。

其主要功能包括全文檢索、命中標示、分面搜尋、動態聚類、資料庫整合，以及富文字（如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：是由triAGENSGmbH開發的原生多模型資料庫系統。

資料庫系統支援三個重要的資料模型（鍵/值，文件，圖形），其中包含一個數據庫核心和統一查詢語言AQL（ArangoDB查詢語言）。

查詢語言是宣告性的，允許在單個查詢中組合不同的資料訪問模式。

ArangoDB是一個NoSQL資料庫系統，但AQL在很多方面與SQL類似。

Titan：是一個可擴充套件的圖形資料庫，針對儲存和查詢包含分佈在多機群集中的數百億個頂點和邊緣的圖形進行了優化。

Titan是一個事務性資料庫，可以支援數千個併發使用者實時執行復雜的圖形遍歷。

10.2相關特性 以Neo4j為例，Neo4j使用資料結構中圖（graph）的概念來進行建模。

Neo4j中兩個最基本的概念是節點和邊。

節點表示實體，邊則表示實體之間的關係。

節點和邊都可以有自己的屬性。

不同實體通過各種不同的關係關聯起來，形成複雜的物件圖。

針對關係資料，兩種資料庫的儲存結構不同： Neo4j中，儲存節點時使用了“index-freeadjacency”，即每個節點都有指向其鄰居節點的指標，可以讓我們在O(1)的時間內找到鄰居節點。

另外，按照官方的說法，在Neo4j中邊是最重要的，即“first-classentities”，所以單獨儲存，這有利於在圖遍歷的時候提高速度，也可以很方便地以任何方向進行遍歷。

優點如下： 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開發基礎知識補課：正確理解前置HTTPSSO單點登陸介面的原理》 《移動端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） 「NoSql」 11.11大促來臨，你的資料庫系統準備好了嗎？ GaussDB(forCassandra)資料庫治理：大key與熱key問題的檢測與解決 Java程式設計師漲薪必備的效能調優知識點，收好了！ 因為不懂重放攻擊小黑差點丟了飯碗 SLM-DB：B樹索引和LSM架構結合的嘗試 MongoDB進階之查詢（二） MongoDB進階之查詢（一） MongoDB入門基礎知識 Redis過期刪除策略和記憶體淘汰機制 【mongo系列】mongodb學習一，基本nosql和mongodb等資料庫對比 「SQL」 OracleSQL注入總結 SQL基礎查詢語句 解構服務風險治理 流量治理最大的痛點-資源利用率上不去 SQL效能調優優秀實踐 萬答#8，如何設定主從複製過濾規則 記一次DISTINCT導致的SQL效率問題 談談執行一條SQL的流程 從一個有趣的SQL優化案例，自頂向下瞭解資料庫優化機制 耗時18個月，我們構建了一個真正可擴充套件的無伺服器SQL資料庫