## 前言

正常情况下，Redis集群中数据都是均匀分配到每个节点，请求也会均匀的分布到每个分片上，但在一些特殊场景中，比如外部爬虫、攻击、热点商品等，最典型的就是明星在微博上宣布离婚，吃瓜群众纷纷涌入路演，导致微博评论功能崩溃，这种短时间内某些key访问量过于大，对于这种相同的key会请求到同一台数据分片上，导致该分片负责较高成为瓶颈问题，导致雪崩等一些问题。



## redis数据热点引起原因？
案例回答：

关于热点数据问题我有话要说，这个问题我早在刚刚学习使用 Redis 时就从已经意识到了，所以在使用时会刻意避免，坚决不会给自己挖坑，热点数据最大的问题会造成 Reids 集群负载不均衡（也就是数据倾斜）导致的故障，这些问题对于 Redis 集群都是致命打击。

先说说造成 Reids 集群负载不均衡故障的主要原因：

1. 高访问量的 Key，也就是热 key，根据过去的维护经验一个 key 访问的 QPS 超过 1000 就要高度关注了，比如热门商品，热门话题等。
2. 大 Value，有些 key 访问 QPS 虽然不高，但是由于 value 很大，造成网卡负载较大，网卡流量被打满，单台机器可能出现千兆 / 秒，IO 故障。
3. 热点 Key + 大 Value 同时存在，服务器杀手。


那么热点 key 或大 Value 会造成哪些故障呢：

1. 数据倾斜问题：大 Value 会导致集群不同节点数据分布不均匀，造成数据倾斜问题，大量读写比例非常高的请求都会落到同一个 redis server 上，该 redis 的负载就会严重升高，容易打挂。
2. QPS 倾斜：分片上的 QPS 不均。
3. 大 Value 会导致 Redis 服务器缓冲区不足，造成 get 超时。
3. 由于 Value 过大，导致机房网卡流量不足。
4. Redis 缓存失效导致数据库层被击穿的连锁反应。


> reds缓存穿透

理解重在穿透吧，也就是访问透过redis直接经过mysql，通常是一个不存在的key,在数据库查询为null。每次请求落在数据库、并且高并发。数据库扛不住会挂掉。

解决方案：
1. 可以将查到的null设为该key的缓存对象
2. 可以根据明显错误的key在逻辑层就就行验证。
3. 可以分析用户行为，是否为故意请求或者爬虫、攻击者。针对用户访问做限制。
4. 用布隆过滤器(超大型hashmap)先过滤。


> redis缓存雪崩

理解雪崩，就是某东西蜂拥而至的意思，像雪崩一样。在这里，就是redis缓存集体大规模集体失效，在高并发情况下突然使得key大规模访问mysql，使得数据库崩掉。可以想象下国家人口老年化。以后那天人集中在70-80岁，就没人干活了。国家劳动力就造成压力。

解决方案：
1. 将key的过期时间后面加上一个随机数，让key均匀的失效。
2. 考虑用队列或者锁让程序执行在压力范围之内，当然这种方案可能会影响并发量。
3. 热点数据可以考虑不失效

> redis缓存击穿

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，好像蛮力击穿一样。

**缓存和击穿的不同**
1. 穿透的意思是想法绕过redis去使得数据库崩掉。
2. 而击穿你可以理解为正面刚击穿,这种通常为大量并发对一个key进行大规模的读写操作。这个key在缓存失效期间大量请求数据库，对数据库造成太大压力使得数据库崩掉。就比如在秒杀场景下10000块钱的mac和100块的mac这个100块的那个订单肯定会被抢到爆，不断的请求(当然具体秒杀有自己处理方式这里只是举个例子)。
3. 所以缓存击穿就是针对某个常用key大量请求导致数据库崩溃。


解决方案：
1. 可以使用互斥锁避免大量请求同时落到db。
2. 布隆过滤器，判断某个容器是否在集合中
3. 可以将缓存设置永不过期(适合部分情况)
4. 做好熔断、降级，防止系统崩溃。


