亿级流量网站架构核心技术---高可用设计原则

最新推荐文章于 2024-06-12 21:34:11 发布
最新推荐文章于 2024-06-12 21:34:11 发布
阅读量962 收藏 7
点赞数
分类专栏： 读书笔记
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/l1394049664/article/details/82050066
版权

亿级流量网站架构核心技术---高可用设计原则

目录

一、负载均衡与反向代理

二、隔离术

1、线程隔离

2、进程隔离

3、集群隔离

4、机房隔离

5、读写隔离

6、动静隔离

7、爬虫隔离

8、热点隔离

9、资源隔离

10、使用Hystrix实现隔离

11、基于Servlet3实现请求隔离

三、限流详解

1、限流算法

1）、令牌桶算法

2）、漏桶算法

3）、令牌桶和漏桶对比

2、应用级限流

1）、限流总并发/连接/请求数

2）、限流总资源数

3）、限流某个接口的总并发/请求数

4）、限流某个接口的时间窗请求数（这种方式比较常用）

5）、平滑限流某个接口的请求数（整形流量：令牌桶和漏桶算法）

3、分布式限流

4、接入层限流

1）、ngx_http_limit_conn_module

2）、ngx_http_limit_req_module

3）、lua-resty-limit-traffic（OpenResty）

四、降级特技

1、降级预案

2、自动开关降级

1）、超时降级

2）、统计失败次数降级

3）、故障降级

4）、限流降级

3、人工开关降级

4、读服务降级

5、写服务降级

6、多级降级

7、配置中心

8、使用Hystrix实现降级

9、使用Hystrix实现熔断

五、超时与重试机制

1、代理层超时与重试

2、Web容器超时

3、中间件客户端超时与重试

4、数据库客户端超时

5、NoSQL客户端超时

6、业务超时

7、前端Ajax超时

六、回滚机制

1、事务回滚

2、代码库回滚

3、部署版本回滚

4、数据版本回滚

5、静态资源版本回滚

七、压测与预案

1、系统压测

1）、线下压测

2）、线上压测

2、系统优化和容灾

3、应急预案

一、负载均衡与反向代理

upstream配置

负载均衡算法

失败重试

健康检查

其他配置

长连接

HTTP反向代理示例

HTTP动态负载均衡

TCP四层负载均衡

二、隔离术

1、线程隔离

线程的隔离其实是线程池的隔离

2、进程隔离

把一个大而全的系统进行拆分，拆分成几个不同的子系统

3、集群隔离

4、机房隔离

尽量不要出现跨机房服务调用

5、读写隔离

数据库访问的读写分离

6、动静隔离

把静态的CSS和JS资源放在CDN上加速访问

7、爬虫隔离

8、热点隔离

比如，为秒杀活动单独做一个独立的系统，不会因为该系统的瞬间访问，影响到系统的系统资源

9、资源隔离

CPU、磁盘、网卡等，可以把这些资源绑定到指定的应用进程中来提升性能

10、使用Hystrix实现隔离

Hystrix简介

 

11、基于Servlet3实现请求隔离

请求解析和业务处理线程池分离

业务线程池隔离

业务线程池监控/运维/降级

如何使用Servlet3异步化

 

三、限流详解

1、限流算法

常见的限流算法有：令牌桶、漏桶。计数器也可以进行粗暴限流实现。

1）、令牌桶算法

令牌桶算法是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌。令牌桶算法的描述如下：

  • 假设限制2r/s，则按照500毫秒的固定速率往桶中添加令牌；

  • 桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃或拒绝；

  • 当一个n个字节大小的数据包到达，将从桶中删除n个令牌，接着数据包被发送到网络上；

  • 如果桶中的令牌不足n个，则不会删除令牌，且该数据包将被限流（要么丢弃，要么缓冲区等待）。

2）、漏桶算法

漏桶作为计量工具（The Leaky Bucket Algorithm as a Meter）时，可以用于流量整形（Traffic Shaping）和流量控制（TrafficPolicing），漏桶算法的描述如下：

  • 一个固定容量的漏桶，按照常量固定速率流出水滴；

  • 如果桶是空的，则不需流出水滴；

  • 可以以任意速率流入水滴到漏桶；

  • 如果流入水滴超出了桶的容量，则流入的水滴溢出了（被丢弃），而漏桶容量是不变的。

3）、令牌桶和漏桶对比

  • 令牌桶是按照固定速率往桶中添加令牌，请求是否被处理需要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求；

  • 漏桶则是按照常量固定速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝；

  • 令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌，4个令牌），并允许一定程度突发流量；

  • 漏桶限制的是常量流出速率（即流出速率是一个固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），从而平滑突发流入速率；

  • 令牌桶允许一定程度的突发，而漏桶主要目的是平滑流入速率；

  • 两个算法实现可以一样，但是方向是相反的，对于相同的参数得到的限流效果是一样的。

2、应用级限流

1）、限流总并发/连接/请求数

对于一个应用系统来说一定会有极限并发/请求数，即总有一个TPS/QPS阀值，如果超了阀值则系统就会不响应用户请求或响应的非常慢，因此我们最好进行过载保护，防止大量请求涌入击垮系统。

如果你使用过Tomcat，其Connector 其中一种配置有如下几个参数：

  • acceptCount：如果Tomcat的线程都忙于响应，新来的连接会进入队列排队，如果超出排队大小，则拒绝连接；
  • maxConnections： 瞬时最大连接数，超出的会排队等待；
  • maxThreads：Tomcat能启动用来处理请求的最大线程数，如果请求处理量一直远远大于最大线程数则可能会僵死。

详细的配置请参考官方文档。另外如Mysql（如max_connections）、Redis（如tcp-backlog）都会有类似的限制连接数的配置。

2）、限流总资源数

如果有的资源是稀缺资源（如数据库连接、线程），而且可能有多个系统都会去使用它，那么需要限制应用；可以使用池化技术来限制总资源数：连接池、线程池。比如分配给每个应用的数据库连接是100，那么本应用最多可以使用100个资源，超出了可以等待或者抛异常。

3）、限流某个接口的总并发/请求数

如果接口可能会有突发访问情况，但又担心访问量太大造成崩溃，如抢购业务；这个时候就需要限制这个接口的总并发/请求数总请求数了；因为粒度比较细，可以为每个接口都设置相应的阀值。可以使用Java中的AtomicLong进行限流：

try {
    if(atomic.incrementAndGet() > 限流数) {
        //拒绝请求
   }
    //处理请求
} finally {
    atomic.decrementAndGet();
}

适合对业务无损的服务或者需要过载保护的服务进行限流，如抢购业务，超出了大小要么让用户排队，要么告诉用户没货了，对用户来说是可以接受的。而一些开放平台也会限制用户调用某个接口的试用请求量，也可以用这种计数器方式实现。这种方式也是简单粗暴的限流，没有平滑处理，需要根据实际情况选择使用；

4）、限流某个接口的时间窗请求数（这种方式比较常用）

