数据库

MVCC 可以看作是行级锁的一个升级，可以有效减少加锁操作，提高性能。

哈希表是键值对的集合，通过键(key)即可快速取出对应的值(value)，因此哈希表可以快速检索数据（接近 O(1)）。

原理

Hash 冲突

因为 Hash 索引不支持顺序和范围查询，MySQL 没有使用其作为索引的数据结构。

二叉查找树（Binary Search Tree）是一种基于二叉树的数据结构。

特点

二叉查找树的性能非常依赖于它的平衡程度，这就导致其不适合作为 MySQL 底层索引的数据结构。

计算机科学中最早被发明的自平衡二叉查找树。

特点

由于 AVL 树需要频繁地进行旋转操作来保持平衡，因此会有较大的计算开销进而降低了查询性能。

红黑树是一种自平衡二叉查找树，通过在插入和删除节点时进行颜色变换和旋转操作，使得树始终保持平衡状态。

特点

因为红黑树的平衡性相对较弱，高度较高的树的查询可能会导致多次磁盘 IO 操作，这也是 MySQL 没有选择红黑树的主要原因。

B 树也称 B-树，全称为 多路平衡查找树 ，B+ 树是 B 树的一种变体。B 树和 B+树中的 B 是 Balanced （平衡）的意思。

大部分数据库系统及文件系统都采用 B-Tree 或其变种 B+Tree 作为索引结构。

B+树与 B 树相比，具备更少的 IO 次数、更稳定的查询效率和更适于范围查询这些优势。

BTree 索引：MySQL 里默认和最常用的索引类型。

哈希索引：类似键值对的形式，一次即可定位。

RTree 索引：一般不会使用，仅支持 geometry 数据类型，优势在于范围查找，效率较低，通常使用搜索引擎如 ElasticSearch 代替。

对文本的内容进行分词，进行搜索。目前只有 CHAR、VARCHAR ，TEXT 列上可以创建全文索引。
一般不会使用，效率较低，通常使用搜索引擎如 ElasticSearch 代替。

聚簇索引（聚集索引）：索引结构和数据一起存放的索引，InnoDB 中的主键索引就属于聚簇索引。

非聚簇索引（非聚集索引）：索引结构和数据分开存放的索引，二级索引(辅助索引)就属于非聚簇索引。

主键索引：加速查询 + 列值唯一（不可以有 NULL）+ 表中只有一个。

普通索引：仅加速查询。

唯一索引：加速查询 + 列值唯一（可以有 NULL）。

覆盖索引：一个索引包含（或者说覆盖）所有需要查询的字段的值。

联合索引：多列值组成一个索引，专门用于组合搜索，其效率大于索引合并。

全文索引：对文本的内容进行分词，进行搜索。

查询速度非常快、对排序查找和范围查找优化。

依赖于有序的数据、更新代价大。

更新代价比聚簇索引要小 。

依赖于有序的数据、可能会二次查询(回表)。

不为 NULL 的字段。

被频繁查询的字段。

被作为条件查询的字段。

频繁需要排序的字段。

被经常频繁用于连接的字段。

建议单张表索引不超过 5 个！

SELECT * 不会直接导致索引失效，但它可能会带来浪费、无法使用索引覆盖。

创建了组合索引，但查询条件未遵守最左匹配原则。

在索引列上进行计算、函数、类型转换等操作。

以 % 开头的 LIKE 查询比如 LIKE '%abc'。

查询条件中使用 OR，且 OR 的前后条件中有一个列没有索引，涉及的索引都不会被使用到。

IN 的取值范围较大时会导致索引失效，走全表扫描(NOT IN 和 IN 的失效场景相同)。

发生隐式转换。

MySQL 实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。

MySQL 中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页。

每条 redo 记录由“表空间号+数据页号+偏移量+修改数据长度+具体修改的数据”组成。

事务提交：当事务提交时，log buffer 里的 redo log 会被刷新到磁盘。

log buffer 空间不足时：log buffer 中缓存的 redo log 已经占满了 log buffer 总容量的大约一半左右，就需要把这些日志刷新到磁盘上。

事务日志缓冲区满：InnoDB 使用一个事务日志缓冲区（transaction log buffer）来暂时存储事务的重做日志条目。