## 真实项目中，热点数据问题如何准确定位的呢？


案例回答：
>这个问题的解决办法比较宽泛，要具体看不同业务场景，比如公司组织促销活动，那参加促销的商品肯定是有办法提前统计的，这种场景就可以通过预估法。对于突发事件，不确定因素，Redis 会自己监控热点数据。大概归纳下：

1. 提前获知法：根据业务，人肉统计 or 系统统计可能会成为热点的数据，如，促销活动商品，热门话题，节假日话题，纪念日活动等。
2. redis客户端收集法，调用端通过计数的方式统计 key 的请求次数，但是无法预知 key 的个数，代码侵入性强。
3. redis集群代理层统计。像 Twemproxy，codis 这些基于代理的 Redis 分布式架构，统一的入口，可以在 Proxy 层做收集上报，但是缺点很明显，并非所有的 Redis 集群架构都有 proxy。


![image.png](/static/img/104361c3ef3c4a4f2cd6e76dcd1cc9cf.image.png)

4. redis服务端收集。监控 Redis 单个分片的 QPS，发现 QPS 倾斜到一定程度的节点进行 monitor，获取热点 key， Redis 提供了 monitor 命令，可以统计出一段时间内的某 Redis 节点上的所有命令，分析热点 key，在高并发条件下，会存在内存暴涨和 Redis 性能的隐患，所以此种方法适合在短时间内使用；同样只能统计一个 Redis 节点的热点 key，对于集群需要汇总统计，业务角度讲稍微麻烦一点。

![image.png](/static/img/d7c38bc0bd6e2e643da6f732e2e11fd6.image.png)
5. 修改redis源码。我发现 Redis4.0 为我们带来了许多新特性，其中便包括基于 LFU 的热点 key 发现机制，有了这个新特性，我们就可以在此基础上实现热点 key 的统计，这个只是我的个人思路。


## 如何解决热点数据问题
案例回答：
> 关于如何治理热点数据问题，解决这个问题主要从两个方面考虑，第一是数据分片，让压力均摊到集群的多个分片上，防止单个机器打挂，第二是迁移隔离

概括总结：
1. key拆分。如果当前 key 的类型是一个二级数据结构，例如哈希类型。如果该哈希元素个数较多，可以考虑将当前 hash 进行拆分，这样该热点 key 可以拆分为若干个新的 key 分布到不同 Redis 节点上，从而减轻压力
2. 迁移热点key。以 Redis Cluster 为例，可以将热点 key 所在的 slot 单独迁移到一个新的 Redis 节点上，这样这个热点 key 即使 QPS 很高，也不会影响到整个集群的其他业务，还可以定制化开发，热点 key 自动迁移到独立节点上，这种方案也较多副本。
3. 热点key限流。对于读命令我们可以通过迁移热点 key 然后添加从节点来解决，对于写命令我们可以通过单独针对这个热点 key 来限流。
4. 增加本地缓存。对于数据一致性不是那么高的业务，可以将热点 key 缓存到业务机器的本地缓存中，因为是业务端的本地内存中，省去了一次远程的 IO 调用。但是当数据更新时，可能会造成业务和 Redis 数据不一致。

## redis支持丰富的数据类型，这些数据类型存储的大Value如何解决，线上有遇到这种情况吗？

案例回答：
> 相比热点 key 大概念，大 Value 的概念比好好理解，由于 Redis 是单线程运行的，如果一次操作的 value 很大会对整个 redis 的响应时间造成负面影响，因为 Redis 是 Key - Value 结构数据库，大 value 就是单个 value 占用内存较大，对 Redis 集群造成最直接的影响就是数据倾斜。

先说说多大的 Value 算大，根据公司基础架构给出的经验值可做以下划分：

* 大：string 类型 value > 10K，set、list、hash、zset 等集合数据类型中的元素个数 > 1000。
* 超大： string 类型 value > 100K，set、list、hash、zset 等集合数据类型中的元素个数 > 10000。


由于 Redis 是单线程运行的，如果一次操作的 value 很大会对整个 redis 的响应时间造成负面影响，所以，业务上能拆则拆，下面举几个典型的分拆方案：