即一个时间窗口内的请求数，如想限制某个接口/服务每秒/每分钟/每天的请求数/调用量。如一些基础服务会被很多其他系统调用，比如商品详情页服务会调用基础商品服务调用，但是怕因为更新量比较大将基础服务打挂，这时我们要对每秒/每分钟的调用量进行限速；一种实现方式如下所示：

LoadingCache<Long, AtomicLong> counter =
        CacheBuilder.newBuilder()
                .expireAfterWrite(2, TimeUnit.SECONDS)
                .build(new CacheLoader<Long, AtomicLong>() {
                    @Override
                    public AtomicLong load(Long seconds) throws Exception {
                        return new AtomicLong(0);
                    }
                });
long limit = 1000;
while(true) {
    //得到当前秒
    long currentSeconds = System.currentTimeMillis() / 1000;
    if(counter.get(currentSeconds).incrementAndGet() > limit) {
        System.out.println("限流了:" + currentSeconds);
        continue;
    }
    //业务处理
}

我们使用Guava的Cache来存储计数器，过期时间设置为2秒（保证1秒内的计数器是有的），然后我们获取当前时间戳然后取秒数来作为KEY进行计数统计和限流，这种方式也是简单粗暴，刚才说的场景够用了

5）、平滑限流某个接口的请求数（整形流量：令牌桶和漏桶算法）

之前的限流方式都不能很好地应对突发请求，即瞬间请求可能都被允许从而导致一些问题；因此在一些场景中需要对突发请求进行整形，整形为平均速率请求处理（比如5r/s，则每隔200毫秒处理一个请求，平滑了速率）。这个时候有两种算法满足我们的场景：令牌桶和漏桶算法。Guava框架提供了令牌桶算法实现，可直接拿来使用。

Guava RateLimiter提供了令牌桶算法实现：平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。

SmoothBursty

RateLimiter limiter = RateLimiter.create(5);
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());

将得到类似如下的输出：
  0.0
  0.198239
  0.196083
  0.200609
  0.199599
  0.19961
  • RateLimiter.create(5) 表示桶容量为5且每秒新增5个令牌，即每隔200毫秒新增一个令牌；
  • limiter.acquire()表示消费一个令牌，如果当前桶中有足够令牌则成功（返回值为0），如果桶中没有令牌则暂停一段时间，比如发令牌间隔是200毫秒，则等待200毫秒后再去消费令牌（如上测试用例返回的为0.198239，差不多等待了200毫秒桶中才有令牌可用），这种实现将突发请求速率平均为了固定请求速率。

再看一个突发示例：

RateLimiter limiter = RateLimiter.create(5);
System.out.println(limiter.acquire(5));
System.out.println(limiter.acquire(1));
System.out.println(limiter.acquire(1));

将得到类似如下的输出：
0.0
0.98745
0.183553
0.199909

limiter.acquire(5)表示桶的容量为5且每秒新增5个令牌，令牌桶算法允许一定程度的突发，所以可以一次性消费5个令牌，但接下来的limiter.acquire(1)将等待差不多1秒桶中才能有令牌，且接下来的请求也整形为固定速率了。

RateLimiter limiter = RateLimiter.create(5);
System.out.println(limiter.acquire(10));
System.out.println(limiter.acquire(1));
System.out.println(limiter.acquire(1));

将得到类似如下的输出：

0.0
1.997428
0.192273
0.200616

同上边的例子类似，第一秒突发了10个请求，令牌桶算法也允许了这种突发（允许消费未来的令牌），但接下来的limiter.acquire(1)将等待差不多2秒桶中才能有令牌，且接下来的请求也整形为固定速率了。
接下来再看一个突发的例子：

RateLimiter limiter = RateLimiter.create(2);
System.out.println(limiter.acquire());
Thread.sleep(2000L);
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());

将得到类似如下的输出：
0.0
0.0
0.0
0.0
0.499876
0.495799
  • 创建了一个桶容量为2且每秒新增2个令牌；
  • 首先调用limiter.acquire()消费一个令牌，此时令牌桶可以满足（返回值为0）；
  • 然后线程暂停2秒，接下来的两个limiter.acquire()都能消费到令牌，第三个limiter.acquire()也同样消费到了令牌，到第四个时就需要等待500毫秒了。

此处可以看到我们设置的桶容量为2（即允许的突发量），这是因为SmoothBursty中有一个参数：最大突发秒数（maxBurstSeconds）默认值是1s，突发量/桶容量=速率*maxBurstSeconds，所以本示例桶容量/突发量为2，例子中前两个是消费了之前积攒的突发量，而第三个开始就是正常计算的了。令牌桶算法允许将一段时间内没有消费的令牌暂存到令牌桶中，留待未来使用，并允许未来请求的这种突发。

SmoothBursty通过平均速率和最后一次新增令牌的时间计算出下次新增令牌的时间的，另外需要一个桶暂存一段时间内没有使用的令牌（即可以突发的令牌数）。另外RateLimiter还提供了tryAcquire方法来进行无阻塞或可超时的令牌消费。

因为SmoothBursty允许一定程度的突发，会有人担心如果允许这种突发，假设突然间来了很大的流量，那么系统很可能扛不住这种突发。因此需要一种平滑速率的限流工具，从而系统冷启动后慢慢的趋于平均固定速率（即刚开始速率小一些，然后慢慢趋于我们设置的固定速率）。Guava也提供了SmoothWarmingUp来实现这种需求，其可以认为是漏桶算法，但是在某些特殊场景又不太一样。

SmoothWarmingUp

创建方式：RateLimiter.create(double permitsPerSecond, long warmupPeriod, TimeUnit unit)

permitsPerSecond表示每秒新增的令牌数，warmupPeriod表示在从冷启动速率过渡到平均速率的时间间隔。

示例如下：

RateLimiter limiter = RateLimiter.create(5, 1000, TimeUnit.MILLISECONDS);
for(int i = 1; i < 5;i++) {
    System.out.println(limiter.acquire());
}
Thread.sleep(1000L);
for(int i = 1; i < 5;i++) {
    System.out.println(limiter.acquire());
}

将得到类似如下的输出：

0.0
0.51767
0.357814
0.219992
0.199984
0.0
0.360826
0.220166
0.199723
0.199555

速率是梯形上升速率的，也就是说冷启动时会以一个比较大的速率慢慢到平均速率；然后趋于平均速率（梯形下降到平均速率）。可以通过调节warmupPeriod参数实现一开始就是平滑固定速率。

到此应用级限流的一些方法就介绍完了。假设将应用部署到多台机器，应用级限流方式只是单应用内的请求限流，不能进行全局限流。因此我们需要分布式限流和接入层限流来解决这个问题。

3、分布式限流

分布式限流最关键的是要将限流服务做成原子化，而解决方案可以使使用redis+lua或者nginx+lua技术进行实现，通过这两种技术可以实现的高并发和高性能。首先我们来使用redis+lua实现时间窗内某个接口的请求数限流，实现了该功能后可以改造为限流总并发/请求数和限制总资源数。Lua本身就是一种编程语言，也可以使用它实现复杂的令牌桶或漏桶算法。