Checkpoint（检查点）：InnoDB 定期会执行检查点操作，将内存中的脏数据刷新到磁盘，并且会将相应的重做日志一同刷新，以确保数据的一致性。

后台刷新线程：InnoDB 启动了一个后台线程，负责周期性（每隔 1 秒）地将脏页刷新到磁盘，并将相关的重做日志一同刷新。

正常关闭服务器：MySQL 关闭的时候，redo log 都会刷入到磁盘里去。

设置参数 innodb_flush_log_at_trx_commit，默认值为1。

0：设置为 0 的时候，表示每次事务提交时不进行刷盘操作。性能最高，但也最不安全。

1：设置为 1 的时候，表示每次事务提交时都将进行刷盘操作。性能最低，但也最安全。

2：设置为 2 的时候，表示每次事务提交时都只把 log buffer 里的 redo log 内容写入 page cache（文件系统缓存）。

硬盘上存储的 redo log 日志文件不只一个，而是以一个日志文件组的形式出现的，每个的redo日志文件大小都是一样的。

它采用的是环形数组形式，从头开始写，写到末尾又回到头循环写。

重要属性

binlog 日志有三种格式，可以通过 binlog_format 参数指定。

statement

row

mixed

事务执行过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到 binlog 文件中。

write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快。

fsync，才是将数据持久化到磁盘的操作。

write 和 fsync 的时机，可以由参数 sync_binlog 控制，默认是1。
为0时，表示每次提交事务都只 write，由系统自行判断什么时候执行 fsync。
为1时，表示每次提交事务都会执行 fsync，就如同 redo log 日志刷盘流程 一样。
为N(N>1)时，表示每次提交事务都 write，但累积N个事务后才 fsync。

将 redo log 的写入拆成了两个步骤 prepare 和 commit，这就是两阶段提交。

MySQL 根据 redo log 日志恢复数据时，发现 redo log 还处于 prepare 阶段，并且没有对应 binlog 日志，就会回滚该事务。

保证事务的原子性。

一个事务读取数据并且对数据进行了修改，这个修改对其他事务来说是可见的，即使当前事务没有提交。
这时另外一个事务读取了这个还未提交的数据，但第一个事务突然回滚，导致数据并没有被提交到数据库，那第二个事务读取到的就是脏数据。

在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，
第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。

指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，
由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。

幻读与不可重复读类似。它发生在一个事务读取了几行数据，接着另一个并发事务插入了一些数据时。
在随后的查询中，第一个事务就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

锁可以看作是悲观控制的模式。

锁控制方式下会通过锁来显示控制共享资源而不是通过调度手段，MySQL 中主要是通过 读写锁 来实现并发控制。

共享锁（S 锁）：又称读锁，事务在读取记录的时候获取共享锁，允许多个事务同时获取（锁兼容）。

排他锁（X 锁）：又称写锁/独占锁，事务在修改记录的时候获取排他锁，不允许多个事务同时获取。

多版本并发控制（MVCC，Multiversion concurrency control）可以看作是乐观控制的模式。

MVCC 是一种并发控制机制，用于在多个并发事务同时读写数据库时保持数据的一致性和隔离性。

原理

当一个事务要对数据库中的数据进行修改时，MVCC 会为该事务创建一个数据快照，而不是直接修改实际的数据行。

记录锁（Record Lock）：也被称为记录锁，属于单个行记录上的锁。

间隙锁（Gap Lock）：锁定一个范围，不包括记录本身。

临键锁（Next-Key Lock）：Record Lock+Gap Lock，锁定一个范围，包含记录本身，主要目的是为了解决幻读问题。

在 InnoDB 默认的隔离级别 REPEATABLE-READ 下，行锁默认使用的是 Next-Key Lock。
但是，如果操作的索引是唯一索引或主键，InnoDB 会对 Next-Key Lock 进行优化，将其降级为 Record Lock，即仅锁住索引本身，而不是范围。

表级锁

意向共享锁（Intention Shared Lock，IS 锁）：事务有意向对表中的某些记录加共享锁（S 锁），加共享锁前必须先取得该表的 IS 锁。

意向排他锁（Intention Exclusive Lock，IX 锁）：事务有意向对表中的某些记录加排他锁（X 锁），加排他锁之前必须先取得该表的 IX 锁。

