架构师，应对千万级流量，应该怎样设计架构

01

前言

我有一个朋友的网站最近达到了千万级流量，虽然是一件令人值得高兴的事情，但他怎么也高兴不起来。系统挂掉的频率越来越多，用户体验明显下降。

既然他向我求助了，不能不帮，我是这样做的，首先了解这个网站的现状，架构层面和业务层面。前期先给一个简单的应急方案。

我总结了他们的架构只有一个热点服务，架构业务也比较简单。

我的建议是增加cdn，减少静态资源的访问压力，业务拆分，隔离热点，独立部署，读写分离，分散数据库压力。

这是我提出的简单的方案。

02

清楚网站Qps计算公式

峰值qps=（日总pv数*80%）/（日总秒数*20%）假设一台服务器承受的qps是100，通过计算，千万级流量大概需要的服务器是5台。

最后我建议他架构需要系统的改造，需要进行拆分、队列、缓存、降级、限流。

03

拆分

刚开始的时候架构是一个混沌状态，所有的东西都放在一起，一台应用服务器，包含文件存储，缓存和数据库加上我们的业务逻辑。

我们首先要加入负载均衡服务器，应用服务器分布式加负载均衡，数据库服务器读写分离，集群。引入分布式消息中间件，nosql数据库，搜索引擎服务器，加入分布式缓存。

总之拆分的维度要从系统维度，功能维度和读写维度进行设计。

04

消息队列

异步，平缓的进行处理，达到流量削峰，瞬间流量巨大，几万人抢购几件商品，目的，让服务器处理请求更加平缓，保护服务器资源。所有调用请求去排队，即使高峰期也不会对调用者直接产生影响。

分布式事务解决方案：使用消息队列的形式来解决。

分布式事务需要保证多个系统之间如果相互调用，必须保证系统的执行结果一致，都成功，或者都失败。使用消息队列，从同步调用改为异步调用，保证最终一致性。

05

缓存

缓存是架构必备，缓存主要分为客户端缓存（浏览器，app），网络缓存（cdn），接入缓存（nginx）应用层缓存（redis）。

使用缓存要保证数据的一致性，缓存数据和数据库数据要一致，无论多大的并发。cache Aside策略：先写数据库，后删除缓存，从数据库读数据到缓存。

还有一个读/写 through策略：用户只与缓存打交道，有缓存和数据库通信，写入或者读取数据。这个需要引入缓存组件。

缓存雪崩和缓存穿透：雪崩，大量数据数据同时失效，数据库压力太大，解决方案：为有效值增加随机值，使用高可用分布式缓存，热点数据永远不过期，在缓存失效后，通过加锁或者队列来控制读数据库的线程数量。

缓存穿透：缓存中没有，需要访问数据库，解决方案：缓存空值和采用布隆过滤器。

06

降级

在系统压力过大的时候，可以降级，改为默认内容。不更新数据库，先放缓存，等高峰过后，再去更新数据库。还有我们的springcloud 使用的hystrix。降级的目的是保证系统的高可用。降级分为这样几种：超时降级，限流降级，统计失败次数降级。

07

限流

对于系统，在应对高性能压力的场景下，限流是一种解决方案，对请求进行限制，保证系统平稳运行。