1）、redis+lua实现

redis+lua实现中的lua脚本：

local key = KEYS[1] --限流KEY（一秒一个）
local limit = tonumber(ARGV[1]) --限流大小
local current = tonumber(redis.call("INCRBY", key, "1")) --请求数+1
if current > limit then --如果超出限流大小
    return 0
elseif current == 1 then --只有第一次访问需要设置2秒的过期时间
    redis.call("expire", key,"2")
end
return 1

如上操作因是在一个lua脚本中，又因Redis是单线程模型，因此是线程安全的。如上方式有一个缺点就是当达到限流大小后还是会递增的，可以改造成如下方式实现：

local key = KEYS[1] --限流KEY（一秒一个）
local limit = tonumber(ARGV[1]) --限流大小
local current = tonumber(redis.call('get', key) or "0")
if current + 1 > limit then --如果超出限流大小
    return 0
else --请求数+1，并设置2秒过期
    redis.call("INCRBY", key,"1")
    redis.call("expire", key,"2")
    return 1
end

 如下是Java中判断是否需要限流的代码：

public static boolean acquire() throws Exception {
String luaScript = Files.toString(new File("limit.lua"), Charset.defaultCharset());
Jedis jedis = new Jedis("192.168.147.52", 6379);
String key = "ip:" + System.currentTimeMillis()/ 1000; //此处将当前时间戳取秒数
Stringlimit = "3"; //限流大小
return (Long)jedis.eval(luaScript,Lists.newArrayList(key), Lists.newArrayList(limit)) == 1;
}

因为Redis的限制（Lua中有写操作不能使用带随机性质的读操作，如TIME）不能在Redis Lua中使用TIME获取时间戳，因此只好从应用获取然后传入，在某些极端情况下（机器时钟不准的情况下），限流会存在一些小问题。

2）、Nginx+Lua实现

使用Nginx+Lua实现的Lua脚本：

local locks = require "resty.lock"
local function acquire()
    local lock =locks:new("locks")
    local elapsed, err =lock:lock("limit_key") --互斥锁
    local limit_counter =ngx.shared.limit_counter --计数器
    local key = "ip:" ..os.time()
    local limit = 5 --限流大小
    local current =limit_counter:get(key)

    if current ~= nil and current + 1> limit then --如果超出限流大小
        lock:unlock()
        return 0
    end
    if current == nil then
        limit_counter:set(key, 1, 1) --第一次需要设置过期时间，设置key的值为1，过期时间为1秒
    else
        limit_counter:incr(key, 1) --第二次开始加1即可
    end
    lock:unlock()
    return 1
end
ngx.print(acquire())

 实现中我们需要使用lua-resty-lock互斥锁模块来解决原子性问题(在实际工程中使用时请考虑获取锁的超时问题)，并使用ngx.shared.DICT共享字典来实现计数器。如果需要限流则返回0，否则返回1。使用时需要先定义两个共享字典（分别用来存放锁和计数器数据）：

http {  
    ……  
    lua_shared_dict locks 10m;  
    lua_shared_dict limit_counter 10m;  
}

有人会纠结如果应用并发量非常大那么redis或者nginx是不是能抗得住；不过这个问题要从多方面考虑：你的流量是不是真的有这么大，是不是可以通过一致性哈希将分布式限流进行分片，是不是可以当并发量太大降级为应用级限流；对策非常多，可以根据实际情况调节；像在京东使用Redis+Lua来限流抢购流量，一般流量是没有问题的。

对于分布式限流目前遇到的场景是业务上的限流，而不是流量入口的限流；

流量入口限流应该在接入层完成，而接入层笔者一般使用Nginx。

4、接入层限流

接入层通常指请求流量的入口，该层的主要目的有：负载均衡、非法请求过滤、请求聚合、缓存、降级、限流、A/B测试、服务质量监控等等。

对于Nginx接入层限流可以使用Nginx自带了两个模块：

  • 连接数限流模块ngx_http_limit_conn_module；
  • 漏桶算法实现的请求限流模块ngx_http_limit_req_module；
  • 还可以使用OpenResty提供的Lua限流模块lua-resty-limit-traffic进行更复杂的限流场景；

limit_conn用来对某个KEY对应的总的网络连接数进行限流，可以按照如IP、域名维度进行限流。

limit_req用来对某个KEY对应的请求的平均速率进行限流，并有两种用法：平滑模式（delay）和允许突发模式(nodelay)。

1）、ngx_http_limit_conn_module

limit_conn是对某个KEY对应的总的网络连接数进行限流。可以按照IP来限制IP维度的总连接数，或者按照服务域名来限制某个域名的总连接数。但是记住不是每一个请求连接都会被计数器统计，只有那些被Nginx处理的且已经读取了整个请求头的请求连接才会被计数器统计。

配置示例：

