从架构上详解技术（SLB，Redis，Mysql，Kafka，Clickhouse）的各类热点问题

什么是热点问题？在我们生活中，定义是：比较受广大群众关注或者欢迎的新闻或者信息或指某时期引人注目的地方或问题。

这里我们要讲的是技术的热点问题，SLB 的热点问题，Redis 的热点问题，Mysql 的热点问题，分布式数据库集群的热点问题等，这类技术热点问题并不是所谓的引人注目的问题而是服务请求过多，流量集中的问题。

SLB

定义：服务器负载均衡（Server Load Balancing），实现多个服务器之间的负载均衡。

主流软件负载均衡有：1：LVS，2：Nginx，3：HAProxy

LVS

1：工作在网络 4 层，通过 VRRP 协议(仅作代理之用)，具体的流量是由 linux 内核来处理，因此没有流量的产生。

2：抗负载能力强，性能高，能达到 F5 的 60%，对内存和 CPU 资源消耗比较低

3：稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)

4：支持 8 种负载均衡算法：rr（轮询）、wrr（带权轮询）、lc（最小连接）、wlc（带权最小连接）、 lblc（基于局部性的最少连接调度算法）、lblcr（复杂的基于局部性最少的连接算法）、dh（目标地址散列调度算法 ）、sh（源地址散列调度算法 ）

5：工作模式有 4 种：

(1) nat 地址转换

(2) dr 直接路由

(3) tun 隧道

(4) full-nat 

Nginx

1：工作在网络 7 层，可以针对 http 应用做一些分流的策略，比如针对域名，目录结构

2：Nginx 仅能支持 http、https 和 Email 协议，这样就在适用范围较小。

3：对后端服务器的健康检查，只支持通过端口来检测，不支持通过 url 来检测

4：可以承担较高的负载压力且稳定，nginx 是为解决 c10k 问题而诞生的

5：Nginx 能做 Web 服务器即 Cache 功能。

HAProxy

1：支持两种代理模式：TCP（四层）和 HTTP（七层），支持虚拟主机

2：支持 url 检测后端的服务器出问题的检测会有很好的帮助。

3：支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求 URL）、rdp-cookie（根据 cookie）

4：支持负载均衡策略：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权 URL 哈希和加权参数哈希(Weighted Parameter Hash)

5：不能做 Web 服务器即 Cache

现在基本所有的公司的业务最前端都是一个负载均衡服务器承载流量，然后分发到各个后端服务器，参照下图，这样的架构应该是大多数公司的架构。从请求主要分三个层次。用户->负载均衡，负载均衡->微服务，微服务->后端服务。

关于负载均衡这一块的热点问题会出现在哪呢？从上面的分析看其实主要是在于散列调度算法，不管是源地址散列算法还是目标地址散列算法，可能会造成一个局域网的很多用户同时请求同一服务而造成这个负载均衡服务器量很大，而造成负载均衡服务器出问题，这就是所说的热点问题。在使用散列调度算法就容易遇到热点问题，因为散列容易造成请求不平均，请求量大可能触发到同一个负载均衡服务器。如果使用轮询，负载请求会平均，不容易触发热点问题。当然啦，负载均衡实际基本不会出现问题，因为要是负载均衡出问题，要么业务量几百万倍几千万倍增长，那确实说明这个量很大很大。

Redis 的架构

关于 Redis 的部署架构主要有单机模式，主从模式，哨兵模式，redis cluser 模式。其实严格意义上来说部署只有三种，哨兵模式其实基于对主从模式的稳定性优化，切主节点能实现自动化。

单机模式

优点：1、部署简单。2、数据一致性高

缺点：1、可靠性无法保证。2、处理能力有限

主从模式（如下图）

优点：1、可靠性得到一定保障，当节点出问题，可由其他节点来提供。2、提升了读能力，分散主节点的读压力

缺点：1、主节点的写能力和存储能力受单机限制。2、主节点宕机，切换从节点需要业务方手动切换，进行人工干预。

