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大特性解读
-
每一个你不满意的现在，都有一个你没有努力的曾经。