http {
    limit_conn_zone$binary_remote_addr zone=addr:10m; 
    limit_conn_log_level error; 
    limit_conn_status 503;
    ...
    server {
    ...
    location /limit {
        limit_conn addr 1;
    }

limit_conn：要配置存放KEY和计数器的共享内存区域和指定KEY的最大连接数；此处指定的最大连接数是1，表示Nginx最多同时并发处理1个连接；

limit_conn_zone：用来配置限流KEY、及存放KEY对应信息的共享内存区域大小；此处的KEY是“$binary_remote_addr”其表示IP地址，也可以使用如$server_name作为KEY来限制域名级别的最大连接数；

limit_conn_status：配置被限流后返回的状态码，默认返回503；

limit_conn_log_level：配置记录被限流后的日志级别，默认error级别。

limit_conn的主要执行过程如下所示：

1、请求进入后首先判断当前limit_conn_zone中相应KEY的连接数是否超出了配置的最大连接数；

2.1、如果超过了配置的最大大小，则被限流，返回limit_conn_status定义的错误状态码；

2.2、否则相应KEY的连接数加1，并注册请求处理完成的回调函数；

3、进行请求处理；

4、在结束请求阶段会调用注册的回调函数对相应KEY的连接数减1。

limt_conn可以限流某个KEY的总并发/请求数，KEY可以根据需要变化。

按照IP限制并发连接数配置示例：

首先定义IP维度的限流区域：

limit_conn_zone $binary_remote_addrzone=perip:10m;

接着在要限流的location中添加限流逻辑：

location /limit {
    limit_conn perip 2;
    echo "123";
}

即允许每个IP最大并发连接数为2。

使用AB测试工具进行测试，并发数为5个，总的请求数为5个：

ab -n 5 -c 5 http://localhost/limit

将得到如下access.log输出：

[08/Jun/2016:20:10:51+0800] [1465373451.802] 200

[08/Jun/2016:20:10:51+0800] [1465373451.803] 200

[08/Jun/2016:20:10:51 +0800][1465373451.803] 503

[08/Jun/2016:20:10:51 +0800][1465373451.803] 503

[08/Jun/2016:20:10:51 +0800][1465373451.803] 503

此处我们把access log格式设置为log_format main  '[$time_local] [$msec] $status'；分别是“日期 日期秒/毫秒值 响应状态码”。

如果被限流了，则在error.log中会看到类似如下的内容：

2016/06/08 20:10:51 [error] 5662#0: *5limiting connections by zone "perip", client: 127.0.0.1, server: _,request: "GET /limit HTTP/1.0", host: "localhost"

按照域名限制并发连接数配置示例：

首先定义域名维度的限流区域：

limit_conn_zone $ server_name zone=perserver:10m;

接着在要限流的location中添加限流逻辑：

location /limit {
    limit_conn perserver 2;
    echo "123";
}

即允许每个域名最大并发请求连接数为2；这样配置可以实现服务器最大连接数限制。

2）、ngx_http_limit_req_module

limit_req是漏桶算法实现，用于对指定KEY对应的请求进行限流，比如按照IP维度限制请求速率。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    limit_conn_log_level error;
    limit_conn_status 503;
    ...
    server {
    ...
    location /limit {
        limit_req zone=one burst=5 nodelay;
    }

limit_req：配置限流区域、桶容量（突发容量，默认0）、是否延迟模式（默认延迟）；

limit_req_zone：配置限流KEY、及存放KEY对应信息的共享内存区域大小、固定请求速率；此处指定的KEY是“$binary_remote_addr”表示IP地址；固定请求速率使用rate参数配置，支持10r/s和60r/m，即每秒10个请求和每分钟60个请求，不过最终都会转换为每秒的固定请求速率（10r/s为每100毫秒处理一个请求；60r/m，即每1000毫秒处理一个请求）。

limit_conn_status：配置被限流后返回的状态码，默认返回503；

limit_conn_log_level：配置记录被限流后的日志级别，默认error级别。

limit_req的主要执行过程如下所示：

1、请求进入后首先判断最后一次请求时间相对于当前时间（第一次是0）是否需要限流，如果需要限流则执行步骤2，否则执行步骤3；

2.1、如果没有配置桶容量（burst），则桶容量为0；按照固定速率处理请求；如果请求被限流，则直接返回相应的错误码（默认503）；

2.2、如果配置了桶容量（burst>0）且延迟模式(没有配置nodelay)；如果桶满了，则新进入的请求被限流；如果没有满则请求会以固定平均速率被处理（按照固定速率并根据需要延迟处理请求，延迟使用休眠实现）；

2.3、如果配置了桶容量（burst>0）且非延迟模式（配置了nodelay）；不会按照固定速率处理请求，而是允许突发处理请求；如果桶满了，则请求被限流，直接返回相应的错误码；

3、如果没有被限流，则正常处理请求；

4、Nginx会在相应时机进行选择一些（3个节点）限流KEY进行过期处理，进行内存回收。

 

场景2.1测试

首先定义IP维度的限流区域：

limit_req_zone $binary_remote_addrzone=test:10m rate=500r/s;

限制为每秒500个请求，固定平均速率为2毫秒一个请求。

接着在要限流的location中添加限流逻辑：

location /limit {
    limit_req zone=test;
    echo "123";
}

即桶容量为0（burst默认为0），且延迟模式。

使用AB测试工具进行测试，并发数为2个，总的请求数为10个：

ab -n 10 -c 2 http://localhost/limit

 将得到如下access.log输出：

[08/Jun/2016:20:25:56+0800] [1465381556.410] 200

[08/Jun/2016:20:25:56 +0800][1465381556.410] 503

[08/Jun/2016:20:25:56 +0800][1465381556.411] 503

[08/Jun/2016:20:25:56+0800] [1465381556.411] 200

[08/Jun/2016:20:25:56 +0800][1465381556.412] 503

[08/Jun/2016:20:25:56 +0800][1465381556.412] 503

虽然每秒允许500个请求，但是因为桶容量为0，所以流入的请求要么被处理要么被限流，无法延迟处理；另外平均速率在2毫秒左右，比如1465381556.410和1465381556.411被处理了；有朋友会说这固定平均速率不是1毫秒嘛，其实这是因为实现算法没那么精准造成的。

如果被限流在error.log中会看到如下内容：

2016/06/08 20:25:56 [error] 6130#0: *1962limiting requests, excess: 1.000 by zone "test", client: 127.0.0.1,server: _, request: "GET /limit HTTP/1.0", host:"localhost"

如果被延迟了在error.log（日志级别要INFO级别）中会看到如下内容：

2016/06/10 09:05:23 [warn] 9766#0: *97021delaying request, excess: 0.368, by zone "test", client: 127.0.0.1,server: _, request: "GET /limit HTTP/1.0", host:"localhost"

场景2.2测试

首先定义IP维度的限流区域：

limit_req_zone $binary_remote_addr zone=test:10m rate=2r/s;

为了方便测试设置速率为每秒2个请求，即固定平均速率是500毫秒一个请求。

接着在要限流的location中添加限流逻辑：

location /limit {
    limit_req zone=test burst=3;
    echo "123";
}

固定平均速率为500毫秒一个请求，通容量为3，如果桶满了新的请求被限流，否则可以进入桶中排队并等待（实现延迟模式）。

为了看出限流效果我们写了一个req.sh脚本：

ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit

首先进行6个并发请求6次URL，然后休眠300毫秒，然后再进行6个并发请求6次URL；中间休眠目的是为了能跨越2秒看到效果，如果看不到如下的效果可以调节休眠时间。

将得到如下access.log输出：

[09/Jun/2016:08:46:43+0800] [1465433203.959] 200

[09/Jun/2016:08:46:43 +0800][1465433203.959] 503

[09/Jun/2016:08:46:43 +0800][1465433203.960] 503

[09/Jun/2016:08:46:44+0800] [1465433204.450] 200

[09/Jun/2016:08:46:44+0800] [1465433204.950] 200

[09/Jun/2016:08:46:45 +0800][1465433205.453] 200

 

[09/Jun/2016:08:46:45 +0800][1465433205.766] 503

[09/Jun/2016:08:46:45 +0800][1465433205.766] 503

[09/Jun/2016:08:46:45 +0800][1465433205.767] 503

[09/Jun/2016:08:46:45+0800] [1465433205.950] 200

[09/Jun/2016:08:46:46+0800] [1465433206.451] 200

[09/Jun/2016:08:46:46+0800] [1465433206.952] 200



 

桶容量为3，即桶中在时间窗口内最多流入3个请求，且按照2r/s的固定速率处理请求（即每隔500毫秒处理一个请求）；桶计算时间窗口（1.5秒）=速率（2r/s）/桶容量(3)，也就是说在这个时间窗口内桶最多暂存3个请求。因此我们要以当前时间往前推1.5秒和1秒来计算时间窗口内的总请求数；另外因为默认是延迟模式，所以时间窗内的请求要被暂存到桶中，并以固定平均速率处理请求：

第一轮：有4个请求处理成功了，按照漏桶桶容量应该最多3个才对；这是因为计算算法的问题，第一次计算因没有参考值，所以第一次计算后，后续的计算才能有参考值，因此第一次成功可以忽略；这个问题影响很小可以忽略；而且按照固定500毫秒的速率处理请求。

第二轮：因为第一轮请求是突发来的，差不多都在1465433203.959时间点，只是因为漏桶将速率进行了平滑变成了固定平均速率（每500毫秒一个请求）；而第二轮计算时间应基于1465433203.959；而第二轮突发请求差不多都在1465433205.766时间点，因此计算桶容量的时间窗口应基于1465433203.959和1465433205.766来计算，计算结果为1465433205.766这个时间点漏桶为空了，可以流入桶中3个请求，其他请求被拒绝；又因为第一轮最后一次处理时间是1465433205.453，所以第二轮第一个请求被延迟到了1465433205.950。这里也要注意固定平均速率只是在配置的速率左右，存在计算精度问题，会有一些偏差。

如果桶容量改为1（burst=1），执行req.sh脚本可以看到如下输出：

09/Jun/2016:09:04:30+0800] [1465434270.362] 200

[09/Jun/2016:09:04:30 +0800][1465434270.371] 503

[09/Jun/2016:09:04:30 +0800] [1465434270.372]503

[09/Jun/2016:09:04:30 +0800][1465434270.372] 503

[09/Jun/2016:09:04:30 +0800][1465434270.372] 503

[09/Jun/2016:09:04:30+0800] [1465434270.864] 200



[09/Jun/2016:09:04:31 +0800][1465434271.178] 503

[09/Jun/2016:09:04:31 +0800][1465434271.178] 503

[09/Jun/2016:09:04:31 +0800][1465434271.178] 503

[09/Jun/2016:09:04:31 +0800][1465434271.178] 503

[09/Jun/2016:09:04:31 +0800][1465434271.179] 503

[09/Jun/2016:09:04:31+0800] [1465434271.366] 200

桶容量为1，按照每1000毫秒一个请求的固定平均速率处理请求。

场景2.3测试

首先定义IP维度的限流区域：

limit_req_zone $binary_remote_addr zone=test:10m rate=2r/s;

为了方便测试配置为每秒2个请求，固定平均速率是500毫秒一个请求。

接着在要限流的location中添加限流逻辑：

location /limit {
    limit_req zone=test burst=3 nodelay;
    echo "123";
}

桶容量为3，如果桶满了直接拒绝新请求，且每秒2最多两个请求，桶按照固定500毫秒的速率以nodelay模式处理请求。

为了看到限流效果我们写了一个req.sh脚本：

ab -c 6 -n 6 http://localhost/limit
sleep 1
ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit
sleep 2
ab -c 6 -n 6 http://localhost/limit

将得到类似如下access.log输出：

[09/Jun/2016:14:30:11+0800] [1465453811.754] 200

[09/Jun/2016:14:30:11+0800] [1465453811.755] 200

[09/Jun/2016:14:30:11+0800] [1465453811.755] 200

[09/Jun/2016:14:30:11+0800] [1465453811.759] 200

[09/Jun/2016:14:30:11 +0800][1465453811.759] 503

[09/Jun/2016:14:30:11 +0800][1465453811.759] 503



[09/Jun/2016:14:30:12+0800] [1465453812.776] 200

[09/Jun/2016:14:30:12+0800] [1465453812.776] 200

[09/Jun/2016:14:30:12 +0800][1465453812.776] 503

[09/Jun/2016:14:30:12 +0800][1465453812.777] 503

[09/Jun/2016:14:30:12 +0800][1465453812.777] 503

[09/Jun/2016:14:30:12 +0800][1465453812.777] 503



[09/Jun/2016:14:30:13 +0800] [1465453813.095]503

[09/Jun/2016:14:30:13 +0800][1465453813.097] 503

[09/Jun/2016:14:30:13 +0800][1465453813.097] 503

[09/Jun/2016:14:30:13 +0800][1465453813.097] 503

[09/Jun/2016:14:30:13 +0800][1465453813.097] 503

[09/Jun/2016:14:30:13 +0800][1465453813.098] 503



[09/Jun/2016:14:30:13+0800] [1465453813.425] 200

[09/Jun/2016:14:30:13 +0800][1465453813.425] 503

[09/Jun/2016:14:30:13 +0800][1465453813.425] 503

[09/Jun/2016:14:30:13 +0800][1465453813.426] 503

[09/Jun/2016:14:30:13 +0800][1465453813.426] 503

[09/Jun/2016:14:30:13 +0800][1465453813.426] 503



[09/Jun/2016:14:30:13+0800] [1465453813.754] 200

[09/Jun/2016:14:30:13 +0800][1465453813.755] 503

[09/Jun/2016:14:30:13 +0800][1465453813.755] 503

[09/Jun/2016:14:30:13 +0800][1465453813.756] 503

[09/Jun/2016:14:30:13 +0800][1465453813.756] 503

[09/Jun/2016:14:30:13 +0800][1465453813.756] 503



[09/Jun/2016:14:30:15+0800] [1465453815.278] 200

[09/Jun/2016:14:30:15+0800] [1465453815.278] 200

[09/Jun/2016:14:30:15+0800] [1465453815.278] 200

[09/Jun/2016:14:30:15 +0800][1465453815.278] 503

[09/Jun/2016:14:30:15 +0800][1465453815.279] 503

[09/Jun/2016:14:30:15 +0800][1465453815.279] 503



[09/Jun/2016:14:30:17+0800] [1465453817.300] 200

[09/Jun/2016:14:30:17+0800] [1465453817.300] 200

[09/Jun/2016:14:30:17+0800] [1465453817.300] 200

[09/Jun/2016:14:30:17+0800] [1465453817.301] 200

[09/Jun/2016:14:30:17 +0800][1465453817.301] 503

[09/Jun/2016:14:30:17 +0800][1465453817.301] 503



 

桶容量为3（，即桶中在时间窗口内最多流入3个请求，且按照2r/s的固定速率处理请求（即每隔500毫秒处理一个请求）；桶计算时间窗口（1.5秒）=速率（2r/s）/桶容量(3)，也就是说在这个时间窗口内桶最多暂存3个请求。因此我们要以当前时间往前推1.5秒和1秒来计算时间窗口内的总请求数；另外因为配置了nodelay，是非延迟模式，所以允许时间窗内突发请求的；另外从本示例会看出两个问题：

第一轮和第七轮：有4个请求处理成功了；这是因为计算算法的问题，本示例是如果2秒内没有请求，然后接着突然来了很多请求，第一次计算的结果将是不正确的；这个问题影响很小可以忽略；

第五轮：1.0秒计算出来是3个请求；此处也是因计算精度的问题，也就是说limit_req实现的算法不是非常精准的，假设此处看成相对于2.75的话，1.0秒内只有1次请求，所以还是允许1次请求的。

 

如果限流出错了，可以配置错误页面：

proxy_intercept_errors on;
recursive_error_pages on;
error_page 503 //www.jd.com/error.aspx;

limit_conn_zone/limit_req_zone定义的内存不足，则后续的请求将一直被限流，所以需要根据需求设置好相应的内存大小。

 

此处的限流都是单Nginx的，假设我们接入层有多个nginx，此处就存在和应用级限流相同的问题；那如何处理呢？一种解决办法：建立一个负载均衡层将按照限流KEY进行一致性哈希算法将请求哈希到接入层Nginx上，从而相同KEY的将打到同一台接入层Nginx上；另一种解决方案就是使用Nginx+Lua（OpenResty）调用分布式限流逻辑实现。

3）、lua-resty-limit-traffic（OpenResty）

之前介绍的两个模块使用上比较简单，指定KEY、指定限流速率等就可以了，如果我们想根据实际情况变化KEY、变化速率、变化桶大小等这种动态特性，使用标准模块就很难去实现了，因此我们需要一种可编程来解决我们问题；而OpenResty提供了lua限流模块lua-resty-limit-traffic，通过它可以按照更复杂的业务逻辑进行动态限流处理了。其提供了limit.conn和limit.req实现，算法与nginx limit_conn和limit_req是一样的。

此处我们来实现ngx_http_limit_req_module中的【场景2.2测试】，不要忘记下载lua-resty-limit-traffic模块并添加到OpenResty的lualib中。

配置用来存放限流用的共享字典：

lua_shared_dict limit_req_store 100m;

以下是实现【场景2.2测试】的限流代码limit_req.lua：

local limit_req = require "resty.limit.req"
local rate = 2 --固定平均速率 2r/s
local burst = 3 --桶容量
local error_status = 503
local nodelay = false --是否需要不延迟处理
local lim, err = limit_req.new("limit_req_store", rate, burst)
if not lim then --没定义共享字典
    ngx.exit(error_status)
end
local key = ngx.var.binary_remote_addr --IP维度的限流
--流入请求，如果请求需要被延迟则delay > 0
local delay, err = lim:incoming(key, true)
if not delay and err == "rejected" then --超出桶大小了
    ngx.exit(error_status)
end
if delay > 0 then --根据需要决定是延迟或者不延迟处理
    if nodelay then
        --直接突发处理了
    else
        ngx.sleep(delay) --延迟处理
    end
end

即限流逻辑再nginx access阶段被访问，如果不被限流继续后续流程；如果需要被限流要么sleep一段时间继续后续流程，要么返回相应的状态码拒绝请求。

在分布式限流中我们使用了简单的Nginx+Lua进行分布式限流，有了这个模块也可以使用这个模块来实现分布式限流。

另外在使用Nginx+Lua时也可以获取ngx.var.connections_active进行过载保护，即如果当前活跃连接数超过阈值进行限流保护。

if tonumber(ngx.var.connections_active) >= tonumber(limit) then
    //限流
end

nginx也提供了limit_rate用来对流量限速，如limit_rate 50k，表示限制下载速度为50k。

这些算法中有些允许突发，有些会整形为平滑，有些计算算法简单粗暴；其中令牌桶算法和漏桶算法实现上是类似的，只是表述的方向不太一样，对于业务来说不必刻意去区分它们；因此需要根据实际场景来决定如何限流，最好的算法不一定是最适用的。

四、降级特技

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

1、降级预案

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

降级按照是否自动化可分为：自动开关降级和人工开关降级。

降级按照功能可分为：读服务降级、写服务降级。

降级按照处于的系统层次可分为：多级降级。

降级的功能点主要从服务端链路考虑，即根据用户访问的服务调用链路来梳理哪里需要降级：

页面降级：在大促或者某些特殊情况下，某些页面占用了一些稀缺服务资源，在紧急情况下可以对其整个降级，以达到丢卒保帅；

页面片段降级：比如商品详情页中的商家部分因为数据错误了，此时需要对其进行降级；

页面异步请求降级：比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级；

服务功能降级：比如渲染商品详情页时需要调用一些不太重要的服务：相关分类、热销榜等，而这些服务在异常情况下直接不获取，即降级即可；

读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景；

写降级：比如秒杀抢购，我们可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。

爬虫降级：在大促活动时，可以将爬虫流量导向静态页或者返回空数据，从而保护后端稀缺资源。

2、自动开关降级

自动降级是根据系统负载、资源使用情况、SLA等指标进行降级。

1）、超时降级

当访问的数据库/http服务/远程调用响应慢或者长时间响应慢，且该服务不是核心服务的话可以在超时后自动降级；比如商品详情页上有推荐内容/评价，但是推荐内容/评价暂时不展示对用户购物流程不会产生很大的影响；对于这种服务是可以超时降级的。如果是调用别人的远程服务，和对方定义一个服务响应最大时间，如果超时了则自动降级。在实际场景用一定主要配置好超时时间和超时重试次数和机制。

2）、统计失败次数降级

有时候依赖一些不稳定的API，比如调用外部机票服务，当失败调用次数达到一定阀值自动降级；然后通过异步线程去探测服务是否恢复了，则取消降级。

3）、故障降级

比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）。

4）、限流降级

当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

3、人工开关降级

在大促期间通过监控发现线上的一些服务存在问题，这个时候需要暂时将这些服务摘掉；还有有时候通过任务系统调用一些服务，但是服务依赖的数据库可能存在：网卡被打满了、挂掉了或者很多慢查询，此时需要暂停下任务系统让服务方进行处理；还有发现突然调用量太大，可能需要改变处理方式（比如同步转换为异步）；此时就可以使用开关来完成降级。开关可以存放到配置文件、存放到数据库、存放到Redis/ZooKeeper；如果不是存放在本地，可以定期同步开关数据（比如1秒同步一次）。然后通过判断某个KEY的值来决定是否降级。

另外对于新开发的服务想上线进行灰度测试；但是不太确定该服务的逻辑是否正确，此时就需要设置开关，当新服务有问题可以通过开关切换回老服务。还有多机房服务，如果某个机房挂掉了，此时需要将一个机房的服务切到另一个机房，此时也可以通过开关完成切换。

还有一些是因为功能问题需要暂时屏蔽掉某些功能，比如商品规格参数数据有问题，数据问题不能用回滚解决，此时需要开关控制降级。

4、读服务降级

对于读服务降级一般采用的策略有：暂时切换读（降级到读缓存、降级到走静态化）、暂时屏蔽读（屏蔽读入口、屏蔽某个读服务）。读服务流程，即接入层缓存-->应用层本地缓存-->分布式缓存-->RPC服务/DB，我们会在接入层、应用层设置开关，当分布式缓存、RPC服务/DB有问题自动降级为不调用。当然这种情况适用于对读一致性要求不高的场景。

页面降级、页面片段降级、页面异步请求降级都是读服务降级，目的是丢卒保帅（比如因为这些服务也要使用核心资源、或者占了带宽影响到核心服务）或者因数据问题暂时屏蔽。

还有一种是页面静态化场景：

动态化降级为静态化：比如平时网站可以走动态化渲染商品详情页，但是到了大促来临之际可以将其切换为静态化来减少对核心资源的占用，而且可以提升性能；其他还有如列表页、首页、频道页都可以这么玩；可以通过一个程序定期的推送静态页到缓存或者生成到磁盘，出问题时直接切过去；

静态化降级为动态化：比如当使用静态化来实现商品详情页架构时，平时使用静态化来提供服务，但是因为特殊原因静态化页面有问题了，需要暂时切换回动态化来保证服务正确性。

以上都保证出问题了有预案，用户还是可以使用网站，不影响用户购物。

5、写服务降级

写服务在大多数场景下是不可降级的，不过可以通过一些迂回战术来解决问题。比如将同步操作转换为异步操作，或者限制写的量/比例。

比如扣减库存一般这样操作：

方案1：

1、扣减DB库存，2、扣减成功后更新Redis中的库存；

方案2：

1、扣减Redis库存，2、同步扣减DB库存，如果扣减失败则回滚Redis库存；

前两种方案非常依赖DB，假设此时DB性能跟不上则扣减库存就会遇到问题；因此我们可以想到方案3：

1、扣减Redis库存，2、正常同步扣减DB库存，性能扛不住时降级为发送一条扣减DB库存的消息，然后异步进行DB库存扣减实现最终一致即可；

这种方式发送扣减DB库存消息也可能成为瓶颈；这种情况我们可以考虑方案4：

1、扣减Redis库存，2、正常同步扣减DB库存，性能扛不住时降级为写扣减DB库存消息到本机，然后本机通过异步进行DB库存扣减来实现最终一致性。

也就是说正常情况可以同步扣减库存，在性能扛不住时降级为异步；另外如果是秒杀场景可以直接降级为异步，从而保护系统。还有如下单操作可以在大促时暂时降级将下单数据写入Redis，然后等峰值过去了再同步回DB，当然也有更好的解决方案，但是更复杂，不是本文的重点。

还有如用户评价，如果评价量太大，也可以把评价从同步写降级为异步写。当然也可以对评价按钮进行按比例开放（比如一些人的看不到评价操作按钮）。比如评价成功后会发一些奖励，在必要的时候降级同步到异步。

6、多级降级

缓存是离用户最近越高效；而降级是离用户越近越能对系统保护的好。因为业务的复杂性导致越到后端QPS/TPS越低。

页面JS降级开关：主要控制页面功能的降级，在页面中通过JS脚本部署功能降级开关，在适当时机开启/关闭开关；

接入层降级开关：主要控制请求入口的降级，请求进入后会首先进入接入层，在接入层可以配置功能降级开关，可以根据实际情况进行自动/人工降级；尤其在后端应用服务出问题时，通过接入层降级从而给应用服务有足够的时间恢复服务；

应用层降级开关：主要控制业务的降级，在应用中配置相应的功能开关，根据实际业务情况进行自动/人工降级。

7、配置中心

应用层API封装

配置文件实现开关配置

配置中心实现开关配置

分布式配置中心zookeeper、disconf、diamond、consul

8、使用Hystrix实现降级

 

9、使用Hystrix实现熔断

熔断机制实现：

hystrix提供了熔断机制，熔断后会自动降级处理

配置示例

采样统计

五、超时与重试机制

简介

 

重要的是网络连接、读、写超时的设置。 

 

1、代理层超时与重试

 

2、Web容器超时

3、中间件客户端超时与重试

 

4、数据库客户端超时

 

5、NoSQL客户端超时

 

6、业务超时

7、前端Ajax超时

 

六、回滚机制

1、事务回滚

 

 

 

2、代码库回滚

 

3、部署版本回滚

4、数据版本回滚

 

5、静态资源版本回滚

 

 

七、压测与预案

1、系统压测

1）、线下压测

2）、线上压测

读压测、写压测、混合压测

 

 

2、系统优化和容灾

https://mp.weixin.qq.com/s/YMgIwaz8YC_zNPh_Jf98HA

 

3、应急预案

 

 

参考：

《亿级流量网站架构核心技术》

http://jinnianshilongnian.iteye.com/blog/2339876

http://jinnianshilongnian.iteye.com/blog/2305117

程序猿渣渣帅
关注
  • 0
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
读书笔记：《亿级流量网站架构核心技术 -- 跟开涛学搭建高可用高并发系统》
看，未来的博客
12-03 4208
from 《亿级流量网站架构核心技术 – 跟开涛学搭建高可用高并发系统》 概述 一个好的设计要做到，解决现有的需求和问题，把控实现和进度风险，预测和规划未来，不要过度设计，从迭代中演进和完善。 在设计系统时，应多思考墨菲定律： 1、任何事情都没有表面看起来那么简单。 2、所有的事都会比你预计的时间长。 3、可能出错的事总会出错。 在系统划分时，也要思考康威定律： 1、系统架构是公司组织架构的反映。 2、应该按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/松耦合，减少沟通成本。 3、如果沟.
亿级流量系统架构设计与实战
努力是为了站在万人之中，成为别人的光
06-04 1万+
亿级流量系统的设计与实现需要综合考虑高可用性、高并发性和高性能等多个方面。通过合理的架构设计、技术选型和优化策略，可以构建出一个稳定高效的系统，满足用户需求。希望本文提供的架构思路和代码示例对您有所帮助。
《亿级流量网站架构核心技术》-高可用-限流详解
最新发布
bigben
06-12 752
限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务，如定向到错误页面。也可以进行排队/等待，降级。
亿级流量网站架构核心技术 跟开涛学搭建高可用高并发系统
热门推荐
Jack魏
01-04 3万+
亿级流量网站架构核心技术　跟开涛学搭建高可用高并发系统1.高并发原则1.1 无状态1.2 拆分1.3 服务化1.4 消息队列1.5 数据异构1.6 缓存银弹1.7 并发化2 高可用原则2.1 降级2.2 限流2.3 切流量2.4 可回滚3 业务设计原则3.1 防重设计3.2 幂等设计3.3 流程可定义3.4 状态与状态机3.5 后台系统操作可反馈3.6 后台系统审批化3.7 文档和注释3.8 备份4 负载均衡与反向代理5 隔离5.1 线程隔离（线程池隔离）5.2 进程隔离5.3 集群隔离5.4 机房隔离5.
《亿级流量网站架构核心技术》总结
02-10 6366
nginx后端节点健康检查 主要有三种实现方式： 1. 本身自带的ngx_http_proxy_module模块和ngx_http_upstream_module模块，属于惰性检测。 ngx_http_proxy_module：proxy_connect_timeout（与后端服务器建立连接的超时时间）、proxy_read_timeout（从后端服务器读取响应的超时）和proxy_next...
《亿级流量网站架构核心技术》.pdf
田维常
12-06 2684
关注“Java后端技术全栈”回复“面试”获取全套面试资料有过互联网开发经验的人员或许有这样的感受：搭建一个设计精良、功能丰富的网站并不是一件特别困难的事情，但是搭建一个能够支持巨大流量并...
《亿级流量网站架构核心技术》读书笔记
bin的专栏
01-21 1187
虽然本人平时主要从事OA系统的开发，系统并发量不会特别大，主要是注重业务逻辑和快速交付，但是通过学习电商网站对高并发高可用的处理，可以促进自己对系统架构的思考，提升自己的业务水平，以后出现高并发高可用问题的时候，才不会手足无措，而且，系统架构原理是想通的，即使是小系统，也可以从大系统的架构中学习到相关技术解决方案和设计思路，也就是所谓的触类旁通。 一，系统设计的一些原则 在我们的技术生涯中
一图速读《亿级流量网站架构核心技术》
Hermaeus Mora's Apocrypha
01-13 544
一图速读《亿级流量网站架构核心技术 跟开涛学搭建高可用高并发系统》 已更新 系统设计原则 已更新 业务设计原则 已更新 高可用 已更新 隔离术 已更新 限流术 已更新 超时/重置机制 已更新 回滚机制/系统压测 已更新 高并发-缓存 已更新 连接池/线程池、异步并发、如何扩容 已更新 队列术
亿级流量网站架构核心技术
CiCi岛的专栏
04-10 2240
网站 更多书籍点击进入>> CiCi岛 下载 电子版仅供预览及学习交流使用，下载后请24小时内删除，支持正版，喜欢的请购买正版书籍 电子书下载(皮皮云盘-点击“普通下载”) 购买正版 封页 编辑推荐 提前看到这部著作的人这样评价——√ 经历618、双11多次大考，是保证大规模电商系统高流量、高频次的葵花宝典。√ 集中火力讲述作者构建大流量系统用到的高可用和高并发原则。√ 浓缩作者...
【总结】服务端-高并发高可用设计原则/分布式架构演进过程
Think Different
07-09 2409
无论是行业技术交流，还是面试或被面试，时常有人会问到此类问题：你做架构设计的原则是如何的？碰到过哪些相关的技术问题？如何解决的？架构如何演进的？等等一系列高并发高可用的相关问题。以前我在学习阅读总结（系统架构师）文章中推荐过涛哥的《亿级流量-高并发高可用架构实战》这本书，如果缺少这方面的相关知识，你可以去读一读这本书，系统性学习一下，同时，我也相信这篇文章能帮你梳理一下整体的架构认知，以及演进过...
6.架构设计系列：如何设计高可用架构
白云
10-24 791
高可用架构是一种设计和架构方法，它旨在确保系统在面对各种故障、异常、硬件或软件问题，以及不可预测的事件下，继续提供稳定的服务。简单来说，高可用就是让我们的系统在任何情况下都尽最大可能能够对外提供服务。高可用架构追求提供连续的服务，不受单点故障、服务中断或其他问题的影响。这通常涉及到复制、冗余、负载均衡和自动故障转移等技术手段，以保持系统的稳定性和可用性。对于一个持续迭代、不断演进的系统而言，我们没有办法将故障发生的概率降为0，能做的只有尽可能的预防故障的发生，以及当故障发生后缩短故障的恢复时间。
Hadoop权威指南---map和reduce函数使用解析
l1394049664的博客
09-19 1万+
目录 1、数据准备 2、  Java MapReduce  2.1、map函数的实现 2.2、reduce函数的实现 2.3、负责运行MapReduce的代码 2.4、运行测试  3、旧的和新的Java MapReduce API几个明显的区别 4、数据流和combiner函数  4.1  数据流  4.2  combiner函数  4.3  Hadoop Streaming...
Hadoop2.x HDFS源码剖析---概述
l1394049664的博客
08-28 6566
一、HDFS概述 基于hadoop2.6 HDFS被设计能够运行在通用硬件上、提供流式数据操作、能够处理超大文件的分布式文件系统。 特点：高容错和高吞吐量、易扩展、高可靠性 HDFS的四个核心模块：namenode节点、datanode节点、客户端、HDFS协议（RPC协议、流式接口协议:HTTP和TCP） 基本概念 1、数据块（block） 数据块是HDFS文件处理（读和写）的最小单元，...
java性能优化权威指南---java性能调优工具
l1394049664的博客
08-19 2030
目录   1、操作系统的工具和分析 1）CPU使用率（vmstat）  2）磁盘使用率（iostat） 3）、网络使用率（netstat） 2、java监控工具 jcm 命令demo jinfo 实例demo   3、性能分析工具 4、java任务控制（暂时跳过，后续再看） 1、操作系统的工具和分析 Unix上，sar（system accounting report） ...
java性能优化权威指南---即时编译器（Just-in-time,JIT）
l1394049664的博客
08-19 1621
目录 1、JIT编译器概览 2、调优入门：选择编译器类型（client、server或者两者同时使用） 1）、优化启动 2）、优化批处理 3）、优化长时间运行的应用 3、java和JIT编译器版本 4、编译器中级调优 1）、调优代码缓存 2）、编译阈值 3）、检测编译过程 5、高级编译器调优 1）、编译线程 2）、内联（默认开启，-XX:+PrintInling） 3）...
Hadoop权威指南---HDFS简介和java API操作
l1394049664的博客
09-16 960
目录 1、HDFS的设计 2、 HDFS的概念  2.1 数据块  2.2 namenode和datanode 概述 2.3 块缓存  ​2.4 联邦HDFS  2.5 HDFS的高可用性  3、 命令行接口 4、 Hadoop文件系统分类 5、Java接口API 5.1、增：创建文件create和write、文件夹mkdirs 5.2、删：删除文件夹和文件delete ...
Hadoop权威指南.大数据的存储与分析.第4版目录
l1394049664的博客
09-10 888
目录 第Ⅰ部分 Hadoop基础知识 第1章 初识Hadoop 3 1.1 数据！数据！ 3 1.2 数据的存储与分析 5 1.3 查询所有数据 6 1.4 不仅仅是批处理 7 1.5 相较于其他系统的优势 8 1.5.1 关系型数据库管理系统 8 1.5.2 网格计算 10 1.5.3 志愿计算 11 1.6 Apache Hadoop发展简史 12 1.7 本书包含的内容 16 第2章 关于M...
Hadoop权威指南---MapReduce的工作机制
l1394049664的博客
09-25 714
目录 1、 剖析MapReduce作业运行机制  ​1.1、 作业的提交  ​1.2、 作业的初始化  ​1.3、 任务的分配  ​1.4 、任务的执行  1.5、 进度和状态的更新 ​1.6、 作业的完成  ​2 、失败  2.1、 任务运行失败 ​2.2、 application master运行失败 ​2.3 、节点管理器运行失败  ​2.4 、资源管理器运行失败  ...
Hadoop权威指南---I／O操作
l1394049664的博客
09-16 657
目录 Hadoop的I／O操作  1、数据完整性  1.1、HDFS的数据完整性  1.2、 LocalFileSystem 和 ChecksumFileSystem  2、 压缩 CompressionCodec 2.1、 codec：Hadoop中对常用压缩解压缩算法的实现 2.2、 压缩和输入分片 2.3、 在MapReduce中使用压缩 ​3、 序列化 Writable ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值