从架构上详解技术（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的Key的值设计是很有讲究的，不建议值超过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的，热点问题相对来说是很难出现的。关于读数据这个就基本不会出现热点问题了，因为消费者是根据partition的个数来确定的，一个partition只能对应一个消费组的一个消费者。当然会存在多个消费者的情况，一般情况不可能达到服务器读的承载量。
Clickhouse的架构
clickhouse的架构是Multi-Master多主架构，客户端访问任意一个节点都能得到相同的结果。clickhouse是一个大数据存储数据库，本身节点就有qps限制。其本身的热点问题是比较明显的，写入不允许高并发，读取也有高并发限制。我们看下clickhouse这种多主架构的一个请求的执行流程，如下图，client发起Request1请求发到节点Clickhouse A 这个请求会转发到Request B,Request C,Request D，等B,C,D节点返回结果之后会给节点A，然后由节点返回总的数据给Client。
总结：
- 关于热点问题要从读和写的方面去考虑，实现读或者写的分散就是解决热点问题的关键。
- 实现产品好的技术架构设计，热点问题是我们首要考虑的问题，架构的了解对我们解决热点问题是非常至关重要的。
公众号：利志分享（talk_lizhi），扫码即可关注。
