B+树索引

B+树索引类型

聚簇索引

InnoDB存储引擎表是索引组织表,即表中数据按照主键顺序存放。

聚集索引( clustered index)就是按照每张表的主键构造一棵B+树,同时叶子节点中存放的即为整张表的行记录数据，也将聚集索引的叶子节点称为数据页。

每个数据页都通过一个双向链表来进行链接。

数据页上存放的是完整的每行的记录,索引页存放的仅仅是键值及指向数据页的偏移量,而不是一个完整的行记录。

聚集索引的存储并不是物理上连续的,而是逻辑上连续的，组织方式如下（物理存储上可以同样不按照主键存储。）

1. 页通过双向链表链接,页按照主键的顺序排序
2. 每个页中的记录也是通过双向链表进行维护的

索引组织表

在 InnoDB存储引擎中,表都是根据主键顺序组织存放的,这种存储方式的表称
为索引组织表( index organized table)。

在 InnoDB存储引擎表中,每张表都有个主键( Primary Key),如果在创建表时没有显式地定义主键,则InnoDB存储引擎会按如下方式选择或创建主键:

1. 首先判断表中是否有非空的唯一索引( Unique NOT NULI),如果有,则该列即为主键。
2. 如果不符合上述条件, InnoDB存储引擎自动创建一个6字节大小的指针。

当表中有多个非空唯一索引时, InnoDB存储引擎将选择建表时第一个定义的非空唯索引为主键。主键的选择根据的是定义索引的顺序,而不是建表时列的顺序。

体系架构

Mysql体系架构

最大努力通知

最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。最大努力通知型的实现方案，一般符合以下特点：

Raft简介

Raft也是一个一致性算法，和Paxos目标相同。但它还有另一个名字-易于理解的一致性算法。

Paxos和Raft都是为了实现一致性产生的。这个过程如同选举一样，参选者需要说服大多数选民(服务器)投票给他，一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。

2PC

2PC,是Two- Phase Commit的缩写,即二阶段提交,是计算机网络尤其是在数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法。

分布式环境的各种问题

通信异常

从集中式向分布式演变的过程中,必然引入了网络因素,而由于网络本身的不可靠性因此也引入了额外的问题。

网络分区

当网络由于发生异常情况,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够进行正常通信,而另一些节点则不能——我们将这个现象称为网络分区,就是俗称的“脑裂”。

三态

从上面的介绍中,我们已经了解到了在分布式环境下,网络可能会出现各式各样的问题,因此分布式系统的每一次请求与响应,存在特有的“三态”概念,即成功、失败与超时。在传统的单机系统中,应用程序在调用一个函数之后,能够得到一个非常明确的响应:成功或失败。

而在分布式系统中,由于网络是不可靠的,虽然在绝大部分情况下,网络通信也能够接收到成功或失败的响应,但是当网络出现异常的情况下,就可能会出现超时现象。

节点故障

节点故障则是分布式环境下另一个比较常见的问题,指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。通常根据经验来说,毎个节点都有可能会出现故障,并且每天都在发生。

常见应用场景

Redis可以做什么？

1. 记录帖子的点赞数、评论数和点击数 (hash)。
2. 记录用户的帖子 ID 列表 (排序)，便于快速显示用户的帖子列表 (zset)。
3. 记录帖子的标题、摘要、作者和封面信息，用于列表页展示 (hash)。
4. 记录帖子的点赞用户 ID 列表，评论 ID 列表，用于显示和去重计数 (zset)。
5. 缓存近期热帖内容 (帖子内容空间占用比较大)，减少数据库压力 (hash)。
6. 记录帖子的相关文章 ID，根据内容推荐相关帖子 (list)。
7. 如果帖子 ID 是整数自增的，可以使用 Redis 来分配帖子 ID(计数器)。
8. 收藏集和帖子之间的关系 (zset)。
9. 记录热榜帖子 ID 列表，总热榜和分类热榜 (zset)。
10. 缓存用户行为历史，进行恶意行为过滤 (zset,hash)。

Redis集群

概述

Redis Cluster是Redis的分布式解决方案，在3.0版本后加入。在3.0之前为了解决容量高可用用方面的需求基本上只能通过 客户端分片+redis sentinel或者代理（twemproxy、codis）方案解决。