80.亿级架构核心：流量架构.md

亿级架构核心：流量架构

根据之前的二八定律和冗余系数，假设1亿用户，大概知道了高峰期每秒可能会有10万的qps之后，来看一下系统中各层组件的部署架构。

各组件的并发能力基线值

1. Nginx: 一个高性能的Web-Server和实施反向代理的软件
2. LVS: linux virtual srever, 使用集群技术，实现在linux操作系统层面的一个高性能，高可用，负载均衡服务器
3. Keepalived: 一款用来检测服务状态存活的软件，常用来做高可用
4. F5:一个高性能，高可用，负载均衡的硬件设备
5. DNS轮询：通过在DNS-Server上对一个域名设置多个IP解析，来扩充Web-Server性能实施负载均衡的技术

Tomcat

tomcat默认配置的最大请求数是150，也就是说同时支持150个并发。

具体能承载多少并发，需要看硬件的配置，CPU越多性能越高，分配给JVM的内存越多，性能也就会越高，但是会增加GC的负担，当某个应用拥有250个以上的并发的时候，应考虑应用服务器的集群。

Nginx

官方的数据是5W的并发量。

1. Nginx只对请求进行转发和响应的转发，而没有进行业务逻辑的处理，大部分时间花在与其他计算的IO上。
2. Nginx的IO模型采用的是单线程或者是少线程，异步非阻塞的模式。（Tomcat是一个连接一个线程，同步阻塞的模式），避免了打开IO通道等待数据传输的过程（仅仅是在数据传到了，再来接受即可），极大的缩短了线程调度和IO处理时间。

MySQL

1. 主键查询： 千万级别数据 = 1-10 ms 4核心 8线程为 1000qps * 8 = 8000qps
2. 唯一索引查询： 千万级别数据 = 10-100 ms, 4核心 8线程 100qps * 8 = 800qps
3. 非唯一索引查询： 千万级别数据 = 100-1000ms ， 4核心 8线程 10qps * 8 = 80qps
4. 无索引： 百万级别数据 = 1000ms+

综合来说，mysql的并发处理能力大约到1500 qps

MySQL数据库事务处理能力

• 更新删除（与查询相同）
• 插入操作，依赖于配置优化，比查询效率低

Redis

Redis单机QPS为5w左右

由于生产环境下业务服务器总响应延迟需要控制在100ms内，为了尽量减少日志输出环节的耗时，考虑将日志吐到redis中缓存。 由其他程序异步的从redis中去数据，在生产环境改造日志数据系统之前，对单机的redis读写性能做了测试。

SpringCloud Gateway

一次8核心8G的压力测试结果：
并发数： 300
netty工作线程数（reactor.netty.ioWorkerCount）：8 （default）
样本数据：返回1.5k大小
服务端响应时间： 10ms左右
测试时长： 5分钟
JVM内存：2G

QPS大概在10000左右

消息队列

Kafka

吞吐量大概在10左右

NoSQL

hbase

7W+ QPS

ES集群

7W+ QPS

流量架构

假设目前用户的规模在10w左右

亿级用户的架构

异地多活的流量架构

1. 通过dns和gslb（智能负载均衡器）做负载均衡，将请求路由到最近的可用服务的机房
2. 服务全部机房内自治，不进行跨机房访问
3. 不同的机房，进行数据异步双向复制