快照读（一致性非锁定读）就是单纯的 SELECT 语句。

比较适合对于数据一致性要求不是特别高且追求极致性能的业务场景。

当前读 （一致性锁定读）就是给行记录加 X 锁或 S 锁。

id

select_type

table

type

possible_keys

key

key_len

rows

Extra

不要使用 UUID、MD5、HASH 字符串列作为主键，主键建议使用自增 ID 值。

1、出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列。

2、包含在 ORDER BY、GROUP BY、DISTINCT 中的字段。

3、并不要将符合 1 和 2 中的字段的列都建立一个索引， 通常将 1、2 中的字段建立联合索引效果更好。

4、多表 join 的关联列。

区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数）。

尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大，IO 性能也就越好）。

使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引）。

覆盖索引：就是包含了所有查询字段 (where,select,order by,group by 包含的字段) 的索引。

好处

不建议使用外键约束（foreign key），但一定要在表与表之间的关联键上建立索引。

外键可用于保证数据的参照完整性，但建议在业务端实现。

外键会影响父表和子表的写操作从而降低性能。

in 的值不要超过 500 个。

MyISAM 引擎的自增值保存在数据文件中。

InnoDB 引擎的自增值，其实是保存在了内存里，并没有持久化。
首次打开表时，会去找自增值的最大值 max(id)，然后将 max(id)+1 作为这个表当前的自增值。

MySQL 8.0 版本后，自增值的变更记录被放在了 redo log 中，提供了自增值持久化的能力。

在 MySQL 里面，如果字段 id 被定义为 AUTO_INCREMENT，在插入一行数据的时候，自增值的行为。

如果插入数据时 id 字段指定为 0、null 或未指定值，那么就把这个表当前的 AUTO_INCREMENT 值填到自增字段。

如果插入数据时 id 字段指定了具体的值，就直接使用语句里指定的值。

根据要插入的值和当前自增值的大小关系，自增值的变更结果也会有所不同。
假设某次要插入的值是 insert_num，当前的自增值是 autoIncrement_num：
如果 insert_num < autoIncrement_num，那么这个表的自增值不变。
如果 insert_num >= autoIncrement_num，就需要把当前自增值修改为新的自增值，

分布式 id 为了避免两个库生成的主键发生冲突，我们可以让一个库的自增 id 都是奇数，另一个库的自增 id 都是偶数。

自增初始值和自增步长设置不为 1。

唯一键冲突。

事务回滚。

批量插入（如 insert...select 语句）。

首次请求数据一定不在 cache 的问题。
解决：可以将热点数据可以提前放入 cache 中。

写操作比较频繁的话导致 cache 中的数据会被频繁被删除，这样会影响缓存命中率 。
解决：
数据库和缓存数据强一致场景：更新 db 的时候同样更新 cache，不过我们需要加一个锁/分布式锁来保证更新 cache 的时候不存在线程安全问题。
可以短暂地允许数据库和缓存数据不一致的场景：更新 db 的时候同样更新 cache，但是给缓存加一个比较短的过期时间。

消息队列中消息的异步写入磁盘、MySQL 的 Innodb Buffer Pool 机制。

db 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。

简单动态字符串（Simple Dynamic String，SDS）

常规数据（比如 Session、Token、序列化后的对象、图片的路径）的缓存。

计数比如用户单位时间的请求数（简单限流可以用到）、页面单位时间的访问数。

分布式锁（利用 SETNX key value 命令可以实现一个最简易的分布式锁）。

对象中某些字段需要经常变动或者经常需要单独查询对象中的个别字段信息，Hash 非常适合。

系统对性能和资源消耗非常敏感的话，String 非常适合。

在绝大部分情况，推荐使用 String 来存储对象数据。

LinkedList（双向链表）/ ZipList（压缩列表）/ QuickList（快速列表）

信息流展示（最新文章、最新动态）

消息队列，只是功能过于简单且存在很多缺陷，不建议这样做。

Dict（哈希表/字典）、ZipList（压缩列表）

对象数据存储场景（用户信息、商品信息、文章信息、购物车信息）

Dict（哈希表/字典）、Intset（整数集合）

需要存放的数据不能重复的场景（网站 UV 统计、文章点赞、动态点赞）

