mirror of
https://github.com/qiurunze123/miaosha.git
synced 2023-11-19 22:41:03 +08:00
redis 整理
This commit is contained in:
qiurunze123
parent
5c54a07abd
commit
0f02933cbc
68
docs/database-shard-dynamic-expand.md
Normal file
68
docs/database-shard-dynamic-expand.md
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
## 面试题
|
||||
如何设计可以动态扩容缩容的分库分表方案？
|
||||
|
||||
## 面试官心理分析
|
||||
对于分库分表来说，主要是面对以下问题：
|
||||
|
||||
- 选择一个数据库中间件，调研、学习、测试；
|
||||
- 设计你的分库分表的一个方案，你要分成多少个库，每个库分成多少个表，比如 3 个库，每个库 4 个表；
|
||||
- 基于选择好的数据库中间件，以及在测试环境建立好的分库分表的环境，然后测试一下能否正常进行分库分表的读写；
|
||||
- 完成单库单表到分库分表的**迁移**，双写方案；
|
||||
- 线上系统开始基于分库分表对外提供服务；
|
||||
- 扩容了，扩容成 6 个库，每个库需要 12 个表，你怎么来增加更多库和表呢？
|
||||
|
||||
这个是你必须面对的一个事儿，就是你已经弄好分库分表方案了，然后一堆库和表都建好了，基于分库分表中间件的代码开发啥的都好了，测试都 ok 了，数据能均匀分布到各个库和各个表里去，而且接着你还通过双写的方案咔嚓一下上了系统，已经直接基于分库分表方案在搞了。
|
||||
|
||||
那么现在问题来了，你现在这些库和表又支撑不住了，要继续扩容咋办？这个可能就是说你的每个库的容量又快满了，或者是你的表数据量又太大了，也可能是你每个库的写并发太高了，你得继续扩容。
|
||||
|
||||
这都是玩儿分库分表线上必须经历的事儿。
|
||||
|
||||
## 面试题剖析
|
||||
### 停机扩容（不推荐）
|
||||
这个方案就跟停机迁移一样，步骤几乎一致，唯一的一点就是那个导数的工具，是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿，有点不太靠谱，因为既然**分库分表**就说明数据量实在是太大了，可能多达几亿条，甚至几十亿，你这么玩儿，可能会出问题。
|
||||
|
||||
从单库单表迁移到分库分表的时候，数据量并不是很大，单表最大也就两三千万。那么你写个工具，多弄几台机器并行跑，1小时数据就导完了。这没有问题。
|
||||
|
||||
如果 3 个库 + 12 个表，跑了一段时间了，数据量都 1~2 亿了。光是导 2 亿数据，都要导个几个小时，6 点，刚刚导完数据，还要搞后续的修改配置，重启系统，测试验证，10 点才可以搞完。所以不能这么搞。
|
||||
|
||||
### 优化后的方案
|
||||
一开始上来就是 32 个库，每个库 32 个表，那么总共是 1024 张表。
|
||||
|
||||
我可以告诉各位同学，这个分法，第一，基本上国内的互联网肯定都是够用了，第二，无论是并发支撑还是数据量支撑都没问题。
|
||||
|
||||
每个库正常承载的写入并发量是 1000，那么 32 个库就可以承载32 * 1000 = 32000 的写并发，如果每个库承载 1500 的写并发，32 * 1500 = 48000 的写并发，接近 5万/s 的写入并发，前面再加一个MQ，削峰，每秒写入 MQ 8 万条数据，每秒消费 5 万条数据。
|
||||
|
||||
有些除非是国内排名非常靠前的这些公司，他们的最核心的系统的数据库，可能会出现几百台数据库的这么一个规模，128个库，256个库，512个库。
|
||||
|
||||
1024 张表，假设每个表放 500 万数据，在 MySQL 里可以放 50 亿条数据。
|
||||
|
||||
每秒的 5 万写并发，总共 50 亿条数据，对于国内大部分的互联网公司来说，其实一般来说都够了。
|
||||
|
||||
谈分库分表的扩容，**第一次分库分表，就一次性给他分个够**，32 个库，1024 张表，可能对大部分的中小型互联网公司来说，已经可以支撑好几年了。
|
||||
|
||||
一个实践是利用 `32 * 32` 来分库分表，即分为 32 个库，每个库里一个表分为 32 张表。一共就是 1024 张表。根据某个 id 先根据 32 取模路由到库，再根据 32 取模路由到库里的表。
|
||||
|
||||
| orderId | id % 32 (库) | id / 32 % 32 (表) |
|
||||
|---|---|---|
|
||||
| 259 | 3 | 8 |
|
||||
| 1189 | 5 | 5 |
|
||||
| 352 | 0 | 11 |
|
||||
| 4593 | 17 | 15 |
|
||||
|
||||
|
||||
刚开始的时候，这个库可能就是逻辑库，建在一个数据库上的，就是一个mysql服务器可能建了 n 个库，比如 32 个库。后面如果要拆分，就是不断在库和 mysql 服务器之间做迁移就可以了。然后系统配合改一下配置即可。
|
||||
|
||||
比如说最多可以扩展到32个数据库服务器，每个数据库服务器是一个库。如果还是不够？最多可以扩展到 1024 个数据库服务器，每个数据库服务器上面一个库一个表。因为最多是1024个表。
|
||||
|
||||
这么搞，是不用自己写代码做数据迁移的，都交给 dba 来搞好了，但是 dba 确实是需要做一些库表迁移的工作，但是总比你自己写代码，然后抽数据导数据来的效率高得多吧。
|
||||
|
||||
哪怕是要减少库的数量，也很简单，其实说白了就是按倍数缩容就可以了，然后修改一下路由规则。
|
||||
|
||||
这里对步骤做一个总结：
|
||||
|
||||
1. 设定好几台数据库服务器，每台服务器上几个库，每个库多少个表，推荐是 32库 * 32表，对于大部分公司来说，可能几年都够了。
|
||||
2. 路由的规则，orderId 模 32 = 库，orderId / 32 模 32 = 表
|
||||
3. 扩容的时候，申请增加更多的数据库服务器，装好 mysql，呈倍数扩容，4 台服务器，扩到 8 台服务器，再到 16 台服务器。
|
||||
4. 由 dba 负责将原先数据库服务器的库，迁移到新的数据库服务器上去，库迁移是有一些便捷的工具的。
|
||||
5. 我们这边就是修改一下配置，调整迁移的库所在数据库服务器的地址。
|
||||
6. 重新发布系统，上线，原先的路由规则变都不用变，直接可以基于 n 倍的数据库服务器的资源，继续进行线上系统的提供服务。
|
||||
160
docs/database-shard-global-id-generate.md
Normal file
160
docs/database-shard-global-id-generate.md
Normal file
|
|
@ -0,0 +1,160 @@
|
|||
## 面试题
|
||||
分库分表之后，id 主键如何处理？
|
||||
|
||||
## 面试官心理分析
|
||||
其实这是分库分表之后你必然要面对的一个问题，就是 id 咋生成？因为要是分成多个表之后，每个表都是从 1 开始累加，那肯定不对啊，需要一个**全局唯一**的 id 来支持。所以这都是你实际生产环境中必须考虑的问题。
|
||||
|
||||
## 面试题剖析
|
||||
### 数据库自增 id
|
||||
这个就是说你的系统里每次得到一个 id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。
|
||||
|
||||
这个方案的好处就是方便简单，谁都会用；**缺点就是单库生成**自增 id，要是高并发的话，就会有瓶颈的；如果你硬是要改进一下，那么就专门开一个服务出来，这个服务每次就拿到当前 id 最大值，然后自己递增几个 id，一次性返回一批 id，然后再把当前最大 id 值修改成递增几个 id 之后的一个值；但是**无论如何都是基于单个数据库**。
|
||||
|
||||
**适合的场景**：你分库分表就俩原因，要不就是单库并发太高，要不就是单库数据量太大；除非是你**并发不高，但是数据量太大**导致的分库分表扩容，你可以用这个方案，因为可能每秒最高并发最多就几百，那么就走单独的一个库和表生成自增主键即可。
|
||||
|
||||
### uuid
|
||||
好处就是本地生成，不要基于数据库来了；不好之处就是，uuid 太长了，**作为主键性能太差**了，不适合用于主键。
|
||||
|
||||
适合的场景：如果你是要随机生成个什么文件名了，编号之类的，你可以用uuid，但是作为主键是不能用uuid的。
|
||||
|
||||
```java
|
||||
UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf
|
||||
```
|
||||
|
||||
### 获取系统当前时间
|
||||
这个就是获取当前时间即可，但是问题是，**并发很高的时候**，比如一秒并发几千，**会有重复的情况**，这个是肯定不合适的。基本就不用考虑了。
|
||||
|
||||
适合的场景：一般如果用这个方案，是将当前时间跟很多其他的业务字段拼接起来，作为一个id，如果业务上你觉得可以接受，那么也是可以的。你可以将别的业务字段值跟当前时间拼接起来，组成一个全局唯一的编号。
|
||||
|
||||
### snowflake 算法
|
||||
snowflake 算法是 twitter 开源的分布式 id 生成算法，就是把一个 64 位的 long 型的 id，1 个bit是不用的，用其中的 41 bit 作为毫秒数，用 10 bit 作为工作机器 id，12 bit 作为序列号。
|
||||
- 1 bit：不用，为啥呢？因为二进制里第一个 bit 为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。
|
||||
- 41 bit：表示的是时间戳，单位是毫秒。41 bit 可以表示的数字多达 `2^41 - 1`，也就是可以标识 `2^41 - 1` 个毫秒值，换算成年就是表示69年的时间。
|
||||
- 10 bit：记录工作机器 id，代表的是这个服务最多可以部署在 2^10台机器上哪，也就是1024台机器。但是 10 bit 里 5 个 bit 代表机房 id，5 个 bit 代表机器 id。意思就是最多代表 `2^5`个机房（32个机房），每个机房里可以代表 `2^5` 个机器（32台机器）。
|
||||
- 12 bit：这个是用来记录同一个毫秒内产生的不同 id，12 bit 可以代表的最大正整数是 `2^12 - 1 = 4096`，也就是说可以用这个 12 bit 代表的数字来区分**同一个毫秒内**的 4096 个不同的 id。
|
||||
|
||||
```
|
||||
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000
|
||||
```
|
||||
|
||||
```java
|
||||
public class IdWorker {
|
||||
|
||||
private long workerId;
|
||||
private long datacenterId;
|
||||
private long sequence;
|
||||
|
||||
public IdWorker(long workerId, long datacenterId, long sequence) {
|
||||
// sanity check for workerId
|
||||
// 这儿不就检查了一下，要求就是你传递进来的机房id和机器id不能超过32，不能小于0
|
||||
if (workerId > maxWorkerId || workerId < 0) {
|
||||
throw new IllegalArgumentException(
|
||||
String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
|
||||
}
|
||||
if (datacenterId > maxDatacenterId || datacenterId < 0) {
|
||||
throw new IllegalArgumentException(
|
||||
String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
|
||||
}
|
||||
System.out.printf(
|
||||
"worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
|
||||
timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);
|
||||
|
||||
this.workerId = workerId;
|
||||
this.datacenterId = datacenterId;
|
||||
this.sequence = sequence;
|
||||
}
|
||||
|
||||
private long twepoch = 1288834974657L;
|
||||
|
||||
private long workerIdBits = 5L;
|
||||
private long datacenterIdBits = 5L;
|
||||
|
||||
// 这个是二进制运算，就是 5 bit最多只能有31个数字，也就是说机器id最多只能是32以内
|
||||
private long maxWorkerId = -1L ^ (-1L << workerIdBits);
|
||||
|
||||
// 这个是一个意思，就是 5 bit最多只能有31个数字，机房id最多只能是32以内
|
||||
private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
|
||||
private long sequenceBits = 12L;
|
||||
|
||||
private long workerIdShift = sequenceBits;
|
||||
private long datacenterIdShift = sequenceBits + workerIdBits;
|
||||
private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
|
||||
private long sequenceMask = -1L ^ (-1L << sequenceBits);
|
||||
|
||||
private long lastTimestamp = -1L;
|
||||
|
||||
public long getWorkerId() {
|
||||
return workerId;
|
||||
}
|
||||
|
||||
public long getDatacenterId() {
|
||||
return datacenterId;
|
||||
}
|
||||
|
||||
public long getTimestamp() {
|
||||
return System.currentTimeMillis();
|
||||
}
|
||||
|
||||
public synchronized long nextId() {
|
||||
// 这儿就是获取当前时间戳，单位是毫秒
|
||||
long timestamp = timeGen();
|
||||
|
||||
if (timestamp < lastTimestamp) {
|
||||
System.err.printf("clock is moving backwards. Rejecting requests until %d.", lastTimestamp);
|
||||
throw new RuntimeException(String.format(
|
||||
"Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
|
||||
}
|
||||
|
||||
if (lastTimestamp == timestamp) {
|
||||
// 这个意思是说一个毫秒内最多只能有4096个数字
|
||||
// 无论你传递多少进来，这个位运算保证始终就是在4096这个范围内，避免你自己传递个sequence超过了4096这个范围
|
||||
sequence = (sequence + 1) & sequenceMask;
|
||||
if (sequence == 0) {
|
||||
timestamp = tilNextMillis(lastTimestamp);
|
||||
}
|
||||
} else {
|
||||
sequence = 0;
|
||||
}
|
||||
|
||||
// 这儿记录一下最近一次生成id的时间戳，单位是毫秒
|
||||
lastTimestamp = timestamp;
|
||||
|
||||
// 这儿就是将时间戳左移，放到 41 bit那儿；
|
||||
// 将机房 id左移放到 5 bit那儿；
|
||||
// 将机器id左移放到5 bit那儿；将序号放最后12 bit；
|
||||
// 最后拼接起来成一个 64 bit的二进制数字，转换成 10 进制就是个 long 型
|
||||
return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift)
|
||||
| (workerId << workerIdShift) | sequence;
|
||||
}
|
||||
|
||||
private long tilNextMillis(long lastTimestamp) {
|
||||
long timestamp = timeGen();
|
||||
while (timestamp <= lastTimestamp) {
|
||||
timestamp = timeGen();
|
||||
}
|
||||
return timestamp;
|
||||
}
|
||||
|
||||
private long timeGen() {
|
||||
return System.currentTimeMillis();
|
||||
}
|
||||
|
||||
// ---------------测试---------------
|
||||
public static void main(String[] args) {
|
||||
IdWorker worker = new IdWorker(1, 1, 1);
|
||||
for (int i = 0; i < 30; i++) {
|
||||
System.out.println(worker.nextId());
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
怎么说呢，大概这个意思吧，就是说 41 bit 是当前毫秒单位的一个时间戳，就这意思；然后 5 bit 是你传递进来的一个机房 id（但是最大只能是32以内），5 bit 是你传递进来的机器 id（但是最大只能是32以内），剩下的那个 12 bit序列号，就是如果跟你上次生成 id 的时间还在一个毫秒内，那么会把顺序给你累加，最多在 4096 个序号以内。
|
||||
|
||||
所以你自己利用这个工具类，自己搞一个服务，然后对每个机房的每个机器都初始化这么一个东西，刚开始这个机房的这个机器的序号就是 0。然后每次接收到一个请求，说这个机房的这个机器要生成一个 id，你就找到对应的 Worker 生成。
|
||||
|
||||
利用这个 snowflake 算法，你可以开发自己公司的服务，甚至对于机房 id 和机器 id，反正给你预留了5 bit + 5 bit，你换成别的有业务含义的东西也可以的。
|
||||
|
||||
这个 snowflake 算法相对来说还是比较靠谱的，所以你要真是搞分布式 id 生成，如果是高并发啥的，那么用这个应该性能比较好，一般每秒几万并发的场景，也足够你用了。
|
||||
36
docs/database-shard-method.md
Normal file
36
docs/database-shard-method.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
## 面试题
|
||||
现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表**动态切换**到分库分表上？
|
||||
|
||||
## 面试官心理分析
|
||||
你看看，你现在已经明白为啥要分库分表了，你也知道常用的分库分表中间件了，你也设计好你们如何分库分表的方案了（水平拆分、垂直拆分、分表），那问题来了，你接下来该怎么把你那个单库单表的系统给迁移到分库分表上去？
|
||||
|
||||
所以这都是一环扣一环的，就是看你有没有全流程经历过这个过程。
|
||||
|
||||
## 面试题剖析
|
||||
这个其实从 low 到高大上有好几种方案，我们都玩儿过，我都给你说一下。
|
||||
|
||||
### 停机迁移方案
|
||||
我先给你说一个最 low 的方案，就是很简单，大家伙儿凌晨 12 点开始运维，网站或者 app 挂个公告，说 0 点到早上 6 点进行运维，无法访问。
|
||||
|
||||
接着到 0 点停机，系统停掉，没有流量写入了，此时老的单库单表数据库静止了。然后你之前得写好一个**导数的一次性工具**，此时直接跑起来，然后将单库单表的数据哗哗哗读出来，写到分库分表里面去。
|
||||
|
||||
导数完了之后，就 ok 了，修改系统的数据库连接配置啥的，包括可能代码和 SQL 也许有修改，那你就用最新的代码，然后直接启动连到新的分库分表上去。
|
||||
|
||||
验证一下，ok了，完美，大家伸个懒腰，看看看凌晨 4 点钟的北京夜景，打个滴滴回家吧。
|
||||
|
||||
但是这个方案比较 low，谁都能干，我们来看看高大上一点的方案。
|
||||
|
||||
|
||||
|
||||
### 双写迁移方案
|
||||
这个是我们常用的一种迁移方案，比较靠谱一些，不用停机，不用看北京凌晨 4 点的风景。
|
||||
|
||||
简单来说，就是在线上系统里面，之前所有写库的地方，增删改操作，**除了对老库增删改，都加上对新库的增删改**，这就是所谓的**双写**，同时写俩库，老库和新库。
|
||||
|
||||
然后**系统部署**之后，新库数据差太远，用之前说的导数工具，跑起来读老库数据写新库，写的时候要根据 gmt_modified 这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写。简单来说，就是不允许用老数据覆盖新数据。
|
||||
|
||||
导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，比对新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。
|
||||
|
||||
接着当数据完全一致了，就 ok 了，基于仅仅使用分库分表的最新代码，重新部署一次，不就仅仅基于分库分表在操作了么，还没有几个小时的停机时间，很稳。所以现在基本玩儿数据迁移之类的，都是这么干的。
|
||||
|
||||
|
||||
105
docs/database-shard.md
Normal file
105
docs/database-shard.md
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
## 面试题
|
||||
为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们具体是如何对数据库如何进行垂直拆分或水平拆分的？
|
||||
|
||||
## 面试官心理分析
|
||||
其实这块肯定是扯到**高并发**了，因为分库分表一定是为了**支撑高并发、数据量大**两个问题的。而且现在说实话，尤其是互联网类的公司面试，基本上都会来这么一下，分库分表如此普遍的技术问题，不问实在是不行，而如果你不知道那也实在是说不过去！
|
||||
|
||||
## 面试题剖析
|
||||
### 为什么要分库分表？（设计高并发系统的时候，数据库层面该如何设计？）
|
||||
说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。
|
||||
|
||||
我先给大家抛出来一个场景。
|
||||
|
||||
假如我们现在是一个小创业公司（或者是一个 BAT 公司刚兴起的一个新部门），现在注册用户就 20 万，每天活跃用户就 1 万，每天单表数据量就 1000，然后高峰期每秒钟并发请求最多就 10。天，就这种系统，随便找一个有几年工作经验的，然后带几个刚培训出来的，随便干干都可以。
|
||||
|
||||
结果没想到我们运气居然这么好，碰上个 CEO 带着我们走上了康庄大道，业务发展迅猛，过了几个月，注册用户数达到了 2000 万！每天活跃用户数 100 万！每天单表数据量 10 万条！高峰期每秒最大请求达到 1000！同时公司还顺带着融资了两轮，进账了几个亿人民币啊！公司估值达到了惊人的几亿美金！这是小独角兽的节奏！
|
||||
|
||||
好吧，没事，现在大家感觉压力已经有点大了，为啥呢？因为每天多 10 万条数据，一个月就多 300 万条数据，现在咱们单表已经几百万数据了，马上就破千万了。但是勉强还能撑着。高峰期请求现在是 1000，咱们线上部署了几台机器，负载均衡搞了一下，数据库撑 1000QPS 也还凑合。但是大家现在开始感觉有点担心了，接下来咋整呢......
|
||||
|
||||
再接下来几个月，我的天，CEO 太牛逼了，公司用户数已经达到 1 亿，公司继续融资几十亿人民币啊！公司估值达到了惊人的几十亿美金，成为了国内今年最牛逼的明星创业公司！天，我们太幸运了。
|
||||
|
||||
但是我们同时也是不幸的，因为此时每天活跃用户数上千万，每天单表新增数据多达 50 万，目前一个表总数据量都已经达到了两三千万了！扛不住啊！数据库磁盘容量不断消耗掉！高峰期并发达到惊人的 `5000~8000`！别开玩笑了，哥。我跟你保证，你的系统支撑不到现在，已经挂掉了！
|
||||
|
||||
好吧，所以你看到这里差不多就理解分库分表是怎么回事儿了，实际上这是跟着你的公司业务发展走的，你公司业务发展越好，用户就越多，数据量越大，请求量越大，那你单个数据库一定扛不住。
|
||||
|
||||
#### 分表
|
||||
|
||||
比如你单表都几千万数据了，你确定你能扛住么？绝对不行，**单表数据量太大**，会极大影响你的 sql **执行的性能**，到了后面你的 sql 可能就跑的很慢了。一般来说，就以我的经验来看，单表到几百万的时候，性能就会相对差一些了，你就得分表了。
|
||||
|
||||
分表是啥意思？就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。
|
||||
|
||||
#### 分库
|
||||
|
||||
分库是啥意思？就是你一个库一般我们经验而言，最多支撑到并发 2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒 1000 左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。
|
||||
|
||||
这就是所谓的**分库分表**，为啥要分库分表？你明白了吧。
|
||||
|
||||
|
||||
| # | 分库分表前 | 分库分表后 |
|
||||
|---|---|---|
|
||||
| 并发支撑情况 | MySQL 单机部署，扛不住高并发 | MySQL从单机到多机，能承受的并发增加了多倍 |
|
||||
| 磁盘使用情况 | MySQL 单机磁盘容量几乎撑满 | 拆分为多个库，数据库服务器磁盘使用率大大降低 |
|
||||
| SQL 执行性能 | 单表数据量太大，SQL 越跑越慢 | 单表数据量减少，SQL 执行效率明显提升 |
|
||||
|
||||
### 用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？
|
||||
这个其实就是看看你了解哪些分库分表的中间件，各个中间件的优缺点是啥？然后你用过哪些分库分表的中间件。
|
||||
|
||||
比较常见的包括：
|
||||
|
||||
- cobar
|
||||
- TDDL
|
||||
- atlas
|
||||
- sharding-jdbc
|
||||
- mycat
|
||||
|
||||
#### cobar
|
||||
阿里 b2b 团队开发和开源的，属于 proxy 层方案。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
|
||||
|
||||
#### TDDL
|
||||
淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。
|
||||
|
||||
#### atlas
|
||||
360 开源的，属于 proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。
|
||||
|
||||
#### sharding-jdbc
|
||||
当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是有不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也**可以选择的方案**。
|
||||
|
||||
#### mycat
|
||||
基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。
|
||||
|
||||
#### 总结
|
||||
综上，现在其实建议考量的，就是 sharding-jdbc 和 mycat，这两个都可以去考虑使用。
|
||||
|
||||
sharding-jdbc 这种 client 层方案的**优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高**，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要**耦合** sharding-jdbc 的依赖；
|
||||
|
||||
mycat 这种 proxy 层方案的**缺点在于需要部署**，自己运维一套中间件，运维成本高，但是**好处在于对于各个项目是透明的**，如果遇到升级之类的都是自己中间件那里搞就行了。
|
||||
|
||||
通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用 sharding-jdbc，client 层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；但是中大型公司最好还是选用 mycat 这类 proxy 层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护 mycat，然后大量项目直接透明使用即可。
|
||||
|
||||
### 你们具体是如何对数据库如何进行垂直拆分或水平拆分的？
|
||||
|
||||
**水平拆分**的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。
|
||||
|
||||
|
||||
|
||||
**垂直拆分**的意思，就是**把一个有很多字段的表给拆分成多个表**，**或者是多个库上去**。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会**将较少的访问频率很高的字段放到一个表里去**，然后**将较多的访问频率很低的字段放到另外一个表里去**。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。
|
||||
|
||||
|
||||
|
||||
这个其实挺常见的，不一定我说，大家很多同学可能自己都做过，把一个大表拆开，订单表、订单支付表、订单商品表。
|
||||
|
||||
还有**表层面的拆分**，就是分表，将一个表变成 N 个表，就是**让每个表的数据量控制在一定范围内**，保证 SQL 的性能。否则单表数据量越大，SQL 性能就越差。一般是 200 万行左右，不要太多，但是也得看具体你怎么操作，也可能是 500 万，或者是 100 万。你的SQL越复杂，就最好让单表行数越少。
|
||||
|
||||
好了，无论分库还是分表，上面说的那些数据库中间件都是可以支持的。就是基本上那些中间件可以做到你分库分表之后，**中间件可以根据你指定的某个字段值**，比如说 userid，**自动路由到对应的库上去，然后再自动路由到对应的表里去**。
|
||||
|
||||
你就得考虑一下，你的项目里该如何分库分表？一般来说，垂直拆分，你可以在表层面来做，对一些字段特别多的表做一下拆分；水平拆分，你可以说是并发承载不了，或者是数据量太大，容量承载不了，你给拆了，按什么字段来拆，你自己想好；分表，你考虑一下，你如果哪怕是拆到每个库里去，并发和容量都ok了，但是每个库的表还是太大了，那么你就分表，将这个表分开，保证每个表的数据量并不是很大。
|
||||
|
||||
|
||||
而且这儿还有两种**分库分表的方式**：
|
||||
|
||||
- 一种是按照 range 来分，就是每个库一段连续的数据，这个一般是按比如**时间范围**来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了。
|
||||
- 或者是按照某个字段hash一下均匀分散，这个较为常用。
|
||||
|
||||
range 来分，好处在于说，扩容的时候很简单，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。
|
||||
|
||||
hash 分发，好处在于说，可以平均分配每个库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash 值重新分配到不同的库或表。
|
||||
47
docs/es-architecture.md
Normal file
47
docs/es-architecture.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
## 面试题
|
||||
es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？
|
||||
|
||||
## 面试官心理分析
|
||||
在搜索这块，lucene 是最流行的搜索库。几年前业内一般都问，你了解 lucene 吗？你知道倒排索引的原理吗？现在早已经 out 了，因为现在很多项目都是直接用基于 lucene 的分布式搜索引擎—— ElasticSearch，简称为 es。
|
||||
|
||||
而现在分布式搜索基本已经成为大部分互联网行业的 Java 系统的标配，其中尤为流行的就是 es，前几年 es 没火的时候，大家一般用 solr。但是这两年基本大部分企业和项目都开始转向 es 了。
|
||||
|
||||
所以互联网面试，肯定会跟你聊聊分布式搜索引擎，也就一定会聊聊 es，如果你确实不知道，那你真的就 out 了。
|
||||
|
||||
如果面试官问你第一个问题，确实一般都会问你 es 的分布式架构设计能介绍一下么？就看看你对分布式搜索引擎架构的一个基本理解。
|
||||
|
||||
## 面试题剖析
|
||||
ElasticSearch 设计的理念就是分布式搜索引擎，底层其实还是基于 lucene 的。核心思想就是在多台机器上启动多个 es 进程实例，组成了一个 es 集群。
|
||||
|
||||
es 中存储数据的**基本单位是索引**，比如说你现在要在 es 中存储一些订单数据，你就应该在 es 中创建一个索引 `order_idx`，所有的订单数据就都写到这个索引里面去，一个索引差不多就是相当于是 mysql 里的一张表。
|
||||
|
||||
```
|
||||
index -> type -> mapping -> document -> field。
|
||||
```
|
||||
|
||||
这样吧，为了做个更直白的介绍，我在这里做个类比。
|
||||
|
||||
index 相当于 mysql 里的一张表。而 type 没法跟 mysql 里去对比，一个 index 里可以有多个 type，每个 type 的字段都是差不多的，但是有一些略微的差别。假设有一个 index，是订单 index，里面专门是放订单数据的。就好比说你在 mysql 中建表，有些订单是实物商品的订单，比如一件衣服、一双鞋子；有些订单是虚拟商品的订单，比如游戏点卡，话费充值。就两种订单大部分字段是一样的，但是少部分字段可能有略微的一些差别。
|
||||
|
||||
所以就会在订单 index 里，建两个 type，一个是实物商品订单 type，一个是虚拟商品订单 type，这两个 type 大部分字段是一样的，少部分字段是不一样的。
|
||||
|
||||
很多情况下，一个 index 里可能就一个 type，但是确实如果说是一个 index 里有多个 type 的情况，你可以认为 index 是一个类别的表，具体的每个 type 代表了具体的一个 mysql 中的表。每个 type 有一个 mapping，如果你认为一个 type 是一个具体的一个表，index 代表多个 type 的同属于的一个类型，mapping 就是这个 type 的**表结构定义**，你在 mysql 中创建一个表，肯定是要定义表结构的，里面有哪些字段，每个字段是什么类型。实际上你往 index 里的一个 type 里面写的一条数据，叫做一条 document，一条 document 就代表了 mysql 中某个表里的一行，每个 document 有多个 field，每个 field 就代表了这个 document 中的一个字段的值。
|
||||
|
||||
|
||||
|
||||
你搞一个索引，这个索引可以拆分成多个 `shard`，每个 shard 存储部分数据。
|
||||
|
||||
|
||||
接着就是这个 shard 的数据实际是有多个备份，就是说每个 shard 都有一个 `primary shard`，负责写入数据，但是还有几个 `replica shard`。`primary shard` 写入数据之后，会将数据同步到其他几个 `replica shard` 上去。
|
||||
|
||||
|
||||
|
||||
通过这个 replica 的方案，每个 shard 的数据都有多个备份，如果某个机器宕机了，没关系啊，还有别的数据副本在别的机器上呢。高可用了吧。
|
||||
|
||||
es 集群多个节点，会自动选举一个节点为 master 节点，这个 master 节点其实就是干一些管理的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举一个节点为 master 节点。
|
||||
|
||||
如果是非 master节点宕机了，那么会由 master 节点，让那个宕机节点上的 primary shard 的身份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器，重启了之后，master 节点会控制将缺失的 replica shard 分配过去，同步后续修改的数据之类的，让集群恢复正常。
|
||||
|
||||
说得更简单一点，就是说如果某个非 master 节点宕机了。那么此节点上的 primary shard 不就没了。那好，master 会让 primary shard 对应的 replica shard（在其他机器上）切换为 primary shard。如果宕机的机器修复了，修复后的节点也不再是 primary shard，而是 replica shard。
|
||||
|
||||
其实上述就是 ElasticSearch 作为一个分布式搜索引擎最基本的一个架构设计。
|
||||
59
docs/es-introduction.md
Normal file
59
docs/es-introduction.md
Normal file
|
|
@ -0,0 +1,59 @@
|
|||
## lucene 和 es 的前世今生
|
||||
lucene 是最先进、功能最强大的搜索库。如果直接基于 lucene 开发，非常复杂，即便写一些简单的功能，也要写大量的 Java 代码，需要深入理解原理。
|
||||
|
||||
elasticsearch 基于 lucene，隐藏了 lucene 的复杂性，提供了简单易用的 restful api / Java api 接口（另外还有其他语言的 api 接口）。
|
||||
|
||||
- 分布式的文档存储引擎
|
||||
- 分布式的搜索引擎和分析引擎
|
||||
- 分布式，支持 PB 级数据
|
||||
|
||||
## es 的核心概念
|
||||
### Near Realtime
|
||||
近实时，有两层意思：
|
||||
|
||||
- 从写入数据到数据可以被搜索到有一个小延迟（大概是 1s）
|
||||
- 基于 es 执行搜索和分析可以达到秒级
|
||||
|
||||
### Cluster 集群
|
||||
集群包含多个节点，每个节点属于哪个集群都是通过一个配置来决定的，对于中小型应用来说，刚开始一个集群就一个节点很正常。
|
||||
|
||||
### Node 节点
|
||||
Node 是集群中的一个节点，节点也有一个名称，默认是随机分配的。默认节点会去加入一个名称为 `elasticsearch` 的集群。如果直接启动一堆节点，那么它们会自动组成一个 elasticsearch 集群，当然一个节点也可以组成 elasticsearch 集群。
|
||||
|
||||
### Document & field
|
||||
文档是 es 中最小的数据单元，一个 document 可以是一条客户数据、一条商品分类数据、一条订单数据，通常用 json 数据结构来表示。每个 index 下的 type，都可以存储多条 document。一个 document 里面有多个 field，每个 field 就是一个数据字段。
|
||||
|
||||
```json
|
||||
{
|
||||
"product_id": "1",
|
||||
"product_name": "iPhone X",
|
||||
"product_desc": "苹果手机",
|
||||
"category_id": "2",
|
||||
"category_name": "电子产品"
|
||||
}
|
||||
```
|
||||
|
||||
### Index
|
||||
索引包含了一堆有相似结构的文档数据，比如商品索引。一个索引包含很多 document，一个索引就代表了一类相似或者相同的 ducument。
|
||||
|
||||
### Type
|
||||
类型，每个索引里可以有一个或者多个 type，type 是 index 的一个逻辑分类，比如商品 index 下有多个 type：日化商品 type、电器商品 type、生鲜商品 type。每个 type 下的 document 的 field 可能不太一样。
|
||||
|
||||
### shard
|
||||
单台机器无法存储大量数据，es 可以将一个索引中的数据切分为多个 shard，分布在多台服务器上存储。有了 shard 就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个 shard 都是一个 lucene index。
|
||||
|
||||
### replica
|
||||
任何一个服务器随时可能故障或宕机，此时 shard 可能就会丢失，因此可以为每个 shard 创建多个 replica 副本。replica 可以在 shard 故障时提供备用服务，保证数据不丢失，多个 replica 还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认 5 个），replica shard（随时修改数量，默认 1 个），默认每个索引 10 个 shard，5 个 primary shard，5个 replica shard，最小的高可用配置，是 2 台服务器。
|
||||
|
||||
这么说吧，shard 分为 primary shard 和 replica shard。而 primary shard 一般简称为 shard，而 replica shard 一般简称为 replica。
|
||||
|
||||
|
||||
|
||||
## es 核心概念 vs. db 核心概念
|
||||
| es | db |
|
||||
|---|---|
|
||||
| index | 数据库 |
|
||||
| type | 数据表 |
|
||||
| docuemnt | 一行数据 |
|
||||
|
||||
以上是一个简单的类比。
|
||||
74
docs/es-optimizing-query-performance.md
Normal file
74
docs/es-optimizing-query-performance.md
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
## 面试题
|
||||
es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？
|
||||
|
||||
## 面试官心理分析
|
||||
这个问题是肯定要问的，说白了，就是看你有没有实际干过 es，因为啥？其实 es 性能并没有你想象中那么好的。很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 `5~10s`，坑爹了。第一次搜索的时候，是 `5~10s`，后面反而就快了，可能就几百毫秒。
|
||||
|
||||
你就很懵，每个用户第一次访问都会比较慢，比较卡么？所以你要是没玩儿过 es，或者就是自己玩玩儿 demo，被问到这个问题容易懵逼，显示出你对 es 确实玩儿的不怎么样？
|
||||
|
||||
## 面试题剖析
|
||||
说实话，es 性能优化是没有什么银弹的，啥意思呢？就是**不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景**。也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。
|
||||
|
||||
### 性能优化的杀手锏——filesystem cache
|
||||
你往es里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 `filesystem cache` 里面去。
|
||||
|
||||
|
||||
|
||||
es 的搜索引擎严重依赖于底层的 `filesystem cache`，你如果给 `filesystem cache` 更多的内存，尽量让内存可以容纳所有的 `idx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。
|
||||
|
||||
性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1秒、5秒、10秒。但如果是走 `filesystem cache`，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。
|
||||
|
||||
这里有个真实的案例。某个公司 es 节点有 3 台机器，每台机器看起来内存很多，64G，总内存就是 `64 * 3 = 192G`。每台机器给 es jvm heap 是 `32G`，那么剩下来留给 `filesystem cache` 的就是每台机器才 `32G`，总共集群里给 `filesystem cache` 的就是 `32 * 3 = 96G` 内存。而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 `1T` 的磁盘容量，es 数据量是 `1T`，那么每台机器的数据量是 `300G`。这样性能好吗？ `filesystem cache` 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。
|
||||
|
||||
归根结底，你要让 es 性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。
|
||||
|
||||
根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 es 中就存少量的数据，就是你要**用来搜索的那些索引**，如果内存留给 `filesystem cache` 的是 100G，那么你就将索引数据控制在 `100G` 以内，这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在 1 秒以内。
|
||||
|
||||
比如说你现在有一行数据。`id name age ....` 30 个字段。但是你现在搜索，只需要根据 `id name age` 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段，就会导致说 `90%` 的数据是不用来搜索的，结果硬是占据了 es 机器上的 `filesystem cache` 的空间，单条数据的数据量越大，就会导致 `filesystem cahce` 能缓存的数据就越少。其实，仅仅写入 es 中要用来检索的**少数几个字段**就可以了，比如说就写入es `id name age` 三个字段，然后你可以把其他的字段数据存在 mysql/hbase 里，我们一般是建议用 `es + hbase` 这么一个架构。
|
||||
|
||||
hbase 的特点是**适用于海量数据的在线存储**，就是对 hbase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 `doc id`，然后根据 `doc id` 到 hbase 里去查询每个 `doc id` 对应的**完整的数据**，给查出来，再返回给前端。
|
||||
|
||||
写入 es 的数据最好小于等于，或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放es，会每次查询都是 5~10秒，现在可能性能就会很高，每次查询就是 50ms。
|
||||
|
||||
### 数据预热
|
||||
假如说，哪怕是你就按照上述的方案去做了，es 集群中每个机器写入的数据量还是超过了 `filesystem cache` 一倍，比如说你写入一台机器 60G 数据，结果 `filesystem cache` 就 30G，还是有 30G 数据留在了磁盘上。
|
||||
|
||||
其实可以做**数据预热**。
|
||||
|
||||
举个例子，拿微博来说，你可以把一些大V，平时看的人很多的数据，你自己提前后台搞个系统，每隔一会儿，自己的后台系统去搜索一下热数据，刷到 `filesystem cache` 里去，后面用户实际上来看这个热数据的时候，他们就是直接从内存里搜索了，很快。
|
||||
|
||||
或者是电商，你可以将平时查看最多的一些商品，比如说 iphone 8，热数据提前后台搞个程序，每隔 1 分钟自己主动访问一次，刷到 `filesystem cache` 里去。
|
||||
|
||||
对于那些你觉得比较热的，经常会有人访问的数据，最好**做一个专门的缓存预热子系统**，就是对热数据每隔一段时间，就提前访问一下，让数据进入 `filesystem cache` 里面去。这样下次别人访问的时候，一定性能会好一些。
|
||||
|
||||
### 冷热分离
|
||||
es 可以做类似于 mysql 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。最好是将**冷数据写入一个索引中，然后热数据写入另外一个索引中**，这样可以确保热数据在被预热之后，尽量都让他们留在 `filesystem os cache` 里，**别让冷数据给冲刷掉**。
|
||||
|
||||
你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个shard。3 台机器放热数据 index；另外 3 台机器放冷数据 index。然后这样的话，你大量的时候是在访问热数据 index，热数据可能就占总数据量的 10%，此时数据量很少，几乎全都保留在 `filesystem cache` 里面了，就可以确保热数据的访问性能是很高的。但是对于冷数据而言，是在别的 index 里的，跟热数据 index 不在相同的机器上，大家互相之间都没什么联系了。如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10% 的人去访问冷数据，90% 的人在访问热数据，也无所谓了。
|
||||
|
||||
### document 模型设计
|
||||
对于 MySQL，我们经常有一些复杂的关联查询。在 es 里该怎么玩儿，es 里面的复杂的关联查询尽量别用，一旦用了性能一般都不太好。
|
||||
|
||||
最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 es 中。搜索的时候，就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。
|
||||
|
||||
document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就是那么多，不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作，尽量在 document 模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。
|
||||
|
||||
### 分页性能优化
|
||||
es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 `1000` 条数据都查到一个协调节点上，如果你有个 5 个shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。
|
||||
|
||||
分布式的，你要查第100页的10条数据，不可能说从5个 shard，每个 shard 就查 2 条数据？最后到协调节点合并成 10 条数据？你必须得从每个 shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长。非常坑爹。所以用 es 做分页的时候，你会发现越翻到后面，就越是慢。
|
||||
|
||||
我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页 or 几十页的时候，基本上就要 5~10秒 才能查出来一页数据了。
|
||||
|
||||
有什么解决方案吗？
|
||||
#### 不允许深度分页/默认深度分页性能很惨
|
||||
你系统不允许翻那么深的页，跟产品经理说，默认翻的越深，性能就越差。
|
||||
|
||||
#### 类似于 app 里的推荐商品不断下拉出来一页一页的
|
||||
类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 `scroll api`，关于如何使用，自行上网搜索。
|
||||
|
||||
scroll 会一次性给你生成**所有数据的一个快照**，然后每次翻页就是通过**游标移动**，获取下一页下一页这样子，性能会比上面说的那种分页性能也高很多很多，基本上都是毫秒级的。
|
||||
|
||||
但是 唯一的一点就是，这个适合于那种类似微博下拉翻页的，**不能随意跳到任何一页的场景**。也就是说，你不能先进入第 10 页，然后去 120 页，然后又回到 58 页，不能随意乱跳页。所以现在很多产品，都是不允许你随意翻页的，app，也有一些网站，做的就是你只能往下拉，一页一页的翻。
|
||||
|
||||
另外，这个 scroll 是要保留一段时间内的数据快照的，你需要确保用户不会持续不断翻页翻几个小时。
|
||||
20
docs/es-production-cluster.md
Normal file
20
docs/es-production-cluster.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
## 面试题
|
||||
es 生产集群的部署架构是什么？每个索引的数据量大概有多少？每个索引大概有多少个分片？
|
||||
|
||||
## 面试官心理分析
|
||||
这个问题，包括后面的 redis 什么的，谈到 es、redis、mysql 分库分表等等技术，面试必问！就是你生产环境咋部署的？说白了，这个问题没啥技术含量，就是看你有没有在真正的生产环境里干过这事儿！
|
||||
|
||||
有些同学可能是没在生产环境中干过的，没实际去拿线上机器部署过 es 集群，也没实际玩儿过，也没往 es 集群里面导入过几千万甚至是几亿的数据量，可能你就不太清楚这里面的一些生产项目中的细节。
|
||||
|
||||
如果你是自己就玩儿过 demo，没碰过真实的 es 集群，那你可能此时会懵。别懵，你一定要云淡风轻的回答出来这个问题，表示你确实干过这事儿。
|
||||
|
||||
## 面试题剖析
|
||||
其实这个问题没啥，如果你确实干过 es，那你肯定了解你们生产 es 集群的实际情况，部署了几台机器？有多少个索引？每个索引有多大数据量？每个索引给了多少个分片？你肯定知道！
|
||||
|
||||
但是如果你确实没干过，也别虚，我给你说一个基本的版本，你到时候就简单说一下就好了。
|
||||
|
||||
- es 生产集群我们部署了 5 台机器，每台机器是 6 核 64G 的，集群总内存是 320G。
|
||||
- 我们 es 集群的日增量数据大概是 2000 万条，每天日增量数据大概是 500MB，每月增量数据大概是 6 亿，15G。目前系统已经运行了几个月，现在 es 集群里数据总量大概是 100G 左右。
|
||||
- 目前线上有 5 个索引（这个结合你们自己业务来，看看自己有哪些数据可以放 es 的），每个索引的数据量大概是 20G，所以这个数据量之内，我们每个索引分配的是 8 个 shard，比默认的 5 个 shard 多了 3 个shard。
|
||||
|
||||
大概就这么说一下就行了。
|
||||
119
docs/es-write-query-search.md
Normal file
119
docs/es-write-query-search.md
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
## 面试题
|
||||
es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？底层的 lucene 介绍一下呗？倒排索引了解吗？
|
||||
|
||||
## 面试官心理分析
|
||||
问这个，其实面试官就是要看看你了解不了解 es 的一些基本原理，因为用 es 无非就是写入数据，搜索数据。你要是不明白你发起一个写入和搜索请求的时候，es 在干什么，那你真的是......
|
||||
|
||||
对 es 基本就是个黑盒，你还能干啥？你唯一能干的就是用 es 的 api 读写数据了。要是出点什么问题，你啥都不知道，那还能指望你什么呢？
|
||||
|
||||
## 面试题剖析
|
||||
### es 写数据过程
|
||||
- 客户端选择一个 node 发送请求过去，这个 node 就是 `coordinating node`（协调节点）。
|
||||
- `coordinating node` 对 document 进行**路由**，将请求转发给对应的 node（有 primary shard）。
|
||||
- 实际的 node 上的 `primary shard` 处理请求，然后将数据同步到 `replica node`。
|
||||
- `coordinating node` 如果发现 `primary node` 和所有 `replica node` 都搞定之后，就返回响应结果给客户端。
|
||||
|
||||
|
||||
|
||||
### es 读数据过程
|
||||
可以通过 `doc id` 来查询，会根据 `doc id` 进行 hash，判断出来当时把 `doc id` 分配到了哪个 shard 上面去，从那个 shard 去查询。
|
||||
|
||||
- 客户端发送请求到**任意**一个 node，成为 `coordinate node`。
|
||||
- `coordinate node` 对 `doc id` 进行哈希路由，将请求转发到对应的 node，此时会使用 `round-robin` **随机轮询算法**，在 `primary shard` 以及其所有 replica 中随机选择一个，让读请求负载均衡。
|
||||
- 接收请求的 node 返回 document 给 `coordinate node`。
|
||||
- `coordinate node` 返回 document 给客户端。
|
||||
|
||||
### es 搜索数据过程
|
||||
es 最强大的是做全文检索，就是比如你有三条数据：
|
||||
```
|
||||
java真好玩儿啊
|
||||
java好难学啊
|
||||
j2ee特别牛
|
||||
```
|
||||
|
||||
你根据 `java` 关键词来搜索，将包含 `java`的 `document` 给搜索出来。es 就会给你返回：java真好玩儿啊，java好难学啊。
|
||||
|
||||
- 客户端发送请求到一个 `coordinate node`。
|
||||
- 协调节点将搜索请求转发到**所有**的 shard 对应的 `primary shard` 或 `replica shard`，都可以。
|
||||
- query phase：每个 shard 将自己的搜索结果（其实就是一些 `doc id`）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
|
||||
- fetch phase：接着由协调节点根据 `doc id` 去各个节点上**拉取实际**的 `document` 数据，最终返回给客户端。
|
||||
|
||||
|
||||
### 写数据底层原理
|
||||
|
||||
|
||||
|
||||
先写入内存 buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入 translog 日志文件。
|
||||
|
||||
如果 buffer 快满了，或者到一定时间，就会将内存 buffer 数据 `refresh` 到一个新的 `segment file` 中，但是此时数据不是直接进入 `segment file` 磁盘文件，而是先进入 `os cache` 。这个过程就是 `refresh`。
|
||||
|
||||
每隔 1 秒钟，es 将 buffer 中的数据写入一个**新的** `segment file`，每秒钟会产生一个**新的磁盘文件** `segment file`，这个 `segment file` 中就存储最近 1 秒内 buffer 中写入的数据。
|
||||
|
||||
但是如果 buffer 里面此时没有数据，那当然不会执行 refresh 操作，如果buffer里面有数据，默认 1 秒钟执行一次 refresh 操作，刷入一个新的 segment file 中。
|
||||
|
||||
操作系统里面，磁盘文件其实都有一个东西，叫做 `os cache`，即操作系统缓存，就是说数据写入磁盘文件之前，会先进入 `os cache`，先进入操作系统级别的一个内存缓存中去。只要 `buffer` 中的数据被 refresh 操作刷入 `os cache`中，这个数据就可以被搜索到了。
|
||||
|
||||
为什么叫 es 是**准实时**的？ `NRT`，全称 `near real-time`。默认是每隔 1 秒 refresh 一次的，所以 es 是准实时的，因为写入的数据 1 秒之后才能被看到。可以通过 es 的 `restful api` 或者 `java api`，**手动**执行一次 refresh 操作，就是手动将 buffer 中的数据刷入 `os cache`中，让数据立马就可以被搜索到。只要数据被输入 `os cache` 中，buffer 就会被清空了，因为不需要保留 buffer 了，数据在 translog 里面已经持久化到磁盘去一份了。
|
||||
|
||||
重复上面的步骤，新的数据不断进入 buffer 和 translog，不断将 `buffer` 数据写入一个又一个新的 `segment file` 中去，每次 `refresh` 完 buffer 清空，translog保留。随着这个过程推进，translog 会变得越来越大。当 translog 达到一定长度的时候，就会触发 `commit` 操作。
|
||||
|
||||
commit 操作发生第一步，就是将 buffer 中现有数据 `refresh` 到 `os cache` 中去，清空 buffer。然后，将一个 `commit point` 写入磁盘文件，里面标识着这个 `commit point` 对应的所有 `segment file`，同时强行将 `os cache` 中目前所有的数据都 `fsync` 到磁盘文件中去。最后**清空** 现有 translog 日志文件，重启一个 translog，此时 commit 操作完成。
|
||||
|
||||
这个 commit 操作叫做 `flush`。默认 30 分钟自动执行一次 `flush`，但如果 translog 过大，也会触发 `flush`。flush 操作就对应着 commit 的全过程，我们可以通过 es api，手动执行 flush 操作，手动将 os cache 中的数据 fsync 强刷到磁盘上去。
|
||||
|
||||
translog 日志文件的作用是什么？你执行 commit 操作之前，数据要么是停留在 buffer 中，要么是停留在 os cache 中，无论是 buffer 还是 os cache 都是内存，一旦这台机器死了，内存中的数据就全丢了。所以需要将数据对应的操作写入一个专门的日志文件 `translog` 中，一旦此时机器宕机，再次重启的时候，es 会自动读取 translog 日志文件中的数据，恢复到内存 buffer 和 os cache 中去。
|
||||
|
||||
translog 其实也是先写入 os cache 的，**默认每隔5秒**刷一次到磁盘中去，所以默认情况下，可能有 5 秒的数据会仅仅停留在 buffer 或者 translog 文件的 os cache 中，如果此时机器挂了，会**丢失** 5 秒钟的数据。但是这样性能比较好，最多丢 5 秒的数据。也可以将 translog 设置成每次写操作必须是直接 `fsync` 到磁盘，但是性能会差很多。
|
||||
|
||||
实际上你在这里，如果面试官没有问你 es 丢数据的问题，你可以在这里给面试官炫一把，你说，其实 es 第一是准实时的，数据写入 1 秒后可以搜索到；可能会丢失数据的。有 5 秒的数据，停留在 buffer、translog os cache、segment file os cache 中，而不在磁盘上，此时如果宕机，会导致 5 秒的**数据丢失**。
|
||||
|
||||
> 数据写入 segment file 之后，同时就建立好了倒排索引。
|
||||
|
||||
### 删除/更新数据底层原理
|
||||
如果是删除操作，commit 的时候会生成一个 `.del` 文件，里面将某个 doc 标识为 `deleted` 状态，那么搜索的时候根据 `.del` 文件就知道这个 doc 是否被删除了。
|
||||
|
||||
如果是更新操作，就是将原来的 doc 标识为 `deleted` 状态，然后新写入一条数据。
|
||||
|
||||
buffer 每次 refresh 一次，就会产生一个 `segment file`，所以默认情况下是 1 秒钟一个 `segment file`，这样下来 `segment file` 会越来越多，此时会定期执行 merge。每次 merge 的时候，会将多个 `segment file` 合并成一个，同时这里会将标识为 `deleted` 的 doc 给**物理删除掉**，然后将新的 `segment file` 写入磁盘，这里会写一个 `commit point`，标识所有新的 `segment file`，然后打开 `segment file` 供搜索使用，同时删除旧的 `segment file`。
|
||||
|
||||
### 底层 lucene
|
||||
简单来说，lucene 就是一个 jar 包，里面包含了封装好的各种建立倒排索引的算法代码。我们用 Java 开发的时候，引入 lucene jar，然后基于 lucene 的 api 去开发就可以了。
|
||||
|
||||
通过 lucene，我们可以将已有的数据建立索引，lucene 会在本地磁盘上面，给我们组织索引的数据结构。
|
||||
|
||||
### 倒排索引
|
||||
在搜索引擎中，每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合。例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。
|
||||
|
||||
那么，倒排索引就是**关键词到文档** ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。
|
||||
|
||||
举个栗子。
|
||||
|
||||
有以下文档：
|
||||
|
||||
| DocId | Doc |
|
||||
|---|---|
|
||||
| 1 | 谷歌地图之父跳槽 Facebook |
|
||||
| 2 | 谷歌地图之父加盟 Facebook |
|
||||
| 3 | 谷歌地图创始人拉斯离开谷歌加盟 Facebook |
|
||||
| 4 | 谷歌地图之父跳槽 Facebook 与 Wave 项目取消有关 |
|
||||
| 5 | 谷歌地图之父拉斯加盟社交网站 Facebook |
|
||||
|
||||
对文档进行分词之后，得到以下**倒排索引**。
|
||||
|
||||
| WordId | Word | DocIds |
|
||||
|---|---|---|
|
||||
| 1 | 谷歌 | 1,2,3,4,5 |
|
||||
| 2 | 地图 | 1,2,3,4,5 |
|
||||
| 3 | 之父 | 1,2,4,5 |
|
||||
| 4 | 跳槽 | 1,4 |
|
||||
| 5 | Facebook | 1,2,3,4,5 |
|
||||
| 6 | 加盟 | 2,3,5 |
|
||||
| 7 | 创始人 | 3 |
|
||||
| 8 | 拉斯 | 3,5 |
|
||||
| 9 | 离开 | 3 |
|
||||
| 10 | 与 | 4 |
|
||||
| .. | .. | .. |
|
||||
|
||||
另外，实用的倒排索引还可以记录更多的信息，比如文档频率信息，表示在文档集合中有多少个文档包含某个单词。
|
||||
|
||||
那么，有了倒排索引，搜索引擎可以很方便地响应用户的查询。比如用户输入查询 `Facebook`，搜索系统查找倒排索引，从中读出包含这个单词的文档，这些文档就是提供给用户的搜索结果。
|
||||
65
docs/high-concurrency-design.md
Normal file
65
docs/high-concurrency-design.md
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
## 面试题
|
||||
如何设计一个高并发系统？
|
||||
|
||||
## 面试官心理分析
|
||||
说实话，如果面试官问你这个题目，那么你必须要使出全身吃奶劲了。为啥？因为你没看到现在很多公司招聘的 JD 里都是说啥，有高并发就经验者优先。
|
||||
|
||||
如果你确实有真才实学，在互联网公司里干过高并发系统，那你确实拿 offer 基本如探囊取物，没啥问题。面试官也绝对不会这样来问你，否则他就是蠢。
|
||||
|
||||
假设你在某知名电商公司干过高并发系统，用户上亿，一天流量几十亿，高峰期并发量上万，甚至是十万。那么人家一定会仔细盘问你的系统架构，你们系统啥架构？怎么部署的？部署了多少台机器？缓存咋用的？MQ 咋用的？数据库咋用的？就是深挖你到底是如何扛住高并发的。
|
||||
|
||||
因为真正干过高并发的人一定知道，脱离了业务的系统架构都是在纸上谈兵，真正在复杂业务场景而且还高并发的时候，那系统架构一定不是那么简单的，用个 redis，用 mq 就能搞定？当然不是，真实的系统架构搭配上业务之后，会比这种简单的所谓“高并发架构”要复杂很多倍。
|
||||
|
||||
如果有面试官问你个问题说，如何设计一个高并发系统？那么不好意思，**一定是因为你实际上没干过高并发系统**。面试官看你简历就没啥出彩的，感觉就不咋地，所以就会问问你，如何设计一个高并发系统？其实说白了本质就是看看你有没有自己研究过，有没有一定的知识积累。
|
||||
|
||||
最好的当然是招聘个真正干过高并发的哥儿们咯，但是这种哥儿们人数稀缺，不好招。所以可能次一点的就是招一个自己研究过的哥儿们，总比招一个傻也不会的哥儿们好吧！
|
||||
|
||||
所以这个时候你必须得做一把个人秀了，秀出你所有关于高并发的知识！
|
||||
|
||||
|
||||
## 面试题剖析
|
||||
其实所谓的高并发，如果你要理解这个问题呢，其实就得从高并发的根源出发，为啥会有高并发？为啥高并发就很牛逼？
|
||||
|
||||
我说的浅显一点，很简单，就是因为刚开始系统都是连接数据库的，但是要知道数据库支撑到每秒并发两三千的时候，基本就快完了。所以才有说，很多公司，刚开始干的时候，技术比较 low，结果业务发展太快，有的时候系统扛不住压力就挂了。
|
||||
|
||||
当然会挂了，凭什么不挂？你数据库如果瞬间承载每秒 5000/8000，甚至上万的并发，一定会宕机，因为比如 mysql 就压根儿扛不住这么高的并发量。
|
||||
|
||||
所以为啥高并发牛逼？就是因为现在用互联网的人越来越多，很多app、网站、系统承载的都是高并发请求，可能高峰期每秒并发量几千，很正常的。如果是什么双十一之类的，每秒并发几万几十万都有可能。
|
||||
|
||||
那么如此之高的并发量，加上原本就如此之复杂的业务，咋玩儿？真正厉害的，一定是在复杂业务系统里玩儿过高并发架构的人，但是你没有，那么我给你说一下你该怎么回答这个问题：
|
||||
|
||||
可以分为以下 6 点：
|
||||
|
||||
- 系统拆分
|
||||
- 缓存
|
||||
- MQ
|
||||
- 分库分表
|
||||
- 读写分离
|
||||
- ElasticSearch
|
||||
|
||||
|
||||
|
||||
### 系统拆分
|
||||
将一个系统拆分为多个子系统，用 dubbo 来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以扛高并发么。
|
||||
|
||||
### 缓存
|
||||
缓存，必须得用缓存。大部分的高并发场景，都是**读多写少**，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家 redis 轻轻松松单机几万的并发。所以你可以考虑考虑你的项目里，那些承载主要请求的**读场景，怎么用缓存来抗高并发**。
|
||||
|
||||
### MQ
|
||||
MQ，必须得用 MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，你要是用 redis 来承载写那肯定不行，人家是缓存，数据随时就被 LRU 了，数据格式还无比简单，没有事务支持。所以该用 mysql 还得用 mysql 啊。那你咋办？用 MQ 吧，大量的写请求灌入 MQ 里，排队慢慢玩儿，**后边系统消费后慢慢写**，控制在 mysql 承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用 MQ 来异步写，提升并发性。MQ 单机抗几万并发也是 ok 的，这个之前还特意说过。
|
||||
|
||||
### 分库分表
|
||||
分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表**拆分为多个表**，每个表的数据量保持少一点，提高 sql 跑的性能。
|
||||
|
||||
### 读写分离
|
||||
读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，**主库写**入，**从库读**取，搞一个读写分离。**读流量太多**的时候，还可以**加更多的从库**。
|
||||
|
||||
### ElasticSearch
|
||||
Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用 es 来承载，还有一些全文搜索类的操作，也可以考虑用 es 来承载。
|
||||
|
||||
|
||||
上面的 6 点，基本就是高并发系统肯定要干的一些事儿，大家可以仔细结合之前讲过的知识考虑一下，到时候你可以系统的把这块阐述一下，然后每个部分要注意哪些问题，之前都讲过了，你都可以阐述阐述，表明你对这块是有点积累的。
|
||||
|
||||
说句实话，毕竟你真正厉害的一点，不是在于弄明白一些技术，或者大概知道一个高并发系统应该长什么样？其实实际上在真正的复杂的业务系统里，做高并发要远远比上面提到的点要复杂几十倍到上百倍。你需要考虑：哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何 join，哪些数据要放到缓存里去，放哪些数据再可以扛住高并发的请求，你需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是无比复杂的，一旦做过一次，并且做好了，你在这个市场上就会非常的吃香。
|
||||
|
||||
其实大部分公司，真正看重的，不是说你掌握高并发相关的一些基本的架构知识，架构中的一些技术，RocketMQ、Kafka、Redis、Elasticsearch，高并发这一块，你了解了，也只能是次一等的人才。对一个有几十万行代码的复杂的分布式系统，一步一步架构、设计以及实践过高并发架构的人，这个经验是难能可贵的。
|
||||
61
docs/how-to-ensure-high-availability-of-message-queues.md
Normal file
61
docs/how-to-ensure-high-availability-of-message-queues.md
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
## 面试题
|
||||
如何保证消息队列的高可用？
|
||||
|
||||
## 面试官心理分析
|
||||
如果有人问到你 MQ 的知识，**高可用是必问的**。[上一讲](/docs/high-concurrency/why-mq.md)提到，MQ 会导致**系统可用性降低**。所以只要你用了 MQ，接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。
|
||||
|
||||
要是你傻乎乎的就干用了一个 MQ，各种问题从来没考虑过，那你就杯具了，面试官对你的印象就是，只会简单使用一些技术，没任何思考，马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内的普通小弟还凑合，要是做薪资 20k+ 的高工，那就惨了，让你设计个系统，里面肯定一堆坑，出了事故公司受损失，团队一起背锅。
|
||||
|
||||
## 面试题剖析
|
||||
这个问题这么问是很好的，因为不能问你 Kafka 的高可用性怎么保证？ActiveMQ 的高可用性怎么保证？一个面试官要是这么问就显得很没水平，人家可能用的就是 RabbitMQ，没用过 Kafka，你上来问人家 Kafka 干什么？这不是摆明了刁难人么。
|
||||
|
||||
所以有水平的面试官，问的是 MQ 的高可用性怎么保证？这样就是你用过哪个 MQ，你就说说你对那个 MQ 的高可用性的理解。
|
||||
|
||||
### RabbitMQ 的高可用性
|
||||
RabbitMQ 是比较有代表性的，因为是**基于主从**（非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。
|
||||
|
||||
RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。
|
||||
|
||||
#### 单机模式
|
||||
单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的😄，没人生产用单机模式。
|
||||
|
||||
#### 普通集群模式（无高可用性）
|
||||
普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。但是你**创建的 queue，只会放在一个 RabbitMQ 实例上**，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。
|
||||
|
||||
|
||||
|
||||
这种方式确实很麻烦，也不怎么好，**没做到所谓的分布式**，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实例消费数据，前者有**数据拉取的开销**，后者导致**单实例性能瓶颈**。
|
||||
|
||||
而且如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你**开启了消息持久化**，让 RabbitMQ 落地存储消息的话，**消息不一定会丢**，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。
|
||||
|
||||
所以这个事儿就比较尴尬了，这就**没有什么所谓的高可用性**，**这方案主要是提高吞吐量的**，就是说让集群中多个节点来服务某个 queue 的读写操作。
|
||||
|
||||
#### 镜像集群模式（高可用性）
|
||||
这种模式，才是所谓的 RabbitMQ 的高可用模式，跟普通集群模式不一样的是，你创建的 queue，无论元数据还是 queue 里的消息都会**存在于多个实例上**，然后每次你写消息到 queue 的时候，都会自动把**消息同步**到多个实例的 queue 上。
|
||||
|
||||
|
||||
|
||||
这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就**没有扩展性可言**了，如果某个 queue 负载很重，你加机器，新增的机器也包含了这个 queue 的所有数据，并没有办法线性扩展你的 queue。
|
||||
|
||||
那么**如何开启这个镜像集群模式**呢？其实很简单，RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是**镜像集群模式的策略**，指定的时候可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
|
||||
|
||||
### Kafka 的高可用性
|
||||
Kafka 一个最基本的架构认识：多个 broker 组成，每个 broker 是一个节点；你创建一个 topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据。
|
||||
|
||||
这就是**天然的分布式消息队列**，就是说一个 topic 的数据，是**分散放在多个机器上的，每个机器就放一部分数据**。
|
||||
|
||||
实际上 RabbmitMQ 之类的，并不是分布式消息队列，它就是传统的消息队列，只不过提供了一些集群、HA(High Availability, 高可用性)的机制而已，因为无论怎么玩儿，RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。
|
||||
|
||||
Kafka 0.8 以前，是没有 HA 机制的，就是任何一个 broker 宕机了，那个 broker 上的 partition 就废了，没法写也没法读，没有什么高可用性可言。
|
||||
|
||||
Kafka 0.8 以后，提供了 HA 机制，就是 replica（复制品） 副本机制。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。然后所有 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是 follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上的数据即可。只能读写 leader？很简单，**要是你可以随意读写每个 follower，那么就要 care 数据一致性的问题**，系统复杂度太高，很容易出问题。Kafka 会均匀的将一个 partition 的所有 replica 分布在不同的机器上，这样才可以提高容错性。
|
||||
|
||||
|
||||
|
||||
这么搞，就有所谓的**高可用性**了，因为如果某个 broker 宕机了，没事儿，那个 broker上面的 partition 在其他机器上都有副本的，如果这上面有某个 partition 的 leader，那么此时会**重新选举**一个新的 leader 出来，大家继续读写那个新的 leader 即可。这就有所谓的高可用性了。
|
||||
|
||||
**写数据**的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
|
||||
|
||||
**消费**的时候，只会从 leader 去读，但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。
|
||||
|
||||
看到这里，相信你大致明白了 Kafka 是如何保证高可用机制的了，对吧？不至于一无所知，现场还能给面试官画画图。要是遇上面试官确实是 Kafka 高手，深挖了问，那你只能说不好意思，太深入的你没研究过┭┮﹏┭┮。
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
## 面试题
|
||||
如何保证 redis 的高并发和高可用？redis 的主从复制原理能介绍一下么？redis 的哨兵原理能介绍一下么？
|
||||
|
||||
## 面试官心理分析
|
||||
其实问这个问题，主要是考考你，redis 单机能承载多高并发？如果单机扛不住如何扩容扛更多的并发？redis 会不会挂？既然 redis 会挂那怎么保证 redis 是高可用的？
|
||||
|
||||
其实针对的都是项目中你肯定要考虑的一些问题，如果你没考虑过，那确实你对生产系统中的问题思考太少。
|
||||
|
||||
## 面试题剖析
|
||||
如果你用 redis 缓存技术的话，肯定要考虑如何用 redis 来加多台机器，保证 redis 是高并发的，还有就是如何让 redis 保证自己不是挂掉以后就直接死掉了，即 redis 高可用。
|
||||
|
||||
由于此节内容较多，因此，会分为两个小节进行讲解。
|
||||
- [redis 主从架构](/docs/high-concurrency/redis-master-slave.md)
|
||||
- [redis 基于哨兵实现高可用](/docs/high-concurrency/redis-sentinel.md)
|
||||
|
||||
redis 实现**高并发**主要依靠**主从架构**，一主多从，一般来说，很多项目其实就足够了，单主用来写入数据，单机几万 QPS，多从用来查询数据，多个从实例可以提供每秒 10w 的 QPS。
|
||||
|
||||
如果想要在实现高并发的同时，容纳大量的数据，那么就需要 redis 集群，使用 redis 集群之后，可以提供每秒几十万的读写并发。
|
||||
|
||||
redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
## 面试题
|
||||
如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？
|
||||
|
||||
## 面试官心理分析
|
||||
其实这是很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是 MQ 领域的基本问题，其实本质上还是问你**使用消息队列如何保证幂等性**，这个是你架构里要考虑的一个问题。
|
||||
|
||||
## 面试题剖析
|
||||
回答这个问题，首先你别听到重复消息这个事儿，就一无所知吧，你**先大概说一说可能会有哪些重复消费的问题**。
|
||||
|
||||
首先，比如 RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题，正常。因为这问题通常不是 MQ 自己保证的，是由我们开发来保证的。挑一个 Kafka 来举个例子，说说怎么重复消费吧。
|
||||
|
||||
Kafka 实际上有个 offset 的概念，就是每个消息写进去，都有一个 offset，代表消息的序号，然后 consumer 消费了数据之后，**每隔一段时间**（定时定期），会把自己消费过的消息的 offset 提交一下，表示“我已经消费过了，下次我要是重启啥的，你就让我继续从上次消费到的 offset 来继续消费吧”。
|
||||
|
||||
但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启了，如果碰到点着急的，直接 kill 进程了，再重启。这会导致 consumer 有些消息处理了，但是没来得及提交 offset，尴尬了。重启之后，少数消息会再次消费一次。
|
||||
|
||||
|
||||
|
||||
举个栗子。
|
||||
|
||||
有这么个场景。数据 1/2/3 依次进入 kafka，kafka 会给这三条数据每条分配一个 offset，代表这条数据的序号，分配的 offset 依次是 152/153/154。消费者从 kafka 去消费的时候，也是按照这个顺序去消费。假如当消费者消费了 `offset=153` 的这条数据，刚准备去提交 offset 到 zookeeper，此时消费者进程被重启了。那么此时消费过的数据 1/2 的 offset 并没有提交，kafka 也就不知道你已经消费了 `offset=153` 这条数据。那么重启之后，消费者会找 kafka 说，嘿，哥儿们，你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。数据 1/2 再次被消费。
|
||||
|
||||
如果消费者干的事儿是拿一条数据就往数据库里写一条，会导致说说，你可能就把数据 1/2 在数据库里插入了 2 次，那么数据就错啦。
|
||||
|
||||
|
||||
其实重复消费不可怕，可怕的是你没考虑到重复消费之后，**怎么保证幂等性**。
|
||||
|
||||
举个例子吧。假设你有个系统，消费一条往数据库里插入一条，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到第二次的时候，自己判断一下已经消费过了，直接扔了，不就保留了一条数据？
|
||||
|
||||
一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性。
|
||||
|
||||
幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，**不能出错**。
|
||||
|
||||
那所以第二个问题来了，怎么保证消息队列消费的幂等性？
|
||||
|
||||
其实还是得结合业务来思考，我这里给几个思路：
|
||||
|
||||
- 比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。
|
||||
- 比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。
|
||||
- 比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
|
||||
- 比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。
|
||||
|
||||
|
||||
|
||||
当然，如何保证 MQ 的消费是幂等性的，需要结合具体的业务来看。
|
||||
30
docs/how-to-ensure-the-order-of-messages.md
Normal file
30
docs/how-to-ensure-the-order-of-messages.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
## 面试题
|
||||
如何保证消息的顺序性？
|
||||
|
||||
## 面试官心理分析
|
||||
其实这个也是用 MQ 的时候必问的话题，第一看看你了不了解顺序这个事儿？第二看看你有没有办法保证消息是有顺序的？这是生产系统中常见的问题。
|
||||
|
||||
## 面试题剖析
|
||||
我举个例子，我们以前做过一个 mysql `binlog` 同步的系统，压力还是非常大的，日同步数据要达到上亿。mysql -> mysql，常见的一点在于说大数据 team，就需要同步一个 mysql 库过来，对公司的业务系统的数据做各种复杂的操作。
|
||||
|
||||
你在 mysql 里增删改一条数据，对应出来了增删改 3 条 `binlog`，接着这三条 `binlog` 发送到 MQ 里面，到消费出来依次执行，起码得保证人家是按照顺序来的吧？不然本来是：增加、修改、删除；你楞是换了顺序给执行成删除、修改、增加，不全错了么。
|
||||
|
||||
本来这个数据同步过来，应该最后这个数据被删除了；结果你搞错了这个顺序，最后这个数据保留下来了，数据同步就出错了。
|
||||
|
||||
先看看顺序会错乱的俩场景：
|
||||
- RabbitMQ：一个 queue，多个 consumer，这不明显乱了；
|
||||
|
||||
|
||||
|
||||
- kafka：一个 topic，一个 partition，一个 consumer，内部多线程，这不也明显乱了。
|
||||
|
||||
|
||||
|
||||
### 解决方案
|
||||
#### RabbitMQ
|
||||
拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已，确实是麻烦点；或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。
|
||||
|
||||
|
||||
#### kafka
|
||||
一个 topic，一个 partition，一个 consumer，内部单线程消费；写 N 个内存 queue，然后对于 N 个线程，每个线程分别消费一个内存 queue 即可。
|
||||
|
||||
91
docs/how-to-ensure-the-reliable-transmission-of-messages.md
Normal file
91
docs/how-to-ensure-the-reliable-transmission-of-messages.md
Normal file
|
|
@ -0,0 +1,91 @@
|
|||
## 面试题
|
||||
如何保证消息的可靠性传输？或者说，如何处理消息丢失的问题？
|
||||
|
||||
## 面试官心理分析
|
||||
这个是肯定的，用 MQ 有个基本原则，就是**数据不能多一条，也不能少一条**，不能多，就是前面说的[重复消费和幂等性问题](/docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md)。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。
|
||||
|
||||
如果说你这个是用 MQ 来传递非常核心的消息，比如说计费、扣费的一些消息，那必须确保这个 MQ 传递过程中**绝对不会把计费消息给弄丢**。
|
||||
|
||||
## 面试题剖析
|
||||
数据的丢失问题，可能出现在生产者、MQ、消费者中，咱们从 RabbitMQ 和 Kafka 分别来分析一下吧。
|
||||
|
||||
### RabbitMQ
|
||||
|
||||
|
||||
#### 生产者弄丢了数据
|
||||
|
||||
生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。
|
||||
|
||||
此时可以选择用 RabbitMQ 提供的事务功能，就是生产者**发送数据之前**开启 RabbitMQ 事务`channel.txSelect`，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务`channel.txRollback`，然后重试发送消息；如果收到了消息，那么可以提交事务`channel.txCommit`。
|
||||
```java
|
||||
// 开启事务
|
||||
channel.txSelect
|
||||
try {
|
||||
// 这里发送消息
|
||||
} catch (Exception e) {
|
||||
channel.txRollback
|
||||
|
||||
// 这里再次重发这条消息
|
||||
}
|
||||
|
||||
// 提交事务
|
||||
channel.txCommit
|
||||
```
|
||||
|
||||
但是问题是，RabbitMQ 事务机制（同步）一搞，基本上**吞吐量会下来，因为太耗性能**。
|
||||
|
||||
所以一般来说，如果你要确保说写 RabbitMQ 的消息别丢，可以开启`confirm`模式，在生产者那里设置开启`confirm`模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个`ack`消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你一个`nack`接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
|
||||
|
||||
事务机制和`cnofirm`机制最大的不同在于，**事务机制是同步的**，你提交一个事务之后会**阻塞**在那儿，但是`confirm`机制是**异步**的，你发送个消息之后就可以发送下一个消息，然后那个消息RabbitMQ 接收了之后会异步回调你一个接口通知你这个消息接收到了。
|
||||
|
||||
所以一般在生产者这块**避免数据丢失**，都是用`confirm`机制的。
|
||||
|
||||
#### RabbitMQ 弄丢了数据
|
||||
就是 RabbitMQ 自己弄丢了数据，这个你必须**开启 RabbitMQ 的持久化**，就是消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了，**恢复之后会自动读取之前存储的数据**，一般数据不会丢。除非极其罕见的是，RabbitMQ 还没持久化，自己就挂了，**可能导致少量数据丢失**，但是这个概率较小。
|
||||
|
||||
设置持久化有**两个步骤**：
|
||||
|
||||
- 创建 queue 的时候将其设置为持久化<br>
|
||||
这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是不会持久化 queue 里的数据。
|
||||
- 第二个是发送消息的时候将消息的 `deliveryMode` 设置为 2<br>
|
||||
就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。
|
||||
|
||||
必须要同时设置这两个持久化才行，RabbitMQ 哪怕是挂了，再次重启，也会从磁盘上重启恢复 queue，恢复这个 queue 里的数据。
|
||||
|
||||
持久化可以跟生产者那边的`confirm`机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者`ack`了，所以哪怕是在持久化到磁盘之前，RabbitMQ 挂了，数据丢了，生产者收不到`ack`，你也是可以自己重发的。
|
||||
|
||||
注意，哪怕是你给 RabbitMQ 开启了持久化机制，也有一种可能，就是这个消息写到了 RabbitMQ 中，但是还没来得及持久化到磁盘上，结果不巧，此时 RabbitMQ 挂了，就会导致内存里的一点点数据丢失。
|
||||
|
||||
#### 消费端弄丢了数据
|
||||
RabbitMQ 如果丢失了数据，主要是因为你消费的时候，**刚消费到，还没处理，结果进程挂了**，比如重启了，那么就尴尬了，RabbitMQ 认为你都消费了，这数据就丢了。
|
||||
|
||||
这个时候得用 RabbitMQ 提供的`ack`机制，简单来说，就是你关闭 RabbitMQ 的自动`ack`，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里`ack`一把。这样的话，如果你还没处理完，不就没有`ack`？那 RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别的 consumer 去处理，消息是不会丢的。
|
||||
|
||||
|
||||
|
||||
### Kafka
|
||||
|
||||
#### 消费端弄丢了数据
|
||||
唯一可能导致消费者弄丢数据的情况，就是说，你那个消费到了这个消息，然后消费者那边**自动提交了 offset**，让 Kafka 以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
|
||||
|
||||
这不是跟 RabbitMQ 差不多吗，大家都知道 Kafka 会自动提交 offset，那么只要**关闭自动提交** offset，在处理完之后自己手动提交 offset，就可以保证数据不会丢。但是此时确实还是**可能会有重复消费**，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
|
||||
|
||||
生产环境碰到的一个问题，就是说我们的 Kafka 消费者消费到了数据之后是写到一个内存的 queue 里先缓冲一下，结果有的时候，你刚把消息写入内存 queue，然后消费者会自动提交 offset。然后此时我们重启了系统，就会导致内存 queue 里还没来得及处理的数据就丢失了。
|
||||
|
||||
#### Kafka 弄丢了数据
|
||||
|
||||
这块比较常见的一个场景，就是 Kafka 某个 broker 宕机，然后重新选举 partiton 的 leader。大家想想，要是此时其他的 follower 刚好还有些数据没有同步，结果此时 leader 挂了，然后选举某个 follower 成 leader 之后，他不就少了一些数据？这就丢了一些数据啊。
|
||||
|
||||
生产环境也遇到过，我们也是，之前 Kafka 的 leader 机器宕机了，将 follower 切换为 leader 之后，就会发现说这个数据就丢了。
|
||||
|
||||
所以此时一般是要求起码设置如下 4 个参数：
|
||||
|
||||
- 给 topic 设置 `replication.factor` 参数：这个值必须大于 1，要求每个 partition 必须有至少2个副本。
|
||||
- 在 Kafka 服务端设置 `min.insync.replicas` 参数：这个值必须大于 1，这个是要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队，这样才能确保 leader 挂了还有一个 follower 吧。
|
||||
- 在 producer 端设置 `acks=all`：这个是要求每条数据，必须是**写入所有 replica 之后，才能认为是写成功了**。
|
||||
- 在 producer 端设置 `retries=MAX`（很大很大很大的一个值，无限次重试的意思）：这个是**要求一旦写入失败，就无限重试**，卡在这里了。
|
||||
|
||||
我们生产环境就是按照上述要求配置的，这样配置之后，至少在 Kafka broker 端就可以保证在 leader 所在 broker 发生故障，进行 leader 切换时，数据不会丢失。
|
||||
|
||||
#### 生产者会不会弄丢数据？
|
||||
如果按照上述的思路设置了 `ack=all`，一定不会丢，要求是，你的 leader 接收到消息，所有的 follower 都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
|
||||
26
docs/mq-design.md
Normal file
26
docs/mq-design.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
## 面试题
|
||||
如果让你写一个消息队列，该如何进行架构设计？说一下你的思路。
|
||||
|
||||
## 面试官心理分析
|
||||
其实聊到这个问题，一般面试官要考察两块：
|
||||
|
||||
- 你有没有对某一个消息队列做过较为深入的原理的了解，或者从整体了解把握住一个消息队列的架构原理。
|
||||
- 看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来。
|
||||
|
||||
说实话，问类似问题的时候，大部分人基本都会蒙，因为平时从来没有思考过类似的问题，大多数人就是平时埋头用，从来不去思考背后的一些东西。类似的问题，比如，如果让你来设计一个 Spring 框架你会怎么做？如果让你来设计一个 Dubbo 框架你会怎么做？如果让你来设计一个 MyBatis 框架你会怎么做？
|
||||
|
||||
|
||||
## 面试题剖析
|
||||
其实回答这类问题，说白了，不求你看过那技术的源码，起码你要大概知道那个技术的基本原理、核心组成部分、基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好。
|
||||
|
||||
比如说这个消息队列系统，我们从以下几个角度来考虑一下：
|
||||
|
||||
- 首先这个 mq 得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个 partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给 topic 增加 partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？
|
||||
|
||||
- 其次你得考虑一下这个 mq 的数据要不要落地磁盘吧？那肯定要了，落磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是 kafka 的思路。
|
||||
|
||||
- 其次你考虑一下你的 mq 的可用性啊？这个事儿，具体参考之前可用性那个环节讲解的 kafka 的高可用保障机制。多副本 -> leader & follower -> broker 挂了重新选举 leader 即可对外服务。
|
||||
|
||||
- 能不能支持数据 0 丢失啊？可以的，参考我们之前说的那个 kafka 数据零丢失方案。
|
||||
|
||||
mq 肯定是很复杂的，面试官问你这个问题，其实是个开放题，他就是看看你有没有从架构角度整体构思和设计的思维以及能力。确实这个问题可以刷掉一大批人，因为大部分人平时不思考这些东西。
|
||||
69
docs/mq-interview.md
Normal file
69
docs/mq-interview.md
Normal file
|
|
@ -0,0 +1,69 @@
|
|||
## 消息队列面试场景
|
||||
|
||||
**面试官**：你好。
|
||||
|
||||
**候选人**：你好。
|
||||
|
||||
（面试官在你的简历上面看到了，呦，有个亮点，你在项目里用过 `MQ`，比如说你用过 `ActiveMQ`）
|
||||
|
||||
**面试官**：你在系统里用过消息队列吗？（面试官在随和的语气中展开了面试）
|
||||
|
||||
**候选人**：用过的（此时感觉没啥）
|
||||
|
||||
**面试官**：那你说一下你们在项目里是怎么用消息队列的？
|
||||
|
||||
**候选人**：巴拉巴拉，“我们啥啥系统发送个啥啥消息到队列，别的系统来消费啥啥的。比如我们有个订单系统，订单系统会每次下一个新的订单的时候，就会发送时一条消息到`ActiveMQ`里面去，后台有个库存系统负责获取了消息然后更新库存。”
|
||||
|
||||
（部分同学在这里会进入一个误区，就是你仅仅就是知道以及回答你们是怎么用这个消息队列的，用这个消息队列来干了个什么事情？）
|
||||
|
||||
**面试官**：那你们为什么使用消息队列啊？你的订单系统不发送消息到 `MQ`，直接订单系统调用库存系统一个接口，咔嚓一下，直接就调用成功，库存不也就更新了。
|
||||
|
||||
**候选人**：额。。。（楞了一下，为什么？我没怎么仔细想过啊，老大让用就用了），硬着头皮胡言乱语了几句。
|
||||
|
||||
（面试官此时听你楞了一下，然后听你胡言乱语了几句，开始心里觉得有点儿那什么了，怀疑你之前就压根儿没思考过这问题）
|
||||
|
||||
**面试官**：那你说说用消息队列都有什么优点和缺点？
|
||||
|
||||
（面试官此时心里想的是，你的 `MQ` 在项目里为啥要用？你没考虑过，那我稍微简单点儿，我问问你消息队列你之前有没有考虑过如果用的话，优点和缺点分别是啥？）
|
||||
|
||||
**候选人**：这个。。。（确实平时没怎么考虑过这个问题啊。。。胡言乱语了）
|
||||
|
||||
（面试官此时心里已经更觉得你这哥儿们不行，平时都没什么思考）
|
||||
|
||||
**面试官**：`Kafka`、`ActiveMQ`、`RabbitMQ`、`RocketMQ` 都有什么区别？
|
||||
|
||||
（面试官问你这个问题，就是说，绕过比较虚的话题，直接看看你对各种 `MQ` 中间件是否了解，是否做过功课，是否做过调研）
|
||||
|
||||
**候选人**：我们就用过 `ActiveMQ`，所以别的没用过。。。区别，也不太清楚。。。
|
||||
|
||||
（面试官此时却是觉得你这哥儿们平时就是瞎用，根本就没什么思考，觉得不行）
|
||||
|
||||
**面试官**：那你们是如何保证消息队列的高可用啊？
|
||||
|
||||
**候选人**：这个。。。我平时就是简单走 API 调用一下，不太清楚消息队列怎么部署的。。。
|
||||
|
||||
**面试官**：如何保证消息不被重复消费啊？如何保证消费的时候是幂等的啊？
|
||||
|
||||
**候选人**：啥？（`MQ` 不就是写入&消费就可以了，哪来这么多问题）
|
||||
|
||||
**面试官**：如何保证消息的可靠性传输啊？要是消息丢失了怎么办啊？
|
||||
|
||||
**候选人**：我们没怎么丢过消息啊。。。
|
||||
|
||||
**面试官**：那如何保证消息的顺序性？
|
||||
|
||||
**候选人**：顺序性？什么意思？我为什么要保证消息的顺序性？
|
||||
|
||||
**面试官**：如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
|
||||
|
||||
**候选人**：不是，我这平时没遇到过这些问题啊，就是简单用用，知道 `MQ` 的一些功能。
|
||||
|
||||
**面试官**：如果让你写一个消息队列，该如何进行架构设计啊？说一下你的思路。
|
||||
|
||||
**候选人**：。。。。。我还是走吧。。。。
|
||||
|
||||
---
|
||||
|
||||
这是面试官的一种面试风格，就是面试官的问题不是发散的，而是从一个小点慢慢铺开。比如说面试官可能会跟你聊聊高并发话题，就这个话题里面跟你聊聊缓存、`MQ` 等等东西，**由浅入深，一步步深挖**。
|
||||
|
||||
其实上面是一个非常典型的关于消息队列的技术考察过程，好的面试官一定是从你做过的某一个点切入，然后层层展开深入考察，一个接一个问，直到把这个技术点刨根问底，问到最底层。
|
||||
32
docs/mq-time-delay-and-expired-failure.md
Normal file
32
docs/mq-time-delay-and-expired-failure.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
## 面试题
|
||||
如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
|
||||
|
||||
## 面试官心理分析
|
||||
你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的极其极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是整个这就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 rabbitmq 设置了消息过期时间后就没了怎么办？
|
||||
|
||||
所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于，举个例子，消费端每次消费之后要写 mysql，结果 mysql 挂了，消费端 hang 那儿了，不动了。或者是消费端出了个什么岔子，导致消费速度极其慢。
|
||||
|
||||
## 面试题剖析
|
||||
关于这个事儿，我们一个一个来梳理吧，先假设一个场景，我们现在消费端出故障了，然后大量消息在 mq 里积压，现在出事故了，慌了。
|
||||
|
||||
### 大量消息在 mq 里积压了几个小时了还没解决
|
||||
几千万条数据在 MQ 里积压了七八个小时，从下午 4 点多，积压到了晚上 11 点多。这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。
|
||||
|
||||
一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟就是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。
|
||||
|
||||
一般这个时候，只能临时紧急扩容了，具体操作步骤和思路如下：
|
||||
- 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。
|
||||
- 新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
|
||||
- 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，**消费之后不做耗时的处理**，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
|
||||
- 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
|
||||
- 等快速消费完积压数据之后，**得恢复原先部署的架构**，**重新**用原先的 consumer 机器来消费消息。
|
||||
|
||||
### mq 中的消息过期失效了
|
||||
假设你用的是 RabbitMQ，RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里，而是**大量的数据会直接搞丢**。
|
||||
|
||||
这个情况下，就不是说要增加 consumer 消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是**批量重导**，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。
|
||||
|
||||
假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。
|
||||
|
||||
### mq 都快写满了
|
||||
如果走的方式是消息积压在 mq 里，那么如果你很长时间都没处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，**消费一个丢弃一个，都不要了**，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。
|
||||
41
docs/mysql-read-write-separation.md
Normal file
41
docs/mysql-read-write-separation.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
## 面试题
|
||||
你们有没有做 MySQL 读写分离？如何实现 MySQL 的读写分离？MySQL 主从复制原理的是啥？如何解决 MySQL 主从同步的延时问题？
|
||||
|
||||
## 面试官心理分析
|
||||
高并发这个阶段，肯定是需要做读写分离的，啥意思？因为实际上大部分的互联网公司，一些网站，或者是 app，其实都是读多写少。所以针对这个情况，就是写一个主库，但是主库挂多个从库，然后从多个从库来读，那不就可以支撑更高的读并发压力了吗？
|
||||
|
||||
## 面试题剖析
|
||||
### 如何实现 MySQL 的读写分离？
|
||||
其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。
|
||||
|
||||
### MySQL 主从复制原理的是啥？
|
||||
主库将变更写入 binlog 日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，然后执行 binlog 日志中的内容，也就是在自己本地再次执行一遍 SQL，这样就可以保证自己跟主库的数据是一样的。
|
||||
|
||||
|
||||
|
||||
这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据一定会比主库慢一些，是**有延时**的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。
|
||||
|
||||
而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。
|
||||
|
||||
所以 MySQL 实际上在这一块有两个机制，一个是**半同步复制**，用来解决主库数据丢失问题；一个是**并行复制**，用来解决主从同步延时问题。
|
||||
|
||||
这个所谓**半同步复制**，也叫 `semi-sync` 复制，指的就是主库写入 binlog 日志之后，就会将**强制**此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到**至少一个从库**的 ack 之后才会认为写操作完成了。
|
||||
|
||||
所谓**并行复制**，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后**并行重放不同库的日志**，这是库级别的并行。
|
||||
|
||||
### MySQL 主从同步延时问题（精华）
|
||||
以前线上确实处理过因为主从同步延时问题而导致的线上的 bug，属于小型的生产事故。
|
||||
|
||||
是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据，再把它查出来，然后更新这条数据。在生产环境高峰期，写并发达到了 2000/s，这个时候，主从复制延时大概是在小几十毫秒。线上会发现，每天总有那么一些数据，我们期望更新一些重要的数据状态，但在高峰期时候却没更新。用户跟客服反馈，而客服就会反馈给我们。
|
||||
|
||||
我们通过 MySQL 命令：
|
||||
```sql
|
||||
show status
|
||||
```
|
||||
查看 `Seconds_Behind_Master`，可以看到从库复制主库的数据落后了几 ms。
|
||||
|
||||
一般来说，如果主从延迟较为严重，有以下解决方案：
|
||||
- 分库，将一个主库拆分为多个主库，每个主库的写并发就减少了几倍，此时主从延迟可以忽略不计。
|
||||
- 打开 MySQL 支持的并行复制，多个库并行复制。如果说某个库的写入并发就是特别高，单库写并发达到了 2000/s，并行复制还是没意义。
|
||||
- 重写代码，写代码的同学，要慎重，插入数据时立马查询可能查不到。
|
||||
- 如果确实是存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询**设置直连主库**。**不推荐**这种方法，你这么搞导致读写分离的意义就丧失了。
|
||||
42
docs/redis-caching-avalanche-and-caching-penetration.md
Normal file
42
docs/redis-caching-avalanche-and-caching-penetration.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
## 面试题
|
||||
了解什么是 redis 的雪崩和穿透？redis 崩溃之后会怎么样？系统该如何应对这种情况？如何处理 redis 的穿透？
|
||||
|
||||
## 面试官心理分析
|
||||
其实这是问到缓存必问的，因为缓存雪崩和穿透，是缓存最大的两个问题，要么不出现，一旦出现就是致命性的问题。所以面试官一定会问你。
|
||||
|
||||
## 面试题剖析
|
||||
### 缓存雪崩
|
||||
对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。
|
||||
|
||||
这就是缓存雪崩。
|
||||
|
||||
|
||||
|
||||
大约在 3 年前，国内比较知名的一个互联网公司，曾因为缓存事故，导致雪崩，后台系统全部崩溃，事故从当天下午持续到晚上凌晨 3~4 点，公司损失了几千万。
|
||||
|
||||
缓存雪崩的事前事中事后的解决方案如下。
|
||||
- 事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃。
|
||||
- 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
|
||||
- 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
|
||||
|
||||
|
||||
|
||||
用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 redis。如果 ehcache 和 redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 redis 中。
|
||||
|
||||
限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？**走降级**！可以返回一些默认的值，或者友情提示，或者空白的值。
|
||||
|
||||
好处：
|
||||
- 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
|
||||
- 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
|
||||
- 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，就是可能点击几次刷不出来页面，但是可能多点几次，就可以刷出来一次。
|
||||
|
||||
### 缓存穿透
|
||||
对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。
|
||||
|
||||
黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。
|
||||
|
||||
举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。
|
||||
|
||||
|
||||
|
||||
解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 `set -999 UNKNOWN`。这样的话，下次便能走缓存了。
|
||||
16
docs/redis-cas.md
Normal file
16
docs/redis-cas.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
## 面试题
|
||||
redis 的并发竞争问题是什么？如何解决这个问题？了解 redis 事务的 CAS 方案吗？
|
||||
|
||||
## 面试官心理分析
|
||||
这个也是线上非常常见的一个问题，就是**多客户端同时并发写**一个 key，可能本来应该先到的数据后到了，导致数据版本错了。或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。
|
||||
|
||||
而且 redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案。
|
||||
|
||||
## 面试题剖析
|
||||
某个时刻，多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 key，别人都不允许读和写。
|
||||
|
||||
|
||||
|
||||
你要写入缓存的数据，都是从 mysql 里查出来的，都得写入 mysql 中，写入 mysql 中的时候必须保存一个时间戳，从 mysql 查出来的时候，时间戳也查出来。
|
||||
|
||||
每次要**写之前，先判断**一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据。
|
||||
117
docs/redis-cluster.md
Normal file
117
docs/redis-cluster.md
Normal file
|
|
@ -0,0 +1,117 @@
|
|||
## 面试题
|
||||
redis 集群模式的工作原理能说一下么？在集群模式下，redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？
|
||||
|
||||
## 面试官心理分析
|
||||
在前几年，redis 如果要搞几个节点，每个节点存储一部分的数据，得**借助一些中间件**来实现，比如说有 `codis`，或者 `twemproxy`，都有。有一些 redis 中间件，你读写 redis 中间件，redis 中间件负责将你的数据分布式存储在多台机器上的 redis 实例中。
|
||||
|
||||
这两年，redis 不断在发展，redis 也不断的有新的版本，现在的 redis 集群模式，可以做到在多台机器上，部署多个 redis 实例，每个实例存储一部分的数据，同时每个 redis 实例可以挂 redis 从实例，自动确保说，如果 redis 主实例挂了，会自动切换到 redis 从实例顶上来。
|
||||
|
||||
现在 redis 的新版本，大家都是用 redis cluster 的，也就是 redis 原生支持的 redis 集群模式，那么面试官肯定会就 redis cluster 对你来个几连炮。要是你没用过 redis cluster，正常，以前很多人用 codis 之类的客户端来支持集群，但是起码你得研究一下 redis cluster 吧。
|
||||
|
||||
如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个 G，单机就足够了，可以使用 replication，一个 master 多个 slaves，要几个 slave 跟你要求的读吞吐量有关，然后自己搭建一个 sentinel 集群去保证 redis 主从架构的高可用性。
|
||||
|
||||
redis cluster，主要是针对**海量数据+高并发+高可用**的场景。redis cluster 支撑 N 个 redis master node，每个 master node 都可以挂载多个 slave node。这样整个 redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。
|
||||
|
||||
## 面试题剖析
|
||||
### redis cluster 介绍
|
||||
- 自动将数据进行分片，每个 master 上放一部分数据
|
||||
- 提供内置的高可用支持，部分 master 不可用时，还是可以继续工作的
|
||||
|
||||
在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。
|
||||
|
||||
16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，`gossip` 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。
|
||||
|
||||
### 节点间的内部通信机制
|
||||
#### 基本通信原理
|
||||
- redis cluster 节点间采用 gossip 协议进行通信
|
||||
集中式是将集群元数据（节点信息、故障等等）几种存储在某个节点上。集中式元数据集中存储的一个典型代表，就是大数据领域的 `storm`。它是分布式的大数据实时计算引擎，是集中式的元数据存储的结构，底层基于 zookeeper（分布式协调的中间件）对所有元数据进行存储维护。
|
||||
|
||||
|
||||
|
||||
redis 维护集群元数据采用另一个方式， `gossip` 协议，所有节点都持有一份元数据，不同的节点如果出现了元数据的变更，就不断将元数据发送给其它的节点，让其它节点也进行元数据的变更。
|
||||
|
||||
|
||||
|
||||
**集中式**的**好处**在于，元数据的读取和更新，时效性非常好，一旦元数据出现了变更，就立即更新到集中式的存储中，其它节点读取的时候就可以感知到；**不好**在于，所有的元数据的更新压力全部集中在一个地方，可能会导致元数据的存储有压力。
|
||||
|
||||
gossip 好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，降低了压力；不好在于，元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。
|
||||
|
||||
- 10000 端口
|
||||
每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如 7001，那么用于节点间通信的就是 17001 端口。每个节点每隔一段时间都会往另外几个节点发送 `ping` 消息，同时其它几个节点接收到 `ping` 之后返回 `pong`。
|
||||
|
||||
- 交换的信息
|
||||
信息包括故障信息，节点的增加和删除，hash slot 信息 等等。
|
||||
|
||||
#### gossip 协议
|
||||
gossip 协议包含多种消息，包含 `ping`,`pong`,`meet`,`fail` 等等。
|
||||
- meet：某个节点发送 meet 给新加入的节点，让新节点加入集群中，然后新节点就会开始与其它节点进行通信。
|
||||
```bash
|
||||
redis-trib.rb add-node
|
||||
```
|
||||
其实内部就是发送了一个 gossip meet 消息给新加入的节点，通知那个节点去加入我们的集群。
|
||||
|
||||
- ping：每个节点都会频繁给其它节点发送 ping，其中包含自己的状态还有自己维护的集群元数据，互相通过 ping 交换元数据。
|
||||
- pong：返回 ping 和 meeet，包含自己的状态和其它信息，也用于信息广播和更新。
|
||||
- fail：某个节点判断另一个节点 fail 之后，就发送 fail 给其它节点，通知其它节点说，某个节点宕机啦。
|
||||
|
||||
#### ping 消息深入
|
||||
ping 时要携带一些元数据，如果很频繁，可能会加重网络负担。
|
||||
|
||||
每个节点每秒会执行 10 次 ping，每次会选择 5 个最久没有通信的其它节点。当然如果发现某个节点通信延时达到了 `cluster_node_timeout / 2`，那么立即发送 ping，避免数据交换延时过长，落后的时间太长了。比如说，两个节点之间都 10 分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题。所以 `cluster_node_timeout` 可以调节，如果调得比较大，那么会降低 ping 的频率。
|
||||
|
||||
每次 ping，会带上自己节点的信息，还有就是带上 1/10 其它节点的信息，发送出去，进行交换。至少包含 `3` 个其它节点的信息，最多包含`总结点-2` 个其它节点的信息。
|
||||
|
||||
### 分布式寻址算法
|
||||
- hash 算法（大量缓存重建）
|
||||
- 一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
|
||||
- redis cluster 的 hash slot 算法
|
||||
|
||||
#### hash 算法
|
||||
来了一个 key，首先计算 hash 值，然后对节点数取模。然后打在不同的 master 节点上。一旦某一个 master 节点宕机，所有请求过来，都会基于最新的剩余 master 节点数去取模，尝试去取数据。这会导致**大部分的请求过来，全部无法拿到有效的缓存**，导致大量的流量涌入数据库。
|
||||
|
||||
|
||||
|
||||
#### 一致性 hash 算法
|
||||
一致性 hash 算法将整个 hash 值空间组织成一个虚拟的圆环，整个空间按顺时针方向组织，下一步将各个 master 节点（使用服务器的 ip 或主机名）进行 hash。这样就能确定每个节点在其哈希环上的位置。
|
||||
|
||||
来了一个 key，首先计算 hash 值，并确定此数据在环上的位置，从此位置沿环**顺时针“行走”**，遇到的第一个 master 节点就是 key 所在位置。
|
||||
|
||||
在一致性哈希算法中，如果一个节点挂了，受影响的数据仅仅是此节点到环空间前一个节点（沿着逆时针方向行走遇到的第一个节点）之间的数据，其它不受影响。增加一个节点也同理。
|
||||
|
||||
燃鹅，一致性哈希算法在节点太少时，容易因为节点分布不均匀而造成**缓存热点**的问题。为了解决这种热点问题，一致性 hash 算法引入了虚拟节点机制，即对每一个节点计算多个 hash，每个计算结果位置都放置一个虚拟节点。这样就实现了数据的均匀分布，负载均衡。
|
||||
|
||||
|
||||
|
||||
#### redis cluster 的 hash slot 算法
|
||||
redis cluster 有固定的 `16384` 个 hash slot，对每个 `key` 计算 `CRC16` 值，然后对 `16384` 取模，可以获取 key 对应的 hash slot。
|
||||
|
||||
redis cluster 中每个 master 都会持有部分 slot，比如有 3 个 master，那么可能每个 master 持有 5000 多个 hash slot。hash slot 让 node 的增加和移除很简单，增加一个 master，就将其他 master 的 hash slot 移动部分过去，减少一个 master，就将它的 hash slot 移动到其他 master 上去。移动 hash slot 的成本是非常低的。客户端的 api，可以对指定的数据，让他们走同一个 hash slot，通过 `hash tag` 来实现。
|
||||
|
||||
任何一台机器宕机，另外两个节点，不影响的。因为 key 找的是 hash slot，不是机器。
|
||||
|
||||
|
||||
|
||||
### redis cluster 的高可用与主备切换原理
|
||||
redis cluster 的高可用的原理，几乎跟哨兵是类似的
|
||||
|
||||
#### 判断节点宕机
|
||||
如果一个节点认为另外一个节点宕机，那么就是 `pfail`，**主观宕机**。如果多个节点都认为另外一个节点宕机了，那么就是 `fail`，**客观宕机**，跟哨兵的原理几乎一样，sdown，odown。
|
||||
|
||||
在 `cluster-node-timeout` 内，某个节点一直没有返回 `pong`，那么就被认为 `pfail`。
|
||||
|
||||
如果一个节点认为某个节点 `pfail` 了，那么会在 `gossip ping` 消息中，`ping` 给其他节点，如果**超过半数**的节点都认为 `pfail` 了，那么就会变成 `fail`。
|
||||
|
||||
#### 从节点过滤
|
||||
对宕机的 master node，从其所有的 slave node 中，选择一个切换成 master node。
|
||||
|
||||
检查每个 slave node 与 master node 断开连接的时间，如果超过了 `cluster-node-timeout * cluster-slave-validity-factor`，那么就**没有资格**切换成 `master`。
|
||||
|
||||
#### 从节点选举
|
||||
每个从节点，都根据自己对 master 复制数据的 offset，来设置一个选举时间，offset 越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。
|
||||
|
||||
所有的 master node 开始 slave 选举投票，给要进行选举的 slave 进行投票，如果大部分 master node`（N/2 + 1）`都投票给了某个从节点，那么选举通过，那个从节点可以切换成 master。
|
||||
|
||||
从节点执行主备切换，从节点切换为主节点。
|
||||
|
||||
#### 与哨兵比较
|
||||
整个流程跟哨兵相比，非常类似，所以说，redis cluster 功能强大，直接集成了 replication 和 sentinel 的功能。
|
||||
78
docs/redis-consistence.md
Normal file
78
docs/redis-consistence.md
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
## 面试题
|
||||
如何保证缓存与数据库的双写一致性？
|
||||
|
||||
## 面试官心理分析
|
||||
你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？
|
||||
|
||||
## 面试题剖析
|
||||
一般来说，就是如果你的系统**不是严格要求**“缓存+数据库”必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案，即：**读请求和写请求串行化**，串到一个**内存队列**里去，这样就可以保证一定不会出现不一致的情况。
|
||||
|
||||
串行化之后，就会导致系统的吞吐量大幅度降低，用比正常情况下多几倍的机器去支撑线上的一个请求。
|
||||
|
||||
### Cache Aside Pattern
|
||||
最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。
|
||||
- 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
|
||||
- 更新的时候，**先删除缓存，然后更新数据库**。
|
||||
|
||||
**为什么是删除缓存，而不是更新缓存？**
|
||||
|
||||
原因很简单，很多时候，复杂点的缓存的场景，缓存不单单是数据库中直接取出来的值。
|
||||
|
||||
比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。
|
||||
|
||||
另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于**比较复杂的缓存数据计算的场景**，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，**这个缓存到底会不会被频繁访问到？**
|
||||
|
||||
举个栗子，一个缓存涉及的表的字段，在 1 分钟内就修改了 20 次，或者是 100 次，那么缓存更新 20 次，100 次；但是这个缓存在 1 分钟内只被读取了 1 次，有**大量的冷数据**。实际上，如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。**用到缓存才去算缓存。**
|
||||
|
||||
其实删除缓存，而不是更新缓存，就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像 mybatis，hibernate，都有懒加载思想。查询一个部门，部门带了一个员工的 list，没有必要说每次查询部门，都里面的 1000 个员工的数据也同时查出来啊。80% 的情况，查这个部门，就只是要访问这个部门的信息就可以了。先查部门，同时要访问里面的员工，那么这个时候只有在你要访问里面的员工的时候，才会去数据库里面查询 1000 个员工。
|
||||
|
||||
### 最初级的缓存不一致问题及解决方案
|
||||
问题：先修改数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。
|
||||
|
||||
|
||||
|
||||
解决思路：先删除缓存，再修改数据库。如果数据库修改失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中。
|
||||
|
||||
### 比较复杂的数据不一致问题分析
|
||||
数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，**查到了修改前的旧数据**，放到了缓存中。随后数据变更的程序完成了数据库的修改。完了，数据库和缓存中的数据不一样了...
|
||||
|
||||
**为什么上亿流量高并发场景下，缓存会出现这个问题？**
|
||||
|
||||
只有在对一个数据在并发的进行读写的时候，才可能会出现这种问题。其实如果说你的并发量很低的话，特别是读并发很低，每天访问量就 1 万次，那么很少的情况下，会出现刚才描述的那种不一致的场景。但是问题是，如果每天的是上亿的流量，每秒并发读是几万，每秒只要有数据更新的请求，就**可能会出现上述的数据库+缓存不一致的情况**。
|
||||
|
||||
**解决方案如下：**
|
||||
|
||||
更新数据的时候，根据**数据的唯一标识**，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中。
|
||||
|
||||
一个队列对应一个工作线程，每个工作线程**串行**拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。
|
||||
|
||||
这里有一个**优化点**，一个队列中，其实**多个更新缓存请求串在一起是没意义的**，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可。
|
||||
|
||||
待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中。
|
||||
|
||||
如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回; 如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值
|
||||
|
||||
高并发的场景下，该解决方案要注意的问题：
|
||||
- 读请求长时阻塞
|
||||
|
||||
由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时时间范围内返回
|
||||
|
||||
该解决方案，最大的风险点在于说，**可能数据更新很频繁**，导致队列中积压了大量更新操作在里面，然后**读请求会发生大量的超时**，最后导致大量的请求直接走数据库。务必通过一些模拟真实的测试，看看更新数据的频繁是怎样的。
|
||||
|
||||
另外一点，因为一个队列中，可能会积压针对多个数据项的更新操作，因此需要根据自己的业务情况进行测试，可能需要**部署多个服务**，每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压100个商品的库存修改操作，每隔库存修改操作要耗费 10ms 去完成，那么最后一个商品的读请求，可能等待10 * 100 = 1000ms = 1s后，才能得到数据，这个时候就导致**读请求的长时阻塞**。
|
||||
|
||||
一定要做根据实际业务系统的运行情况，去进行一些压力测试，和模拟线上环境，去看看最繁忙的时候，内存队列可能会挤压多少更新操作，可能会导致最后一个更新操作对应的读请求，会 hang 多少时间，如果读请求在 200ms 返回，如果你计算过后，哪怕是最繁忙的时候，积压 10 个更新操作，最多等待 200ms，那还可以的。
|
||||
|
||||
- 读请求并发量过高
|
||||
|
||||
这里还必须做好压力测试，确保恰巧碰上上述情况的时候，还有一个风险，就是突然间大量读请求会在几十毫秒的延时 hang 在服务上，看服务能不能抗的住，需要多少机器才能抗住最大的极限情况的峰值
|
||||
|
||||
但是因为并不是所有的数据都在同一时间更新，缓存也不会同一时间失效，所以每次可能也就是少数数据的缓存失效了，然后那些数据对应的读请求过来，并发量应该也不会特别大。
|
||||
|
||||
- 多服务实例部署的请求路由
|
||||
|
||||
可能这个服务部署了多个实例，那么必须**保证**说，执行数据更新操作，以及执行缓存更新操作的请求，都通过 nginx 服务器**路由到相同的服务实例上**。
|
||||
|
||||
- 热点商品的路由问题，导致请求的倾斜
|
||||
|
||||
万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能造成某台机器的压力过大。就是说，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些。
|
||||
122
docs/redis-data-types.md
Normal file
122
docs/redis-data-types.md
Normal file
|
|
@ -0,0 +1,122 @@
|
|||
## 面试题
|
||||
redis 都有哪些数据类型？分别在哪些场景下使用比较合适？
|
||||
|
||||
## 面试官心理分析
|
||||
除非是面试官感觉看你简历，是工作 3 年以内的比较初级的同学，可能对技术没有很深入的研究，面试官才会问这类问题。否则，在宝贵的面试时间里，面试官实在不想多问。
|
||||
|
||||
其实问这个问题，主要有两个原因：
|
||||
- 看看你到底有没有全面的了解 redis 有哪些功能，一般怎么来用，啥场景用什么，就怕你别就会最简单的 kv 操作
|
||||
- 看看你在实际项目里都怎么玩儿过 redis
|
||||
|
||||
要是你回答的不好，没说出几种数据类型，也没说什么场景，你完了，面试官对你印象肯定不好，觉得你平时就是做个简单的 set 和 get。
|
||||
|
||||
## 面试题剖析
|
||||
redis 主要有以下几种数据类型：
|
||||
- string
|
||||
- hash
|
||||
- list
|
||||
- set
|
||||
- sorted set
|
||||
|
||||
### string
|
||||
这是最简单的类型，就是普通的 set 和 get，做简单的 KV 缓存。
|
||||
```bash
|
||||
set college szu
|
||||
```
|
||||
|
||||
### hash
|
||||
这个是类似 map 的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是**这个对象没嵌套其他的对象**）给缓存在 redis 里，然后每次读写缓存的时候，可以就操作 hash 里的**某个字段**。
|
||||
|
||||
```bash
|
||||
hset person name bingo
|
||||
hset person age 20
|
||||
hset person id 1
|
||||
hget person name
|
||||
```
|
||||
|
||||
```json
|
||||
person = {
|
||||
"name": "bingo",
|
||||
"age": 20,
|
||||
"id": 1
|
||||
}
|
||||
```
|
||||
|
||||
### list
|
||||
list 是有序列表，这个可以玩儿出很多花样。
|
||||
|
||||
比如可以通过 list 存储一些列表型的数据结构，类似粉丝列表了、文章的评论列表了之类的东西。
|
||||
|
||||
比如可以通过 lrange 命令，读取某个闭区间内的元素，可以基于 list 实现分页查询，这个是很棒的一个功能，基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西，性能高，就一页一页走。
|
||||
```bash
|
||||
# 0开始位置，-1结束位置，结束位置为-1时，表示列表的最后一个位置，即查看所有。
|
||||
lrange mylist 0 -1
|
||||
```
|
||||
|
||||
比如可以搞个简单的消息队列，从 list 头怼进去，从 list 尾巴那里弄出来。
|
||||
```bash
|
||||
lpush mylist 1
|
||||
lpush mylist 2
|
||||
lpush mylist 3 4 5
|
||||
|
||||
# 1
|
||||
rpop mylist
|
||||
```
|
||||
|
||||
### set
|
||||
set 是无序集合，自动去重。
|
||||
|
||||
直接基于 set 将系统里需要去重的数据扔进去，自动就给去重了，如果你需要对一些数据进行快速的全局去重，你当然也可以基于 jvm 内存里的 HashSet 进行去重，但是如果你的某个系统部署在多台机器上呢？得基于 redis 进行全局的 set 去重。
|
||||
|
||||
可以基于 set 玩儿交集、并集、差集的操作，比如交集吧，可以把两个人的粉丝列表整一个交集，看看俩人的共同好友是谁？对吧。
|
||||
|
||||
把两个大v的粉丝都放在两个 set 中，对两个 set 做交集。
|
||||
```bash
|
||||
#-------操作一个set-------
|
||||
# 添加元素
|
||||
sadd mySet 1
|
||||
|
||||
# 查看全部元素
|
||||
smembers mySet
|
||||
|
||||
# 判断是否包含某个值
|
||||
sismember mySet 3
|
||||
|
||||
# 删除某个/些元素
|
||||
srem mySet 1
|
||||
srem mySet 2 4
|
||||
|
||||
# 查看元素个数
|
||||
scard mySet
|
||||
|
||||
# 随机删除一个元素
|
||||
spop mySet
|
||||
|
||||
#-------操作多个set-------
|
||||
# 将一个set的元素移动到另外一个set
|
||||
smove yourSet mySet 2
|
||||
|
||||
# 求两set的交集
|
||||
sinter yourSet mySet
|
||||
|
||||
# 求两set的并集
|
||||
sunion yourSet mySet
|
||||
|
||||
# 求在yourSet中而不在mySet中的元素
|
||||
sdiff yourSet mySet
|
||||
```
|
||||
|
||||
### sorted set
|
||||
sorted set 是排序的 set，去重但可以排序，写进去的时候给一个分数，自动根据分数排序。
|
||||
```bash
|
||||
zadd board 85 zhangsan
|
||||
zadd board 72 lisi
|
||||
zadd board 96 wangwu
|
||||
zadd board 63 zhaoliu
|
||||
|
||||
# 获取排名前三的用户（默认是升序，所以需要 rev 改为降序）
|
||||
zrevrange board 0 3
|
||||
|
||||
# 获取某用户的排名
|
||||
zrank board zhaoliu
|
||||
```
|
||||
71
docs/redis-expiration-policies-and-lru.md
Normal file
71
docs/redis-expiration-policies-and-lru.md
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
## 面试题
|
||||
redis 的过期策略都有哪些？内存淘汰机制都有哪些？手写一下 LRU 代码实现？
|
||||
|
||||
## 面试官心理分析
|
||||
如果你连这个问题都不知道，上来就懵了，回答不出来，那线上你写代码的时候，想当然的认为写进 redis 的数据就一定会存在，后面导致系统各种 bug，谁来负责？
|
||||
|
||||
常见的有两个问题：
|
||||
- 往 redis 写入的数据怎么没了？
|
||||
|
||||
可能有同学会遇到，在生产环境的 redis 经常会丢掉一些数据，写进去了，过一会儿可能就没了。我的天，同学，你问这个问题就说明 redis 你就没用对啊。redis是缓存，你给当存储了是吧？
|
||||
|
||||
啥叫缓存？用内存当缓存。内存是无限的吗，内存是很宝贵而且是有限的，磁盘是廉价而且是大量的。可能一台机器就几十个 G 的内存，但是可以有几个 T 的硬盘空间。redis 主要是基于内存来进行高性能、高并发的读写操作的。
|
||||
|
||||
那既然内存是有限的，比如 redis 就只能用 10G，你要是往里面写了 20G 的数据，会咋办？当然会干掉 10G 的数据，然后就保留 10G 的数据了。那干掉哪些数据？保留哪些数据？当然是干掉不常用的数据，保留常用的数据了。
|
||||
|
||||
- 数据明明过期了，怎么还占用着内存？
|
||||
|
||||
这是由 redis 的过期策略来决定。
|
||||
|
||||
## 面试题剖析
|
||||
### redis 过期策略
|
||||
redis 过期策略是：**定期删除+惰性删除**。
|
||||
|
||||
所谓**定期删除**，指的是 redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。
|
||||
|
||||
假设 redis 里放了 10w 个 key，都设置了过期时间，你每隔几百毫秒，就检查 10w 个 key，那 redis 基本上就死了，cpu 负载会很高的，消耗在你的检查过期 key 上了。注意，这里可不是每隔 100ms 就遍历所有的设置过期时间的 key，那样就是一场性能上的**灾难**。实际上 redis 是每隔 100ms **随机抽取**一些 key 来检查和删除的。
|
||||
|
||||
但是问题是，定期删除可能会导致很多过期 key 到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。这就是说，在你获取某个 key 的时候，redis 会检查一下 ，这个 key 如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。
|
||||
|
||||
> 获取key 的时候，如果此时 key 已经过期，就删除，不会返回任何东西。
|
||||
|
||||
但是实际上这还是有问题的，如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期 key 堆积在内存里，导致 redis 内存块耗尽了，咋整？
|
||||
|
||||
答案是：**走内存淘汰机制**。
|
||||
|
||||
### 内存淘汰机制
|
||||
redis 内存淘汰机制有以下几个：
|
||||
- noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了。
|
||||
- **allkeys-lru**：当内存不足以容纳新写入数据时，在**键空间**中，移除最近最少使用的key（这个是**最常用**的）
|
||||
- allkeys-random：当内存不足以容纳新写入数据时，在**键空间**中，随机移除某个 key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊。
|
||||
- volatile-lru：当内存不足以容纳新写入数据时，在**设置了过期时间的键空间**中，移除最近最少使用的 key（这个一般不太合适）
|
||||
- volatile-random：当内存不足以容纳新写入数据时，在**设置了过期时间的键空间**中，**随机移除**某个 key。
|
||||
- volatile-ttl：当内存不足以容纳新写入数据时，在**设置了过期时间的键空间**中，有**更早过期时间**的 key 优先移除。
|
||||
|
||||
### 手写一个 LRU 算法
|
||||
你可以现场手写最原始的 LRU 算法，那个代码量太大了，似乎不太现实。
|
||||
|
||||
不求自己纯手工从底层开始打造出自己的 LRU，但是起码要知道如何利用已有的 JDK 数据结构实现一个 Java 版的 LRU。
|
||||
|
||||
```java
|
||||
class LRUCache<K, V> extends LinkedHashMap<K, V> {
|
||||
private final int CACHE_SIZE;
|
||||
|
||||
/**
|
||||
* 传递进来最多能缓存多少数据
|
||||
*
|
||||
* @param cacheSize 缓存大小
|
||||
*/
|
||||
public LRUCache(int cacheSize) {
|
||||
// true 表示让 linkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。
|
||||
super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
|
||||
CACHE_SIZE = cacheSize;
|
||||
}
|
||||
|
||||
@Override
|
||||
protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
|
||||
// 当 map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。
|
||||
return size() > CACHE_SIZE;
|
||||
}
|
||||
}
|
||||
```
|
||||
89
docs/redis-master-slave.md
Normal file
89
docs/redis-master-slave.md
Normal file
|
|
@ -0,0 +1,89 @@
|
|||
# Redis 主从架构
|
||||
|
||||
单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑**读高并发**的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的**读请求全部走从节点**。这样也可以很轻松实现水平扩容，**支撑读高并发**。
|
||||
|
||||
|
||||
|
||||
redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发
|
||||
|
||||
## redis replication 的核心机制
|
||||
- redis 采用**异步方式**复制数据到 slave 节点，不过 redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量；
|
||||
- 一个 master node 是可以配置多个 slave node 的；
|
||||
- slave node 也可以连接其他的 slave node；
|
||||
- slave node 做复制的时候，不会 block master node 的正常工作；
|
||||
- slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；
|
||||
- slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。
|
||||
|
||||
注意，如果采用了主从架构，那么建议必须**开启** master node 的[持久化](/docs/high-concurrency/redis-persistence.md)，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。
|
||||
|
||||
另外，master 的各种备份方案，也需要做。万一本地的所有文件丢失了，从备份中挑选一份 rdb 去恢复 master，这样才能**确保启动的时候，是有数据的**，即使采用了后续讲解的[高可用机制](/docs/high-concurrency/redis-sentinel.md)，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空。
|
||||
|
||||
## redis 主从复制的核心原理
|
||||
当启动一个 slave node 的时候，它会发送一个 `PSYNC` 命令给 master node。
|
||||
|
||||
如果这是 slave node 初次连接到 master node，那么会触发一次 `full resynchronization` 全量复制。此时 master 会启动一个后台线程，开始生成一份 `RDB` 快照文件，同时还会将从客户端 client 新收到的所有写命令缓存在内存中。`RDB` 文件生成完毕后， master 会将这个 `RDB` 发送给 slave，slave 会先**写入本地磁盘，然后再从本地磁盘加载到内存**中，接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。
|
||||
|
||||
|
||||
|
||||
### 主从复制的断点续传
|
||||
从 redis2.8 开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。
|
||||
|
||||
master node 会在内存中维护一个 backlog，master 和 slave 都会保存一个 replica offset 还有一个 master run id，offset 就是保存在 backlog 中的。如果 master 和 slave 网络连接断掉了，slave 会让 master 从上次 replica offset 开始继续复制，如果没有找到对应的 offset，那么就会执行一次 `resynchronization`。
|
||||
|
||||
> 如果根据 host+ip 定位 master node，是不靠谱的，如果 master node 重启或者数据出现了变化，那么 slave node 应该根据不同的 run id 区分。
|
||||
|
||||
### 无磁盘化复制
|
||||
master 在内存中直接创建 `RDB`，然后发送给 slave，不会在自己本地落地磁盘了。只需要在配置文件中开启 `repl-diskless-sync yes` 即可。
|
||||
```bash
|
||||
repl-diskless-sync yes
|
||||
|
||||
# 等待 5s 后再开始复制，因为要等更多 slave 重新连接过来
|
||||
repl-diskless-sync-delay 5
|
||||
```
|
||||
|
||||
### 过期 key 处理
|
||||
slave 不会过期 key，只会等待 master 过期 key。如果 master 过期了一个 key，或者通过 LRU 淘汰了一个 key，那么会模拟一条 del 命令发送给 slave。
|
||||
|
||||
## 复制的完整流程
|
||||
slave node 启动时，会在自己本地保存 master node 的信息，包括 master node 的`host`和`ip`，但是复制流程没开始。
|
||||
|
||||
slave node 内部有个定时任务，每秒检查是否有新的 master node 要连接和复制，如果发现，就跟 master node 建立 socket 网络连接。然后 slave node 发送 `ping` 命令给 master node。如果 master 设置了 requirepass，那么 slave node 必须发送 masterauth 的口令过去进行认证。master node **第一次执行全量复制**，将所有数据发给slave node。而在后续，master node 持续将写命令，异步复制给 slave node。
|
||||
|
||||
|
||||
|
||||
### 全量复制
|
||||
- master 执行 bgsave ，在本地生成一份 rdb 快照文件。
|
||||
- master node 将 rdb 快照文件发送给 slave node，如果 rdb 复制时间超过 60秒（repl-timeout），那么 slave node 就会认为复制失败，可以适当调大这个参数(对于千兆网卡的机器，一般每秒传输 100MB，6G 文件，很可能超过 60s)
|
||||
- master node 在生成 rdb 时，会将所有新的写命令缓存在内存中，在 slave node 保存了 rdb 之后，再将新的写命令复制给 slave node。
|
||||
- 如果在复制期间，内存缓冲区持续消耗超过 64MB，或者一次性超过 256MB，那么停止复制，复制失败。
|
||||
```bash
|
||||
client-output-buffer-limit slave 256MB 64MB 60
|
||||
```
|
||||
- slave node 接收到 rdb 之后，清空自己的旧数据，然后重新加载 rdb 到自己的内存中，同时**基于旧的数据版本**对外提供服务。
|
||||
- 如果 slave node 开启了 AOF，那么会立即执行 BGREWRITEAOF，重写 AOF。
|
||||
|
||||
### 增量复制
|
||||
- 如果全量复制过程中，master-slave 网络连接断掉，那么 slave 重新连接 master 时，会触发增量复制。
|
||||
- master 直接从自己的 backlog 中获取部分丢失的数据，发送给 slave node，默认 backlog 就是1MB。
|
||||
- msater就是根据 slave 发送的 psync 中的 offset 来从 backlog 中获取数据的。
|
||||
|
||||
### heartbeat
|
||||
主从节点互相都会发送 heartbeat 信息。
|
||||
|
||||
master 默认每隔 10秒 发送一次 heartbeat，slave node 每隔 1秒 发送一个 heartbeat。
|
||||
|
||||
### 异步复制
|
||||
master 每次接收到写命令之后，先在内部写入数据，然后异步发送给 slave node。
|
||||
|
||||
## redis 如何才能做到高可用
|
||||
如果系统在 365 天内，有 99.99% 的时间，都是可以哗哗对外提供服务的，那么就说系统是高可用的。
|
||||
|
||||
一个 slave 挂掉了，是不会影响可用性的，还有其它的 slave 在提供相同数据下的相同的对外的查询服务。
|
||||
|
||||
但是，如果 master node 死掉了，会怎么样？没法写数据了，写缓存的时候，全部失效了。slave node 还有什么用呢，没有 master 给它们复制数据了，系统相当于不可用了。
|
||||
|
||||
redis 的高可用架构，叫做 `failover` **故障转移**，也可以叫做主备切换。
|
||||
|
||||
master node 在故障时，自动检测，并且将某个 slave node 自动切换位 master node的过程，叫做主备切换。这个过程，实现了 redis 的主从架构下的高可用。
|
||||
|
||||
后面会详细说明 redis **基于哨兵的高可用性**。
|
||||
50
docs/redis-persistence.md
Normal file
50
docs/redis-persistence.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
## 面试题
|
||||
redis 的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？
|
||||
|
||||
## 面试官心理分析
|
||||
redis 如果仅仅只是将数据缓存在内存里面，如果 redis 宕机了再重启，内存里的数据就全部都弄丢了啊。你必须得用 redis 的持久化机制，将数据写入内存的同时，异步的慢慢的将数据写入磁盘文件里，进行持久化。
|
||||
|
||||
如果 redis 宕机重启，自动从磁盘上加载之前持久化的一些数据就可以了，也许会丢失少许数据，但是至少不会将所有数据都弄丢。
|
||||
|
||||
这个其实一样，针对的都是 redis 的生产环境可能遇到的一些问题，就是 redis 要是挂了再重启，内存里的数据不就全丢了？能不能重启的时候把数据给恢复了？
|
||||
|
||||
## 面试题剖析
|
||||
持久化主要是做灾难恢复、数据恢复，也可以归类到高可用的一个环节中去，比如你 redis 整个挂了，然后 redis 就不可用了，你要做的事情就是让 redis 变得可用，尽快变得可用。
|
||||
|
||||
重启 redis，尽快让它堆外提供服务，如果没做数据备份，这时候 redis 启动了，也不可用啊，数据都没了。
|
||||
|
||||
很可能说，大量的请求过来，缓存全部无法命中，在 redis 里根本找不到数据，这个时候就死定了，出现**缓存雪崩**问题。所有请求没有在 redis 命中，就会去 mysql 数据库这种数据源头中去找，一下子 mysql 承接高并发，然后就挂了...
|
||||
|
||||
如果你把 redis 持久化做好，备份和恢复方案做到企业级的程度，那么即使你的 redis 故障了，也可以通过备份数据，快速恢复，一旦恢复立即对外提供服务。
|
||||
|
||||
### redis 持久化的两种方式
|
||||
- RDB：RDB 持久化机制，是对 redis 中的数据执行**周期性**的持久化。
|
||||
- AOF：AOF 机制对每条写入命令作为日志，以 `append-only` 的模式写入一个日志文件中，在 redis 重启的时候，可以通过**回放** AOF 日志中的写入指令来重新构建整个数据集。
|
||||
|
||||
通过 RDB 或 AOF，都可以将 redis 内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云等云服务。
|
||||
|
||||
如果 redis 挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动 redis，redis 就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务。
|
||||
|
||||
如果同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 **AOF** 来重新构建数据，因为 AOF 中的**数据更加完整**。
|
||||
|
||||
#### RDB 优缺点
|
||||
- RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，**非常适合做冷备**，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说 Amazon 的 S3 云服务上去，在国内可以是阿里云的 ODPS 分布式存储上，以预定好的备份策略来定期备份redis中的数据。
|
||||
- RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis **保持高性能**，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
|
||||
- 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
|
||||
|
||||
- 如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。一般来说，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。
|
||||
- RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
|
||||
|
||||
#### AOF 优缺点
|
||||
- AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次`fsync`操作，最多丢失 1 秒钟的数据。
|
||||
- AOF 日志文件以 `append-only` 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
|
||||
- AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 `rewrite` log 的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
|
||||
- AOF 日志文件的命令通过非常可读的方式进行记录，这个特性非常**适合做灾难性的误删除的紧急恢复**。比如某人不小心用 `flushall` 命令清空了所有数据，只要这个时候后台 `rewrite` 还没有发生，那么就可以立即拷贝 AOF 文件，将最后一条 `flushall` 命令给删了，然后再将该 `AOF` 文件放回去，就可以通过恢复机制，自动恢复所有数据。
|
||||
- 对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。
|
||||
- AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 `fsync` 一次日志文件，当然，每秒一次 `fsync`，性能也还是很高的。（如果实时写入，那么 QPS 会大降，redis 性能会大大降低）
|
||||
- 以前 AOF 发生过 bug，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似 AOF 这种较为复杂的基于命令日志/merge/回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令日志进行 merge 的，而是**基于当时内存中的数据进行指令的重新构建**，这样健壮性会好很多。
|
||||
|
||||
### RDB和AOF到底该如何选择
|
||||
- 不要仅仅使用 RDB，因为那样会导致你丢失很多数据
|
||||
- 也不要仅仅使用 AOF，因为那样有两个问题，第一，你通过 AOF 做冷备，没有 RDB 做冷备，来的恢复速度更快; 第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug。
|
||||
- redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。
|
||||
20
docs/redis-production-environment.md
Normal file
20
docs/redis-production-environment.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
## 面试题
|
||||
生产环境中的 redis 是怎么部署的？
|
||||
|
||||
## 面试官心理分析
|
||||
看看你了解不了解你们公司的 redis 生产集群的部署架构，如果你不了解，那么确实你就很失职了，你的 redis 是主从架构？集群架构？用了哪种集群方案？有没有做高可用保证？有没有开启持久化机制确保可以进行数据恢复？线上 redis 给几个 G 的内存？设置了哪些参数？压测后你们 redis 集群承载多少 QPS？
|
||||
|
||||
兄弟，这些你必须是门儿清的，否则你确实是没好好思考过。
|
||||
|
||||
## 面试题剖析
|
||||
redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。
|
||||
|
||||
机器是什么配置？32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。
|
||||
|
||||
5 台机器对外提供读写，一共有 50g 内存。
|
||||
|
||||
因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。
|
||||
|
||||
你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。
|
||||
|
||||
其实大型的公司，会有基础架构的 team 负责缓存集群的运维。
|
||||
135
docs/redis-sentinel.md
Normal file
135
docs/redis-sentinel.md
Normal file
|
|
@ -0,0 +1,135 @@
|
|||
# Redis 哨兵集群实现高可用
|
||||
|
||||
## 哨兵的介绍
|
||||
sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：
|
||||
- 集群监控：负责监控 redis master 和 slave 进程是否正常工作。
|
||||
- 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
|
||||
- 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
|
||||
- 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
|
||||
|
||||
哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。
|
||||
- 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
|
||||
- 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。
|
||||
|
||||
## 哨兵的核心知识
|
||||
- 哨兵至少需要 3 个实例，来保证自己的健壮性。
|
||||
- 哨兵 + redis 主从的部署架构，是**不保证数据零丢失**的，只能保证 redis 集群的高可用性。
|
||||
- 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
|
||||
|
||||
哨兵集群必须部署 2 个以上节点，如果哨兵集群仅仅部署了 2 个哨兵实例，quorum = 1。
|
||||
```
|
||||
+----+ +----+
|
||||
| M1 |---------| R1 |
|
||||
| S1 | | S2 |
|
||||
+----+ +----+
|
||||
```
|
||||
配置 `quorum=1`，如果 master 宕机， s1 和 s2 中只要有 1 个哨兵认为 master 宕机了，就可以进行切换，同时 s1 和 s2 会选举出一个哨兵来执行故障转移。但是同时这个时候，需要 majority，也就是大多数哨兵都是运行的。
|
||||
```
|
||||
2 个哨兵，majority=2
|
||||
3 个哨兵，majority=2
|
||||
4 个哨兵，majority=2
|
||||
5 个哨兵，majority=3
|
||||
...
|
||||
```
|
||||
如果此时仅仅是 M1 进程宕机了，哨兵 s1 正常运行，那么故障转移是 OK 的。但是如果是整个 M1 和 S1 运行的机器宕机了，那么哨兵只有 1 个，此时就没有 majority 来允许执行故障转移，虽然另外一台机器上还有一个 R1，但是故障转移不会执行。
|
||||
|
||||
经典的 3 节点哨兵集群是这样的：
|
||||
```
|
||||
+----+
|
||||
| M1 |
|
||||
| S1 |
|
||||
+----+
|
||||
|
|
||||
+----+ | +----+
|
||||
| R2 |----+----| R3 |
|
||||
| S2 | | S3 |
|
||||
+----+ +----+
|
||||
```
|
||||
|
||||
配置 `quorum=2`，如果 M1 所在机器宕机了，那么三个哨兵还剩下 2 个，S2 和 S3 可以一致认为 master 宕机了，然后选举出一个来执行故障转移，同时 3 个哨兵的 majority 是 2，所以还剩下的 2 个哨兵运行着，就可以允许执行故障转移。
|
||||
|
||||
## redis 哨兵主备切换的数据丢失问题
|
||||
### 两种情况和导致数据丢失
|
||||
主备切换的过程，可能会导致数据丢失：
|
||||
- 异步复制导致的数据丢失
|
||||
因为 master->slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这部分数据就丢失了。
|
||||
|
||||
|
||||
|
||||
- 脑裂导致的数据丢失
|
||||
脑裂，也就是说，某个 master 所在机器突然**脱离了正常的网络**，跟其他 slave 机器不能连接，但是实际上 master 还运行着。此时哨兵可能就会**认为** master 宕机了，然后开启选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个 master ，也就是所谓的**脑裂**。
|
||||
|
||||
此时虽然某个 slave 被切换成了master，但是可能 client 还没来得及切换到新的 master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client 写入的数据，因此，这部分数据也就丢失了。
|
||||
|
||||
|
||||
|
||||
### 数据丢失问题的解决方案
|
||||
进行如下配置：
|
||||
```bash
|
||||
min-slaves-to-write 1
|
||||
min-slaves-max-lag 10
|
||||
```
|
||||
表示，要求至少有 1 个 slave，数据复制和同步的延迟不能超过 10 秒。
|
||||
|
||||
如果说一旦所有的 slave，数据复制和同步的延迟都超过了 10 秒钟，那么这个时候，master 就不会再接收任何请求了。
|
||||
|
||||
- 减少异步复制数据的丢失
|
||||
有了 `min-slaves-max-lag` 这个配置，就可以确保说，一旦 slave 复制数据和 ack 延时太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样可以把 master 宕机时由于部分数据未同步到 slave 导致的数据丢失降低的可控范围内。
|
||||
|
||||
- 减少脑裂的数据丢失
|
||||
如果一个 master 出现了脑裂，跟其他 slave 丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的 slave 发送数据，而且 slave 超过 10 秒没有给自己 ack 消息，那么就直接拒绝客户端的写请求。因此在脑裂场景下，最多就丢失 10 秒的数据。
|
||||
|
||||
## sdown 和 odown 转换机制
|
||||
- sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机
|
||||
- odown 是客观宕机，如果 quorum 数量的哨兵都觉得一个 master 宕机了，那么就是客观宕机
|
||||
|
||||
sdown 达成的条件很简单，如果一个哨兵 ping 一个 master，超过了 `is-master-down-after-milliseconds` 指定的毫秒数之后，就主观认为 master 宕机了；如果一个哨兵在指定时间内，收到了 quorum 数量的 其它哨兵也认为那个 master 是 sdown 的，那么就认为是 odown 了。
|
||||
|
||||
## 哨兵集群的自动发现机制
|
||||
哨兵互相之间的发现，是通过 redis 的 pub/sub 系统实现的，每个哨兵都会往`__sentinel__:hello`这个 channel 里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在。
|
||||
|
||||
每隔两秒钟，每个哨兵都会往自己监控的某个 master+slaves 对应的`__sentinel__:hello` channel 里**发送一个消息**，内容是自己的 host、ip 和 runid 还有对这个 master 的监控配置。
|
||||
|
||||
每个哨兵也会去**监听**自己监控的每个 master+slaves 对应的`__sentinel__:hello` channel，然后去感知到同样在监听这个 master+slaves 的其他哨兵的存在。
|
||||
|
||||
每个哨兵还会跟其他哨兵交换对 `master` 的监控配置，互相进行监控配置的同步。
|
||||
|
||||
## slave 配置的自动纠正
|
||||
哨兵会负责自动纠正 slave 的一些配置，比如 slave 如果要成为潜在的 master 候选人，哨兵会确保 slave 复制现有 master 的数据; 如果 slave 连接到了一个错误的 master 上，比如故障转移之后，那么哨兵会确保它们连接到正确的 master 上。
|
||||
|
||||
## slave->master 选举算法
|
||||
如果一个 master 被认为 odown 了，而且 majority 数量的哨兵都允许主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个 slave 来，会考虑 slave 的一些信息：
|
||||
|
||||
- 跟 master 断开连接的时长
|
||||
- slave 优先级
|
||||
- 复制 offset
|
||||
- run id
|
||||
|
||||
如果一个 slave 跟 master 断开连接的时间已经超过了`down-after-milliseconds`的 10 倍，外加 master 宕机的时长，那么 slave 就被认为不适合选举为 master。
|
||||
```
|
||||
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
|
||||
```
|
||||
|
||||
接下来会对 slave 进行排序：
|
||||
- 按照 slave 优先级进行排序，slave priority 越低，优先级就越高。
|
||||
- 如果 slave priority 相同，那么看 replica offset，哪个 slave 复制了越多的数据，offset 越靠后，优先级就越高。
|
||||
- 如果上面两个条件都相同，那么选择一个 run id 比较小的那个 slave。
|
||||
|
||||
## quorum 和 majority
|
||||
每次一个哨兵要做主备切换，首先需要 quorum 数量的哨兵认为 odown，然后选举出一个哨兵来做切换，这个哨兵还得得到 majority 哨兵的授权，才能正式执行切换。
|
||||
|
||||
如果 quorum < majority，比如 5 个哨兵，majority 就是 3，quorum 设置为2，那么就 3 个哨兵授权就可以执行切换。
|
||||
|
||||
但是如果 quorum >= majority，那么必须 quorum 数量的哨兵都授权，比如 5 个哨兵，quorum 是 5，那么必须 5 个哨兵都同意授权，才能执行切换。
|
||||
|
||||
## configuration epoch
|
||||
哨兵会对一套 redis master+slaves 进行监控，有相应的监控的配置。
|
||||
|
||||
执行切换的那个哨兵，会从要切换到的新 master（salve->master）那里得到一个 configuration epoch，这就是一个 version 号，每次切换的 version 号都必须是唯一的。
|
||||
|
||||
如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待 failover-timeout 时间，然后接替继续执行切换，此时会重新获取一个新的 configuration epoch，作为新的 version 号。
|
||||
|
||||
## configuraiton 传播
|
||||
哨兵完成切换之后，会在自己本地更新生成最新的 master 配置，然后同步给其他的哨兵，就是通过之前说的 pub/sub 消息机制。
|
||||
|
||||
这里之前的 version 号就很重要了，因为各种消息都是通过一个 channel 去发布和监听的，所以一个哨兵完成一次新的切换之后，新的 master 配置是跟着新的 version 号的。其他的哨兵都是根据版本号的大小来更新自己的 master 配置的。
|
||||
48
docs/redis-single-thread-model.md
Normal file
48
docs/redis-single-thread-model.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
## 面试题
|
||||
redis 和 memcached 有什么区别？redis 的线程模型是什么？为什么 redis 单线程却能支撑高并发？
|
||||
|
||||
## 面试官心理分析
|
||||
这个是问 redis 的时候，最基本的问题吧，redis 最基本的一个内部原理和特点，就是 redis 实际上是个**单线程工作模型**，你要是这个都不知道，那后面玩儿 redis 的时候，出了问题岂不是什么都不知道？
|
||||
|
||||
还有可能面试官会问问你 redis 和 memcached 的区别，但是 memcached 是早些年各大互联网公司常用的缓存方案，但是现在近几年基本都是 redis，没什么公司用 memcached 了。
|
||||
|
||||
## 面试题剖析
|
||||
|
||||
### redis 和 memcached 有啥区别？
|
||||
|
||||
#### redis 支持复杂的数据结构
|
||||
redis 相比 memcached 来说，拥有更多的数据结构，能支持更丰富的数据操作。如果需要缓存能够支持更复杂的结构和操作， redis 会是不错的选择。
|
||||
|
||||
#### redis 原生支持集群模式
|
||||
在 redis3.x 版本中，便能支持 cluster 模式，而 memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据。
|
||||
|
||||
#### 性能对比
|
||||
由于 redis 只使用单核，而 memcached 可以使用多核，所以平均每一个核上 redis 在存储小数据时比 memcached 性能更高。而在 100k 以上的数据中，memcached 性能要高于 redis，虽然 redis 最近也在存储大数据的性能上进行优化，但是比起 memcached，还是稍有逊色。
|
||||
|
||||
### redis 的线程模型
|
||||
redis 内部使用文件事件处理器 `file event handler`，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。
|
||||
|
||||
文件事件处理器的结构包含 4 个部分：
|
||||
- 多个 socket
|
||||
- IO 多路复用程序
|
||||
- 文件事件分派器
|
||||
- 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）
|
||||
|
||||
多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。
|
||||
|
||||
来看客户端与 redis 的一次通信过程：
|
||||
|
||||
|
||||
|
||||
客户端 socket01 向 redis 的 server socket 请求建立连接，此时 server socket 会产生一个 `AE_READABLE` 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给`连接应答处理器`。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 `AE_READABLE` 事件与命令请求处理器关联。
|
||||
|
||||
假设此时客户端发送了一个 `set key value` 请求，此时 redis 中的 socket01 会产生 `AE_READABLE` 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 socket01 的 `AE_READABLE` 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 `key value` 并在自己内存中完成 `key value` 的设置。操作完成后，它会将 socket01 的 `AE_WRITABLE` 事件与命令回复处理器关联。
|
||||
|
||||
如果此时客户端准备好接收返回结果了，那么 redis 中的 socket01 会产生一个 `AE_WRITABLE` 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 `ok`，之后解除 socket01 的 `AE_WRITABLE` 事件与命令回复处理器的关联。
|
||||
|
||||
这样便完成了一次通信。
|
||||
|
||||
### 为啥 redis 单线程模型也能效率这么高？
|
||||
- 纯内存操作
|
||||
- 核心是基于非阻塞的 IO 多路复用机制
|
||||
- 单线程反而避免了多线程的频繁上下文切换问题
|
||||
39
docs/why-cache.md
Normal file
39
docs/why-cache.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
## 面试题
|
||||
项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？
|
||||
|
||||
## 面试官心理分析
|
||||
这个问题，互联网公司必问，要是一个人连缓存都不太清楚，那确实比较尴尬。
|
||||
|
||||
只要问到缓存，上来第一个问题，肯定是先问问你项目哪里用了缓存？为啥要用？不用行不行？如果用了以后可能会有什么不良的后果？
|
||||
|
||||
这就是看看你对你用缓存这个东西背后有没有思考，如果你就是傻乎乎的瞎用，没法给面试官一个合理的解答。那面试官对你印象肯定不太好，觉得你平时思考太少，就知道干活儿。
|
||||
|
||||
|
||||
## 面试题剖析
|
||||
### 项目中缓存是如何使用的？
|
||||
这个，需要结合自己项目的业务来。
|
||||
|
||||
### 为什么要用缓存？
|
||||
用缓存，主要有两个用途：**高性能**、**高并发**。
|
||||
|
||||
#### 高性能
|
||||
假设这么个场景，你有个操作，一个请求过来，吭哧吭哧你各种乱七八糟操作 mysql，半天查出来一个结果，耗时 600ms。但是这个结果可能接下来几个小时都不会变了，或者变了也可以不用立即反馈给用户。那么此时咋办？
|
||||
|
||||
缓存啊，折腾 600ms 查出来的结果，扔缓存里，一个 key 对应一个 value，下次再有人查，别走 mysql 折腾 600ms 了。直接从缓存里，通过一个 key 查出来一个 value，2ms 搞定。性能提升300倍。
|
||||
|
||||
就是说对于一些需要复杂操作耗时查出来的结果，且确定后面不怎么变化，但是有很多读请求，那么结果直接放在缓存，后面直接读缓存就好。
|
||||
|
||||
#### 高并发
|
||||
mysql 这么重的数据库，压根儿设计不是让你玩儿高并发的，虽然也可以玩儿，但是天然支持不好。mysql 单机支撑到 `2000QPS` 也开始容易报警了。
|
||||
|
||||
所以要是你有个系统，高峰期一秒钟过来的请求有 1万，那一个 mysql 单机绝对会死掉。你这个时候就只能上缓存，把很多数据放缓存，别放 mysql。缓存功能简单，说白了就是 key-value 式操作，单机支撑的并发量轻松一秒几万十几万，支撑高并发 so easy。单机承载并发量是 mysql 单机的几十倍。
|
||||
|
||||
> 缓存是走内存的，内存天然就支撑高并发。
|
||||
|
||||
### 用了缓存之后会有什么不良后果？
|
||||
常见的缓存问题有以下几个：
|
||||
- [缓存与数据库双写不一致](/docs/high-concurrency/redis-consistence.md)
|
||||
- [缓存雪崩、缓存穿透](/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md)
|
||||
- [缓存并发竞争](/docs/high-concurrency/redis-cas.md)
|
||||
|
||||
后面再详细说明。
|
||||
107
docs/why-mq.md
Normal file
107
docs/why-mq.md
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
## 面试题
|
||||
- 为什么使用消息队列？
|
||||
- 消息队列有什么优点和缺点？
|
||||
- Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？
|
||||
|
||||
## 面试官心理分析
|
||||
其实面试官主要是想看看：
|
||||
|
||||
- **第一**，你知不知道你们系统里为什么要用消息队列这个东西？<br>
|
||||
不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。<br>
|
||||
没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。
|
||||
|
||||
- **第二**，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？<br>
|
||||
你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。
|
||||
|
||||
- **第三**，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？<br>
|
||||
你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ **没有绝对的好坏**，但是就是看用在哪个场景可以**扬长避短，利用其优势，规避其劣势**。<br>
|
||||
如果是一个不考虑技术选型的候选人招进了团队，leader 交给他一个任务，去设计个什么系统，他在里面用一些技术，可能都没考虑过选型，最后选的技术可能并不一定合适，一样是留坑。
|
||||
|
||||
## 面试题剖析
|
||||
### 为什么使用消息队列
|
||||
其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？
|
||||
|
||||
面试官问你这个问题，**期望的一个回答**是说，你们公司有个什么**业务场景**，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。
|
||||
|
||||
先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：**解耦**、**异步**、**削峰**。
|
||||
|
||||
#### 解耦
|
||||
看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃......
|
||||
|
||||
|
||||
|
||||
在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！
|
||||
|
||||
如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
|
||||
|
||||
|
||||
|
||||
**总结**：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。
|
||||
|
||||
**面试技巧**：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解耦。
|
||||
|
||||
#### 异步
|
||||
再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。
|
||||
|
||||
|
||||
|
||||
一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。
|
||||
|
||||
如果**使用 MQ**，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！
|
||||
|
||||
|
||||
|
||||
#### 削峰
|
||||
每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。
|
||||
|
||||
一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。
|
||||
|
||||
但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。
|
||||
|
||||
|
||||
|
||||
如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。
|
||||
|
||||
|
||||
|
||||
这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。
|
||||
|
||||
### 消息队列有什么优缺点
|
||||
优点上面已经说了，就是**在特殊场景下有其对应的好处**，**解耦**、**异步**、**削峰**。
|
||||
|
||||
缺点有以下几个：
|
||||
|
||||
- 系统可用性降低<br>
|
||||
系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？如何保证消息队列的高可用，可以[点击这里查看](/docs/high-concurrency/how-to-ensure-high-availability-of-message-queues.md)。
|
||||
|
||||
- 系统复杂度提高<br>
|
||||
硬生生加个 MQ 进来，你怎么[保证消息没有重复消费](/docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md)？怎么[处理消息丢失的情况](/docs/high-concurrency/how-to-ensure-the-reliable-transmission-of-messages.md)？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
|
||||
|
||||
- 一致性问题<br>
|
||||
A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
|
||||
|
||||
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。
|
||||
|
||||
### Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
|
||||
|
||||
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|
||||
|---|---|---|---|---|
|
||||
| 单机吞吐量 | 万级，比 RocketMQ、Kafka 低一个数量级 | 同 ActiveMQ | 10 万级，支撑高吞吐 | 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
|
||||
| topic 数量对吞吐量的影响 | | | topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic | topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 |
|
||||
| 时效性 | ms 级 | 微秒级，这是 RabbitMQ 的一大特点，延迟最低 | ms 级 | 延迟在 ms 级以内 |
|
||||
| 可用性 | 高，基于主从架构实现高可用 | 同 ActiveMQ | 非常高，分布式架构 | 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
|
||||
| 消息可靠性 | 有较低的概率丢失数据 | | 经过参数优化配置，可以做到 0 丢失 | 同 RocketMQ |
|
||||
| 功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
|
||||
|
||||
|
||||
综上，各种对比之后，有如下建议：
|
||||
|
||||
一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
|
||||
|
||||
后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；
|
||||
|
||||
不过现在确实越来越多的公司，会去用 RocketMQ，确实很不错（阿里出品），但社区可能有突然黄掉的风险，对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。
|
||||
|
||||
所以**中小型公司**，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；**大型公司**，基础架构研发实力较强，用 RocketMQ 是很好的选择。
|
||||
|
||||
如果是**大数据领域**的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
|
||||
Loading…
Reference in New Issue
Block a user