放松时刻

这里跟大家讲个段子，以前有个朋友，他在传统软件行业，他时常问我你们互联网就一个App项目，整天迭代来迭代去，还招那么多人去干，有那么多东西做吗？在他眼里可能我们这种互联网App就是上线即巅峰，只要App发布出去了，就没程序员啥事了，当然要是换以前的我，我可能会顿时暴怒并反驳他，但现在作为一个成熟程序员我并不会去反驳，因为我知道跟他讲太多也没有结果，我就笑笑，问题不大。

业务背景

在互联网项目中，分布式、高并发、大数据是绕不开的话题，尤其现在容器化，微服务，云原生的概念越来越火，由此诞生了很多 crud-boy sql-boy k8s-boy ... 好了 不废话 直接说背景 千万用户级别直播项目 先不说其他用户 先看用户中心中最基础的用户表 在设计上至少得超过亿级存储才能满足我们系统的需求 这个时候怎么做呢？ 正常人肯定会说 分库分表啊 ok 确实能解决问题 但是会引发其他的问题 接下来我帮你们分析下分库分表的缺点

依赖中间件

全局分布式事务已然失效

别想聚合和复杂join查询了

大多时候需要双写一份全局数据到其他nosql型数据库

扩容方式麻烦

加索引加字段蛋疼的要死

重构/数据迁移改造时喊爹骂娘

单纯以上几点足以击溃crud-boys sql-boys 的心理防线，答应我千万不要emo，今天我将带你们解放双手，拥抱美好的明天。

分布式数据库

什么是分布式数据库？

web2.0时代以来，国产数据库百花齐放，各种海量数据存储需求似乎成为了互联网标配，同样的，在当下云原生时代，分布式集群技术也成为了项目的标配。如果你还不了解分布式数据库的概念，下面一张图将助你初步认识分布式数据库

分布式数据库有什么特征？

1.可靠性

消除了单点故障问题，分布式数据库系统具有重复的数据构成，单机故障时整个服务仍然能屹立不倒，从而解决了可靠性问题

2.数据透明性管理

在分布式系统中，数据不是存储在一片地皮，而是存储在计算机网络的多个地皮上，并且还保证了逻辑上是一个整体，它们被所有用户共享，并由一个全局的 DBMS 统一管理。用户访问数据时无须知道数据存放在哪片地皮，也不需要知道由分布式系统中的哪些服务器来完成，从而降低了使用门槛，让数据对用户更加透明，管理更加方便。

3.数据分布式存储

现在的数据存储需求都是TB，PB级别，分布式数据库的数据存储不受单机磁盘容量限制，可通过动态增加数据服务器的数量提升存储能力

4.计算存储分离

计算节点无状态，可通过水平扩展增加计算能力，存储节点和计算节点能够分层优化，不要再被类似单表最多只能存储XX条数据的思维所禁锢。

5.弹性伸缩

可以随时随地的在不影响现有应用的情况下，动态对数据存储节点扩缩容，这算是在一定程度上根据自己的业务情况

进行成本的控制。

6.多数据副本

自动将数据以强一致、高性能的方式复制至跨机房的多个副本，以保证数据99.99999....%可用性

分布式数据库有哪些？

1.Spanner

Spanner由谷歌的一个全球级别的分布式数据库，它管理着全球成百上千个数据中心，数百万个服务器，将数万亿数据分片存储到这些服务器上。

数据可以有多个备份副本，并且可以灵活、细粒度地配置：副本数量、副本所在的数据中心等，副本甚至可以跨国家存储，即使面临大范围自然灾害，数据依旧可用，真正做到了真正意义上的全球容灾。

读和写操作的外部一致性，以及在一个时间戳下跨数据库的全球一致性操作，这个特性可以保证一致性备份，以及基于一致性备份的一致性MapReduce操作，以及原子操作。

支持广域的分布式事务，对于涉及不同数据中心的事务，也能保证ACID特性，有兴趣的话大家可以了解下它的杀手锏TrueTime的实现。

优点

99.999%的SLA

自动完成数据库sharding

夸张的扩展性，可以扩展数百万机器

使用场景

游戏、金融科技、医疗保健、媒体娱乐行业

2.TiDB

TiDB Server

TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，返回结果。 TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。

PD Server

PD Server 是整个集群的管理模块，主要工作有三个：

存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）

分配全局唯一且递增的事务ID

对TiKV 集群进行调度和负载均衡

PD Server 是一个集群，需要部署奇数个节点，一般线上推荐部署>=3个节点。

TiKV Server

TiKV Server 负责存储数据，存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range的数据，每个 TiKV 节点会负责多个 Region 。使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。

优点

无限水平扩展

高可用，TiDB Server/TiKV Server/PD Server 都能容忍部分实例失效，不影响整个集群的可用性。

具备良好的MySQL兼容性，业务扩大可以基本实现无缝由MySQL切换成TiDB

缺点

硬件要求高

使用成本高

使用场景

互联网社交行业、游戏场景、数据仓库

3.Mongo DB

MongoDB是高性能、可扩展、易部署、易使用，存储数据非常方便的面向集合存储的数据库

Config Server