需要获取多个数据源交集、并集和差集的场景（共同好友(交集)、好友推荐（差集）、订阅号推荐（差集+交集））

需要随机获取数据源中的元素的场景（抽奖系统、随机点名）

ZipList（压缩列表）、SkipList（跳跃表）

需要随机获取数据源中的元素根据某个权重进行排序的场景（各种排行榜）

需要存储的数据有优先级或者重要程度的场景（优先级任务队列）

需要保存状态信息（0/1 即可表示）的场景（用户签到情况、活跃用户情况、用户行为统计）

稀疏矩阵：计数较少的时候，占用空间很小。

稠密矩阵：计数达到某个阈值的时候，占用 12k 的空间。

数量量巨大（百万、千万级别以上）的计数场景（热门网站每日/每周/每月访问 ip 数统计、热门帖子 uv 统计）

需要管理使用地理空间数据的场景（附近的人）

将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能）。

将快照留在原地以便重启服务器的时候使用。

save : 同步保存操作，会阻塞 Redis 主线程。

bgsave : fork 出一个子进程，子进程执行，不会阻塞 Redis 主线程，默认选项。

RDB 文件存储的内容是经过压缩的二进制数据， 保存着某个时间点的数据集，文件很小，适合做数据的备份，灾难恢复。

使用 RDB 文件恢复数据，直接解析还原数据即可，不需要一条一条地执行命令，速度非常快。

RDB 文件是以特定的二进制格式保存的，并且在 Redis 版本演进中有多个版本的 RDB，所以存在老版本的 Redis 服务不兼容新版本的 RDB 格式的问题。

命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。

文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。

文件同步（fsync）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。

文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。

重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

定义

appendfsync always：write + fsync，这样会严重降低 Redis 的性能。

appendfsync everysec：write + fsync，fsync 间隔为 1 秒，兼顾数据和写入性能。

appendfsync no：write 但不 fsync，fsync 的时机由操作系统决定。

这 3 种持久化方式的主要区别在于 fsync 同步 AOF 文件的时机（刷盘）。

从 Redis 7.0.0 开始，Redis 使用了 Multi Part AOF 机制。顾名思义，Multi Part AOF 就是将原来的单个 AOF 文件拆分成多个 AOF 文件。
在 Multi Part AOF 中，AOF 文件被分为三种类型，分别为：
BASE：表示基础 AOF 文件，它一般由子进程通过重写产生，该文件最多只有一个。
INCR：表示增量 AOF 文件，它一般会在 AOFRW 开始执行时被创建，该文件可能存在多个。
HISTORY：表示历史 AOF 文件，它由 BASE 和 INCR AOF 变化而来，每次 AOFRW 成功完成时，本次 AOFRW 之前对应的 BASE 和 INCR AOF 都将变为 HISTORY，HISTORY 类型的 AOF 会被 Redis 自动删除。

避免额外的检查开销，AOF 记录日志不会对命令进行语法检查。

在命令执行完之后再记录，不会阻塞当前的命令执行。

风险

当 AOF 变得太大时，Redis 在后台自动重写 AOF 产生一个新的 AOF 文件，新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。

Redis 在启动时对 AOF 文件进行检查，以判断文件是否完整，是否有损坏或者丢失的数据。

原理

RDB 的数据安全性不如 AOF，没有办法实时或者秒级持久化数据。

AOF 以一种易于理解和解析的格式包含所有操作的日志。

Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型 ，该模型对应的是 Redis 中的文件事件处理器（file event handler）。

由于文件事件处理器（file event handler）是单线程方式运行的，所以一般都说 Redis 是单线程模型。

多个 socket（客户端连接）

IO 多路复用程序（支持多个客户端连接的关键）

文件事件分派器（将 socket 关联到相应的事件处理器）

事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

String 类型的 value 超过 1MB。

复合类型（List、Hash、Set、Sorted Set 等）的 value 包含的元素超过 5000 个。

客户端超时阻塞、网络阻塞、工作线程阻塞

使用 Redis 自带的 --bigkeys 参数来查找。

使用 Redis 自带的 SCAN 命令。

借助开源工具分析 RDB 文件。

借助公有云的 Redis 分析服务。

分割 bigkey：将一个 bigkey 分割为多个小 key。

手动清理：Redis 4.0+ 可以使用 UNLINK 命令来异步删除一个或多个指定的 key。