1. 一个较大的 key-value 拆分成几个 key-value ，将操作压力平摊到多个 redis 实例中，降低对单个 redis 的 IO 影响
2. 将分拆后的几个 key-value 存储在一个 hash 中，每个 field 代表一个具体的属性，使用 hget,hmget 来获取部分的 value，使用 hset，hmset 来更新部分属性。
3. hash、set、zset、list 中存储过多的元素

类似于场景一中的第一个做法，可以将这些元素分拆。
以 hash 为例，原先的正常存取流程是:
```
hget(hashKey,field)
hset(hashKey,field,value)
```
现在，固定一个桶的数量，比如 10000，每次存取的时候，先在本地计算 field 的 hash 值，模除 10000，确定该 field 落在哪个 key 上，核心思想就是将 value 打散，每次只 get 你需要的。
```
newHashKey = hashKey +(hash(field)%10000)
hset(newHashKey,field,value)
hget(newHashKey,field)
```

redis热点数据问题解决方案

# 为什么不推荐使用物理外键

之前在设计数据库的时候，有思考过这个问题，到底应该在什么情况下使用外键，什么情况不使用外键？



## 1. 外键的介绍
> 什么是外键？

一个表中的foreign key指向另一个表中的primary key

用外键的好处：
* 外键的约束为我们保证了数据主从关系和产生的先后关系，保证数据的完整性和一致性
* 级联操作为update和delete带来了不少方便
* 能够增加ER图的可读性



建键的原则：
* 为关联字段创建外键
* 所有的键都必须唯一
* 避免使用复合键（复合键：表中两个或两个以上列的组合，它允许我们唯一标识表的每一行。）
* 外键总是关联唯一的键字段