Config Server是MondoDB的配置服务器，存储分片集群的元数据，元数据反映了分片集群中所有数据和组件的状态和组织，Shards还会从配置服务器读取块元数据，配置服务器还存储身份验证配置信息，例如角色的访问控制或群集的内部身份验证，MongoDB还使用配置服务器来管理分布式锁，每个分片群集必须具有自己的配置服务器，不要将相同的配置服务器用于不同的分片群集。

Mongos

Mongos 可以有多个，相当于一个控制中心，负责路由和协调操作，使得集群像一个整体的系统。mongos可以运行在任何一台服务器上，有些选择放在shards服务器上，也有放在client 服务器上的。mongos启动时需要从config servers上获取基本信息，然后接受client端的请求，路由到指定的shards服务器，然后整理返回的结果返回给client服务器。 

Shards

存储节点，为了保证数据的高可用性和一致性，可以是一个单独的实例，也可以是一个副本集，在生产环境下Shard一般是一个Replica Set，以防止该数据片的单点故障。所有Shard中有一个PrimaryShard，里面包含未进行划分的数据集合。

存储引擎

MongoDB的核心组件，其负责管理和组织数据采取什么样的格式存储在硬盘和内存上。在MongoDB3.2版本以前，默认的存储引擎是wiredTiger，在3.2版本之后和4.0版本之前，默认的存储引擎是MMAPv1，在4.0版本之后，默认的存储引擎是In-memory。具体的存储引擎特性我这边不多讲，有兴趣大家可以自己去搜索下。

优点

高可用的副本集支持

文档存储 业务经常变动 此特性可以让开发忽略前期的数据的前期设计问题

易于查询 不同于SQL模型 查询编写和优化比传统SQL容易得多

支持完全索引，包含内部对象 亿级数据下检索毫秒级返回成为了现实

缺点

不支持事务

不支持reload，只能冷重启，初始化配置麻烦

使用场景

互联网社交行业、游戏行业、直播行业、需求变化/迭代快、不需要事务操作的业务

4.PolarDB

PolarDB是aliyun自主研发的新一代关系型云原生数据库，既拥有分布式设计的低成本优势，又具有集中式的易用性,采用存储计算分离、软硬一体化设计，满足大规模应用场景需求，先看一张它的架构图

一写多读

PolarDB采用分布式集群架构，一个集群包含一个主节点和最多15个只读节点（至少一个，用于保障高可用）。主节点处理读写请求，只读节点仅处理读请求。主节点和只读节点之间采用Active-Active的Failover方式，提供数据库的高可用服务。

计算与存储分离

PolarDB采用计算与存储分离的设计理念，满足公共云计算环境下根据业务发展弹性扩展集群的刚性需求。数据库的计算节点（Database Engine Server）仅存储元数据，而将数据文件、Redo Log等存储于远端的存储节点（Database Storage Server）。各计算节点之间仅需同步Redo Log相关的元数据信息，极大降低了主节点和只读节点间的复制延迟，而且在主节点故障时，只读节点可以快速切换为主节点。

读写分离

读写分离是PolarDB集群版默认提供的一个透明、高可用、自适应的负载均衡能力。通过集群地址，SQL请求自动转发到PolarDB集群版的各个节点，提供聚合、高吞吐的并发SQL处理能力。

高速链路互联

数据库的计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使I/O性能不再成为瓶颈。

共享分布式存储

多个计算节点共享一份数据，而不是每个计算节点都存储一份数据，极大降低了用户的存储成本。基于全新打造的分布式块存储（Distributed Storage）和文件系统（Distributed Filesystem），存储容量可以在线平滑扩展，不会受到单个数据库服务器的存储容量限制，可应对上百TB级别的数据规模。

数据多副本、Parallel-Raft协议

数据库存储节点的数据采用多副本形式，确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。

优点

100%兼容MySQL、PostgreSQL、高度兼容Oracle语法

计算能力最高可扩展至1000核以上，存储容量最高可达 100TB

支持列索引（In-Memory Column Index，简称IMCI）功能，支持实时事务级别行列数据一致，列索引结合SIMD向量化和并行执行加速技术，在大数据量复杂查询场景，相比传统MySQL获得百倍以上执行性能加速效果。

缺点

不能访问用户表，数据库的功能受限，如果要做DMS可能需要搭配对应的云服务使用

aliyun老毛病:技术文档不规范

使用场景

适用教育、直播、金融、电商等互联网业务量快速剧增、读多写少的场景

选型方案确定

数据库性能稳定性扩展性成本

Spanner强高无敌(可以扩展到数百万的机器，数已百计的数据中心)价格和硬件要求高

TiDB一般高高价格和硬件要求高

MongoDB强高一般(适用场景也有限)价格和硬件要求较高

PolarDB一般高高(弹性扩缩容)低 (基于开源MySQL的引擎 价格和硬件要求低)

由于我们做的是直播社交项目，从各方面去考虑，从0-1做的话优先选PolarDB作为分布式数据库方案。

总结

分布式数据库服务是互联网项目非常有必要要引入的架构

分布式数据库虽好，但也需要根据具体使用场景进行选型，切勿盲目忽略实际情况进行选型操作

对于小企业/项目来说，其实也不是一开始就要使用分布式数据库，像PolarDB，是无缝兼容MySQL引擎的，可以先从单机、主备MySQL服务先开始用，后期迁移到分布式数据库其实也很容易，云原生数据库本来就是为了满足用户扩展性、可用性、可移植性方面的要求。