什么是热点？在我们的生活中，其定义是：一般大众比较关心或流行的新闻或信息，或指在一定时期内引起注意的地点或问题。下面我们就来聊一聊技术热点问题，SLB热点问题，Redis热点问题，Mysql热点问题，分布式数据库集群热点问题等等，这些技术热点问题并不是所谓的吸引眼球的问题，而是而是服务请求过多，流量集中的问题。SLB定义：服务器负载均衡（ServerLoadBalancing），实现多台服务器之间的负载均衡。主流软件负载均衡包括：1：LVS，2：Nginx，3：HAProxy1LVS(1)工作在网络的第4层，通过VRRP协议（仅用于proxy），具体流量由linux内核处理，所以没有流量产生。(2)抗负载能力强，性能高，可达F5的60%，内存和CPU资源消耗相对较低(3)稳定，高可靠，自带完善的热备方案(Keepalived+lvs)(4)支持8种负载均衡算法：rr（roundrobin）、wrr（weightedroundrobin）、lc（最小连接数）、wlc（加权最小连接数）、lblc（locality-basedleastconnectionschedulingalgorithm）、lblcr（complexconnectionalgorithmbased）ontheleastlocality),dh(目的地址哈希调度算法),sh(源地址哈希调度算法)(5)有4种工作模式：nat地址转换drdirectroutingtuntunnelfull-nat2Nginx(1)works位于网络的第7层，可以对http应用实现一些导流策略，比如域名、目录结构等(2)Nginx只能支持http、https和Email协议，应用范围有限。（3）后端服务器的健康检查只支持通过端口检测，不支持通过url检测（4）能承受高负载压力且稳定，nginx就是为解决c10k问题而诞生的（5）Nginx可以用作Web服务器，即Cache功能。3HAProxy（1）支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机（2）支持url检测，对后端检测服务器问题会有很大帮助。（3）支持负载均衡算法：Round-robin（循环）、Weight-round-robin（带权重的循环）、source（保留原始地址）、RI（请求URL）、rdp-cookie（根据cookie）（4）支持负载均衡策略：动态加权轮循（DynamicRoundRobin）、加权源地址哈希（WeightedSourceHash）、加权URL哈希和加权参数哈希（WeightedParameterHash）（5）不能作为Web服务器或缓存目前基本上所有公司的业务前端都是一个负载均衡服务器承载流量，然后分发到各个后端服务器。参考下图，这样的架构应该是大部分公司的架构。请求分为三个主要级别。用户->负载均衡器，负载均衡器->微服务，微服务->后端服务。负载均衡的热点问题会出现在哪里？从上面的分析来看，主要是hash调度算法的问题。无论是源地址哈希算法还是目标地址哈希算法，都可能导致一个局域网内有很多用户同时请求同一个服务，造成负载均衡服务器很大。并且导致负载均衡服务器出现问题，这就是所谓的热点问题。使用hash调度算法时，很容易遇到热点问题，因为hash容易造成请求不均，大量请求可能会触发同一个负载均衡服务器。如果采用轮询的方式，负载请求会被平均化，不易引发热点。当然，负载均衡基本不会有问题，因为如果负载均衡出现问题，或者业务量增长几百万、几千万倍，确实说明量很大。Redis架构Redis的部署架构主要有单机模式、主从模式、哨兵模式、rediscluser模式。其实严格来说，部署只有三种。哨兵模式其实是基于主从模式的稳定性优化，可以自动切换主节点。1单机模式优点：1、部署简单。2.数据一致性高缺点：1.可靠性无法保证。2、处理能力有限2、主从模式的优点（如下图）：1、可靠性在一定程度上得到保证。当一个节点发生故障时，可以由其他节点提供。2、提高读能力，分散主节点的读压力。缺点：1.主节点的写入能力和存储能力受限于单机。2、主节点宕机，切换从节点需要业务方手动切换，进行人工干预。3Sentinel模式（如下图）优点：1.基于主从模式，可以自动切换主从。缺点：1.节点承载能力有限，写入和存储能力都有限。4rediscluser模式的优点（如下图）：高可用、可扩展、分布式、支持容错。当rediscluster接受客户端请求时，首先会计算出key所在的slot，对key进行CRC16校验并对16384取模(CRC16(key)%16383)，确定slot所在的节点，并然后去对应的节点执行Fetchdata或者savedata，实现数据的访问更新。缺点：不管redis的三种架构模式，redis的集群架构的热点问题很明显。在主从模式下，写请求是一个明显的热点问题。读请求在读节点轮询读取，不会出现热点。问题，但是如果对读节点进行哈希处理，也会出现热点问题。Redis集群架构是多主多从架构。理论上可以很好的解决热点问题。写请求会随机发送到不同主从集群的不同master节点，读请求会发送到不同主从集群的slave。这样就很好的分散了请求。其实至少要保证每个master节点都有master和slave。如果只有一个master节点，其实和master-slave模式没什么区别。在这种情况下，很容易出现写入和读取的热点，尤其是redis的大key读取问题。当然无论是什么模式都存在大键读的热点问题。为了解决大key的热点问题，redis的value设计很有讲究。不建议超过128KB。了解了基础知识后，如何选择架构就成为解决热点问题、提升服务稳定性的关键点。Mysql架构关于Mysql的架构（如下图），其实只有主从模式。在业务中，我们通常使用读写分离来处理大体量的问题。完成。关于Mysql读写的热点问题，其实是比较明显的。无论是阅读还是写作，只要音量达到一定程度就会存在。在我们业务流量大的情况下，我们的Mysql前端会有Redis或者中间件来挡流量。Kafka的架构关于Kafka的架构（如下图所示）是一个分布式多分区、多副本、多订阅者的高可用、高性能、高并发的MQ系统。Kafka写数据是从Producer产生的，需要指定Topic，最后写入一个Partition（一个Leader副本的Partition）。Kafka的消费数据是通过从Leader副本的一个Partition中读取数据来消费的。好吧，让我们看看写作和阅读的热点。如果客户端一直请求同一个主题和分区，当容量达到集群的容量时，很容易出现热点。所以为了避免这样的问题，我们尽量做更多的分区，让数据随机平均到不同的分区，这样承载量会更大，也不容易出现热点。另外，Kafka号称百万级qps（这涉及到Kafka的底层实现，顺序io，零拷贝等机制），热点相对不易出现。对于读取数据，基本不会出现热点问题，因为消费者是根据partition的个数来确定的，一个partition只能对应一个consumergroup的一个consumer。当然，会有多个消费者。一般情况下是不可能达到服务器的负载能力的。Clickhouse架构clickhouse的架构（如下图）是Multi-Master多Master架构，客户端访问任何一个节点都可以得到相同的结果。Clickhouse是一个大数据存储数据库，自身节点有qps限制。自身的热点问题比较明显。写不允许高并发，读也限制高并发。下面我们来看看一个请求在clickhouse这样的多主架构下的执行过程。如下图，客户端发起一个Request1请求，发送给节点ClickhouseA，这个请求会被转发给RequestB、RequestC、RequestD，等待B、C、D节点返回.结果将发送给节点A，然后节点将总数据返回给客户端。总结热点问题要从读写两方面考虑，实现读写的分散是解决热点问题的关键。做好产品的技术架构设计，热点问题是我们首要考虑的问题，理解架构对我们解决热点问题非常重要。