采用合适的数据结构。

开启 lazy-free（惰性删除/延迟释放） ：lazy-free 特性是 Redis 4.0 开始引入的。

处理 hotkey 会占用大量的 CPU 和带宽，可能会影响 Redis 实例对其他请求的正常处理。

如果突然访问 hotkey 的请求超出了 Redis 的处理能力，Redis 就会直接宕机。

使用 Redis 自带的 --hotkeys 参数来查找。

使用MONITOR 命令。

借助开源项目。

根据业务情况提前预估。

业务代码中记录分析。

借助公有云的 Redis 分析服务。

读写分离：主节点处理写请求，从节点处理读请求。

使用 Redis Cluster：将热点数据分散存储在多个 Redis 节点上。

二级缓存：hotkey 采用二级缓存的方式进行处理，将 hotkey 存放一份到 JVM 本地内存中（可以用 Caffeine）。

公有云，通过代理查询缓存功能（Proxy Query Cache）优化热点 Key 问题。

KEYS *：会返回所有符合规则的 key。

HGETALL：会返回一个 Hash 中所有的键值对。

LRANGE：会返回 List 中指定范围内的元素。

SMEMBERS：返回 Set 中的所有元素。

SINTER/SUNION/SDIFF：计算多个 Set 的交集/并集/差集。

ZRANGE/ZREVRANGE：返回指定 Sorted Set 中指定排名范围内的所有元素。

ZREMRANGEBYRANK/ZREMRANGEBYSCORE：移除 Sorted Set 中指定排名范围/指定 score 范围内的所有元素。

在 redis.conf 文件中，我们可以使用 slowlog-log-slower-than 参数设置耗时命令的阈值，并使用 slowlog-max-len 参数设置耗时命令的最大记录条数。

Redis 存储存储数据的时候向操作系统申请的内存空间可能会大于数据实际需要的存储空间。

频繁修改 Redis 中的数据也会产生内存碎片。

使用 info memory 命令即可查看 Redis 内存相关的信息。

内存碎片率的计算公式：mem_fragmentation_ratio = used_memory_rss / used_memory

mem_fragmentation_ratio （内存碎片率）的值越大代表内存碎片率越严重。

mem_fragmentation_ratio > 1.5 才需要清理内存碎片。

直接通过 config set 命令将 activedefrag 配置项设置为 yes 即可。

重启节点可以做到内存碎片重新整理。

最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。

缓存无效 key、布隆过滤器、接口限流

设置热点数据永不过期或者过期时间比较长。

针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。

请求数据库写数据到缓存之前，先获取互斥锁，保证只有一个请求会落到数据库上，减少数据库的压力。

服务不可用

热点缓存失效

配置简单，易于实现。

实现数据冗余，提高数据可靠性。

读写分离，提高系统性能。

主节点故障时，需要手动切换到从节点，故障恢复时间较长。

主节点承担所有写操作，可能成为性能瓶颈。

无法实现数据分片，受单节点内存限制。

数据备份和容灾恢复：通过从节点备份主节点的数据，实现数据冗余。

读写分离：将读操作分发到从节点，减轻主节点压力，提高系统性能。

在线升级和扩展：在不影响主节点的情况下，通过增加从节点来扩展系统的读取能力。

自动故障转移，提高系统的高可用性。

具有主从复制模式的所有优点，如数据冗余和读写分离。

配置和管理相对复杂。

依然无法实现数据分片，受单节点内存限制。

高可用性要求较高的场景：通过自动故障转移，确保服务的持续可用。

数据备份和容灾恢复：在主从复制的基础上，提供自动故障转移功能。

Redis的一种高级集群模式，它通过数据分片和分布式存储实现了负载均衡和高可用性。

在Cluster模式下，Redis将所有的键值对数据分散在多个节点上。每个节点负责一部分数据，称为槽位。

通过对数据的分片，Cluster模式可以突破单节点的内存限制，实现更大规模的数据存储。

Redis Cluster将数据分为16384个槽位，每个节点负责管理一部分槽位。

当客户端向Redis Cluster发送请求时，Cluster会根据键的哈希值将请求路由到相应的节点。

具体来说，Redis Cluster使用CRC16算法计算键的哈希值，然后对16384取模，得到槽位编号。