[外键的好处](https://blog.csdn.net/yaochongchong/article/details/44308659)


用外键的成本你可以参考以下内容：

## 2. 外键的性能问题

为何说外键有性能问题？
1. 数据库需要维护外键的内部管理；

2. 外键等于把数据的一致性事务实现，全部交给数据库服务器完成；

3. 有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；

4. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；

所以，如果项目的服务并发量（增加、删除操作），建议不用外键，大量的这些操作会对数据库服务器有成本消耗。如果查询比较多的，可以使用。

## 3. myql的外键设计问题（对SQl标准的背离）
虽然很多人都不推荐你在关系型数据库使用外键。 但你更多听到的是mysql的，而不是SQLserver或者其他。比较公认的是，他的外键设计得的确不是很好，限制多功能不强大等。（同样的，讨论是不是该用存储过程也存在这种思考）

这里贴上一些从博客园看到的，比较严重的问题。

* 所有tables必须是InnoDB型，它们不能说临时表
* 不支持对外键列的索引前缀。样的后果之一是BLOB和TEXT列不被包括在一个外键中，这是因为对这些列的索引必须总是包含一个前缀长度
* nnoDB不对那些外键或包含NULL列的被引用键值检查外键约束

关于对SQL标准的背离（这里只贴其中一个点）


默认的行为应被延迟检查（即约束仅在整个SQL语句被处理之后才被检查）

类似一般的MySQL，在一个插入，删除或更新许多行的SQL语句内，InnoDB逐行检查UNIQUE和FOREIGN KEY约束。

直到InnoDB实现延迟的约束检查之前，一些事情是不可能的，比如删除一个通过外键参考到自身的记录。

[详细参考](http://www.cnblogs.com/discuss/articles/1862244.html)

## 4. 不使用外键我们也有好的解决方案
外键是个好东西，他为选择了关系型数据库的我们做了约束和级联做了保障。但不使用物理外键的我们也有方案去实现我们的逻辑外键，并保证他正确运行。

数据库上的一个策略：可以选择大多数情况下我们只更新不删除，也就是逻辑删，不再使用的历史数据定期归档来减少压力。

代码上的各种设计和限制：对表范围的操作权限，开启事务去处理逻辑，有需要进行异步操作来提高性能的我们设计补偿机制去弥补，等等。

## 5. 外键对扩展性的限制和影响

在我的实际项目中，就靠这一点，直接放弃使用外键。如果表的扩展性需求很高，尽量远离外键。

计划赶不上变化，外键的主从关系是定的，然后你会因为这个做很多事情，但是万一哪天主键所在表就见鬼去了呢？万一哪天你发现外键表不是非得跟人家的主键挂上关系呢？就我经历过的来看，这种情况并不少见，尤其是数据库设计者水平不够高的情况下。

 

另一个看法比较主观，就是你让数据库去帮你管外键了，你平时写程序的时候就真的很思路清晰吗？因为某些原因（比如你想要的关系数据库不支持，mysql经常），有些地方你就不能设计外键了，到时候一有级联更新的需要时，一部分你靠物理外键，一部分你还得靠自己，我觉得还不如全靠代码逻辑去保证。即使你对业务理解深刻，对外键也掌握的透彻，你也不太希望老是你管一部分他管一部分吧？

## 6. 反对的声音
最后再来说说一些坚持用外键的思考

有人问：原本在物理外键的开销，在程序上不也有开销吗？的确，但是这样我们对优化性能的方式也灵活了，刚刚说的异步处理就是一种。视具体情况而定，如果设计的好，有时候某些无用数据你不是非得立刻删除他，甚至不是非得删除他。

[参考](http://www.justabug.net/think-in-mysql-foreign-key/)

为什么不推荐使用外键

## 1.docker-compose 安装
[官方文档](https://docs.docker.com/compose/install/)



核心命令：
```
# 下载并安装docker-compose命令
 sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
# 修改文件权限为可执行
 sudo chmod +x /usr/local/bin/docker-compose
# 创建软链接， 让命令支持全局调用
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose 
# 验证命令是否安装成功
 docker-compose --version

```

## 2. 使用docker-compose 安装RabbitMq
### 2.1 设置rabbitMq数据存放目录 
首先创建RabbitMq目录文件在/usr/local/software/RabbitMq，这个路径可以自定义
```
mkdir /usr/local/software/RabbitMQ

cd /usr/local/software/RabbitMQ

```
### 2.2 创建RabbitMq的dockerfile.yml
在/usr/loacl/software/RabbitMq下创建dockerfile.yml文件

```
version: "3.8"
services:
  rabbitmq:
    image: daocloud.io/library/rabbitmq:3.8.7
    container_name: rabbitmq
    restart: always
    volumes:
      - ./data/:/var/lib/rabbitmq/
    ports:
      - 5672:5672
      - 15672:15672

```

### 2.3 安装
通过docker-compose 安装rabbitMq
```
docker-compose up -d
```
## 3. 验证RabbitMq是否安装成功
```
curl localhost:5672 --output run.log |cat run.log

```

## 4. 开启图形化管理
### 4.1 进入容器内部
```
docker exec -it rabbitmq /bin/bash
```
### 4.2 进入rabbitmq默认安装目录
```
# 进入rabbitmq的可执行命令目录
cd /opt/rabbitmq/sbin
```

### 4.3 开启图形化管理
```
./rabbitmq-plugins enable rabbitmq_management
```

开启成功如下图：

![image.png](/static/img/1e4956e0e79e436b0dcbcdfb329172cd.image.png)





### 4.4 防火墙跟安全组

如果在本地虚拟机，只需要关闭防火墙即可。
如果是云服务器，需要在安全组配置准入规则，开放15672端口，如果防火墙开启了，需要在防火墙的配置15672端口放行，重启防火墙才可以。

之后可以通过Ip:15672端口访问图形化界面，

默认账号：guest
默认密码：guest

![image.png](/static/img/7fbd17fa8ee40350924f4b68f7a6ff2e.image.png)

docker-compose 安装rabbitMq

## 概览

![image.png](https://www.choumaomi.com/static/img/103b19b3be33764a8da880b2caf1b96a.image.png)



## 1. 批量思想：批量操作数据库
优化前：
```java
//for循环单笔入库
for(TransDetail detail:transDetailList){
  insert(detail);  
}
```

优化后：
```java
batchInsert(transDetailList);
```

打个比喻：
> 假如你需要搬一万块砖到楼顶,你有一个电梯,电梯一次可以放适量的砖（最多放500）, 你可以选择一次运送一块砖,也可以一次运送500,你觉得哪种方式更方便，时间消耗更少?


## 2. 异步思想：耗时操作，考虑放到异步执行
耗时操作，考虑用异步处理，这样可以降低接口耗时。

假设一个转账接口，匹配联行号，是同步执行的，但是它的操作耗时有点长，优化前的流程：

![image.png](https://www.choumaomi.com/static/img/2e51c506970bd70c1998a72435e8d96d.image.png)

为了降低接口耗时，更快返回，你可以把匹配联行号移到异步处理，优化后：


![image.png](https://www.choumaomi.com/static/img/d63899e0ef41e1730f318443ff1d5e1a.image.png)

除了转账这个例子，日常工作中还有很多这种例子。比如：用户注册成功后，短信邮件通知，也是可以异步处理的~

至于异步的实现方式，你可以用线程池，也可以用消息队列实现。


## 空间换时间思想：恰当使用缓存。
在适当的业务场景，恰当地使用缓存，是可以大大提高接口性能的。缓存其实就是一种空间换时间的思想，就是你把要查的数据，提前放好到缓存里面，需要时，直接查缓存，而避免去查数据库或者计算的过程。

这里的缓存包括：Redis缓存，JVM本地缓存，memcached，或者Map等等。我举个我工作中，一次使用缓存优化的设计吧，比较简单，但是思路很有借鉴的意义。

> 那是一次转账接口的优化，老代码，每次转账，都会根据客户账号，查询数据库，计算匹配联行号。


![image.png](https://www.choumaomi.com/static/img/435fe98b7c9c35ce8d85d60cfa46d34d.image.png)

因为每次都查数据库，都计算匹配，比较耗时，所以使用缓存，优化后流程如下：


![image.png](https://www.choumaomi.com/static/img/60d0ea7e5bb194295edb9622a0627f51.image.png)


## 4. 预取思想：提前初始化到缓存
预取思想很容易理解，就是提前把要计算查询的数据，初始化到缓存。如果你在未来某个时间需要用到某个经过复杂计算的数据，才实时去计算的话，可能耗时比较大。这时候，我们可以采取预取思想，提前把将来可能需要的数据计算好，放到缓存中，等需要的时候，去缓存取就行。这将大幅度提高接口性能。

我记得以前在第一个公司做视频直播的时候，看到我们的直播列表就是用到这种优化方案。就是启动个任务，提前把直播用户、积分等相关信息，初始化到缓存。

## 5. 池化思想：预分配与循环使用

大家应该都记得，我们为什么需要使用线程池？

> 线程池可以帮我们管理线程，避免增加创建线程和销毁线程的资源损耗。

如果你每次需要用到线程，都去创建，就会有增加一定的耗时，而线程池可以重复利用线程，避免不必要的耗时。 池化技术不仅仅指线程池，很多场景都有池化思想的体现，它的本质就是预分配与循环使用。

比如TCP三次握手，大家都很熟悉吧，它为了减少性能损耗，引入了Keep-Alive长连接，避免频繁的创建和销毁连接。当然，类似的例子还有很多，如数据库连接池、HttpClient连接池。

我们写代码的过程中，学会池化思想，最直接相关的就是使用线程池而不是去new一个线程。

## 6.事件回调思想：拒绝阻塞等待。

如果你调用一个系统B的接口，但是它处理业务逻辑，耗时需要10s甚至更多。然后你是一直阻塞等待，直到系统B的下游接口返回，再继续你的下一步操作吗？这样显然不合理。

我们参考IO多路复用模型。即我们不用阻塞等待系统B的接口，而是先去做别的操作。等系统B的接口处理完，通过事件回调通知，我们接口收到通知再进行对应的业务操作即可。


## 7.远程调用由串行改为并行

假设我们设计一个APP首页的接口，它需要查用户信息、需要查banner信息、需要查弹窗信息等等。如果是串行一个一个查，比如查用户信息200ms，查banner信息100ms、查弹窗信息50ms，那一共就耗时350ms了，如果还查其他信息，那耗时就更大了。


![image.png](https://www.choumaomi.com/static/img/16e7caf3bea689f6880a6e07988d7806.image.png)

其实我们可以改为并行调用，即查用户信息、查banner信息、查弹窗信息，可以同时并行发起。

![image.png](https://www.choumaomi.com/static/img/ba8a74ada5a38f8f1e55d126849c0f48.image.png)

最后接口耗时将大大降低。

## 8.锁粒度避免过粗

在高并发场景，为了防止超卖等情况，我们经常需要加锁来保护共享资源。但是，如果加锁的粒度过粗，是很影响接口性能的。

什么是加锁粒度呢？

> 其实就是就是你要锁住的范围是多大。比如你在家上卫生间，你只要锁住卫生间就可以了吧，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。

不管你是synchronized加锁还是redis分布式锁，只需要在共享临界资源加锁即可，不涉及共享资源的，就不必要加锁。这就好像你上卫生间，不用把整个家都锁住，锁住卫生间门就可以了。

比如，在业务代码中，有一个ArrayList因为涉及到多线程操作，所以需要加锁操作，假设刚好又有一段比较耗时的操作（代码中的slowNotShare方法）不涉及线程安全问题。反例加锁，就是一锅端，全锁住:

```java
//不涉及共享资源的慢方法
private void slowNotShare() {
    try {
        TimeUnit.MILLISECONDS.sleep(100);
    } catch (InterruptedException e) {
    }
}

//错误的加锁方法
public int wrong() {
    long beginTime = System.currentTimeMillis();
    IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
        //加锁粒度太粗了，slowNotShare其实不涉及共享资源
        synchronized (this) {
            slowNotShare();
            data.add(i);
        }
    });
    log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
    return data.size();
}
```

正例：
```java
public int right() {
    long beginTime = System.currentTimeMillis();
    IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
        slowNotShare();//可以不加锁
        //只对List这部分加锁
        synchronized (data) {
            data.add(i);
        }
    });
    log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
    return data.size();
}
```
## 9. 切换存储方式：文件中转暂存数据
如果数据太大，落地数据库实在是慢的话，就可以考虑先用文件的方式暂存。先保存文件，再异步下载文件，慢慢保存到数据库。

这里可能会有点抽象，给大家分享一个，我之前的一个真实的优化案例吧。


> 之前开发了一个转账接口。如果是并发开启，10个并发度，每个批次1000笔转账明细数据，数据库插入会特别耗时，大概6秒左右；这个跟我们公司的数据库同步机制有关，并发情况下，因为优先保证同步，所以并行的插入变成串行啦，就很耗时。

优化前，1000笔明细转账数据，先落地DB数据库，返回处理中给用户，再异步转账。如图：


![image.png](https://www.choumaomi.com/static/img/0eabe6d3e6500664aa6b20eb12abeb0e.image.png)

记得当时压测的时候，高并发情况，这1000笔明细入库，耗时都比较大。所以我转换了一下思路，把批量的明细转账记录保存的文件服务器，然后记录一笔转账总记录到数据库即可。接着异步再把明细下载下来，进行转账和明细入库。最后优化后，性能提升了十几倍。

优化后，流程图如下：


![image.png](https://www.choumaomi.com/static/img/969ca71212d9b43d6168290d6a63772e.image.png)

如果你的接口耗时瓶颈就在数据库插入操作这里，用来批量操作等，还是效果还不理想，就可以考虑用文件或者MQ等暂存。有时候批量数据放到文件，会比插入数据库效率更高。

## 10.索引

提到接口优化，很多小伙伴都会想到添加索引。没错，添加索引是成本最小的优化，而且一般优化效果都很不错。

索引优化这块的话，一般从这几个维度去思考：

* 你的SQL加索引了没？
* 你的索引是否真的生效？
* 你的索引建立是否合理？

### 10.1 SQL没加索引
我们开发的时候，容易疏忽而忘记给SQL添加索引。所以我们在写完SQL的时候，就顺手查看一下 explain执行计划。
```
explain select * from user_info where userId like '%123';
```
你也可以通过命令show create table ，整张表的索引情况。
```
show create table user_info;
```
如果某个表忘记添加某个索引，可以通过alter table add index命令添加索引
```
alter table user_info add index idx_name (name);
```
一般就是：SQL的where条件的字段，或者是order by 、group by后面的字段需需要添加索引。

### 10.2 索引不生效

有时候，即使你添加了索引，但是索引会失效的。整理了索引失效的7个常见原因：

[索引不生效原因](http://www.syrr.cn/news/38620.html?action=onClick)

### 10.3 索引设计不合理
我们的索引不是越多越好，需要合理设计。比如：

* 删除冗余和重复索引。
* 索引一般不能超过5个
* 索引不适合建在有大量重复数据的字段上、如性别字段
* 适当使用覆盖索引
* 如果需要使用force index强制走某个索引，那就需要思考你的索引设计是否真的合理了
## 11. 优化SQL
处了索引优化，其实SQL还有很多其他有优化的空间。比如这些：

![image.png](https://www.choumaomi.com/static/img/1ba513230bdc7e68aac328242151e85d.image.png)

## 12. 避免大事务问题
为了保证数据库数据的一致性，在涉及到多个数据库修改操作时，我们经常需要用到事务。而使用spring声明式事务，又非常简单，只需要用一个注解就行@Transactional，如下面的例子
```java
@Transactional
public int createUser(User user){
    //保存用户信息
    userDao.save(user);
    passCertDao.updateFlag(user.getPassId());
    return user.getUserId();
}

```
这块代码主要逻辑就是创建个用户，然后更新一个通行证pass的标记。如果现在新增一个需求，创建完用户，调用远程接口发送一个email消息通知，很多小伙伴会这么写：
```java
@Transactional
public int createUser(User user){
    //保存用户信息
    userDao.save(user);
    passCertDao.updateFlag(user.getPassId());
    sendEmailRpc(user.getEmail());
    return user.getUserId();
}
```
这样实现可能会有坑，事务中嵌套RPC远程调用，即事务嵌套了一些非DB操作。如果这些非DB操作耗时比较大的话，可能会出现大事务问题。

> 所谓大事务问题就是，就是运行时间长的事务。由于事务一致不提交，就会导致数据库连接被占用，即并发场景下，数据库连接池被占满，影响到别的请求访问数据库，影响别的接口性能。

大事务引发的问题主要有：接口超时、死锁、主从延迟等等。因此，为了优化接口，我们要规避大事务问题。我们可以通过这些方案来规避大事务：

* RPC远程调用不要放到事务里面
* 一些查询相关的操作，尽量放到事务之外
* 事务中避免处理太多数据

## 13.深分页问题
在以前公司分析过几个接口耗时长的问题，最终结论都是因为深分页问题。

深分页问题，为什么会慢？我们看下这个SQL

```sql
select id,name,balance from account where create_time> '2020-09-19' limit 100000,10;
```
limit 100000,10意味着会扫描100010行，丢弃掉前100000行，最后返回10行。即使create_time，也会回表很多次。

我们可以通过标签记录法和延迟关联法来优化深分页问题。

### 13.1 标签记录法
> 就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描。就好像看书一样，上次看到哪里了，你就折叠一下或者夹个书签，下次来看的时候，直接就翻到啦。

假设上一次记录到100000，则SQL可以修改为：
```sql
select  id,name,balance FROM account where id > 100000 limit 10;
```
这样的话，后面无论翻多少页，性能都会不错的，因为命中了id主键索引。但是这种方式有局限性：需要一种类似连续自增的字段

### 13.2 延迟关联法
延迟关联法，就是把条件转移到主键索引树，然后减少回表。优化后的SQL如下：

```sql
select  acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10) AS acct2 on acct1.id= acct2.id;
```
优化思路就是，先通过idx_create_time二级索引树查询到满足条件的主键ID，再与原表通过主键ID内连接，这样后面直接走了主键索引了，同时也减少了回表。

## 14. 优化程序结构
优化程序逻辑、程序代码，是可以节省耗时的。比如，你的程序创建多不必要的对象、或者程序逻辑混乱，多次重复查数据库、又或者你的实现逻辑算法不是最高效的，等等。

我举个简单的例子：复杂的逻辑条件，有时候调整一下顺序，就能让你的程序更加高效。

> 假设业务需求是这样：如果用户是会员，第一次登陆时，需要发一条感谢短信。如果没有经过思考，代码直接这样写了

```java
if(isUserVip && isFirstLogin){
    sendSmsMsg();
}
```
假设有5个请求过来，isUserVip判断通过的有3个请求，isFirstLogin通过的只有1个请求。那么以上代码，isUserVip执行的次数为5次，isFirstLogin执行的次数也是3次，如下：

![image.png](https://www.choumaomi.com/static/img/3c9edd64121adfbfdac3a106790d50da.image.png)

如果调整一下isUserVip和isFirstLogin的顺序：
```java
if(isFirstLogin && isUserVip ){
    sendMsg();
}
```
isFirstLogin执行的次数是5次，isUserVip执行的次数是1次：


![image.png](https://www.choumaomi.com/static/img/94aff2a178d44e8cc93a82dfd4c900d8.image.png)

## 15. 压缩传输内容

压缩传输内容，传输报文变得更小，因此传输会更快啦。10M带宽，传输10k的报文，一般比传输1M的会快呀。
> 打个比喻，一匹千里马，它驮着100斤的货跑得快，还是驮着10斤的货物跑得快呢？

再举个视频网站的例子：

> 如果不对视频做任何压缩编码，因为带宽又是有限的。巨大的数据量在网络传输的耗时会比编码压缩后，慢好多倍。


## 16. 海量数据处理，考虑NoSQL

前看过几个慢SQL，都是跟深分页问题有关的。发现用来标签记录法和延迟关联法，效果不是很明显，原因是要统计和模糊搜索，并且统计的数据是真的大。最后跟组长对齐方案，就把数据同步到Elasticsearch，然后这些模糊搜索需求，都走Elasticsearch去查询了。

我想表达的就是，如果数据量过大，一定要用关系型数据库存储的话，就可以分库分表。但是有时候，我们也可以使用NoSQL，如Elasticsearch、Hbase等。

## 17. 线程池设计要合理

我们使用线程池，就是让任务并行处理，更高效地完成任务。但是有时候，如果线程池设计不合理，接口执行效率则不太理想。

一般我们需要关注线程池的这几个参数：核心线程、最大线程数量、阻塞队列。

* 如果核心线程过小，则达不到很好的并行效果。
* 如果阻塞队列不合理，不仅仅是阻塞的问题，甚至可能会OOM
* 如果线程池不区分业务隔离，有可能核心业务被边缘业务拖垮。

## 18. 机器问题 （fullGC、线程打满、太多IO资源没关闭等等）
有时候，我们的接口慢，就是机器处理问题。主要有fullGC、线程打满、太多IO资源没关闭等等。

* 之前排查过一个fullGC问题：运营小姐姐导出60多万的excel的时候，说卡死了，接着我们就收到监控告警。后面排查得出，我们老代码是Apache POI生成的excel，导出excel数据量很大时，当时JVM内存吃紧会直接Full GC了。
* 如果线程打满了，也会导致接口都在等待了。所以。如果是高并发场景，我们需要接入限流，把多余的请求拒绝掉。
* 如果IO资源没关闭，也会导致耗时增加。这个大家可以看下，平时你的电脑一直打开很多很多文件，是不是会觉得很卡。

前言

为什么不推荐使用物理外键

1.docker-compose 安装

概览

CHAPTER 6: DESIGN A KEY-VALUE STORE 设计键值存储