HTTPS面试常问全解析，太厉害了！

开头

最近一个哥们去面试某当红大厂了，其中几个他印象深刻的面试题你们品品：

1、介绍下如何对MySQL SQL语句进行分析和优化？

2、Redis 怎样实现的分布式锁？

3、如何实现本地缓存和分布式缓存？

4、说一下 JVM 的内存布局和运行原理？

5、RocketMQ 是怎么存储消息的？源码中有哪些高可用、高性能的设计？

面试官不愧是大佬，一层接一层的问过来，问完**“Redis 怎样实现的分布式锁”又问“单机锁有哪些？它为什么不能在分布式环境下使用？”**

由于平时只是改改以前的框架代码，哥们当场懵逼！面完瞬间觉得自己的技术弱爆了！结果当然是挂！

结构化数据、非结构化数据与半结构化数据

文章的开始，聊一下结构化数据、非结构化数据与半结构化数据，因为数据特点的不同，将在技术上直接影响存储引擎的选型。

首先是结构化数据，根据定义结构化数据指的是由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，也称作为行数据，特点为：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是相同的。例如：

因此关系型数据库完美契合结构化数据的特点，关系型数据库也是关系型数据最主要的存储与管理引擎。

非结构化数据，指的是数据结构不规则或不完整，没有任何预定义的数据模型，不方便用二维逻辑表来表现的数据，例如办公文档（Word）、文本、图片、HTML、各类报表、视频音频等。

介于结构化与非结构化数据之间的数据就是半结构化数据了，它是结构化数据的一种形式，虽然不符合二维逻辑这种数据模型结构，但是包含相关标记，用来分割语义元素以及对记录和字段进行分层。常见的半结构化数据有XML和JSON，例如：

<person>
    <name>张三</name>
    <age>18</age>
    <phone>12345</phone>
</person>

这种结构也被成为自描述的结构。

以关系型数据库的方式做存储的架构演进

首先，我们看一下使用关系型数据库的方式，企业一个系统发展的几个阶段的架构演进（由于本文写的是Sql与NoSql，因此只以存储方式作为切入点，不会涉及类似MQ、ZK这些中间件内容）：

阶段一：企业刚发展的阶段，最简单，一个应用服务器配一个关系型数据库，每次读写数据库。

阶段二：无论是使用MySQL还是Oracle还是别的关系型数据库，数据库通常不会先成为性能瓶颈，通常随着企业规模的扩大，一台应用服务器扛不住上游过来的流量且一台应用服务器会产生单点故障的问题，因此加应用服务器并且在流量入口使用Nginx做一层负载均衡，保证把流量均匀打到应用服务器上。

阶段三：随着企业规模的继续扩大，此时由于读写都在同一个数据库上，数据库性能出现一定的瓶颈，此时简单地做一层读写分离，每次写主库，读备库，主备库之间通过binlog同步数据，就能很大程度上解决这个阶段的数据库性能问题

阶段四：企业发展越来越好了，业务越来越大了，做了读写分离数据库压力还是越来越大，这时候怎么办呢，一台数据库扛不住，那我们就分几台吧，做分库分表，对表做垂直拆分，对库做水平拆分。以扩数据库为例，扩出两台数据库，以一定的单号（例如交易单号），以一定的规则（例如取模），交易单号对2取模为0的丢到数据库1去，交易单号对2取模为1的丢到数据库2去，通过这样的方式将写数据库的流量均分到两台数据库上。一般分库分表会使用Shard的方式，通过一个中间件，便于连接管理、数据监控且客户端无需感知数据库ip

关系型数据库的优点

上面的方式，看似可以解决问题（实际上确实也能解决很多问题），正常对关系型数据库做一下读写分离 + 分库分表，支撑个1W+的读写QPS还是问题不大的。但是受限于关系型数据库本身，这套架构方案依然有着明显的不足，下面对利用关系型数据库方式做存储的方案的优点先进行一下分析，后一部分再分析一下缺点，对某个技术的优缺点的充分理解是技术选型的前提。

• 易理解

因为行 + 列的二维表逻辑是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型更加容易被理解

• 操作方便

通用的SQL语言使得操作关系型数据库非常方便，支持join等复杂查询

• 数据一致性

支持ACID特性，可以维护数据之间的一致性，这是使用数据库非常重要的一个理由之一，例如同银行转账，张三转给李四100元钱，张三扣100元，李四加100元，而且必须同时成功或者同时失败，否则就会造成用户的资损

• 数据稳定</