vlambda博客
学习文章列表

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

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

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

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

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

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

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

5：工作模式有4种：

(2) dr 直接路由

(3) tun 隧道

(4) full-nat 

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

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

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

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

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

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

5：不能做Web服务器即Cache

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

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

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

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

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

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

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

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

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

缺点：无

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

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

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

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