数据分片，实现大规模数据存储。

负载均衡，提高系统性能。

自动故障转移，提高高可用性。

配置和管理较复杂。

一些复杂的多键操作可能受到限制。

大规模数据存储：通过数据分片，突破单节点内存限制。

高性能要求场景：通过负载均衡，提高系统性能。

高可用性要求场景：通过自动故障转移，确保服务的持续可用。

单词词典（Term Dictionary）

倒排列表（Posting List）

键不能含有 \0(空字符）。这个字符用来表示键的结尾。

. 和 $ 有特别的意义，只有在特定环境下才能使用。

以下划线_开头的键是保留的(不是严格要求的)。

集合名不能是空字符串""。

集合名不能含有 \0 （空字符)，这个字符表示集合名的结尾。

集合名不能以"system."开头，这是为系统集合保留的前缀。

集合名必须以下划线或者字母符号开始，并且不能包含 $。

admin : admin 数据库主要是保存 root 用户和角色。

local : local 数据库是不会被复制到其他分片的，因此可以用来存储本地单台服务器的任意 collection。

config : 当 MongoDB 使用分片设置时，config 数据库可用来保存分片的相关信息。

test : 默认创建的测试库，连接 mongod 服务时，如果不指定连接的具体数据库，默认就会连接到 test 数据库。

不能是空字符串""。

不得含有' '（空格)、.、$、/、\和 \0 (空字符)。

应全部小写。

最多 64 字节。

root page（根节点）：B+ 树的根节点。

internal page（内部节点）：不实际存储数据的中间索引节点。

leaf page（叶子节点）：真正存储数据的叶子节点，包含一个页头（page header）、块头（block header）和真正的数据（key/value）。

接受一系列原始数据文档。

对这些文档进行一系列运算。

结果文档输出给下一个阶段。

$match

$project

$sort

$limit

$skip

$count

$group

$unwind

$lookup

主节点：整个集群的写操作入口，接收所有的写操作，并将集合所有的变化记录到操作日志中，即 oplog。主节点挂掉之后会自动选出新的主节点。

从节点：从主节点同步数据，在主节点挂掉之后选举新节点。不过，从节点可以配置成 0 优先级，阻止它在选举中成为主节点。

仲裁节点：这个是为了节约资源或者多机房容灾用，只负责主节点选举时投票不存数据，保证能有节点获得多数赞成票。

实现 failover：提供自动故障恢复的功能。

实现读写分离：减轻了主节点读写压力过大的问题。

不仅大幅提升了整个集群的数据容量上限，也将读写的压力分散到不同分片，以解决副本集性能瓶颈的难题。

Config Servers：配置服务器，本质上是一个 MongoDB 的副本集，负责存储集群的各种元数据和配置，如分片地址、Chunks 等。

Mongos：路由服务，不存具体数据，从 Config 获取集群配置讲请求转发到特定的分片，并且整合分片结果返回给客户端。

Shard：每个分片是整体数据的一部分子集，从 MongoDB3.6 版本开始，每个 Shard 必须部署为副本集（replica set）架构。

垂直扩展：通过增加单个服务器的能力来实现，比如磁盘空间、内存容量、CPU 数量等。

水平扩展：通过将数据存储到多个服务器上来实现，根据需要添加额外的服务器以增加容量。

存储容量受单机限制，即磁盘资源遭遇瓶颈。

读写能力受单机限制，可能是 CPU、内存或者网卡等资源遭遇瓶颈，导致读写能力无法扩展。

分片键（Shard Key） 是数据分区的前提， 从而实现数据分发到不同服务器上，减轻服务器的负担。

分片键就是文档里面的一个字段，但是这个字段不是普通的字段，有一定的要求。

要求

选择条件

基于范围的分片

基于 Hash 值的分片

除了上述两种分片策略，还可以配置 复合片键 ，例如由一个低基数的键和一个单调递增的键组成。

Chunk（块）

分片集群不会记录每条数据在哪个分片上，而是记录 Chunk 在哪个分片上一级这个 Chunk 包含哪些数据。

默认情况下，一个 Chunk 的最大值默认为 64MB（可调整，取值范围为 1~1024 MB。如无特殊需求，建议保持默认值）。

Chunk 分裂

再平衡（Rebalance）

Chunk 迁移