< div style = "color:#16b0ff;font-size:50px;font-weight: 900;text-shadow: 5px 5px 10px var(--theme-color);font-family: 'Comic Sans MS';" > Middleware< / div >
< span style = "color:#16b0ff;font-size:20px;font-weight: 900;font-family: 'Comic Sans MS';" > Introduction</ span > ：收纳技术相关的基础知识 `Redis` 、`RocketMQ`、`Zookeeper`、`Netty`、`Tomcat` 等总结！
[TOC]
# SPI
SPI 全称为 Service Provider Interface，
## Java SPI
JDK 中 提供了一个 `SPI` 的功能，核心类是 `java.util.ServiceLoader` 。其作用就是，可以通过类名获取在 `META-INF/services/` 下的多个配置实现文件。为了解决上面的扩展问题，现在我们在`META-INF/services/`下创建一个`com.github.yu120.test.SuperLoggerConfiguration`文件（没有后缀）。文件中只有一行代码，那就是我们默认的`com.github.yu120.test.XMLConfiguration`（注意，一个文件里也可以写多个实现，回车分隔）。然后通过 ServiceLoader 获取我们的 SPI 机制配置的实现类：
```java
// META-INF/services/com.github.test.test.SuperLoggerConfiguration:
com.github.yu120.test.XMLConfiguration
ServiceLoader< SuperLoggerConfiguration > serviceLoader = ServiceLoader.load(SuperLoggerConfiguration.class);
Iterator< SuperLoggerConfiguration > iterator = serviceLoader.iterator();
SuperLoggerConfiguration configuration;
while(iterator.hasNext()) {
// 加载并初始化实现类
configuration = iterator.next();
}
// 对最后一个configuration类调用configure方法
configuration.configure(configFile);
```
## [Dubbo SPI](https://github.com/apache/dubbo/tree/master/dubbo-common/src/main/java/org/apache/dubbo/common/extension)
Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader类中， ， ， ：
- 通过配置文件，解耦拓展接口和拓展实现类
- 通过IOC自动注入依赖的拓展实现类对象
- 通过URL参数，
Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下， （ ）
```properties
optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee
```
与 Java SPI 实现类配置不同， @SPI 注解。
## [Motan SPI](https://github.com/weibocom/motan/tree/master/motan-core/src/main/java/com/weibo/api/motan/core/extension)
Motan使用SPI机制来实现模块间的访问， ，
Motan的SPI的实现在 `motan-core/com/weibo/api/motan/core/extension` 中。组织结构如下：
```tex
motan-core/com.weibo.api.motan.core.extension
|-Activation： ，
|-ActivationComparator：
|-ExtensionLoader： ，
|-Scope： ，
|-Spi： ， ，
|-SpiMeta： ， ，
```
## SpringBoot SPI
Spring 的 SPI 配置文件是一个固定的文件 - `META-INF/spring.factories` ，功能上和 JDK 的类似，每个接口可以有多个扩展实现，使用起来非常简单：
```java
// 获取所有factories文件中配置的LoggingSystemFactory
List< LoggingSystemFactory > > factories = SpringFactoriesLoader.loadFactories(LoggingSystemFactory.class, classLoader);
```
下面是一段 Spring Boot 中 spring.factories 的配置
```properties
# Logging Systems
org.springframework.boot.logging.LoggingSystemFactory=\
org.springframework.boot.logging.logback.LogbackLoggingSystem.Factory,\
org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.Factory
# PropertySource Loaders
org.springframework.boot.env.PropertySourceLoader=\
org.springframework.boot.env.PropertiesPropertySourceLoader,\
org.springframework.boot.env.YamlPropertySourceLoader
```
# Redis
## 数据类型
在 Redis 中，常用的 5 种数据类型和应用场景如下：
- **String：
- **List：
- **Hash：
- **Set：
- **Zset：
当然是为了追求速度，不同数据类型使用不同的数据结构速度才得以提升。每种数据类型都有一种或者多种数据结构来支撑，底层数据结构有 6 种。
### Redis hash字典
Redis 整体就是一个 哈希表来保存所有的键值对，无论数据类型是 5 种的任意一种。哈希表，本质就是一个数组，每个元素被叫做哈希桶，不管什么数据类型，每个桶里面的 entry 保存着实际具体值的指针。
整个数据库就是一个全局哈希表，而哈希表的时间复杂度是 O(1)，只需要计算每个键的哈希值，便知道对应的哈希桶位置，定位桶里面的 entry 找到对应数据，这个也是 Redis 快的原因之一。
**那 Hash 冲突怎么办？**
当写入 Redis 的数据越来越多的时候，哈希冲突不可避免，会出现不同的 key 计算出一样的哈希值。Redis 通过链式哈希解决冲突：也就是同一个 桶里面的元素使用链表保存。但是当链表过长就会导致查找性能变差可能，所以 Redis 为了追求快，使用了两个全局哈希表。用于 rehash 操作，增加现有的哈希桶数量，减少哈希冲突。开始默认使用 hash 表 1 保存键值对数据，哈希表 2 此刻没有分配空间。当数据越来多触发 rehash 操作，则执行以下操作：
1. 给 hash 表 2 分配更大的空间
2. 将 hash 表 1 的数据重新映射拷贝到 hash 表 2 中
3. 释放 hash 表 1 的空间
值得注意的是，将 hash 表 1 的数据重新映射到 hash 表 2 的过程中并不是一次性的，这样会造成 Redis 阻塞，无法提供服务。而是采用了渐进式 rehash， ，
### SDS简单动态字符
字符串结构使用最广泛， ， ， ， ， ，
### 双端列表
Redis List 数据类型通常被用于队列、微博关注人时间轴列表等场景。不管是先进先出的队列， ，
- **双端**：链表节点带有 prev 和 next 指针，获取某个节点的前置节点和后置节点的复杂度都是 O（ ）
- **无环**：表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL，
- **带表头指针和表尾指针**：通过 list 结构的 head 指针和 tail 指针，程序获取链表的表头节点和表尾节点的复杂度为 O（ ）
- **带链表长度计数器**：程序使用 list 结构的 len 属性来对 list 持有的链表节点进行计数，程序获取链表中节点数量的复杂度为 O（ ）
- **多态**：链表节点使用 void* 指针来保存节点值，并且可以通过 list 结构的 dup、free、match 三个属性为节点值设置类型特定函数，所以链表可以用于保存各种不同类型的值
后续版本对列表数据结构进行了改造，使用 quicklist 代替了 ziplist 和 linkedlist。quicklist 是 ziplist 和 linkedlist 的混合体，它将 linkedlist 按段切分，每一段使用 ziplist 来紧凑存储，多个 ziplist 之间使用双向指针串接起来。
这也是为何 Redis 快的原因，不放过任何一个可以提升性能的细节。
### zipList压缩列表
压缩列表是 List 、hash、 sorted Set 三种数据类型底层实现之一。当一个列表只有少量数据的时候，并且每个列表项要么就是小整数值，要么就是长度比较短的字符串，那么 Redis 就会使用压缩列表来做列表键的底层实现。ziplist 是由一系列特殊编码的连续内存块组成的顺序型的数据结构， ， ， ，
```go
struct ziplist< T > {
int32 zlbytes; // 整个压缩列表占用字节数
int32 zltail_offset; // 最后一个元素距离压缩列表起始位置的偏移量，用于快速定位到最后一个节点
int16 zllength; // 元素个数
T[] entries; // 元素内容列表，挨个挨个紧凑存储
int8 zlend; // 标志压缩列表的结束，值恒为 0xFF
}
```
如果我们要查找定位第一个元素和最后一个元素，可以通过表头三个字段的长度直接定位，复杂度是 O(1)。而查找其他元素时，就没有这么高效了，只能逐个查找，此时的复杂度就是 O(N)。
### skipList跳跃表
sorted set 类型的排序功能便是通过「跳跃列表」数据结构来实现。跳跃表（ ） ， ， （ ） （ ） ， ， ， ， ， ：
当需要查找 40 这个元素需要经历 三次查找。
### 整数数组（ ）
当一个集合只包含整数值元素， ，
```go
typedef struct intset{
//编码方式
uint32_t encoding;
//集合包含的元素数量
uint32_t length;
//保存元素的数组
int8_t contents[];
}intset;
```
contents 数组是整数集合的底层实现：整数集合的每个元素都是 contents 数组的一个数组项（ ） ， ，
## 持久化
### RDB
**① save命令 —— 同步数据到磁盘上**
`save` 命令执行一个同步操作，
由于 `save` 命令是同步命令， ， ， ， ，
**② bgsave命令 —— 异步保存数据到磁盘上**
`bgsave` 命令执行一个异步操作，
Redis使用Linux系统的`fock()`生成一个子进程来将DB数据保存到磁盘， ，
**③ 自动生成RDB**
可以通过配置文件对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动进行数据集保存操作。比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动进行数据集保存操作:
```shell
# RDB自动持久化规则
# 当 900 秒内有至少有 1 个键被改动时，自动进行数据集保存操作
save 900 1
# 当 300 秒内有至少有 10 个键被改动时，自动进行数据集保存操作
save 300 10
# 当 60 秒内有至少有 10000 个键被改动时，自动进行数据集保存操作
save 60 10000
# RDB持久化文件名
dbfilename dump-< port > .rdb
# 数据持久化文件存储目录
dir /var/lib/redis
# bgsave发生错误时是否停止写入，
stop-writes-on-bgsave-error yes
# rdb文件是否使用压缩格式
rdbcompression yes
# 是否对rdb文件进行校验和检验，
rdbchecksum yes
```
### AOF
AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是**只追加**的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog，
优点：
- AOF是一秒一次去通过一个后台的线程fsync操作，
缺点：
- 对于相同数量的数据集而言，
- 根据同步策略的不同，
**AOF整个流程分两步**：
- 第一步是命令的实时写入， ， ，
- 第二步是对aof文件的**重写**， ， ， ，
- 在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；它`依然会写入旧`的AOF中， ，
- 为了把重写期间响应的写入信息也写入到新的文件中，因此也会`为子进程保留一个buf`，
- 重写是直接把`当前内存的数据生成对应命令`，
- **无论是 RDB 还是 AOF 都是先写入一个临时文件，然后通过`rename`完成文件的替换工作**。
关于Fork的建议：
- 降低fork的频率，
- 控制Redis最大使用内存，
- 配置牛逼点， ，
- Redis在执行`BGSAVE`和`BGREWRITEAOF`命令时，哈希表的负载因子>=5，
- **哈希表的扩展因子**：哈希表已保存节点数量 / 哈希表大小。因子决定了是否扩展哈希表
## 过期策略
**过期策略用于处理过期缓存数据**。Redis采用过期策略： `定期删除` 。memcached采用过期策略：
### 定时过期
每个设置过期时间的key都需要创建一个定时器， ， ；
### 惰性过期
只有当访问一个key时， ， ， ， ，
### 定期过期
每隔一定的时间， ， ，
expires字典会保存所有设置了过期时间的key的过期时间数据， ，
## 内存淘汰策略
Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，
- **volatile-lru**： （ ）
- **volatile-ttl**： （ ）
- **volatile-random**： （ ）
- **allkeys-lru**： （ ）
- **allkeys-random**： （ ）
- **no-enviction（ ）
## 应用场景
- 缓存-键过期时间
- 把session会话存在redis,过期删除
- 缓存用户信息， ， ， ，
- 商城优惠卷过期时间
- 排行榜-列表& 有序集合
- 热度/点击数排行榜
- 直播间礼物积分排行
- 计数器-天然支持计数器
- 帖子浏览数
- 视频播放数
- 评论数
- 点赞/踩
- 社交网络-集合
- 粉丝
- 共同好友
- 兴趣爱好
- 标签
- 消息队列-发布订阅
- 配合ELK缓存收集来的日志
## 主从复制
**概念定义**
- runID 服务器运行的ID
- offset 主服务器的复制偏移量和从服务器复制的偏移量
- replication backlog 主服务器的复制积压缓冲区
在redis2.8之后， ， ：
- 其中完整同步用于处理初次复制情况： ， ，
- 部分重同步是用于处理断线后重复制情况：当从服务器在断线后重新连接主服务器时，主服务可以讲主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以讲数据库更新至主服务器当前所处的状态
### 完整重同步
1. slave发送psync给master， ，
2. master接收到请求，
3. master生成保存rdb文件
4. master发送rdb文件给slave
5. 在发送rdb这个操作的同时， ，
6. slave将rdb文件的数据装载，
如果网络的抖动或者是短时间的断链也需要进行完整同步就会导致大量的开销， ， ， ， ， ，
### 部分重同步
- 网络发生错误，
- master依然向buffer缓冲区写入数据
- slave重新连接上master
- slave向master发送自己目前的runid和offset
- master会判断slave发送给自己的offset是否存在buffer队列中， ， ， ， ， ，
- master发送从offset偏移后的缓冲区数据给slave
- slave获取数据更新自身数据
## 部署架构
### 单节点(Single)
**优点**
- 架构简单，部署方便
- 高性价比：缓存使用时无需备用节点(单实例可用性可以用 supervisor 或 crontab 保证)，当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务
- 高性能
**缺点**
- 不保证数据的可靠性
- 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务
- 高性能受限于单核CPU的处理能力(Redis是单线程机制)， ， ，
### 主从复制(Replication)
**基本原理**
主从复制模式中包含一个主数据库实例（ ） （ ） ， ：
.png)
优缺点.png)
### 哨兵(Sentinel)
Sentinel主要作用如下：
- **监控**：
- **通知**： ，
- **自动故障转移**： ， ， ，
.png)
优缺点.png)
### 集群(Cluster)
.png)
优缺点.png)
## 环境搭建
**Redis安装及配置**
Redis的安装十分简单， http://redis.io ](http://redis.io/ ) 。
- 下载一个最新版本的安装包，如 redis-version.tar.gz
- 解压 `tar zxvf redis-version.tar.gz`
- 执行 make (执行此命令可能会报错， ，
如果是 mac 电脑， ， ，
```shell
port 6379 # 指定端口为 6379，
daemonize yes # 指定后台运行
```
### 单节点(Single)
安装好redis之后，
```shell
$ < redishome > /bin/redis-server path/to/redis.config
```
假设我们没有配置后台运行（ ： ）
```shell
93825:C 20 Jan 2019 11:43:22.640 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
93825:C 20 Jan 2019 11:43:22.640 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=93825, just started
93825:C 20 Jan 2019 11:43:22.640 # Configuration loaded
93825:S 20 Jan 2019 11:43:22.641 * Increased maximum number of open files to 10032 (it was originally set to 256).
_._
_.-``__ ''-._
_.-`` `. `_ . ''-._ Redis 5.0.3 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in standalone mode
|`-._`-...-` __ ...-.``-._|'` _.-'| Port: 6380
| `-._ ` ._ / _.-' | PID: 93825
`-._ ` -._ `-./ _.-' _ .-'
|`-._`-._ `-.__.-' _.-'_ .-'|
| `-._` -._ _.-'_ .-' | http://redis.io
`-._ ` -._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_ .-'|
| `-._` -._ _.-'_ .-' |
`-._ ` -._`-.__.-'_.-' _.-'
`-._ ` -.__.-' _.-'
`-._ _.-'
`-.__.-'
```
### 主从复制(Replication)
Redis主从配置非常简单， ：
**第一步**： （ ， ， ）
```shell
mkdir redis-master-slave
cp path/to/redis/conf/redis.conf path/to/redis-master-slave master.conf
cp path/to/redis/conf/redis.conf path/to/redis-master-slave slave.conf
```
**第二步**：修改配置
```shell
## master.conf
port 6379
## master.conf
port 6380
slaveof 127.0.0.1 6379
```
**第三步**：
```shell
redis-server path/to/redis-master-slave/master.conf
redis-server path/to/redis-master-slave/slave.conf
```
启动之后，打开两个命令行窗口，分别执行 `telnet localhost 6379` 和 `telnet localhost 6380` ，然后分别在两个窗口中执行 `info` 命令,可以看到：
```shell
# Replication
role:master
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
```
主从配置没问题。然后在master 窗口执行 set 之后， ， ， ，
```shell
-READONLY You can't write against a read only replica.
```
因为从节点是只读的。
### 哨兵(Sentinel)
Sentinel是用来监控主从节点的健康情况。客户端连接Redis主从的时候， ， ， ， ， ，
**哨兵sentinel配置**
为了说明sentinel的用处， （ ） ， ：
```shell
mkdir redis-sentinel
cd redis-sentinel
cp redis/path/conf/redis.conf path/to/redis-sentinel/redis01.conf
cp redis/path/conf/redis.conf path/to/redis-sentinel/redis02.conf
cp redis/path/conf/redis.conf path/to/redis-sentinel/redis03.conf
touch sentinel.conf
```
上我们创建了 3个redis配置文件， ， ，
```shell
vim redis01.conf
port 63791
vim redis02.conf
port 63792
slaveof 127.0.0.1 63791
vim redis03.conf
port 63793
slaveof 127.0.0.1 63791
vim sentinel.conf
daemonize yes
port 26379
sentinel monitor mymaster 127.0.0.1 63793 1 # 下面解释含义
```
上面的主从配置都熟悉，只有哨兵配置 sentinel.conf， ：
```shell
mymaster # 为主节点名字，可以随便取，后面程序里边连接的时候要用到
127.0.0.1 63793 # 为主节点的 ip,port
1 # 后面的数字 1 表示选举主节点的时候，
```
**启动哨兵**
上面我们配置好了redis主从， ， ， ：
```shell
redis-server path/to/redis-sentinel/redis01.conf
redis-server path/to/redis-sentinel/redis02.conf
redis-server path/to/redis-sentinel/redis03.conf
redis-server path/to/redis-sentinel/sentinel.conf --sentinel
```
启动之后，可以分别连接到 3个redis上，
**模拟主节点宕机情况**
运行上面的程序（**注意， ， ， ， ） ， ，
```shell
redis-cli -p 63791 shutdown
```
### 集群(Cluster)
上述所做的这些工作只是保证了数据备份以及高可用， ， ， ， ：
- 单个redis并发有限
- 单个redis接收所有数据， ， ，
所以需要redis cluster 即redis集群。Redis 集群是一个提供在**多个Redis间节点间共享数据**的程序集。Redis集群并不支持处理多个keys的命令， ，
- 自动分割数据到不同的节点上
- 整个集群的部分节点失败或者不可达的情况下能够继续处理命令
为了配置一个redis cluster,我们需要准备至少6台redis， ？ ：
> Note that the minimal cluster that works as expected requires to contain at least three master nodes.
因为最小的redis集群， ， ， ， ，
**配置 redis cluster 集群**
上面提到， ：
```shell
# 主：
# 主：
# 主：
mkdir redis-cluster
cd redis-cluster
mkdir redis01 到 redis06 6个文件夹
cp redis.conf 到 redis01 ... redis06
# 修改端口, 分别配置3组主从关系
```
**启动redis集群**
上面的配置完成之后， ， ：
```shell
redis-5.0.3/src/redis-cli --cluster create 127.0.0.1:6371 127.0.0.1:6372 127.0.0.1:6373 127.0.0.1:6374 127.0.0.1:6375 127.0.0.1:6376 --cluster-replicas 1
```
**注意**， ，
```shell
ERR Invalid node address specified: localhost:6371
```
执行成功之后， ，
```shell
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:1515
cluster_stats_messages_pong_sent:1506
cluster_stats_messages_sent:3021
cluster_stats_messages_ping_received:1501
cluster_stats_messages_pong_received:1515
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:3021
```
我们可以看到`cluster_state:ok`， ，
# RocketMQ
RocketMQ 是阿里巴巴开源的分布式消息中间件。支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。它里面有几个区别于标准消息中件间的概念，
**RocketMQ 特点**
- 是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式等特点
- Producer、Consumer、队列都可以分布式
- Producer 向一些队列轮流发送消息，队列集合称为 Topic，
- 能够保证严格的消息顺序
- 支持拉（ ） （ ）
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
- 支持多种消息协议，如 JMS、OpenMessaging 等
- 较少的依赖
## 功能优势
- **削峰填谷**：主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题
- **系统解耦**：解决不同重要程度、不同能力级别系统之间依赖导致一死全死
- **提升性能**：当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统
- **蓄流压测**：线上有些链路不好压测，可以通过堆积一定量消息再放开来压测
## 队列模式
### 集群模式
生产者往某个队列里面发送消息，一个队列可以存储多个生产者的消息，一个队列也可以有多个消费者，但是消费者之间是竞争关系，即每条消息只能被一个消费者消费。
### 广播模式
**为了解决一条消息能被多个消费者消费的问题**，发布/订阅模型就来了。该模型是将消息发往一个`Topic`即主题中，所有订阅了这个 `Topic` 的订阅者都能消费这条消息。
## 分布式事务消息
MQ与DB一致性原理（ ）
## 最佳实践
### Producer
- **Topic**： ，
- **Tag**： ， ，
- **key**：每个消息在业务层面的唯一标识码，要设置到 keys 字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引(哈希索引)，应用可以通过 topic， ， ，
- **日志**：消息发送成功或者失败，要打印消息日志，务必要打印 send result 和key 字段
- **send**： ， ， ，
- **SEND_OK**：消息发送成功
- **FLUSH_DISK_TIMEOUT**：消息发送成功，但是服务器刷盘超时，消息已经进入服务器队列，只有此时服务器宕机，消息才会丢失
- **FLUSH_SLAVE_TIMEOUT**： ， ， ， ，
- **SLAVE_NOT_AVAILABLE**： ， ， ， ，
- **订阅关系一致**
多个Group ID订阅了多个Topic，
### Consumer
- **消费幂等**
为了防止消息重复消费导致业务处理异常， ， ：
- **发送时消息重复**
- **投递时消息重复**
- **负载均衡时消息重复**（ ）
- **日志**：消费时记录日志，以便后续定位问题
- **批量消费**：尽量使用批量方式消费方式，可以很大程度上提高消费吞吐量
## 常见问题
**消息可靠性怎么保证？**
消息丢失可能发生在生产者发送消息、MQ本身丢失消息、消费者丢失消息3个方面。
- **生产者丢失**
** 产生原因**： ，
** 解决方案**：
- 发送异常：本地消息表
- 发送成功无回调：异步发送+回调通知+本地消息表
- **MQ丢失**
** 产生原因**： ， ， ，
** 解决方案**： ， ， ，
- **消费者丢失**
** 产生原因**： ： ， ， ， ，
** 解决方案**： ， ， ，
**如果一直消费失败导致消息积压怎么处理？**
因为考虑到时消费者消费一直出错的问题，那么我们可以从以下几个角度来考虑：
- 消费者出错， ， ， ，
- 如果时间来不及处理很麻烦， ， ， ， ， ，
- 处理完积压数据后， ， ，
**RocketMQ实现原理？
RocketMQ由NameServer注册中心集群、Producer生产者集群、Consumer消费者集群和若干Broker（ ） ， ：
- Broker在启动的时候去向所有的NameServer注册， ，
- Producer在发送消息的时候从NameServer获取Broker服务器地址，
- Conusmer消费消息的时候同样从NameServer获取Broker地址，
**为什么 RocketMQ 不使用 Zookeeper 作为注册中心呢？**
- 根据CAP理论， ， ， ， ， ， ， ，
- 基于性能的考虑， ， ， ， ， ， ， ， ，
- 持久化的机制来带的问题， ， （ ） ， ， ，
- 消息发送应该弱依赖注册中心， ， ， ，
**Broker是怎么保存数据的呢？
RocketMQ主要的存储文件包括commitlog文件、consumequeue文件、indexfile文件。
Broker在收到消息之后， ， ， ， ， ，
CommitLog文件保存于${Rocket_Home}/store/commitlog目录中， ， ，
由于同一个topic的消息并不是连续的存储在commitlog中， ， ， ， （ ）
**Master 和 Slave 之间是怎么同步数据的呢？**
而消息在master和slave之间的同步是根据raft协议来进行的：
- 在broker收到消息后，
- 然后会把消息发送给所有的slave
- slave在收到消息之后返回ack响应给master
- master在收到超过半数的ack之后，
- 发送committed消息给所有slave，
**RocketMQ 为什么速度快吗？**
是因为使用了顺序存储、Page Cache和异步刷盘。
- 我们在写入commitlog的时候是顺序写入的，
- 写入commitlog的时候并不是直接写入磁盘，
- 最后由操作系统异步将缓存中的数据刷到磁盘
**什么是事务、半事务消息？怎么实现的？**
事务消息就是MQ提供的类似XA的分布式事务能力， ， ， ：
- 生产者先发送一条半事务消息到MQ
- MQ收到消息后返回ack确认
- 生产者开始执行本地事务
- 如果事务执行成功发送commit到MQ，
- 如果MQ长时间未收到生产者的二次确认commit或者rollback，
- 生产者查询事务执行最终状态
- 根据查询事务状态再次提交二次确认
如果MQ收到二次确认commit， ， ，
## 消息丢失
**消息发送流程**
一条消息从生产到被消费，将会经历三个阶段：
- 生产阶段：
- 存储阶段：消息将会存储在 Broker 端磁盘中
- 消息阶段：
以上任一阶段都可能会丢失消息，我们只要找到这三个阶段丢失消息原因，采用合理的办法避免丢失，就可以彻底解决消息丢失的问题。
### 生产阶段
生产者（ ） ， ，
### Broker 存储阶段
默认情况下，消息只要到了 Broker 端，将会优先保存到内存中，然后立刻返回确认响应给生产者。随后 Broker 定期批量的将一组消息从内存异步刷入磁盘。这种方式减少 I/O 次数，可以取得更好的性能，但是如果发生机器掉电，异常宕机等情况，消息还未及时刷入磁盘，就会出现丢失消息的情况。若想保证 Broker 端不丢消息，保证消息的可靠性，我们需要将消息保存机制修改为同步刷盘方式，即消息**存储磁盘成功**，才会返回响应。修改 Broker 端配置如下：
```properties
# 默认情况为 ASYNC_FLUSH
flushDiskType = SYNC_FLUSH
```
若 Broker 未在同步刷盘时间内（**默认为 5s**）完成刷盘，将会返回 `SendStatus.FLUSH_DISK_TIMEOUT` 状态给生产者。
### 消费阶段
消费者从broker拉取消息， ，
# Zookeeper
**下载地址：**http://www.apache.org/dist/zookeeper/
## ZK特性
Zookeeper主要靠其 ** 分布式数据一致性** 为集群提供 ** 分布式协调服务**，即指在集群的节点中进行可靠的消息传递，来协调集群的工作。主要具有如下特点：
- **最终一致性：**Client无论连接到哪个Server， ，
- **可靠性：**如果一个消息或事物被一台Server接受，
- **实时性：**Zookeeper不能保证强一致性， ， ， ， ，
- **原子性：**更新只能成功或者失败，没有中间状态
- **顺序性：**包括 ** 全序（ ） ** 因果顺序（ ）
- **全序：**如果消息a在消息b之前发送，
- **因果顺序：**如果消息a在消息b之前发生（ ） ， ，
## ZK角色
- **Server（ ）
- **Leader（ ） ： ， ，
- **Learner（ ）
- **Follower（ ） ：
- **Observer（ ） ： ， ， ， ，
- **Client（ ） ：
每个Server在工作过程中有三种状态：
- **LOOKING： ，
- **LEADING：
- **FOLLOWING： ，
Zookeeper集群中，
- **领导者（ ）
Leader服务器是整个ZooKeeper集群工作机制中的核心， ：
- 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
- 集群内部各服务的调度者
- **跟随者（ ）
Follower服务器是ZooKeeper集群状态的跟随者， ：
- 处理客户端非事务请求，
- 参与事务请求Proposal的投票
- 参与Leader选举投票
- **观察者（ ） ，
Observer是3.3.0 版本开始引入的一个服务器角色， ：
- 处理客户端的非事务请求，转发事务请求给 Leader 服务器
- 不参与任何形式的投票
## 数据模型
Zookeeper 的数据模型：
- 层次化的目录结构， ，
- 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
- 节点Znode可以包含数据和子节点，
- Znode中的数据可以有多个版本， ，
- 客户端应用可以在节点上设置监视器
- 节点不支持部分读写，而是一次性完整读写
## Server工作状态
服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。
- LOOKING： ， ，
- FOLLOWING：
- LEADING：
- OBSERVING：
## 运行模式
Zookeeper 有三种运行模式：单机模式、伪集群模式和集群模式。
- **单机模式**：这种模式一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。
- **集群模式**：一个 ZooKeeper 集群通常由一组机器组成，一般 3 台以上就可以组成一个可用的 ZooKeeper 集群了。组成 ZooKeeper 集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都会互相保持通信。
- **伪集群模式**： ， ， ， ， ，
## Leader选举
### 服务器启动的Leader选举
zookeeper集群初始化阶段， （ ） ，
- 服务器1（ ） ， ，
- 服务器2（ ） ， ，
- 每个服务器发出一个投票
服务器1 和 服务器2都将自己作为Leader服务器进行投票， ： ， （ ， ） ， ， （ ） ， （ ） ，
- 接受来自各个服务器的投票
每个服务器都会接受来自其他服务器的投票。同时， ，
- 处理投票
收到其他服务器的投票， ， ：
- 优先检查ZXID。ZXID比较大的服务器优先作为leader。
- 如果ZXID相同的话， ， （ ） ， （ ） ， ， ， ， （ ） ， ， ，
- 统计投票
每次投票后， ， ， （ ） ，
- 服务器3（ ） ，
跟前面流程一致， ， ， ， （ ） ， ， ；
- 服务器4启动，
此时服务器1， ， ， ： ， ；
- 服务器5启动，
同理， ， ；
- 投票结束，
### 服务器运行期间的Leader选举
zookeeper集群的五台服务器（ ） ， ， ，
- 变更状态
Leader 服务器挂了之后， ，
- 每个服务器发起投票
每个服务器都把票投给自己， ， ， （ ） ， （ ， ） ， （ ） （ ） ，
- 接受来自各个服务器的投票
- 处理投票
投票规则是跟Zookeeper集群启动期间一致的， ， ，
- 统计投票
- 改变服务器状态
## 节点（ ）
**① 节点组成**
每个znode由4部分组成:
- **path：
- **stat： ， ，
- **data：
- **children：
**② 节点类型**
- **PERSISTENT（ ）
客户端与zookeeper断开连接后，
- **PERSISTENT_SEQUENTIAL（ ）
客户端与zookeeper断开连接后， ，
- **EPHEMERAL（ ）
客户端与zookeeper断开连接后，
- **EPHEMERAL_SEQUENTIAL（ ）
客户端与zookeeper断开连接后， ，
## 关键词
- **zxid（ ）
ZooKeeper状态的每一次改变， ， ， ， ， ，
- **session（ ）
在Client和Server通信之前， ， ， ， ，
## Watcher监听机制
Zookeeper 允许客户端向服务端的某个Znode注册一个Watcher监听， ， ，
- ZooKeeper的Watcher机制主要包括客户端线程、客户端 WatcherManager、Zookeeper服务器三部分
- 客户端向ZooKeeper服务器注册Watcher的同时，
- 当zookeeper服务器触发watcher事件后， ，
**Watcher特性总结**
- **「一次性:」** 一个Watch事件是一个一次性的触发器。一次性触发，
- **「异步的：」** Zookeeper服务器发送watcher的通知事件到客户端是异步的， ， ，
- **「轻量级：」** Watcher 通知非常简单，它只是通知发生了事件，而不会传递事件对象内容
- **「客户端串行：」** 执行客户端 Watcher 回调的过程是一个串行同步的过程
- 注册 watcher用getData、exists、getChildren方法
- 触发 watcher用create、delete、setData方法
## ZXID
ZXID有两部分组成：
- 任期： ， ，
- 事务计数器：单调递增，每生效一次写入，计数器加一
ZXID的低32位是计数器， ， ， ， ，
## 工作流程
**① 客户端发起的操作的主要流程**
Leader可以执行增删改查操作， ， ， ， ， ， ，
**② 客户端的请求什么时候才能算处理成功？为什么说集群过半机器宕机后无法再工作？**
Leader在收到客户端提交过来的任务后， ， ， ， ， ， ， ， ， ，
- **Leader工作流程**
Leader主要有三个功能：
- 恢复数据
- 维持与Learner的心跳，
- Learner的消息类型主要有如下四种， ， ：
- **PING消息：
- **REQUEST消息： ，
- **ACK消息： ， ，
- **REVALIDATE消息：
- **Follower工作流程**
Follower主要有四个功能：
- 向Leader发送消息请求（ ）
- 接收Leader消息并进行处理
- 接收Client的请求， ，
- 返回Client结果
Follower的消息循环处理如下几种来自Leader的消息：
- **PING消息：
- **PROPOSAL消息： ，
- **COMMIT消息：
- **UPTODATE消息：
- **REVALIDATE消息： ，
- **SYNC消息： ， ，
- **Observer工作流程**
对于Observer的流程不再叙述，
## ZAB协议
ZooKeeper并没有完全采用Paxos算法， （ ， ） ， ：
- **崩溃恢复模式（ ） ： ， ， ，
- **消息广播模式（ ） ： ， ， （ ： ）
**① 崩溃恢复模式（ ）
为了使Leader挂了后系统能正常工作， ：
- 已经被处理的消息不能丢
- 被丢弃的消息不能再次出现
**② 消息广播模式（ ）
广播的过程实际上是一个简化的二阶段提交过程：
- Leader 接收到消息请求后，将消息赋予一个全局唯一的 64 位自增 id， ： ，
- Leader 通过先进先出队列（通过 TCP 协议来实现，以此实现了全局有序这一特性）将带有 zxid 的消息作为一个提案（ ）
- 当 follower 接收到 proposal，
- 当 leader 接收到合法数量的 ACKs 后，
- 当 follower 收到消息的 COMMIT 命令时，就会执行该消息
**总结**
个人认为 Zab 协议设计的优秀之处有两点， ， ； ， ， ， ， （ ）
**③ ZAB 的四个阶段**
- **Leader election（ ） ： ， ， （ ， ） ，
- **Discovery（ ） ： ， ， ，
- **Synchronization（ ） ： ， ，
- **Broadcast（ ） ： ， ， ，
**④ JAVA版ZAB协议**
- **Fast Leader Election**：
前面提到 FLE 会选举拥有最新提议历史（ ） ，
- 选epoch最大的
- epoch相等，
- epoch和zxid都相等， （ ）
- **Recovery Phase**： ， ：
- **Broadcast Phase**：暂无
## ZK选举过程
最开始集群启动时，
当Leader崩溃或者Leader失去大多数的Follower， ， ， ：
- 选举线程由当前Server发起选举的线程担任， ，
- 选举线程首先向所有Server发起一次询问（ ）
- 选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)， ， ，
- 收到所有Server回复以后， ，
- 线程将当前zxid最大的Server设置为当前Server要推荐的Leader， ， ， ， ， ，
**分析结论**
要使Leader获得多数Server的支持， ， ，
## Zookeeper安装
### 单机模式
**第一步：安装部署**
```shell
# 下载解压
wget http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.9/zookeeper-3.4.9.tar.gz
tar -zxvf zookeeper-3.4.9.tar.gz
# 设置全局变量
vim ~/.bash_profile
# 最后一行加入
export ZOOKEEPER_HOME=/home/zookeeper/zookeeper-3.4.9
export PATH=$ZOOKEEPER_HOME/bin:$PATH
# 使之生效
source ~/.bash_profile
# 复制配置文件
cp /home/zookeeper/zookeeper-3.4.9/conf/zoo_sample.cfg /home/zookeeper/zookeeper-3.4.9/conf/zoo.cfg
```
**第二步：配置信息**
```shell
# 心跳间隔
tickTime=2000
# 保存数据目录
dataDir=/home/zookeeper/zookeeper-3.4.9/dataDir
# 保存日志目录
dataLogDir=/home/zookeeper/zookeeper-3.4.9/dataLogDir
# 客户端连接Zookeeper的端口
clientPort=2181
# 允许follower连接并同步到leader的初始化连接时间(心跳倍数)，超过则连接失败
initLimit=5
# 表示leader和follower之间发送消息时, 请求和应答的最大时间长度
syncLimit=2
```
### 集群模式
**第一步：安装部署**
安装方式参考单机模式。
**第二步：配置信息**
在dataDir根目录下新建myid文件， ：
```shell
# 1表示当前集群的id号
echo "1" > myid
```
在单机配置情况下，新增下述参数：
```shell
# 格式：
# X表示myid(范围1~255)
# A是该server所在的IP地址
# B配置该server和集群中的leader交换消息所使用的端口,即数据同步端口
# C配置选举leader时所使用的端口
server.1=10.24.1.62:2888:3888
server.2=10.24.1.63:2888:3888
server.3=10.24.1.64:2888:3888
```
### 运维命令
```shell
# 启动ZK服务器
./zkServer.sh start
# 使用ZK Client连接指定服务器
./zkCli.sh -server 127.0.0.1:2181
# 查看ZK服务状态
./zkServer.sh status
# 停止ZK服务
./zkServer.sh stop
# 重启ZK服务
./zkServer.sh restart
```
### zoo.cfg配置参数
```shell
# 客户端连接server的端口，
clientPort=2181
# 存储快照文件snapshot的目录
dataDir=/User/lry/zookeeper/data
# ZK中的最小时间单元，
tickTime=5000
# 事务日志输出目录
dataLogDir=/User/lry/zookeeper/datalog
# Server端最大允许的请求堆积数，
globalOutstandingLimit=1000
# 每个事务日志文件的大小，
preAllocSize=64
# 每进行snapCount次事务日志输出后，
snapCount=100000
# 单个客户端与单台服务器之间的连接数的限制， ， ， ，
maxClientCnxns=60
# 对于多网卡的机器，
clientPortAddress=10.24.22.56
# Session超时时间限制， ，
minSessionTimeoutmaxSessionTimeout
# Follower在启动过程中， ，
initLimit
# 在运行过程中， ， ， ， ，
syncLimit
# 默认情况下， ， ， ， ， ，
leaderServes=yes
# server.[myid]=[hostname]:[数据同步和其它通讯端口]:[选举投票通讯]
server.x=[hostname]:nnnnn[:nnnnn]
# 对机器分组和权重设置
group.x=nnnnn[:nnnnn]weight.x=nnnnn
# Leader选举过程中， ，
cnxTimeout
# 每个节点最大数据量，
jute.maxbuffer
```
# Netty
## Netty流程
从功能上，流程可以分为服务启动、建立连接、读取数据、业务处理、发送数据、关闭连接以及关闭服务。整体流程如下所示(图中没有包含关闭的部分)：
## 处理事件
Netty中Reactor线程和worker线程所处理的事件：
1、Server端NioEventLoop处理的事件：
2、Client端NioEventLoop处理的事件
### 服务启动
服务启动时，以 example 代码中的 EchoServer 为例，启动的过程以及相应的源码类如下：
1. `EchoServer#new NioEventLoopGroup(1)->NioEventLoop#provider.openSelector()` : 创建 selector
2. `EchoServer#b.bind(PORT).sync->AbstractBootStrap#doBind()->initAndRegister()-> channelFactory.newChannel() / init(channel)` : 创建 serverSocketChannel 以及初始化
3. `EchoServer#b.bind(PORT).sync->AbstractBootStrap#doBind()->initAndRegister()-> config().group().register(channel)` ：从 boss group 中选择一个 NioEventLoop 开始注册 serverSocketChannel
4. `EchoServer#b.bind(PORT).sync->AbstractBootStrap#doBind()->initAndRegister()->config().group().register(channel)->AbstractChannel#register0(promise)->AbstractNioChannel#javaChannel().register(eventLoop().unwrappedSelector(), 0, this)` : 将 server socket channel 注册到选择的 NioEventLoop 的 selector
5. `EchoServer#b.bind(PORT).sync()->AbstractBootStrap#doBind()->doBind0()->AbstractChannel#doBind(localAddress)->NioServerSocketChannel#javaChannel().bind(localAddress, config.getBacklog())` : 绑定地址端口开始启动
6. `EchoServer#b.bind(PORT).sync()->AbstractBootStrap#doBind()->doBind0()->AbstractChannel#pipeline.fireChannelActive()->AbstractNioChannel#selectionKey.interestOps(interestOps|readInterestOp)` : 注册 OP_READ 事件
上述启动流程中， ， ， ：
### 建立连接
服务启动后便是建立连接的过程了，相应过程及源码类如下：
1. `NioEventLoop#run()->processSelectedKey()` NioEventLoop 中的 selector 轮询创建连接事件（ ）
2. `NioEventLoop#run()->processSelectedKey()->AbstractNioMessageChannel#read->NioServerSocketChannel#doReadMessages()->SocketUtil#accept(serverSocketChannel)` 创建 socket channel
3. `NioEventLoop#run()->processSelectedKey()->AbstractNioMessageChannel#fireChannelRead->ServerBootstrap#ServerBootstrapAcceptor#channelRead-> childGroup.register(child)` 从worker group 中选择一个 NioEventLoop 开始注册 socket channel
4. `NioEventLoop#run()->processSelectedKey()->AbstractNioMessageChannel#fireChannelRead->ServerBootstrap#ServerBootstrapAcceptor#channelRead-> childGroup.register(child)->AbstractChannel#register0(promise)-> AbstractNioChannel#javaChannel().register(eventLoop().unwrappedSelector(), 0, this)` 将 socket channel 注册到选择的 NioEventLoop 的 selector
5. `NioEventLoop#run()->processSelectedKey()->AbstractNioMessageChannel#fireChannelRead->ServerBootstrap#ServerBootstrapAcceptor#channelRead-> childGroup.register(child)->AbstractChannel#pipeline.fireChannelActive()-> AbstractNioChannel#selectionKey.interestOps(interestOps | readInterestOp)` 注册 OP_ACCEPT 事件
同样，上述流程中 1、2、3 的执行仍由 Boss Thread 执行，直到 4、5 由具体的 Work Thread 执行。
### 读写与业务处理
连接建立完毕后是具体的读写，以及业务处理逻辑。以 EchoServerHandler 为例，读取数据后会将数据传播出去供业务逻辑处理，此时的 EchoServerHandler 代表我们的业务逻辑，而它的实现也非常简单，就是直接将数据写回去。我们将这块看成一个整条，流程如下：
1. `NioEventLoop#run()->processSelectedKey() NioEventLoop 中的 selector` 轮询创建读取事件（ ）
2. `NioEventLoop#run()->processSelectedKey()->AbstractNioByteChannel#read()` nioSocketChannel 开始读取数据
3. `NioEventLoop#run()->processSelectedKey()->AbstractNioByteChannel#read()->pipeline.fireChannelRead(byteBuf)` 把读取到的数据传播出去供业务处理
4. `AbstractNioByteChannel#pipeline.fireChannelRead->EchoServerHandler#channelRead` 在这个例子中即 EchoServerHandler 的执行
5. `EchoServerHandler#write->ChannelOutboundBuffer#addMessage` 调用 write 方法
6. `EchoServerHandler#flush->ChannelOutboundBuffer#addFlush` 调用 flush 准备数据
7. `EchoServerHandler#flush->NioSocketChannel#doWrite` 调用 flush 发送数据
在这个过程中读写数据都是由 Work Thread 执行的，但是业务处理可以由我们自定义的线程池来处理，并且一般我们也是这么做的，默认没有指定线程的情况下仍然由 Work Thread 代为处理。
### 关闭连接
服务处理完毕后，单个连接的关闭是什么样的呢？
1. `NioEventLoop#run()->processSelectedKey()` NioEventLoop 中的 selector 轮询创建读取事件（
2. `NioEventLoop#run()->processSelectedKey()->AbstractNioByteChannel#read()->closeOnRead(pipeline)` 当字节< 0 时开始执行关闭 nioSocketChannel
3. `NioEventLoop#run()->processSelectedKey()->AbstractNioByteChannel#read()->closeOnRead(pipeline)->AbstractChannel#close->AbstractNioChannel#doClose()` 关闭 socketChannel
4. `NioEventLoop#run()->processSelectedKey()->AbstractNioByteChannel#read()->closeOnRead(pipeline)->AbstractChannel#close->outboundBuffer.failFlushed/close` 清理消息： ，
5. `NioEventLoop#run()->processSelectedKey()->AbstractNioByteChannel#read()->closeOnRead(pipeline)->AbstractChannel#close->fireChannelInactiveAndDeregister->AbstractNioChannel#doDeregister eventLoop().cancel(selectionKey())` 关闭多路复用器的 key
时序图如下：
### 关闭服务
最后是关闭整个 Netty 服务：
1. `NioEventLoop#run->closeAll()->selectionKey.cancel/channel.close` 关闭 channel，
2. `NioEventLoop#run->confirmShutdown->cancelScheduledTasks` 取消定时任务
3. `NioEventLoop#cleanup->selector.close()` 关闭 selector
时序图如下，为了好画将 NioEventLoop 拆成了 2 块：
## 长连接优化
### 更多连接
### 更高QPS
## 线程模型
Netty通过Reactor模型基于多路复用器接收并处理用户请求， ， ， ， ， ， ， ，
### 单线程Reactor线程模型
下图演示了单线程reactor线程模型， ， ， ， ， ， ， ，
特别的， ， ， ， ，
### 多线程Reactor线程模型
所谓多线程reactor线程模型， ，
### 混合型Reactor线程模型
混合型reactor线程模型， ：
- 将任务处理切分成多个阶段进行，每个阶段处理完自己的部分之后，转发到下一个阶段进行处理。不同的阶段之间的执行是异步的，可以认为每个阶段都有一个独立的线程池。
- 不同的类型的任务，有着不同的处理流程，划分时需要划分成不同的阶段。如下图蓝色是一种任务、绿色是另一种任务，两种任务有着不同的执行流程
### Netty-Reactor线程模型
图中大致包含了5个步骤， ， ， ：
- 设置服务端ServerBootStrap启动参数
- 通过ServerBootStrap的bind方法启动服务端， ，
- Client发起连接CONNECT请求， ， ，
- ACCEPT事件触发后， ，
- childGroup中的NioEventLoop不断检测自己管理的NioSocketChannel是否有读写事件准备好， ，
## HashedWheelTimer
时间轮其实就是一种环形的数据结构，可以想象成时钟，分成很多格子，一个格子代表一段时间。并用一个链表保存在该格子上的计划任务，同时一个指针随着时间一格一格转动，并执行相应格子中的所有到期任务。任务通过时间取模决定放入那个格子。
在网络通信中管理上万的连接， ， ， ，
Netty 的时间轮 `HashedWheelTimer` 给出了一个**粗略的定时器实现**，之所以称之为粗略的实现是**因为该时间轮并没有严格的准时执行定时任务**，而是在每隔一个时间间隔之后的时间节点执行，并执行当前时间节点之前到期的定时任务。
当然具体的定时任务的时间执行精度可以通过调节 HashedWheelTimer 构造方法的时间间隔的大小来进行调节，在大多数网络应用的情况下，由于 IO 延迟的存在，并**不会严格要求具体的时间执行精度**，所以默认的 100ms 时间间隔可以满足大多数的情况，不需要再花精力去调节该时间精度。
**HashedWheelTimer的特点**
- 从源码分析可以看出，其实 HashedWheelTimer 的时间精度并不高，误差能够在 100ms 左右，同时如果任务队列中的等待任务数量过多，可能会产生更大的误差
- 但是 HashedWheelTimer 能够处理非常大量的定时任务，且每次定位到要处理任务的候选集合链表只需要 O(1) 的时间，而 Timer 等则需要调整堆，是 O(logN) 的时间复杂度
- HashedWheelTimer 本质上是`模拟了时间的轮盘`，将大量的任务拆分成了一个个的小任务列表，能够有效`节省 CPU 和线程资源`
### 源码解读
```java
public HashedWheelTimer(ThreadFactory threadFactory, long tickDuration, TimeUnit unit,
int ticksPerWheel, boolean leakDetection, long maxPendingTimeouts) {
......
}
```
- `threadFactory` ：自定义线程工厂，用于创建线程对象
- `tickDuration` ：间隔多久走到下一槽（相当于时钟走一格）
- `unit` ：
- `ticksPerWheel` ：一圈有多个槽
- `leakDetection` ：是否开启内存泄漏检测
- `maxPendingTimeouts` ：
### 优缺点
- **优点**
- 可以添加、删除、取消定时任务
- 能高效的处理大批定时任务
- **缺点**
- 对内存要求较高，占用较高的内存
- 时间精度要求不高
### 定时任务方案
目前主流的一些定时任务方案：
- Timer
- ScheduledExecutorService
- ThreadPoolTaskScheduler（ ）
- Netty的schedule（ ）
- Netty的HashedWheelTimer（ ）
- Kafka的TimingWheel（ ）
### 使用案例
```java
// 构造一个 Timer 实例
Timer timer = new HashedWheelTimer();
// 提交一个任务，让它在 5s 后执行
Timeout timeout1 = timer.newTimeout(new TimerTask() {
@Override
public void run(Timeout timeout) {
System.out.println("5s 后执行该任务");
}
}, 5, TimeUnit.SECONDS);
// 再提交一个任务，让它在 10s 后执行
Timeout timeout2 = timer.newTimeout(new TimerTask() {
@Override
public void run(Timeout timeout) {
System.out.println("10s 后执行该任务");
}
}, 10, TimeUnit.SECONDS);
// 取消掉那个 5s 后执行的任务
if (!timeout1.isExpired()) {
timeout1.cancel();
}
// 原来那个 5s 后执行的任务，已经取消了。这里我们反悔了，我们要让这个任务在 3s 后执行
// 我们说过 timeout 持有上、下层的实例，所以下面的 timer 也可以写成 timeout1.timer()
timer.newTimeout(timeout1.task(), 3, TimeUnit.SECONDS);
```
## ByteBuf
### 工作流程
ByteBuf维护两个不同的索引： `写索引(writerIndex)` 。如下图所示:
- `ByteBuf` 维护了 `readerIndex` 和 `writerIndex` 索引
- 当 `readerIndex > writerIndex` 时，则抛出 `IndexOutOfBoundsException`
- `ByteBuf` 容量 = `writerIndex`
- `ByteBuf` 可读容量 = `writerIndex` - `readerIndex`
- `readXXX()` 和 `writeXXX()` 方法将会推进其对应的索引。自动推进
- `getXXX()` 和 `setXXX()` 方法将对 `writerIndex` 和 `readerIndex` 无影响
### 使用模式
ByteBuf本质是一个由不同的索引分别控制读访问和写访问的字节数组。ByteBuf共有三种模式： `复合缓冲区模式(Composite Buffer)` 。
#### 堆缓冲区模式(Heap Buffer)
堆缓冲区模式又称为`支撑数组(backing array)`。将数据存放在JVM的堆空间，
- **优点**： ，
- **缺点**： ，
```java
public static void heapBuffer() {
// 创建Java堆缓冲区
ByteBuf heapBuf = Unpooled.buffer();
if (heapBuf.hasArray()) { // 是数组支撑
byte[] array = heapBuf.array();
int offset = heapBuf.arrayOffset() + heapBuf.readerIndex();
int length = heapBuf.readableBytes();
handleArray(array, offset, length);
}
}
```
#### 直接缓冲区模式(Direct Buffer)
Direct Buffer属于堆外分配的直接内存， ， ， ，
- **优点**: 使用Socket传递数据时性能很好，
- **缺点**: 相对于堆缓冲区而言，
```java
public static void directBuffer() {
ByteBuf directBuf = Unpooled.directBuffer();
if (!directBuf.hasArray()) {
int length = directBuf.readableBytes();
byte[] array = new byte[length];
directBuf.getBytes(directBuf.readerIndex(), array);
handleArray(array, 0, length);
}
}
```
#### 复合缓冲区模式(Composite Buffer)
Composite Buffer是Netty特有的缓冲区。本质上类似于提供一个或多个ByteBuf的组合视图，
- Composite Buffer是一个组合视图。它提供一种访问方式让使用者自由组合多个ByteBuf，
- Composite Buffer不支持访问其支撑数组。因此如果要访问， ，
下图是将两个ByteBuf：
```java
public static void byteBufComposite() {
// 复合缓冲区，只是提供一个视图
CompositeByteBuf messageBuf = Unpooled.compositeBuffer();
ByteBuf headerBuf = Unpooled.buffer(); // can be backing or direct
ByteBuf bodyBuf = Unpooled.directBuffer(); // can be backing or direct
messageBuf.addComponents(headerBuf, bodyBuf);
messageBuf.removeComponent(0); // remove the header
for (ByteBuf buf : messageBuf) {
System.out.println(buf.toString());
}
}
```
### 字节级操作
#### 随机访问索引
ByteBuf的索引与普通的Java字节数组一样。第一个字节的索引是0， ：
- readXXX()和writeXXX()方法将会推进其对应的索引readerIndex和writerIndex。自动推进
- getXXX()和setXXX()方法用于访问数据，
```java
public static void byteBufRelativeAccess() {
ByteBuf buffer = Unpooled.buffer(); // get reference form somewhere
for (int i = 0; i < buffer.capacity ( ) ; i + + ) {
byte b = buffer.getByte(i); // 不改变readerIndex值
System.out.println((char) b);
}
}
```
#### 顺序访问索引
Netty的ByteBuf同时具有读索引和写索引， ， ： ** 可写字节区域** 。
#### 可丢弃字节区域
可丢弃字节区域是指：[0，
- discardReadBytes()效果 ----- 将可读字节区域(CONTENT)[readerIndex, writerIndex)往前移动readerIndex位，
- discardReadBytes()方法会移动可读字节区域内容(CONTENT)。如果频繁调用，会有多次数据复制开销，对性能有一定的影响
#### 可读字节区域
可读字节区域是指:[readerIndex, writerIndex)之间的区域。任何名称以read和skip开头的操作方法，
#### 可写字节区域
可写字节区域是指:[writerIndex, capacity)之间的区域。任何名称以write开头的操作方法都将改变writerIndex的值。
#### 索引管理
- markReaderIndex()+resetReaderIndex() ----- markReaderIndex()是先备份当前的readerIndex， ，
- readerIndex(int) ----- 设置readerIndex为固定的值
- writerIndex(int) ----- 设置writerIndex为固定的值
- clear() ----- 效果是: readerIndex=0, writerIndex(0)。不会清除内存
- 调用clear()比调用discardReadBytes()轻量的多。仅仅重置readerIndex和writerIndex的值， ，
#### 查找操作(indexOf)
查找ByteBuf指定的值。类似于，
- 最简单的方法 —— indexOf()
- 利用ByteProcessor作为参数来查找某个指定的值
```java
public static void byteProcessor() {
ByteBuf buffer = Unpooled.buffer(); //get reference form somewhere
// 使用indexOf()方法来查找
buffer.indexOf(buffer.readerIndex(), buffer.writerIndex(), (byte)8);
// 使用ByteProcessor查找给定的值
int index = buffer.forEachByte(ByteProcessor.FIND_CR);
}
```
#### 派生缓冲——视图
派生缓冲区为ByteBuf提供了一个访问的视图。视图仅仅提供一种访问操作， ， ，
- duplicate()
- slice()
- slice(int, int)
- Unpooled.unmodifiableBuffer(...)
- Unpooled.wrappedBuffer(...)
- order(ByteOrder)
- readSlice(int)
**理解**
- 上面的6中方法， ， ，
- 请注意： ， ，
- 如果需要拷贝现有缓冲区的真实副本，
- 使用派生缓冲区，避免了复制内存的开销，有效提高程序的性能
```java
public static void byteBufSlice() {
Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);
ByteBuf sliced = buf.slice(0, 15);
System.out.println(sliced.toString(utf8));
buf.setByte(0, (byte)'J');
assert buf.getByte(0) == sliced.getByte(0); // return true
}
public static void byteBufCopy() {
Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);
ByteBuf copy = buf.copy(0, 15);
System.out.println(copy.toString(utf8));
buf.setByte(0, (byte)'J');
assert buf.getByte(0) != copy.getByte(0); // return true
}
```
#### 读/写操作
如上文所提到的，有两种类别的读/写操作:
- get()和set()操作 ----- 从给定的索引开始，并且保持索引不变
- read()和write()操作 ----- 从给定的索引开始，并且根据已经访问过的字节数对索引进行访问
- 下图给出get()操作API，
#### 更多操作
下面的两个方法操作字面意思较难理解，给出解释:
- **hasArray()**： ， ： ，
- **array()**： ， ，
### ByteBuf分配
创建和管理ByteBuf实例的多种方式： **ByteBufUtil类** 。
#### 按序分配：
Netty通过接口ByteBufAllocator实现了(ByteBuf的)池化。Netty提供池化和非池化的ButeBufAllocator:
- `ctx.channel().alloc().buffer()` ：
- `ByteBufAllocator.DEFAULT.buffer()` ：
- `ByteBufAllocator.DEFAULT` ：有两种类型: UnpooledByteBufAllocator.DEFAULT(非池化)和PooledByteBufAllocator.DEFAULT(池化)。对于Java程序， ，
- 可以通过BootStrap中的Config为每个Channel提供独立的ByteBufAllocator实例
解释:
- 上图中的buffer()方法，
- ByteBufAllocator.DEFAULT ----- 可能是池化，也可能是非池化。默认是池化(PooledByteBufAllocator.DEFAULT)
#### Unpooled缓冲区——非池化
Unpooled提供静态的辅助方法来创建未池化的ByteBuf。
注意:
- 上图的buffer()方法，
- wrappedBuffer() ----- 创建一个视图，
创建ByteBuf代码:
```java
public void createByteBuf(ChannelHandlerContext ctx) {
// 1. 通过Channel创建ByteBuf
ByteBuf buf1 = ctx.channel().alloc().buffer();
// 2. 通过ByteBufAllocator.DEFAULT创建
ByteBuf buf2 = ByteBufAllocator.DEFAULT.buffer();
// 3. 通过Unpooled创建
ByteBuf buf3 = Unpooled.buffer();
}
```
#### ByteBufUtil类
ByteBufUtil类提供了用于操作ByteBuf的静态的辅助方法: hexdump()和equals
- hexdump()：
- equals()：
### 引用计数
Netty4.0版本中为ButeBuf和ButeBufHolder引入了引用计数技术。请区别引用计数和可达性分析算法(jvm垃圾回收)
- 谁负责释放：一般来说，是由最后访问(引用计数)对象的那一方来负责将它释放
- buffer.release()：
- buffer.retain()：
- buffer.refCnt()：返回当前对象引用计数值
- buffer.touch()：记录当前对象的访问位置，主要用于调试
- 引用计数并非仅对于直接缓冲区(direct Buffer)。ByteBuf的三种模式: 堆缓冲区(heap Buffer)、直接缓冲区(dirrect Buffer)和复合缓冲区(Composite Buffer)都使用了引用计数，某些时候需要程序员手动维护引用数值
```java
public static void releaseReferenceCountedObject(){
ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer();
// 引用计数加1
buffer.retain();
// 输出引用计数
buffer.refCnt();
// 引用计数减1
buffer.release();
}
```
## Zero-Copy
**Netty** 的`Zero-copy` 体现在如下几个个方面:
- **通过CompositeByteBuf实现零拷贝**： ， ，
- **通过wrap操作实现零拷贝**：通过`wrap`操作， ，
- 通过slice操作实现零拷贝： ， ，
- **通过FileRegion实现零拷贝**：通过 `FileRegion` 包装的`FileChannel.tranferTo` 实现文件传输，可以直接将文件缓冲区的数据发送到目标 Channel，
### 零拷贝操作
#### 通过CompositeByteBuf实现零拷贝
```java
ByteBuf header = null;
ByteBuf body = null;
// 传统合并header和body：
ByteBuf allBuf = Unpooled.buffer(header.readableBytes() + body.readableBytes());
allBuf.writeBytes(header);
allBuf.writeBytes(body);
// 合并header和body：
CompositeByteBuf compositeByteBuf = Unpooled.compositeBuffer();
compositeByteBuf.addComponents(true, header, body);
// 底层封装了 CompositeByteBuf 操作
ByteBuf allByteBuf = Unpooled.wrappedBuffer(header, body);
```
#### 通过wrap操作实现零拷贝
```java
byte[] bytes = null;
// 传统方式：
ByteBuf byteBuf = Unpooled.buffer();
byteBuf.writeBytes(bytes);
// wrap方式：
// 即最后我们生成的生成的ByteBuf对象是和bytes数组共用了同一个存储空间, 对bytes的修改也会反映到ByteBuf对象中
ByteBuf byteBuf = Unpooled.wrappedBuffer(bytes);
```
#### 通过slice操作实现零拷贝
slice 操作和 wrap 操作刚好相反,`Unpooled.wrappedBuffer` 可以将多个 ByteBuf 合并为一个, 而 slice 操作可以将一个 **ByteBuf ** `切片` 为多个共享一个存储区域的 ByteBuf 对象. ByteBuf 提供了两个 slice 操作方法:
```java
public ByteBuf slice();
public ByteBuf slice(int index, int length);
```
不带参数的`slice`方法等同于`buf.slice(buf.readerIndex(), buf.readableBytes())` 调用, 即返回 buf 中可读部分的切片. 而 `slice(int index, int length)` 方法相对就比较灵活了, 我们可以设置不同的参数来获取到 buf 的不同区域的切片。
用 `slice` 方法产生 header 和 body 的过程是没有拷贝操作的, header 和 body 对象在内部其实是共享了 byteBuf 存储空间的不同部分而已，即：
#### 通过FileRegion实现零拷贝
Netty 中使用 FileRegion 实现文件传输的零拷贝, 不过在底层 FileRegion 是依赖于 **Java NIO** `FileChannel.transfer` 的零拷贝功能。当有了 FileRegion 后, 我们就可以直接通过它将文件的内容直接写入 **Channel** 中, 而不需要像传统的做法: 拷贝文件内容到临时 **buffer** , 然后再将 **buffer** 写入 **Channel.** 通过这样的零拷贝操作, 无疑对传输大文件很有帮助。
### 传统IO的流程
- **「第一步」**：将文件通过 ** 「DMA」** 技术从磁盘中拷贝到内核缓冲区
- **「第二步」**：将文件从内核缓冲区拷贝到用户进程缓冲区域中
- **「第三步」**：将文件从用户进程缓冲区中拷贝到 socket 缓冲区中
- **「第四步」**： ** 「DMA」** 技术拷贝到网卡
### 零拷贝整体流程图
## TCP粘包拆包
### 粘包拆包图解
假设客户端分别发送了两个数据包D1和D2给服务端， ， ：
- 服务端分两次读取到两个独立的数据包， ，
- 服务端一次接收到了两个数据包， ，
- 服务端分两次读取到数据包， ， ，
- 服务端分两次读取到数据包， ，
- 当TCP缓存再小一点的话，
### 产生原因
产生粘包和拆包问题的主要原因是， ， ， ：
- 如果一次请求发送的数据量比较小， ， ，
- 如果一次请求发送的数据量比较大， ， ， ，
### 解决方案
#### 固定长度
对于使用固定长度的粘包和拆包场景，可以使用：
- `FixedLengthFrameDecoder` ：每次读取固定长度的消息，如果当前读取到的消息不足指定长度，那么就会等待下一个消息到达后进行补足。其使用也比较简单，只需要在构造函数中指定每个消息的长度即可。
```java
@Override
protected void initChannel(SocketChannel ch) throws Exception {
// 这里将FixedLengthFrameDecoder添加到pipeline中，
ch.pipeline().addLast(new FixedLengthFrameDecoder(20));
// 将前一步解码得到的数据转码为字符串
ch.pipeline().addLast(new StringDecoder());
// 这里FixedLengthFrameEncoder是我们自定义的，
ch.pipeline().addLast(new FixedLengthFrameEncoder(20));
// 最终的数据处理
ch.pipeline().addLast(new EchoServerHandler());
}
```
#### 指定分隔符
对于通过分隔符进行粘包和拆包问题的处理， ：
- `LineBasedFrameDecoder` ：通过换行符，即`\n`或者` \r\n`对数据进行处理
- `DelimiterBasedFrameDecoder` ：通过用户指定的分隔符对数据进行粘包和拆包处理
```java
@Override
protected void initChannel(SocketChannel ch) throws Exception {
String delimiter = "_$";
// 将delimiter设置到DelimiterBasedFrameDecoder中， ，
// 被按照_$进行分隔， ， ，
// 读取到分隔符，则舍弃当前数据段，因为其很有可能是由于码流紊乱造成的
ch.pipeline().addLast(new DelimiterBasedFrameDecoder(1024,
Unpooled.wrappedBuffer(delimiter.getBytes())));
// 将分隔之后的字节数据转换为字符串数据
ch.pipeline().addLast(new StringDecoder());
// 这是我们自定义的一个编码器，主要作用是在返回的响应数据最后添加分隔符
ch.pipeline().addLast(new DelimiterBasedFrameEncoder(delimiter));
// 最终处理数据并且返回响应的handler
ch.pipeline().addLast(new EchoServerHandler());
}
```
#### 数据包长度字段
处理粘拆包的主要思想是在生成的数据包中添加一个长度字段，用于记录当前数据包的长度。
- `LengthFieldBasedFrameDecoder` ：按照参数指定的包长度偏移量数据对接收到的数据进行解码，从而得到目标消息体数据。解码过程如下图所示：
- `LengthFieldPrepender` ：在响应的数据前面添加指定的字节数据，这个字节数据中保存了当前消息体的整体字节数据长度。编码过程如下图所示：
```java
@Override
protected void initChannel(SocketChannel ch) throws Exception {
// 这里将LengthFieldBasedFrameDecoder添加到pipeline的首位，
// 进行长度字段解码，这里也会对数据进行粘包和拆包处理
ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(1024, 0, 2, 0, 2));
// LengthFieldPrepender是一个编码器，
ch.pipeline().addLast(new LengthFieldPrepender(2));
// 对经过粘包和拆包处理之后的数据进行json反序列化，
ch.pipeline().addLast(new JsonDecoder());
// 对响应数据进行编码，
ch.pipeline().addLast(new JsonEncoder());
// 处理客户端的请求的数据，并且进行响应
ch.pipeline().addLast(new EchoServerHandler());
}
```
#### 自定义粘包拆包器
可以通过实现`MessageToByteEncoder`和`ByteToMessageDecoder`来实现自定义粘包和拆包处理的目的。
- `MessageToByteEncoder` ：
- `ByteToMessageDecoder` ：
## 高性能
- **IO线程模型**：同步非阻塞，用最少的资源做更多的事
- **内存零拷贝**：尽量减少不必要的内存拷贝，实现了更高效率的传输
- **内存池设计**：申请的内存可以重用，主要指直接内存。内部实现是用一颗二叉查找树管理内存分配情况
- **串形化处理读写**：避免使用锁带来的性能开销
- **高性能序列化协议**：支持 protobuf 等高性能序列化协议
## 操作系统调优
### 文件描述符
- 设置系统最大文件句柄数
```bash
# 查看
cat /proc/sys/fs/file-max
# 修改
在/etc/sysctl.conf插入fs.file-max=1000000
# 配置生效
sysctl -p
```
- 设置单进程打开的最大句柄数
默认单进程打开的最大句柄数是 `1024` ，通过 `ulimit -a` 可以查看相关参数，示例如下：
```powershell
[root@test ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 256324
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
......
```
当并发接入的TCP连接数超过上限时， ， `vi /etc/security/limits.conf` 命令添加如下配置参数：
```powershell
* soft nofile 1000000
* hard nofile 1000000
```
修改之后保存，注销当前用户，重新登录，通过 `ulimit -a` 查看修改的状态是否生效。
**注意**：尽管我们可以将单个进程打开的最大句柄数修改的非常大，但是当句柄数达到一定数量级之后，处理效率将出现明显下降，因此，需要根据服务器的硬件配置和处理能力进行合理设置。
### TCP/IP相关参数
需要重点调优的TCP IP参数如下：
- net.ipv4.tcp_rmem：
### 多网卡队列和软中断
- **TCP缓冲区**
根据推送消息的大小，合理设置以下两个参数，对于海量长连接，通常 32K 是个不错的选择：
- **SO_SNDBUF**：发送缓冲区大小
- **SO_RCVBUF**：接收缓冲区大小
- **软中断**
使用命令 `cat /proc/interrupts` 查看网卡硬件中断的运行情况， ， ， ， ， ： ， ， ， ，
## Netty性能调优
### 设置合理的线程数
**boss线程池优化**
对于Netty服务端， ， ， ， ， ， ， ， ， ， ， ，
**work线程池优化(I/O工作线程池)**
对于I/O工作线程池的优化， （ ） ， ， ， ：
- 通过执行 `ps -ef|grep java` 找到服务端进程pid
- 执行`top -Hp pid`查询该进程下所有线程的运行情况， ，
- 使用`printf'%x\n' pid`将pid转换成16进制格式
- 通过`jstack -f pid`命令获取线程堆栈， ， ， ， ：
**分析**
- 如果连续采集几次进行对比， ， ，
- 如果发现I/O线程的热点停留在读或写操作， ， ：
- 接口API指定：
- 系统参数指定：通过-Dio.netty.eventLoopThreads来指定NioEventLoopGroup线程池（ ）
### 心跳检测优化
心跳检测的目的就是确认当前链路是否可用，对方是否活着并且能够正常接收和发送消息。从技术层面看，要解决链路的可靠性问题，必须周期性地对链路进行有效性检测。目前最流行和通用的做法就是心跳检测。
**海量设备接入的服务端心跳优化策略**
- **要能够及时检测失效的连接，并将其剔除**。防止无效的连接句柄积压，
- **设置合理的心跳周期**。防止心跳定时任务积压， （ ， ） ，
- **使用Nety提供的链路空闲检测机制**。不要自己创建定时任务线程池，加重系统的负担，以及增加潜在的并发安全问题
**心跳检测机制分为三个层面**
- **TCP层的心跳检测**： ，
- **协议层的心跳检测**： ，
- **应用层的心跳检测**：它主要由各业务产品通过约定方式定时给对方发送心跳消息实现
**心跳检测机制分类**
- **Ping-Pong型心跳**： ， ，
- **Ping-Ping型心跳**： ， ，
**心跳检测机制策略**
- **心跳超时**： ，
- **心跳失败**： ， ，
**链路空闲检测机制**
- **读空闲**：
- **写空闲**：
- **读写空闲**：
**案例分析**
由于移动无线网络的特点， ， ， ， ， （ ） ，
在 Netty 中，可以通过在 ChannelPipeline 中增加 IdleStateHandler 的方式实现心跳检测，在构造函数中指定链路空闲时间，然后实现空闲回调接口，实现心跳的发送和检测。拦截链路空闲事件并处理心跳：
```java
public class MyHandler extends ChannelHandlerAdapter {
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
if (evt instanceof IdleStateEvent) {
// 心跳处理
}
}
}
```
**心跳优化结论**
- 对于百万级的服务器，一般不建议很长的心跳周期和超时时长
- 心跳检测周期通常不要超过60s，
- 建议通过IdleStateHandler实现心跳， ，
- 发生心跳超时或心跳失败时，都需要关闭链路，由客户端发起重连操作，保证链路能够恢复正常
- 链路空闲事件被触发后并没有关闭链路， ， ，
- 链路空闲检测类库主要包括：
### 接收和发送缓冲区调优
对于长链接， ，
**场景**： ， ， ， ， ， ， ， ×
Netty提供的ByteBuf支持容量动态调整， ：
- **FixedRecvByteBufAllocator**： ， ， ，
- **AdaptiveRecvByteBufAllocator**： ， ， ， ， ，
相对于FixedRecvByteBufAllocator， ，
```java
Bootstrap b = new Bootstrap();
b.group(group)
.channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.option(ChannelOption.RCVBUF_ALLOCATOR, AdaptiveRecvByteBufAllocator.DEFAULT)
```
**注意**：无论是接收缓冲区还是发送缓冲区，缓冲区的大小建议设置为消息的平均大小，不要设置成最大消息的上限，这会导致额外的内存浪费。
### 合理使用内存池
每个NioEventLoop线程处理N个链路。**链路处理流程**：
如果使用内存池， ， ， ， ， ， （ ）
Netty默认不使用内存池， ：
```java
Bootstrap b = new Bootstrap();
b.group(group)
.channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)
```
使用内存池之后，内存的申请和释放必须成对出现，即 retain() 和 release() 要成对出现，否则会导致内存泄露。值得注意的是，如果使用内存池，完成 ByteBuf 的解码工作之后必须显式的调用 ReferenceCountUtil.release(msg) 对接收缓冲区 ByteBuf 进行内存释放，否则它会被认为仍然在使用中，这样会导致内存泄露。
### 防止I/O线程被意外阻塞
通常情况不能在Netty的I/O线程上做执行时间不可控的操作， ， ，
生产环境中， ， ， ， ， ， ， ， ，
常用的log4j虽然支持异步写日志(AsyncAppender)，但当日志队列满之后，它会同步阻塞业务线程，直到日志队列有空闲位置可用。
类似问题具有极强的隐蔽性， ， ， ，
### I/O线程与业务线程分离
- 如果服务端不做复杂业务逻辑操作， ， ， ， ，
- 如果有复杂的业务逻辑操作，
- 对于I/O线程， ， ，
- 对于后端的业务线程池， ， ， ，
### 服务端并发连接数流控
无论服务端的性能优化到多少， ， ，
## 案例分析
### 疑似内存泄漏
**环境**：
**描述**： ， ， ， ，
**分析**： ， ， ， ， ， ： ， ，
**解决**： ，
### 当心CLOSE_WAIT
由于网络不稳定经常会导致客户端断连，如果服务端没有能够及时关闭 socket， ， ， ， ，
close_wait 是被动关闭连接是形成的，根据 TCP 状态机，服务器端收到客户端发送的 FIN， ， ，
导致 close_wait 过多的可能原因如下：
- **程序处理Bug**：导致接收到对方的 fin 之后没有及时关闭 socket， ， ，
- **关闭socket不及时**：例如 I/O 线程被意外阻塞，或者 I/O 线程执行的用户自定义 Task 比例过高，导致 I/O 操作处理不及时，链路不能被及时释放
**解决方案**
- **不要在 Netty 的 I/O 线程（ ） （ ）
- **在I/O线程上执行自定义Task要当心**
- **IdleStateHandler、ReadTimeoutHandler和WriteTimeoutHandler使用要当**
# RabbitMQ
## 模式介绍
在 RabbitMQ 官网上提供了 6 中工作模式：简单模式、工作队列模式、发布/订阅模式、路由模式、主题模式 和 RPC 模式。本篇只对前 5 种工作方式进行介绍。
### 简单模式与工作队列模式
之所以将这两种模式合并在一起介绍，是因为它们工作原理非常简单，由 3 个对象组成：生产者、队列、消费者。
[](http://images.extlight.com/rabbitmq-work-01.png)
生产者负责生产消息，将消息发送到队列中，消费者监听队列，队列有消息就进行消费。
[](http://images.extlight.com/rabbitmq-work-02.png)
当有多个消费者时，消费者平均消费队列中的消息。代码演示：
生产者：
```java
//1.获取连接
Connection connection = ConnectionUtil.getConnection();
//2.创建通道
Channel channel = connection.createChannel();
//3.申明队列
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
//4.发送消息
channel.basicPublish("", QUEUE_NAME, null, "hello simple".getBytes());
System.out.println("发送成功");
//5.释放连接
channel.close();
connection.close();
```
消费者：
```java
// 1.获取连接
Connection connection = ConnectionUtil.getConnection();
// 2.创建通道
Channel channel = connection.createChannel();
// 3.申明队列
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
// 4.监听消息
channel.basicConsume(QUEUE_NAME, true, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
byte[] body) throws IOException {
String message = new String(body, "UTF-8");
System.out.println("接收:" + message);
}
});
```
### 发布/订阅、路由与主题模式
这 3 种模式都使用到交换机。生产者不直接与队列交互，而是将消息发送到交换机中，再由交换机将消息放入到已绑定该交换机的队列中给消费者消费。常用的交换机类型有 3 种： ：
[](http://images.extlight.com/rabbitmq-work-03-1.png)
**fanout**： ，
**其中，发布/订阅模式使用的是 fanout 类型的交换机。**
[](http://images.extlight.com/rabbitmq-work-04-1.png)
**direct**：处理路由键。需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。如果一个队列绑定到该交换机上要求路由键 “dog”， ， ，
**其中，路由模式使用的是 direct 类型的交换机。**
[](http://images.extlight.com/rabbitmq-work-05-1.png)
**topic**：将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。符号 “#” 匹配一个或多个词，符号“\*”匹配不多不少一个词。因此“audit.#” 能够匹配到“audit.irs.corporate”，
**其中，主题模式使用的是 topic 类型的交换机。**代码演示：
生产者：
```java
// 1.获取连接
Connection connection = ConnectionUtil.getConnection();
// 2.创建通道
Channel channel = connection.createChannel();
// 3.申明交换机
channel.exchangeDeclare(EXCHANGE_NAME, "fanout");
// 4.发送消息
for (int i = 0; i < 100 ; i + + ) {
channel.basicPublish(EXCHANGE_NAME, "", null, ("hello ps" + i + "").getBytes());
}
System.out.println("发送成功");
// 5.释放连接
channel.close();
connection.close();
```
多个消费者：
```java
// 1.获取连接
Connection connection = ConnectionUtil.getConnection();
// 2.创建通道
Channel channel = connection.createChannel();
// 3.申明交换机
channel.exchangeDeclare(EXCHANGE_NAME, "fanout");
// 4.队列绑定交换机
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "");
// 5.消费消息
channel.basicQos(1);
channel.basicConsume(QUEUE_NAME, false, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
String message = new String(body, "UTF-8");
System.out.println("recv1:" + message);
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
channel.basicAck(envelope.getDeliveryTag(), false);
}
});
```
# Dubbo
Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架。Apache Dubbo 提供了六大核心能力：**面向接口代理的高性能RPC调用， ， ， ， ，
- **面向接口代理的高性能RPC调用**
提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
- **智能负载均衡**
内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
- **服务自动注册与发现**
支持多种注册中心服务，服务实例上下线实时感知。
- **高度可扩展能力**
遵循微内核+插件的设计原则， ，
- **运行期流量调度**
内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
- **可视化的服务治理与运维**
提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。
# Nacos
## 基本架构
### 服务 (Service)
服务是指一个或一组软件功能（ ） ， （ ）
### 服务注册中心 (Service Registry)
服务注册中心，它是服务，其实例及元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。
### 服务元数据 (Service Metadata)
服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。
### 服务提供方 (Service Provider)
是指提供可复用和可调用服务的应用方。
### 服务消费方 (Service Consumer)
是指会发起对某个服务调用的应用方。
### 配置 (Configuration)
在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，
### 配置管理 (Configuration Management)
在数据中心中，系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。
### 名字服务 (Naming Service)
提供分布式系统中所有对象(Object)、实体(Entity)的“名字”到关联的元数据之间的映射管理服务，例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。
### 配置服务 (Configuration Service)
在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。
## 逻辑架构
- 服务管理： ， ， ，
- 配置管理： ， ， ， ， ，
- 元数据管理：
- 插件机制： ，
- 事件机制： ，
- 日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档
- 回调机制： ，
- 寻址模式： ， ， ，
- 推送通道：
- 容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性
- 流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制
- 缓存机制： ， ，
- 启动模式： ， ， ， ， ，
- 一致性协议：解决不同数据，不同一致性要求情况下，不同一致性机制
- 存储模块：解决数据持久化、非持久化存储，解决数据分片问题
- Nameserver： ，
- CMDB： ， ， ， ，
- Metrics： ，
- Trace： ， ， ， ，
- 接入管理：相当于阿里云开通服务，分配身份、容量、权限过程
- 用户管理： ， ，
- 权限管理：解决身份识别，访问控制，角色管理等问题
- 审计系统：扩展接口方便与不同公司审计系统打通
- 通知系统： ， ， ，
- OpenAPI： ， ，
- Console： ，
- SDK：
- Agent： ，
- CLI： ，
## 功能特性
Nacos 的关键特性包括：
- **服务发现和服务健康监测**
- **动态配置服务**
- **动态 DNS 服务**
- **服务及其元数据管理**
### 数据模型
Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串， （ ） ，
### Nacos-SDK类视图
### 配置领域模型
围绕配置，主要有两个关联的实体，一个是配置变更历史，一个是服务标签（用于打标分类，方便索引），由 ID 关联。
## 安装部署
### 下载源码或者安装包
**从 Github 上下载源码方式**
```bash
git clone https://github.com/alibaba/nacos.git
cd nacos/
mvn -Prelease-nacos -Dmaven.test.skip=true clean install -U
ls -al distribution/target/
// change the $version to your actual path
cd distribution/target/nacos-server-$version/nacos/bin
```
**下载编译后压缩包方式**
您可以从 [最新稳定版本 ](https://github.com/alibaba/nacos/releases ) 下载 `nacos-server-$version.zip` 包。
```bash
unzip nacos-server-$version.zip 或者 tar -xvf nacos-server-$version.tar.gz
cd nacos/bin
```
### 启动服务器
**Linux/Unix/Mac**
启动命令(standalone代表着单机模式运行，
```shell
sh startup.sh -m standalone
```
如果您使用的是ubuntu系统， ， ：
```shell
bash startup.sh -m standalone
```
**Windows**
启动命令(standalone代表着单机模式运行，
```shell
startup.cmd -m standalone
```
### 服务测试
**服务注册**
```shell
curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName& ip=20.18.7.10& port=8080'
```
**服务发现**
```shell
curl -X GET 'http://127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=nacos.naming.serviceName'
```
**发布配置**
```shell
curl -X POST "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=nacos.cfg.dataId& group=test& content=HelloWorld"
```
**获取配置**
```shell
curl -X GET "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=nacos.cfg.dataId& group=test"
```
### 关闭服务器
**Linux/Unix/Mac**
```shell
sh shutdown.sh
```
**Windows**
```shell
shutdown.cmd
```
或者双击 `shutdown.cmd` 运行文件。
## 开源案例
### Spring Boot
#### 启动配置管理
启动了 Nacos server 后，您就可以参考以下示例代码，为您的 Spring Boot 应用启动 Nacos 配置管理服务了。
**第一步**：添加依赖
```xml
< dependency >
< groupId > com.alibaba.boot< / groupId >
< artifactId > nacos-config-spring-boot-starter< / artifactId >
< version > ${latest.version}< / version >
< / dependency >
```
**注意**：版本 [0.2.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.boot/nacos-config-spring-boot-starter ) 对应的是 Spring Boot 2.x 版本，版本 [0.1.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.boot/nacos-config-spring-boot-starter ) 对应的是 Spring Boot 1.x 版本。
**第二步**：在 `application.properties` 中配置 Nacos server 的地址：
```properties
nacos.config.server-addr=127.0.0.1:8848
```
**第三步**：使用 `@NacosPropertySource` 加载 `dataId` 为 `example` 的配置源，并开启自动更新：
```java
@SpringBootApplication
@NacosPropertySource (dataId = "example", autoRefreshed = true)
public class NacosConfigApplication {
public static void main(String[] args) {
SpringApplication.run(NacosConfigApplication.class, args);
}
}
```
**第四步**：通过 Nacos 的 `@NacosValue` 注解设置属性值。
```java
@Controller
@RequestMapping ("config")
public class ConfigController {
@NacosValue (value = "${useLocalCache:false}", autoRefreshed = true)
private boolean useLocalCache;
@RequestMapping (value = "/get", method = GET)
@ResponseBody
public boolean get() {
return useLocalCache;
}
}
```
**第五步**：启动 `NacosConfigApplication` ，调用 `curl http://localhost:8080/config/get` ，返回内容是 `false` 。
**第六步**：通过调用 [Nacos Open API ](https://nacos.io/zh-cn/docs/open-api.html ) 向 Nacos server 发布配置：
```shell
curl -X POST "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=example& group=DEFAULT_GROUP& content=useLocalCache=true"
```
**第七步**：再次访问 `http://localhost:8080/config/get` ，此时返回内容为`true`，说明程序中的`useLocalCache`值已经被动态更新了。
#### 启动服务发现
本节演示如何在您的 Spring Boot 项目中启动 Nacos 的服务发现功能。
**第一步**：添加依赖
```xml
< dependency >
< groupId > com.alibaba.boot< / groupId >
< artifactId > nacos-discovery-spring-boot-starter< / artifactId >
< version > ${latest.version}< / version >
< / dependency >
```
**注意**：版本 [0.2.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.boot/nacos-discovery-spring-boot-starter ) 对应的是 Spring Boot 2.x 版本，版本 [0.1.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.boot/nacos-discovery-spring-boot-starter ) 对应的是 Spring Boot 1.x 版本。
**第二步**：在 `application.properties` 中配置 Nacos server 的地址：
```properties
nacos.discovery.server-addr=127.0.0.1:8848
```
**第三步**：使用 `@NacosInjected` 注入 Nacos 的 `NamingService` 实例：
```java
@Controller
@RequestMapping ("discovery")
public class DiscoveryController {
@NacosInjected
private NamingService namingService;
@RequestMapping (value = "/get", method = GET)
@ResponseBody
public List< Instance > get(@RequestParam String serviceName) throws NacosException {
return namingService.getAllInstances(serviceName);
}
}
@SpringBootApplication
public class NacosDiscoveryApplication {
public static void main(String[] args) {
SpringApplication.run(NacosDiscoveryApplication.class, args);
}
}
```
**第四步**：启动 `NacosDiscoveryApplication` ，调用 `curl http://localhost:8080/discovery/get?serviceName=example` ，此时返回为空 JSON 数组`[]`。
**第五步**：通过调用 [Nacos Open API ](https://nacos.io/zh-cn/docs/open-api.html ) 向 Nacos server 注册一个名称为 `example` 服务
```shell
curl -X PUT 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=example& ip=127.0.0.1& port=8080'
```
**第六步**：再次访问 `curl http://localhost:8080/discovery/get?serviceName=example` ，此时返回内容为：
```json
[
{
"instanceId": "127.0.0.1-8080-DEFAULT-example",
"ip": "127.0.0.1",
"port": 8080,
"weight": 1.0,
"healthy": true,
"cluster": {
"serviceName": null,
"name": "",
"healthChecker": {
"type": "TCP"
},
"defaultPort": 80,
"defaultCheckPort": 80,
"useIPPort4Check": true,
"metadata": {}
},
"service": null,
"metadata": {}
}
]
```
### Spring Cloud
#### 启动配置管理
启动了 Nacos server 后，您就可以参考以下示例代码，为您的 Spring Cloud 应用启动 Nacos 配置管理服务了。
**第一步**：添加依赖
```xml
< dependency >
< groupId > com.alibaba.cloud< / groupId >
< artifactId > spring-cloud-starter-alibaba-nacos-config< / artifactId >
< version > ${latest.version}< / version >
< / dependency >
```
**注意**：版本 [2.1.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-nacos-config ) 对应的是 Spring Boot 2.1.x 版本。版本 [2.0.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-nacos-config ) 对应的是 Spring Boot 2.0.x 版本，版本 [1.5.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-nacos-config ) 对应的是 Spring Boot 1.5.x 版本。
**第二步**：在 `bootstrap.properties` 中配置 Nacos server 的地址和应用名
```properties
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
spring.application.name=example
```
说明：之所以需要配置 `spring.application.name` ，是因为它是构成 Nacos 配置管理 `dataId` 字段的一部分。
**第三步**：在 Nacos Spring Cloud 中，`dataId` 的完整格式如下：
```properties
${prefix}-${spring.profiles.active}.${file-extension}
```
- `prefix` 默认为 `spring.application.name` 的值，也可以通过配置项 `spring.cloud.nacos.config.prefix` 来配置。
- `spring.profiles.active` 即为当前环境对应的 profile， Spring Boot文档 ](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html#boot-features-profiles )。 ** 注意：当 `spring.profiles.active` 为空时，对应的连接符 `-` 也将不存在， `${prefix}.${file-extension}` **
- `file-exetension` 为配置内容的数据格式，可以通过配置项 `spring.cloud.nacos.config.file-extension` 来配置。目前只支持 `properties` 和 `yaml` 类型。
**第四步**：通过 Spring Cloud 原生注解 `@RefreshScope` 实现配置自动更新：
```java
@RestController
@RequestMapping ("/config")
@RefreshScope
public class ConfigController {
@Value ("${useLocalCache:false}")
private boolean useLocalCache;
@RequestMapping ("/get")
public boolean get() {
return useLocalCache;
}
}
```
**第五步**：首先通过调用 [Nacos Open API ](https://nacos.io/zh-cn/docs/open-api.html ) 向 Nacos Server 发布配置：
```shell
curl -X POST "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=example.properties& group=DEFAULT_GROUP& content=useLocalCache=true"
```
**第六步**：运行 `NacosConfigApplication` ，调用 `curl http://localhost:8080/config/get` ，返回内容是 `true` 。
**第七步**：再次调用 [Nacos Open API ](https://nacos.io/zh-cn/docs/open-api.html ) 向 Nacos server 发布配置：
```shell
curl -X POST "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=example.properties& group=DEFAULT_GROUP& content=useLocalCache=false"
```
**第八步**：再次访问 `http://localhost:8080/config/get` ，此时返回内容为`false`，说明程序中的`useLocalCache`值已经被动态更新了。
#### 启动服务发现
本节通过实现一个简单的 `echo service` 演示如何在您的 Spring Cloud 项目中启用 Nacos 的服务发现功能，如下图示:
**第一步**：添加依赖：
```xml
< dependency >
< groupId > com.alibaba.cloud< / groupId >
< artifactId > spring-cloud-starter-alibaba-nacos-discovery< / artifactId >
< version > ${latest.version}< / version >
< / dependency >
```
**注意**：版本 [2.1.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-nacos-discovery ) 对应的是 Spring Boot 2.1.x 版本。版本 [2.0.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-nacos-discovery ) 对应的是 Spring Boot 2.0.x 版本，版本 [1.5.x.RELEASE ](https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-nacos-discovery ) 对应的是 Spring Boot 1.5.x 版本。
**第二步**：配置服务提供者，从而服务提供者可以通过 Nacos 的服务注册发现功能将其服务注册到 Nacos server 上。
i. 在 `application.properties` 中配置 Nacos server 的地址：
```properties
server.port=8070
spring.application.name=service-provider
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
```
ii. 通过 Spring Cloud 原生注解 `@EnableDiscoveryClient` 开启服务注册发现功能：
```java
@SpringBootApplication
@EnableDiscoveryClient
public class NacosProviderApplication {
public static void main(String[] args) {
SpringApplication.run(NacosProviderApplication.class, args);
}
@RestController
class EchoController {
@RequestMapping (value = "/echo/{string}", method = RequestMethod.GET)
public String echo(@PathVariable String string) {
return "Hello Nacos Discovery " + string;
}
}
}
```
**第三步**：配置服务消费者，从而服务消费者可通过 Nacos 的服务注册发现功能从 Nacos server 上获取到它要调用的服务。
i. 在 `application.properties` 中配置 Nacos server 的地址：
```properties
server.port=8080
spring.application.name=service-consumer
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
```
ii. 通过 Spring Cloud 原生注解 `@EnableDiscoveryClient` 开启服务注册发现功能。给 [RestTemplate ](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-resttemplate.html ) 实例添加 `@LoadBalanced` 注解，开启 `@LoadBalanced` 与 [Ribbon ](https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-ribbon.html ) 的集成：
```java
@SpringBootApplication
@EnableDiscoveryClient
public class NacosConsumerApplication {
@LoadBalanced
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(NacosConsumerApplication.class, args);
}
@RestController
public class TestController {
private final RestTemplate restTemplate;
@Autowired
public TestController(RestTemplate restTemplate) {this.restTemplate = restTemplate;}
@RequestMapping (value = "/echo/{str}", method = RequestMethod.GET)
public String echo(@PathVariable String str) {
return restTemplate.getForObject("http://service-provider/echo/" + str, String.class);
}
}
}
```
**第四步**：启动 `ProviderApplication` 和 `ConsumerApplication` ，调用 `http://localhost:8080/echo/2018` ，返回内容为 `Hello Nacos Discovery 2018` 。
# Sentinel
Sentinel（ ） ，
- **丰富的应用场景**：
- **完备的实时监控**：
- **广泛的开源生态**：
- **完善的 SPI 扩展点**：
## 主要特性
Sentinel 的主要特性：
## 开源生态
Sentinel 的开源生态：
Sentinel 分为两个部分:
- 核心库（
- 控制台（ ）
## Quick Start
### 手动接入Sentinel以及控制台
下面例子将展示应用如何三步接入 Sentinel。同时，
**STEP 1. 在应用中引入Sentinel Jar包**
如果应用使用 pom 工程，则在 `pom.xml` 文件中加入以下代码即可：
```xml
< dependency >
< groupId > com.alibaba.csp< / groupId >
< artifactId > sentinel-core< / artifactId >
< version > 1.8.1< / version >
< / dependency >
```
注意: Sentinel仅支持JDK 1.8或者以上版本。如果未使用依赖管理工具，请到 [Maven Center Repository ](https://mvnrepository.com/artifact/com.alibaba.csp/sentinel-core ) 直接下载JAR 包。
**STEP 2. 定义资源**
接下来，我们把需要控制流量的代码用 Sentinel API `SphU.entry("HelloWorld")` 和 `entry.exit()` 包围起来即可。在下面的例子中，我们将 `System.out.println("hello world");` 这端代码作为资源，用 API 包围起来（埋点）。参考代码如下:
```java
public static void main(String[] args) {
initFlowRules();
while (true) {
Entry entry = null;
try {
entry = SphU.entry("HelloWorld");
/*您的业务逻辑 - 开始*/
System.out.println("hello world");
/*您的业务逻辑 - 结束*/
} catch (BlockException e1) {
/*流控逻辑处理 - 开始*/
System.out.println("block!");
/*流控逻辑处理 - 结束*/
} finally {
if (entry != null) {
entry.exit();
}
}
}
}
```
完成以上两步后，代码端的改造就完成了。当然，我们也提供了 [注解支持模块 ](https://github.com/alibaba/Sentinel/wiki/注解支持 )，可以以低侵入性的方式定义资源。
**STEP 3. 定义规则**
接下来，通过规则来指定允许该资源通过的请求次数，如下面的代码定义了资源 `HelloWorld` 每秒最多只能通过 20 个请求。
```java
private static void initFlowRules(){
List< FlowRule > rules = new ArrayList< >();
FlowRule rule = new FlowRule();
rule.setResource("HelloWorld");
rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
// Set limit QPS to 20.
rule.setCount(20);
rules.add(rule);
FlowRuleManager.loadRules(rules);
}
```
完成上面 3 步， 使用文档 ](https://github.com/alibaba/Sentinel/wiki/如何使用 )。
**STEP 4. 检查效果**
Demo 运行之后，我们可以在日志 `~/logs/csp/${appName}-metrics.log.xxx` 里看到下面的输出:
```shell
|--timestamp-|------date time----|-resource-|p |block|s |e|rt
1529998904000|2018-06-26 15:41:44|HelloWorld|20|0 |20|0|0
1529998905000|2018-06-26 15:41:45|HelloWorld|20|5579 |20|0|728
1529998906000|2018-06-26 15:41:46|HelloWorld|20|15698|20|0|0
1529998907000|2018-06-26 15:41:47|HelloWorld|20|19262|20|0|0
1529998908000|2018-06-26 15:41:48|HelloWorld|20|19502|20|0|0
1529998909000|2018-06-26 15:41:49|HelloWorld|20|18386|20|0|0
```
其中 `p` 代表通过的请求, `block` 代表被阻止的请求, `s` 代表成功执行完成的请求个数, `e` 代表用户自定义的异常, `rt` 代表平均响应时长。可以看到，这个程序每秒稳定输出 "hello world" 20 次，和规则中预先设定的阈值是一样的。
**STEP 5. 启动 Sentinel 控制台**
您可以参考 [Sentinel 控制台文档 ](https://github.com/alibaba/Sentinel/wiki/控制台 ) 启动控制台，可以实时监控各个资源的运行情况，并且可以实时地修改限流规则。
# Influxdb
InfluxDB 是用Go语言编写的一个开源分布式时序、事件和指标数据库，
## 重要特性
- **极简架构：**单机版的InfluxDB只需要安装一个binary， ，
- **极强的写入能力：** 底层采用自研的TSM存储引擎， ，
- **高效查询：**对Tags会进行索引，
- **InfluxQL**： ， ，
- **Continuous Queries**: 通过CQ能够支持auto-rollup和pre-aggregation，
## 存储引擎
InfluxDB 采用自研的TSM (Time-Structured Merge Tree) 作为存储引擎， 其核心思想是通过牺牲掉一些功能来对性能达到极致优化， ， ，
**时序数据库的需求：**
- 数十亿个单独的数据点
- 高写入吞吐量
- 高读取吞吐量
- 大型删除（数据过期）
- 主要是插入/追加工作负载，很少更新
### LSM
**LSM 的局限性**
在官方文档上有写， 为了解决高写入吞吐量的问题， Influxdb 一开始选择了LevelDB 作为其存储引擎。 然而， ，
**LSM （日志结构合并树）为 LevelDB的引擎原理**
- levelDB 不支持热备份。 对数据库进行安全备份必须关闭后才能复制。LevelDB的RocksDB和HyperLevelDB变体可以解决此问题
- 时序数据库需要提供一种自动管理数据保存的方式。 即删除过期数据， 而在levelDB 中，删除的代价过高。（通过添加墓碑的方式， 段结构合并的时候才会真正物理性的删除）
### TSM
按不同的时间范围划分为不同的分区（ ） ， ， ， ， ，
- 在最开始的时候， influxdb 采用的方案每个shard都是一个独立的数据库实例， ， ， ， ，
- 由于遇到大量的客户反馈文件句柄过多的问题，
- 之后Influxdb 最终决定仿照LSM 的思想自研TSM ， ， ，
## 系统架构
- **DataBase：
- **Retention Policy（ ） ：
- **Shard Group： ， ， ，
# Spring
Spring是一个轻量级的IoC和AOP容器框架。是为Java应用程序提供基础性服务的一套框架， ，
**Spring的优点？
- spring属于低侵入式设计，
- spring的DI机制将对象之间的依赖关系交由框架处理，
- Spring提供了AOP技术， ， ，
- spring对于主流的应用框架提供了集成支持
** 使用Spring框架的好处是什么？
- **轻量：**Spring 是轻量的，
- **控制反转：**Spring通过控制反转实现了松散耦合， ，
- **面向切面的编程(AOP)： ，
- **容器：**Spring 包含并管理应用中对象的生命周期和配置
- **MVC框架**： ，
- **事务管理：**Spring 提供一个持续的事务管理接口， （ ）
- **异常处理：**Spring 提供方便的API把具体技术相关的异常（ ， ）
## 相关概念
### Spring
Spring是一个开源容器框架， ， ， ， ， ，
### SpringMVC
Spring MVC属于SpringFrameWork的后续产品， ， （ ， ， ， ，
SpringMVC是属于SpringWeb里面的一个功能模块（ ）
### SpringBoot
Springboot是一个微服务框架， ， ， ， ，
Spring Boot基本上是Spring框架的扩展， ， ， ：
- 创建独立的spring应用
- 嵌入Tomcat, JettyUndertow 而且不需要部署他们
- 提供的“starters” poms来简化Maven配置
- 尽可能自动配置spring应用
- 提供生产指标,健壮检查和外部化配置
- 绝对没有代码生成和XML配置要求
## Spring原理
### 核心组件
### Spring常用模块
主要包括以下七个模块：
- **Spring Context**： ， （ ）
- **Spring Core**： ， ，
- **Spring AOP**：
- **Spring Web**： ， ， ， ，
- **Spring MVC**： ，
- **Spring DAO**： ， ，
- **Spring ORM**：
### Spring主要包
### Spring常用注解
## IoC
IOC就是控制反转， ， ， ， ， ，
最直观的表达就是， ， ， ， ， ，
Spring的IOC有三种注入方式 ：
## AOP
AOP， ， ， ， ， ， （ ） ， ， ， ， ；
### 静态代理
AspectJ是静态代理， ， ， ，
### 动态代理
Spring AOP使用的动态代理， ， ， ， ， ， ：
- **JDK动态代理**： ， ， ， ， （ ， ） ， ，
**InvocationHandler的invoke(Object proxy,Method method,Object[] args)** ：
- **proxy**：是最终生成的代理对象
- **method**：是被代理目标实例的某个具体方法;
- **args**：是被代理目标实例某个方法的具体入参, 在方法反射调用时使用
- **CGLIB动态代理**： ， （ ） ， ， ， ， ， ，
**静态代理与动态代理区别？**
生成AOP代理对象的时机不同， ， ，
IoC让相互协作的组件保持松散的耦合，
### 应用场景
AOP 主要应用场景有：
- Authentication 权限
- Caching 缓存
- Context passing 内容传递
- Error handling 错误处理
- Lazy loading 懒加载
- Debugging 调试
- logging, tracing, profiling and monitoring 记录跟踪 优化 校准
- Performance optimization 性能优化
- Persistence 持久化
- Resource pooling 资源池
- Synchronization 同步
- Transactions 事务
## 过滤器（ ）
主要作用是过滤字符编码、做一些业务逻辑判断， ， ， ， ， ， ：
- 用户授权Filter： ，
- 日志Filter：
- 解码Filter：
## 拦截器（ ）
主要作用是拦截用户请求， ， ，
Interceptor分两种情况， ， ， ， ，
**Filter和Interceptor的区别**
- Filter是基于函数回调（ ） ， （ ）
- Filter依赖于Servlet容器，
- Filter对几乎所有的请求起作用，
- Interceptor可以访问Action的上下文， ，
- 在action的生命周期里， ，
- Filter在过滤是只能对request和response进行操作，
### HandlerInterceptor
HandlerInterceptor是springMVC项目中的拦截器， ，
实现一个HandlerInterceptor拦截器可以直接实现HandlerInterceptor接口，
这两种方法殊途同归， ，
### MethodInterceptor
MethodInterceptor是AOP项目中的拦截器， ， ， ，
## Spring流程
### Spring容器启动流程
- 初始化Spring容器，
① 实例化BeanFactory【DefaultListableBeanFactory】工厂，
② 实例化BeanDefinitionReader注解配置读取器， （ ） ， （ ， ， ，
③ 实例化ClassPathBeanDefinitionScanner路径扫描器，
- 将配置类的BeanDefinition注册到容器中
- 调用refresh()方法刷新容器
① prepareRefresh()刷新前的预处理
② obtainFreshBeanFactory()：
③ prepareBeanFactory(beanFactory)： ，
④ postProcessBeanFactory(beanFactory)： ，
⑤ invokeBeanFactoryPostProcessors(beanFactory)： ，
⑥ registerBeanPostProcessors(beanFactory)： ， ，
⑦ initMessageSource()： ， ，
⑧ initApplicationEventMulticaster()：初始化事件派发器，在注册监听器时会用到
⑨ onRefresh()：留给子容器、子类重写这个方法，在容器刷新的时候可以自定义逻辑
⑩ registerListeners()： ，
⑪ finishBeanFactoryInitialization(beanFactory)： ， ，
⑫ finishRefresh()：
### SpringMVC流程
- 用户发送请求至前端控制器DispatcherServlet
- DispatcherServlet收到请求后， ，
- 处理器映射器根据请求url找到具体的处理器Handler， ，
- DispatcherServlet 调用 HandlerAdapter处理器适配器，
- HandlerAdapter 经过适配调用 具体处理器进行处理业务逻辑
- Handler执行完成返回ModelAndView
- HandlerAdapter将Handler执行结果ModelAndView返回给DispatcherServlet
- DispatcherServlet将ModelAndView传给ViewResolver视图解析器进行解析
- ViewResolver解析后返回具体View
- DispatcherServlet对View进行渲染视图（ ）
- DispatcherServlet响应用户
- 前端控制器 DispatcherServlet： ， ，
- 处理器映射器 HandlerMapping：
- 处理器适配器 HandlerAdapter：
- 处理器 Handler： ，
- 视图解析器 ViewResolver： ， （ ）
- 视图View： ， ， ， ，
### 非拦截器Http请求流程
用户的普通Http请求执行顺序：
### 拦截器Http请求流程
过滤器、拦截器添加后的执行顺序：
# SpringCloud
## Eurake
Netflix Eureka 是由 Netflix 开源的一款基于 REST 的服务发现组件，包括 Eureka Server 及 Eureka Client。
- **Eurake客户端**：
- **Eureka服务端**： ， ， ，
## Zuul
Zuul 是由 Netflix 孵化的一个致力于“网关 “解决方案的开源组件。
**网关的作用**
- 统一入口：未全部为服务提供一个唯一的入口，网关起到外部和内部隔离的作用，保障了后台服务的安全性
- 鉴权校验：识别每个请求的权限，拒绝不符合要求的请求
- 动态路由：动态的将请求路由到不同的后端集群中
- 减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射
## Feign
Feign是是一个声明式的Web Service客户端。
Feign就是使用了动态代理：
- 首先，如果你对某个接口定义了@FeignClient注解，
- 接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，
- Feign的动态代理会根据你在接口上的@RequestMapping等注解，
- 最后针对这个地址，发起请求、解析响应
## Ribbon
Ribbon Netflix 公司开源的一个负载均衡的组件。
Ribbon在服务消费者端配置和使用， ， ， ， ， ， ， ：
## Hystrix
Hystrix是Netstflix 公司开源的一个项目，它提供了熔断器功能，能够阻止分布式系统中出现联动故障。
Hystrix是隔离、熔断以及降级的一个框架， ， ， ， ， ， ， ， ， ， ， ， ：
## Gateway
Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0、 Spring Boot 2.0 和 Project Reactor 等技术开发的网关， Spring Cloud Gateway 旨在为微服务架构提供简单、 有效且统一的 API 路由管理方式。
## Config
Spring Cloud 中提供了分布式配置中 Spring Cloud Config ，为外部配置提供了客户端和服务器端的支持。
## Bus
使用 Spring Cloud Bus, 可以非常容易地搭建起消息总线。
## OAuth2
Sprin Cloud 构建的微服务系统中可以使用 Spring Cloud OAuth2 来保护微服务系统。
## Sleuth
Spring Cloud Sleuth是Spring Cloud 个组件，它的主要功能是在分布式系统中提供服务链路追踪的解决方案。
# MyBatis
Mybatis是一个半ORM（ ） ， ， ， ， ，
作为一个半ORM框架， ，
通过xml 文件或注解的方式将要执行的各种 statement 配置起来， ， （ ）
由于MyBatis专注于SQL本身， ， ， ，
**Mybaits优缺点**
- 优点
- 基于SQL语句编程， ， ， ， ， ； ， ，
- 与JDBC相比， ， ，
- 很好的与各种数据库兼容（ ， ）
- 能够与Spring很好的集成
- 提供映射标签， ； ，
- 缺点
- SQL语句的编写工作量较大， ，
- SQL语句依赖于数据库， ，
**#{}和${}的区别是什么？**
- `${}` 是字符串替换
- `#{}` 是预处理
使用#{}可以有效的防止SQL注入，
## MyBatis架构
核心成员说明
| 核心成员 | 功能说明 |
| ---------------- | ------------------------------------------------------------ |
| Configuration | 保存MyBatis大部分配置信息 |
| SqlSession | MyBatis主要的顶层API， ，
| Executor | MyBatis 调度器，
| StatementHandler | 封装JDBC，
| ParameterHandler | 用户传递的参数转换成JDBC Statement 所对应的数据类型 |
| ResultSetHandler | 负责将JDBC返回的ResultSet结果集对象转换成List类型的集合 |
| TypeHandler | 负责java数据类型和jdbc数据类型(也可以说是数据表列类型)之间的映射和转换 |
| MappedStatement | MappedStatement维护一条< select \|update \|delete \|insert > 节点的封装 |
| SqlSource | 负责根据用户传递的parameterObject， ， ，
| BoundSql | 表示动态生成的SQL语句以及相应的参数信息 |
## MyBatis流程
## Dao接口工作原理
Mapper 接口的工作原理是JDK动态代理， ， ， ， ，
Mapper接口里的方法， ，
## MyBatis缓存
MyBatis 中有一级缓存和二级缓存，默认情况下一级缓存是开启的，而且是不能关闭的。一级缓存是指 SqlSession 级别的缓存，当在同一个 SqlSession 中进行相同的 SQL 语句查询时，第二次以后的查询不会从数据库查询，而是直接从缓存中获取，一级缓存最多缓存 1024 条 SQL。二级缓存是指可以跨 SqlSession 的缓存。是 mapper 级别的缓存， ，
### 一级缓存
Mybatis的一级缓存原理(sqlsession级别)。第一次发出一个查询 sql，
- key：
- value：
同一个 sqlsession 再次发出相同的 sql，
### 二级缓存
二级缓存的范围是 mapper 级别（ ） ，
- key：
**具体使用需要配置：**
- Mybatis 全局配置中启用二级缓存配置
- 在对应的 Mapper.xml 中配置 cache 节点
- 在对应的 select 查询节点中添加 useCache=true
## MyBatis主要组件
### SqlSessionFactoryBuilder
从名称长可以看出来使用的建造者设计模式（ ） ， ：
- 解析mybatis的xml配置文件， （ < configuration > 标签）
- 根据创建的Configuration对象， （ ）
### SqlSessionFactory
从名称上可以看出使用的工厂模式（ ） ， （ ）
- 调用openSession方法， ， （ ）
- openSession方法有多个重载，
### SqlSession
如果了解web开发， ， ， ， （ ） ， （ ） ， （ ， ， ， ， ）
SqlSession只是定义了执行sql的一些方法， ， ， （ ） ，
### Executor
Executor（ ） ， ， ：
CacheExecutor其实是一个Executor代理类， ， （ ， ， ，
Executor是对JDBC的封装。当我们使用JDBC来执行sql时， ， ， （ ） ， ，
### StatementHandler
在JDBC中， ， ， ， ，
- 对sql进行预处理
- 调用statement.executeXxx()执行sql
- 将数据库返回的结果集进行对象转换（ ）
### ParameterHandler
，
### ResultSetHandler
当执行statement.execute()后， ， ， （ ） ， ，
### TypeHandler
TypeHandler主要用在两个地方：
- 参数绑定，
MyBatis中， < resultMap > 来定义结果的映射关系， ， ， （ ）
- 获取结果集中的字段值，
# Nginx
## Nginx安装
```shell
# CentOS
yum install nginx;
# Ubuntu
sudo apt-get install nginx;
# Mac
brew install nginx;
```
安装完成后，通过 `rpm \-ql nginx` 命令查看 `Nginx` 的安装信息：
```shell
# Nginx配置文件
/etc/nginx/nginx.conf # nginx 主配置文件
/etc/nginx/nginx.conf.default
# 可执行程序文件
/usr/bin/nginx-upgrade
/usr/sbin/nginx
# nginx库文件
/usr/lib/systemd/system/nginx.service # 用于配置系统守护进程
/usr/lib64/nginx/modules # Nginx模块目录
# 帮助文档
/usr/share/doc/nginx-1.16.1
/usr/share/doc/nginx-1.16.1/CHANGES
/usr/share/doc/nginx-1.16.1/README
/usr/share/doc/nginx-1.16.1/README.dynamic
/usr/share/doc/nginx-1.16.1/UPGRADE-NOTES-1.6-to-1.10
# 静态资源目录
/usr/share/nginx/html/404.html
/usr/share/nginx/html/50x.html
/usr/share/nginx/html/index.html
# 存放Nginx日志文件
/var/log/nginx
```
主要关注的文件夹有两个：
- `/etc/nginx/conf.d/` 是子配置项存放处， `/etc/nginx/nginx.conf` 主配置文件会默认把该文件夹中所有子配置项都引入
- `/usr/share/nginx/html/` 静态文件都放在这个文件夹，也可以根据你自己的习惯放在其他地方
## 运维命令
一般可以在 `/etc/nginx/nginx.conf` 中配置。
### systemctl命令
```shell
# 开机配置
# 开机自动启动
systemctl enable nginx
# 关闭开机自动启动
systemctl disable nginx
# 启动Nginx
systemctl start nginx # 启动Nginx成功后， ，
# 停止Nginx
systemctl stop nginx
# 重启Nginx
systemctl restart nginx
# 重新加载Nginx
systemctl reload nginx
# 查看 Nginx 运行状态
systemctl status nginx
# 查看Nginx进程
ps -ef | grep nginx
# 杀死Nginx进程
kill -9 pid # 根据上面查看到的Nginx进程号， ，
```
### Nginx应用命令
```shell
# 启动
nginx -s start
# 向主进程发送信号，重新加载配置文件，热重启
nginx -s reload
# 重启 Nginx
nginx -s reopen
# 快速关闭
nginx -s stop
# 等待工作进程处理完成后关闭
nginx -s quit
# 查看当前 Nginx 最终的配置
nginx -T
# 检查配置是否有问题
nginx -t
```
## 配置规则
Nginx层级结构如下：
### URI匹配
```shell
location = / {
# 完全匹配 =
# 大小写敏感 ~
# 忽略大小写 ~*
}
location ^~ /images/ {
# 前半部分匹配 ^~
# 可以使用正则，如：
# location ~* \.(gif|jpg|png)$ { }
}
location / {
# 如果以上都未匹配，会进入这里
}
```
### upstream
```nginx
语法：
...
}
上下文：
示例：
upstream back_end_server{
server 192.168.100.33:8081
}
```
`upstream` 用于定义上游服务器（指的就是后台提供的应用服务器）的相关信息。
```nginx
upstream test_server{
# weight=3 权重值，
# max_conns=1000 上游服务器的最大并发连接数
# fail_timeout=10s 服务器不可用的判定时间
# max_fails=2 服务器不可用的检查次数
# backup 备份服务器，仅当其他服务器都不可用时才会启用
# down 标记服务器长期不可用，离线维护；
server 127.0.0.1:8081 weight=3 max_conns=1000 fail_timeout=10s max_fails=2;
# 限制每个worker子进程与上游服务器空闲长连接的最大数量
keepalive 16;
# 单个长连接可以处理的最多 HTTP 请求个数
keepalive_requests 100;
# 空闲长连接的最长保持时间
keepalive_timeout 60s;
}
```
### proxy_pass
```nginx
语法：
上下文：
示例：
proxy_pass http://127.0.0.1:8081
proxy_pass http://127.0.0.1:8081/proxy
```
`URL` 参数原则：
- `URL` 必须以 `http` 或 `https` 开头
- `URL` 中可以携带变量
- `URL` 中是否带 `URI` ，会直接影响发往上游请求的 `URL`
`URL` 后缀带 `/` 和不带 `/` 的区别：
- 不带 `/` 意味着 `Nginx` 不会修改用户 `URL` ，而是直接透传给上游的应用服务器
- 带 `/` 意味着 `Nginx` 会修改用户 `URL` ，修改方法是将 `location` 后的 `URL` 从用户 `URL` 中删除
```nginx
# 用户请求 URL ：
location /bbs/{
# 请求到达上游应用服务器的 URL ：
proxy_pass http://127.0.0.1:8080;
# 请求到达上游应用服务器的 URL ：
proxy_pass http://127.0.0.1:8080/;
}
```
## 应用场景
### 反向代理
```nginx
# 1 /etc/nginx/conf.d/proxy.conf
# 1.1 模拟被代理服务
server{
listen 8080;
server_name localhost;
location /proxy/ {
root /usr/share/nginx/html/proxy;
index index.html;
}
}
# 1.2 /usr/share/nginx/html/proxy/index.html
< h1 > 121.42.11.34 proxy html < / h1 >
# 2 /etc/nginx/conf.d/proxy.conf
# 2.1 back server
upstream back_end {
server 121.42.11.34:8080 weight=2 max_conns=1000 fail_timeout=10s max_fails=3;
keepalive 32;
keepalive_requests 80;
keepalive_timeout 20s;
}
# 2.2 代理配置
server {
listen 80;
# vim /etc/hosts进入配置文件,添加如下内容：
server_name proxy.lion.club;
location /proxy {
proxy_pass http://back_end/proxy;
}
}
```
### 负载均衡
```nginx
# 1 /etc/nginx/conf.d/balance.conf
# 1.1 模拟被代理服务1
server{
listen 8020;
location / {
return 200 'return 8020 \n';
}
}
# 1.2 模拟被代理服务2
server{
listen 8030;
location / {
return 200 'return 8030 \n';
}
}
# 1.3 模拟被代理服务3
server{
listen 8040;
location / {
return 200 'return 8040 \n';
}
}
# 2 /etc/nginx/conf.d/balance.conf
# 2.1 demo server list
upstream demo_server {
server 121.42.11.34:8020;
server 121.42.11.34:8030;
server 121.42.11.34:8040;
}
# 2.2 代理配置
server {
listen 80;
server_name balance.lion.club;
location /balance/ {
proxy_pass http://demo_server;
}
}
```
#### hash算法
```nginx
upstream demo_server {
hash $request_uri;
server 121.42.11.34:8020;
server 121.42.11.34:8030;
server 121.42.11.34:8040;
}
server {
listen 80;
server_name balance.lion.club;
location /balance/ {
proxy_pass http://demo_server;
}
}
```
`hash $request_uri` 表示使用 `request_uri` 变量作为 `hash` 的 `key` 值，只要访问的 `URI` 保持不变，就会一直分发给同一台服务器。
#### ip_hash
```nginx
upstream demo_server {
ip_hash;
server 121.42.11.34:8020;
server 121.42.11.34:8030;
server 121.42.11.34:8040;
}
server {
listen 80;
server_name balance.lion.club;
location /balance/ {
proxy_pass http://demo_server;
}
}
```
根据客户端的请求 `ip` 进行判断，只要 `ip` 地址不变就永远分配到同一台主机。它可以有效解决后台服务器 `session` 保持的问题。
#### 最少连接数算法
```nginx
upstream demo_server {
zone test 10M; # zone可以设置共享内存空间的名字和大小
least_conn;
server 121.42.11.34:8020;
server 121.42.11.34:8030;
server 121.42.11.34:8040;
}
server {
listen 80;
server_name balance.lion.club;
location /balance/ {
proxy_pass http://demo_server;
}
}
```
各个 `worker` 子进程通过读取共享内存的数据，来获取后端服务器的信息。来挑选一台当前已建立连接数最少的服务器进行分配请求。
### 配置缓存
**① proxy_cache**
存储一些之前被访问过、而且可能将要被再次访问的资源，使用户可以直接从代理服务器获得，从而减少上游服务器的压力，加快整个访问速度。
```nginx
语法：
默认值：
上下文：
```
**② proxy_cache_path**
设置缓存文件的存放路径。
```nginx
语法：
默认值：
上下文：
```
参数含义：
- `path` 缓存文件的存放路径
- `level path` 的目录层级
- `keys_zone` 设置共享内存
- `inactive` 在指定时间内没有被访问， ，
**③ proxy_cache_key**
设置缓存文件的 `key` 。
```nginx
语法：
默认值：
上下文：
```
**④ proxy_cache_valid**
配置什么状态码可以被缓存，以及缓存时长。
```nginx
语法：
上下文：
配置示例：
```
**⑤ proxy_no_cache**
定义相应保存到缓存的条件，如果字符串参数的至少一个值不为空且不等于“ 0”，
```nginx
语法：
上下文：
示例：
```
**⑥ proxy_cache_bypass**
定义条件，在该条件下将不会从缓存中获取响应。
```nginx
语法：
上下文：
示例：
```
**⑦ upstream_cache_status 变量**
它存储了缓存是否命中的信息，会设置在响应头信息中，在调试中非常有用。
```nginx
MISS: 未命中缓存
HIT：
EXPIRED: 缓存过期
STALE: 命中了陈旧缓存
REVALIDDATED: Nginx验证陈旧缓存依然有效
UPDATING: 内容陈旧，但正在更新
BYPASS: X响应从原始服务器获取
```
```nginx
proxy_cache_path /etc/nginx/cache_temp levels=2:2 keys_zone=cache_zone:30m max_size=2g inactive=60m use_temp_path=off;
upstream cache_server{
server 121.42.11.34:1010;
server 121.42.11.34:1020;
}
server {
listen 80;
server_name cache.lion.club;
# 场景一：实时性要求不高，则配置缓存
location /demo {
proxy_cache cache_zone; # 设置缓存内存，上面配置中已经定义好的
proxy_cache_valid 200 5m; # 缓存状态为200的请求，
proxy_cache_key $request_uri; # 缓存文件的key为请求的URI
add_header Nginx-Cache-Status $upstream_cache_status # 把缓存状态设置为头部信息，响应给客户端
proxy_pass http://cache_server; # 代理转发
}
# 场景二：实时性要求非常高，则配置不缓存
# URI 中后缀为 .txt 或 .text 的设置变量值为 "no cache"
if ($request_uri ~ \.(txt|text)$) {
set $cache_name "no cache"
}
location /test {
proxy_no_cache $cache_name; # 判断该变量是否有值，如果有值则不进行缓存，如果没有值则进行缓存
proxy_cache cache_zone; # 设置缓存内存
proxy_cache_valid 200 5m; # 缓存状态为200的请求，
proxy_cache_key $request_uri; # 缓存文件的key为请求的URI
add_header Nginx-Cache-Status $upstream_cache_status # 把缓存状态设置为头部信息，响应给客户端
proxy_pass http://cache_server; # 代理转发
}
}
```
### HTTPS
下载证书的压缩文件，里面有个 `Nginx` 文件夹，把 `xxx.crt` 和 `xxx.key` 文件拷贝到服务器目录，再进行如下配置：
```nginx
server {
listen 443 ssl http2 default_server; # SSL 访问端口号为 443
server_name lion.club; # 填写绑定证书的域名(我这里是随便写的)
ssl_certificate /etc/nginx/https/lion.club_bundle.crt; # 证书地址
ssl_certificate_key /etc/nginx/https/lion.club.key; # 私钥地址
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 支持ssl协议版本， ，
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
```
### 开启gzip压缩
在 `/etc/nginx/conf.d/` 文件夹中新建配置文件 `gzip.conf` ：
```nginx
# 默认off，
gzip on;
# 要采用 gzip 压缩的 MIME 文件类型，其中 text/html 被系统强制启用
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
# ---- 以上两个参数开启就可以支持Gzip压缩了 ----
# 默认 off， ，
gzip_static on;
# 默认 off， ，
gzip_proxied any;
# 用于在响应消息头中添加Vary： ，
gzip_vary on;
# gzip 压缩比，压缩级别是 1-9， ，
gzip_comp_level 6;
# 获取多少内存用于缓存压缩结果，
gzip_buffers 16 8k;
# 允许压缩的页面最小字节数， ，
gzip_min_length 1k;
# 默认 1.1，启用 gzip 所需的 HTTP 最低版本
gzip_http_version 1.1;
```
## 常用配置
### 侦听端口
```nginx
server {
# Standard HTTP Protocol
listen 80;
# Standard HTTPS Protocol
listen 443 ssl;
# For http2
listen 443 ssl http2;
# Listen on 80 using IPv6
listen [::]:80;
# Listen only on using IPv6
listen [::]:80 ipv6only=on;
}
```
### 访问日志
```nginx
server {
# Relative or full path to log file
access_log /path/to/file.log;
# Turn 'on' or 'off'
access_log on;
}
```
### 域名
```nginx
server {
# Listen to yourdomain.com
server_name yourdomain.com;
# Listen to multiple domains server_name yourdomain.com www.yourdomain.com;
# Listen to all domains
server_name *.yourdomain.com;
# Listen to all top-level domains
server_name yourdomain.*;
# Listen to unspecified Hostnames (Listens to IP address itself)
server_name "";
}
```
### 静态资源
```nginx
server {
listen 80;
server_name yourdomain.com;
location / {
root /path/to/website;
}
}
```
### 重定向
```nginx
server {
listen 80;
server_name www.yourdomain.com;
return 301 http://yourdomain.com$request_uri;
}
server {
listen 80;
server_name www.yourdomain.com;
location /redirect-url {
return 301 http://otherdomain.com;
}
}
```
### 反向代理
```nginx
server {
listen 80;
server_name yourdomain.com;
location / {
proxy_pass http://0.0.0.0:3000;
# where 0.0.0.0:3000 is your application server (Ex: node.js) bound on 0.0.0.0 listening on port 3000
}
}
```
### 负载均衡
```nginx
upstream node_js {
server 0.0.0.0:3000;
server 0.0.0.0:4000;
server 123.131.121.122;
}
server {
listen 80;
server_name yourdomain.com;
location / {
proxy_pass http://node_js;
}
}
```
### SSL协议
```nginx
server {
listen 443 ssl;
server_name yourdomain.com;
ssl on;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/privatekey.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/fullchain.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_timeout 1h;
ssl_session_cache shared:SSL:50m;
add_header Strict-Transport-Security max-age=15768000;
}
# Permanent Redirect for HTTP to HTTPS
server {
listen 80;
server_name yourdomain.com;
return 301 https://$host$request_uri;
}
```
## 日志分析
```shell
# 统计IP访问量
awk '{print $1}' access.log | sort -n | uniq | wc -l
# 查看某一时间段的IP访问量(4-5点)
grep "07/Apr/2017:0[4-5]" access.log | awk '{print $1}' | sort | uniq -c| sort -nr | wc -l
# 查看访问最频繁的前100个IP
awk '{print $1}' access.log | sort -n |uniq -c | sort -rn | head -n 100
# 查看访问100次以上的IP
awk '{print $1}' access.log | sort -n |uniq -c |awk '{if($1 >100) print $0}'|sort -rn
# 查询某个IP的详细访问情况,按访问频率排序
grep '104.217.108.66' access.log |awk '{print $7}'|sort |uniq -c |sort -rn |head -n 100
# 页面访问统计
# 查看访问最频的页面(TOP100)
awk '{print $7}' access.log | sort |uniq -c | sort -rn | head -n 100
# 查看访问最频的页面([排除php页面】(TOP100)
grep -v ".php" access.log | awk '{print $7}' | sort |uniq -c | sort -rn | head -n 100
# 查看页面访问次数超过100次的页面
cat access.log | cut -d ' ' -f 7 | sort |uniq -c | awk '{if ($1 > 100) print $0}' | less
# 查看最近1000条记录，
tail -1000 access.log |awk '{print $7}'|sort|uniq -c|sort -nr|less
# 请求量统计
# 统计每秒的请求数,top100的时间点(精确到秒)
awk '{print $4}' access.log |cut -c 14-21|sort|uniq -c|sort -nr|head -n 100
# 统计每分钟的请求数,top100的时间点(精确到分钟)
awk '{print $4}' access.log |cut -c 14-18|sort|uniq -c|sort -nr|head -n 100
# 统计每小时的请求数,top100的时间点(精确到小时)
awk '{print $4}' access.log |cut -c 14-15|sort|uniq -c|sort -nr|head -n 100
# 性能分析
# 列出传输时间超过 3 秒的页面，
cat access.log|awk '($NF > 3){print $7}'|sort -n|uniq -c|sort -nr|head -20
# 列出php页面请求时间超过3秒的页面， ，
cat access.log|awk '($NF > 1 && $7~/\.php/){print $7}'|sort -n|uniq -c|sort -nr|head -100
# 蜘蛛抓取统计
# 统计蜘蛛抓取次数
grep 'Baiduspider' access.log |wc -l
# 统计蜘蛛抓取404的次数
grep 'Baiduspider' access.log |grep '404' | wc -l
# TCP连接统计
# 查看当前TCP连接数
netstat -tan | grep "ESTABLISHED" | grep ":80" | wc -l
# 用tcpdump嗅探80端口的访问看看谁最高
tcpdump -i eth0 -tnn dst port 80 -c 1000 | awk -F"." '{print $1"."$2"."$3"."$4}' | sort | uniq -c | sort -nr
awk '{print $1}' $logpath |sort -n|uniq|wc -l
# 系统正在统计某一个时间段IP访问量为
sed -n '/22\/Jun\/2017:1[5]/,/22\/Jun\/2017:1[6]/p' $logpath|awk '{print $1}'|sort -n|uniq|wc -l
# 访问100次以上的IP
awk '{print $1}' $logpath|sort -n|uniq -c|awk '{if($1>100) print $0}'|sort -rn
# 访问最频繁的请求(TOP50)
awk '{print $7}' $logpath |sort |uniq -c|sort -rn |head -n 50
# 统计每秒的请求数(TOP50)
awk '{print $4}' $logpath|cut -c 14-21|sort |uniq -c|sort -nr|head -n 50
# 统计每分钟的请求数(TOP50)
awk '{print $4}' $logpath|cut -c 14-18|sort|uniq -c|sort -nr|head -n 50
# 统计每小时请求数(TOP50)
awk '{print $4}' $logpath|cut -c 14-15|sort|uniq -c|sort -nr|head -n 50
# 传输时间超过1秒的请求(TOP20)
cat $logpath|awk '($NF > 1){print $7}'|sort -n|uniq -c|sort -nr|head -20
```
# LVS
LVS是Linux Virtual Server的简写， ，
## 工作模式
LVS有三种常见的负载均衡的模式： （ ） （ ）
**术语**
- **DS**： ，
- **RS**： ，
- **VIP**： ， ，
- **DIP**： ，
- **RIP**： ，
- **CIP**： ，
(假设 cip 是200.200.200.2， ）
### NAT模式(网络地址转换)
**NAT模式(NetWork Address Translation-网络地址转换)**。客户发出请求， ， ，
**原理**
- client发出请求（ ， ）
- 请求包到达lvs， （ ， ）
- 请求包到达rs， （ ， ）
- 这个回复包不能直接给client，
- 但是因为lvs是网关， ，
- 网关修改sip为VIP， （ ， ）
**优点**
- 配置简单
- 支持端口映射（看名字就知道）
- RIP一般是私有地址，
**缺点**
- LVS和所有RS必须在同一个vlan
- 进出流量都要走LVS转发
- LVS容易成为瓶颈
- 一般而言需要将VIP配置成RS的网关
**分析**
- **为什么NAT要求lvs和RS在同一个vlan？
因为回复包必须经过lvs再次修改sip为vip， ， （ ） ， ， ， ，
**NAT结构**
- LVS修改进出包的(sip, dip)的时只改了其中一个（ ）
- NAT最大的缺点是要求LVS和RS必须在同一个vlan，
### IP TUN模型(IP隧道)
**IP TUN模型(IP Tunneling-IP隧道)**。和DR模式差不多， ， ， ， ， ，
**原理**
- 请求包到达LVS后，
- 新的IP包的目的IP是某一RS的IP，
- RS收到报文后IPIP内核模块解封装，
- 发现目的IP是VIP， ，
**优点**
- 集群节点可以跨vlan
- 跟DR一样，
**缺点**
- RS上必须安装运行IPIP模块
- 多增加了一个IP头
- LVS和RS上的tunl0虚拟网卡上配置同一个VIP（ ）
**分析**
- **为什么IP TUN不要求同一个vlan？
因为IP TUN中不是修改MAC来路由， ，
- **IP TUN性能**
回包不走LVS， ，
**IP TUN结构**
- 图中红线是再次封装过的包，
- DR可能在小公司用的比较多，
### DR模式(直接路由)
**DR模式(Director Routing-直接路由)**。整个DR模式都是停留在第二层的数据链路层。直接修改MAC。实现报文的转发。
**原理**
- 请求流量(sip 200.200.200.2, dip 200.200.200.1) 先到达LVS
- 然后LVS， ，
- 然后丢给交换机，
- 选中的RS看到MAC地址是自己的、dip也是自己的，
- 回复包（ ， ）
- 经过交换机直接回复给client了（ ）
**优点**
- DR模式是性能最好的一种模式， ，
**缺点**
- 要求LVS和rs在同一个vlan
- RS需要配置vip同时特殊处理arp
- 不支持端口映射
**分析**
- **为什么要求LVS和RS在同一个vlan（ ） ？
因为DR模式依赖多个RS和LVS共用同一个VIP， ，
- **DR 模式为什么性能最好？**
因为回复包不走LVS了， ， ， ，
- **DR 模式为什么回包不需要走LVS了？
因为RS和LVS共享同一个vip， ， （ ）
**DR结构**
- 绿色是请求包进来，
### full NAT模式
**full NAT模式(full NetWork Address Translation-全部网络地址转换)**。
**原理（ ）
- client发出请求（ ）
- 请求包到达lvs， （ ， ）
- 请求包到达rs， （ ， ）
- 这个回复包的目的IP是VIP(不像NAT中是 cip)，
- lvs修改sip为vip， ， （ ， ）
**优点**
- 解决了NAT对LVS和RS要求在同一个vlan的问题，
**缺点**
- RS看不到cip（ ）
- 进出流量还是都走的lvs， （ ）
**分析**
- **为什么full NAT解决了NAT中要求的LVS和RS必须在同一个vlan的问题？
因为LVS修改进来的包的时候把(sip, dip)都修改了(这也是full的主要含义吧)， （ ） ， ， ， ，
- **为什么full NAT后RS看不见cip了？
因为cip被修改掉了， ， ， ，
**full NAT结构**
- full NAT解决了NAT的同vlan的要求，
- 但还没解决进出流量都走LVS的问题（ ）
### ENAT模式
**ENAT模式(enhence NAT)**。ENAT模式在内部也会被称为 三角模式或者DNAT/SNAT模式。
**原理**
- client发出请求（ ， ）
- 请求包到达lvs， （ ， ） ，
- 请求包根据ip路由到达rs，
- 回复包(RIP, vip)被ctk模块截获， （
- 因为回复包的目的地址是cip所以不需要经过lvs，
**优点**
- 不要求LVS和RS在同一个vlan
- 出去的流量不需要走LVS，
**缺点**
- 集团实现的自定义方案， （ ）
**分析**
- **为什么ENAT的回复包不需要走回LVS了？
因为full NAT模式下要走回去是需要LVS再次改写回复包的IP， ，
- **为什么ENAT的LVS和RS可以在不同的vlan？
跟full NAT一样。
**ENAT结构**
## 调度算法
### 静态调度算法
只根据算法进行调度 而不考虑后端服务器的实际连接情况和负载情况。
- **RR： （ ）
调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载｡
- **WRR： （ ）
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
- **DH： （ ）
根据请求的目标IP地址，
- **SH： （ ）
源地址散列”调度算法根据请求的源IP地址，
### 动态调度算法
- **LC： （ ）
调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用”最小连接”调度算法可以较好地均衡负载。
- **WLC： （ ）
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
- **SED： （ ）
在WLC基础上改进， （ ） ， ， ， ， ： ，
- **NQ永不排队/最少队列调度（ ）
无需队列。如果有台 realserver的连接数＝ ， ， ， ， ， ， ， ， ，
- **LBLC： （ ）
基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡， ， ，
- **LBLCR： （ ）
带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡， ， ， ， ， ； ， ， ， ， ， ，
## 常见问题分析
### 脑裂
由于两台高可用服务器对之间， ， ， ， ， ， ， ， ，
**1）
- 心跳链路故障，导致无法通信
- 开启防火墙阻挡心跳消息传输
- 心跳网卡地址配置等不正确
- 其他： ， ，
备注：
- 心跳线坏了（故障或老化）
- 网卡相关驱动坏了， （ ）
- 心跳线间连接的设备故障（网卡及交换机）
- 仲裁机器出问题
**2）
- 采用串行或以太网电缆连接，同时用两条心跳线路
- 做好裂脑的监控报警，在问题发生时人为第一时间介入仲裁
- 启用磁盘锁，即正在服务的一方只在发现心跳线全部断开时，才开启磁盘锁
- fence设备（ ）
- 增加仲裁盘
- 加冗余线路
### 负载不均
**原因分析**
- lvs自身的会话保持参数设置。优化：
- lvs调度算法设置，
- 后端RS节点的会话保持参数，
- 访问量较少的情况下，不均衡的现象更加明显
- 用户发送的请求时间长短和请求资源多少以及大小
### 排错
先检查客户端到服务端——>然后检查负载均衡到RS端——>最后检查客户端到LVS端。
- 调度器上lvs调度规则及IP正确性
- RS节点上VIP和ARP抑制的检查
**生成思路**
- 对绑定的VIP做实时监控，
- 把绑定的VIP做成配置文件，
**ARP抑制的配置思路**
- 如果是单个VIP，
- 如果RS端有多个VIP绑定， ，
- RS节点上自身提供服务的检查
- 辅助排除工具有tcpdump、ping等
- 负载均衡和反向代理三角形排查理论
# Keepalived
Keepalived是一个免费开源的， & 7交换机制软件， （ ） （ ） ， （ ） ，
## 功能体系
Keepalived的所有功能是配置keepalived.conf文件来实现的。上图是Keepalived的功能体系结构， ：
- **内核空间（ ）
主要包括IPVS（ ， ） （ ）
- **用户空间（ ）
- WatchDog：
- VRRP Stack： ， ，
- Checkers： ， ， ，
- IPVS wrapper：
- Netlink Reflector：
**重要功能**
- 管理LVS负载均衡软件
- 实现LVS集群节点的健康检查中
- 作为系统网络服务的高可用性（ ）
**高可用故障切换转移原理**
Keepalived高可用服务对之间的故障切换转移，
在 Keepalived服务正常工作时， （ ） ， ， ， ， ， ， ， ，
**VRRP**
全称Virtual Router Redundancy Protocol ,中文名为虚拟路由冗余协议 ， ，
## 脑裂问题
在高可用（ ） ， ， ， ， ， ， ； ， ， （ ）
对付HA系统“裂脑”的对策， ：
- 添加冗余的心跳线， ： （ ） ，
- 启用磁盘锁。正在服务一方锁住共享磁盘， ， ， ， ， ： （ ）
- 设置仲裁机制。例如设置参考IP（ ） ， ， ， ， （ ） ， ， ， ，
### 产生原因
一般来说，裂脑的发生，有以下几种原因：
- 高可用服务器对之间心跳线链路发生故障，导致无法正常通信
- 因心跳线坏了（包括断了，老化）
- 因网卡及相关驱动坏了， （ ）
- 因心跳线间连接的设备故障（网卡及交换机）
- 因仲裁的机器出问题（采用仲裁的方案）
- 高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输
- 高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败
- 其他服务配置不当等原因， ，
**提示：** Keepalived配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。
### 解决方案
在实际生产环境中，我们可以从以下几个方面来防止裂脑问题的发生：
- 同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息
- 当检测到裂脑时强行关闭一个心跳节点（ ， ） ，
- 做好对裂脑的监控报警（如邮件及手机短信等或值班）.在问题发生时人为第一时间介入仲裁，降低损失。例如，百度的监控报警短倍就有上行和下行的区别。报警消息发送到管理员手机上，管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障，这样解决故障的时间更短.
在实施高可用方案时，要根据业务实际需求确定是否能容忍这样的损失。对于一般的网站常规业务，这个损失是可容忍的。
## 安装部署
**第一步：
`yum install keepalived -y `
```
/etc/keepalived
/etc/keepalived/keepalived.conf #keepalived 服务主配置文件
/etc/rc.d/init.d/keepalived #服务启动脚本
/etc/sysconfig/keepalived
/usr/bin/genhash
/usr/libexec/keepalived
/usr/sbin/keepalived
```
**第二步：配置文件说明**
全局配置
```shell
global_defs { # 全局配置
notification_email { # 定义报警邮件地址
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc # 定义发送邮件的地址
smtp_server 192.168.200.1 # 邮箱服务器
smtp_connect_timeout 30 # 定义超时时间
router_id LVS_DEVEL # 定义路由标识信息，相同局域网唯一
}
```
虚拟ip配置brrp
```shell
vrrp_instance VI_1 { # 定义实例
state MASTER # 状态参数 master/backup 只是说明
interface eth0 # 虚IP地址放置的网卡位置
virtual_router_id 51 # 同一家族要一直，
priority 100 # 优先级决定是主还是备 越大越优先
advert_int 1 # 主备通讯时间间隔
authentication {
auth_type PASS
auth_pass 1111 # 认证
}
virtual_ipaddress {
192.168.200.16 # 设备之间使用的虚拟ip地址
192.168.200.17
192.168.200.18
}
}
```
**第三步：最终配置文件**
主负载均衡服务器配置
```shell
[root@lb01 conf]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id lb01
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.3
}
}
```
备负载均衡服务器配置
```shell
[root@lb02 ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id lb02
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.3
}
}
```
**第四步：
```shell
[root@lb02 ~]# /etc/init.d/keepalived start
Starting keepalived: [ OK ]
```
**第五步：在进行访问测试之前要保证后端的节点都能够单独的访问**
测试连通性. 后端节点
```shell
[root@lb01 conf]# curl -H host:www.etiantian.org 10.0.0.8
web01 www
[root@lb01 conf]# curl -H host:www.etiantian.org 10.0.0.7
web02 www
[root@lb01 conf]# curl -H host:www.etiantian.org 10.0.0.9
web03 www
[root@lb01 conf]# curl -H host:bbs.etiantian.org 10.0.0.9
web03 bbs
[root@lb01 conf]# curl -H host:bbs.etiantian.org 10.0.0.8
web01 bbs
[root@lb01 conf]# curl -H host:bbs.etiantian.org 10.0.0.7
web02 bbs
```
**第六步：
```shell
[root@lb01 conf]# ip a
1: lo: < LOOPBACK , UP , LOWER_UP > mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: < BROADCAST , MULTICAST , UP , LOWER_UP > mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:90:7f:0d brd ff:ff:ff:ff:ff:ff
inet 10.0.0.5/24 brd 10.0.0.255 scope global eth0
inet 10.0.0.3/24 scope global secondary eth0:1
inet6 fe80::20c:29ff:fe90:7f0d/64 scope link
valid_lft forever preferred_lft forever
3: eth1: < BROADCAST , MULTICAST , UP , LOWER_UP > mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:90:7f:17 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.5/24 brd 172.16.1.255 scope global eth1
inet6 fe80::20c:29ff:fe90:7f17/64 scope link
valid_lft forever preferred_lft forever
```
**第七步：【总结】配置文件修改**
Keepalived主备配置文件区别：
- router_id 信息不一致
- state 状态描述信息不一致
- priority 主备竞选优先级数值不一致
# HAProxy
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代 理， ， ， ， ，
## 四层负载均衡
所谓的四层就是ISO参考模型中的第四层。四层负载均衡也称为四层交换机，
以常见的TCP应用为例， ， ， ， ， ， ， ， ，
## 七层负载均衡
七层负载均衡器也称为七层交换机， ， ， ， ， ， ， ， ， ， ， ， ， ，
这里仍以常见的TCP应用为例， ， ， ， ， ，
**四层和七层负载均衡**
对比四层负载均衡和七层负载均衡运行的整个过程， ， ， ， ， ， ，
## 负载均衡策略
- roundrobin：
- static-rr：
- leastconn：
- source： ，
- uri：
- url_param：
- rdp-cookie(name)：
**常用的负载均衡算法**
- 轮询算法：
- 根据请求源IP算法：
- 最少连接者先处理算法：
## HAProxy与LVS的区别
HAProxy负载均衡与LVS负载均衡的区别：
- 两者都是软件负载均衡产品， ，
- LVS是基于四层的IP负载均衡技术，
- LVS工作在ISO模型的第四层， ， ，
- HAProxy虽然功能强大， ，
综上所述， ， ， ，
## 安装配置
**第一步：安装依赖**
```shell
[root@test ~] # yum -y install make gcc gcc-c++ openssl-devel
```
**第二步：
```shell
[root@test ~] # wget http://haproxy.1wt.eu/download/1.3/src/haproxy-1.3.20.tar.gz
[root@test ~] # tar zcvf haproxy-1.3.20.tar.gz
[root@test ~] # cd haproxy-1.3.20
[root@test ~] # make TARGET=linux26 PREFIX=/usr/local/haproxy # 将haproxy安装到/usr/local/haproxy
[root@test ~] # make install PREFIX=/usr/local/haproxy
```
Redis主从复制-部分重同步.jpeg