哨兵模式（如下图）

优点：1、基于主从模式，主从可以自动切换。

缺点：1、节点的承载能力有限，写能力和存储能力都有限。

redis cluser 模式（如下图）

优点：高可用、可扩展性、分布式、支持容错。redis cluster 接受客户端请求，会首先通过对 key 进行 CRC16 校验并对 16384 取模（CRC16(key)%16383）计算出 key 所在的槽，确定槽所在的节点，然后再到对应的节点上进行取数据或者存数据，这样就实现了数据的访问更新。

缺点：无

关于 redis 的三种架构模式，redis 的集群架构的热点问题就明显了，主从模式，写请求是很明显的热点问题，读请求在读节点中轮询读取，则不会出现热点问题，但是如果读节点是通过散列方式，则也会出现热点问题。关于 redis cluster 架构是多主，多从的架构，理论上是能很好的解决热点问题，写请求随机到不同的主从集群不同的主节点中，读请求会到不同的主从集群的从节点中，这样就很好的分散了请求，做到这一点其实至少要保证每个主节点都有一个主备。如果只有一个主节点，那其实和主从模式没有区别了，这样的话写的热点问题和读的热点问题就容易出现了，尤其是 redis 的大 key 读取问题，当然不管是哪种模式下都会存在大 key 读取的热点问题，要解决大 key 热点问题，redis 的值设计是很有讲究的，不建议值超过 128KB。基础知识了解之后，关于如何选架构成为解决热点问题，提升服务稳定性的关键点。

Mysql 的架构

关于 Mysql 的架构（如下图），其实只有主从模式，在业务中我们处理量大的问题通常使用读写分离，mysql 是做数据持久化存储，读写分离也是有通过中间件来实现。关于 Mysql 的读和写热点问题，其实还是比较明显，不管是读和写，量达到一定程度，都会存在的。在我们很大的业务流量下，我们 Mysql 的前端都会有 Redis 或者中间件的来挡量。

Kafka 的架构

关于 Kafka 的架构（如下图）是一个分布式多分区，多副本，多订阅者的高可用，高性能，高并发的 MQ 系统。Kafka 写数据是从 Producer 生成，需指定 Topic，最终是写入到某一个 Partition（某个 Leader 副本的 Partition）。Kafka 的消费数据则是从 Leader 副本的某个 Partition 读数据去消费。好了我们来看下写入和读取的热点问题，如果客户端一直请求同一个 topic，同一个 partition，等这个量达到集群的承载量就容易出现热点问题了。所以要避免这样的问题我们尽量让 partition 能够多一些，让数据随机平均到不同的 partition 上，这样承载量会更大，热点问题就不容易出现。再者 kafka 是号称百万 qps 的（这个涉及到 kafka 的底层实现，顺序 io，零拷贝等机制），热点问题相对来说是很难出现的。关于读数据这个就基本不会出现热点问题了，因为消费者是根据 partition 的个数来确定的，一个 partition 只能对应一个消费组的一个消费者。当然会存在多个消费者的情况，一般情况不可能达到服务器读的承载量。

Clickhouse 的架构

clickhouse 的架构（如下图）是 Multi-Master 多主架构，客户端访问任意一个节点都能得到相同的结果。clickhouse 是一个大数据存储数据库，本身节点就有 qps 限制。其本身的热点问题是比较明显的，写入不允许高并发，读取也有高并发限制。我们看下 clickhouse 这种多主架构的一个请求的执行流程，如下图，client 发起 Request1 请求发到节点 Clickhouse A 这个请求会转发到 Request B,Request C,Request D，等 B,C,D 节点返回结果之后会给节点 A，然后由节点返回总的数据给 Client。

总结

1. 关于热点问题要从读和写的方面去考虑，实现读或者写的分散就是解决热点问题的关键。

2. 实现产品好的技术架构设计，热点问题是我们首要考虑的问题，架构的了解对我们解决热点问题是非常至关重要的。