Redis集群HA架构+双写一致性解决方案、Nginx+Storm负载均衡策略、Hyst-shop-detail.zip

### hystrix的一些概念 资源隔离：让你的系统里，某一块东西，在故障的情况下，不会耗尽系统所有的资源，比如线程资源 我实际的项目中的一个case，有一块东西，是要用多线程做一些事情，小伙伴做项目的时候，没有太留神，资源隔离，那块代码，在遇到一些故障的情况下，每个线程在跑的时候，因为那个bug，直接就死循环了，导致那块东西启动了大量的线程，每个线程都死循环 最终导致我的系统资源耗尽，崩溃，不工作，不可用，废掉了 资源隔离，那一块代码，最多最多就是用掉10个线程，不能再多了，就废掉了，限定好的一些资源 hystrix进行资源隔离，其实是提供了一个抽象，叫做command，就是说，你如果要把对某一个依赖服务的所有调用请求，全部隔离在同一份资源池内 对这个依赖服务的所有调用请求，全部走这个资源池内的资源，不会去用其他的资源了，这个就叫做资源隔离 hystrix最最基本的资源隔离的技术，线程池隔离技术 对某一个依赖服务，商品服务，所有的调用请求，全部隔离到一个线程池内，对商品服务的每次调用请求都封装在一个command里面 每个command（每次服务调用请求）都是使用线程池内的一个线程去执行的 所以哪怕是对这个依赖服务，商品服务，现在同时发起的调用量已经到了1000了，但是线程池内就10个线程，最多就只会用这10个线程去执行 不会说，对商品服务的请求，因为接口调用延迟，将tomcat内部所有的线程资源全部耗尽，不会出现了 限流：高并发的流量涌入进来，比如说突然间一秒钟100万QPS，废掉了，10万QPS进入系统，其他90万QPS被拒绝了 熔断：系统后端的一些依赖，出了一些故障，比如说mysql挂掉了，每次请求都是报错的，熔断了，后续的请求过来直接不接收了，拒绝访问，10分钟之后再尝试去看看mysql恢复没有 降级：mysql挂了，系统发现了，自动降级，从内存里存的少量数据中，去提取一些数据出来 运维监控：监控+报警+优化，各种异常的情况，有问题就及时报警，优化一些系统的配置和参数，或者代码 ### hystrix为了实现高可用性的架构，设计hystrix的时候，一些设计原则是什么？？？ （1）对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护 （2）在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了，服务B也故障了，服务A故障了，整套分布式系统全部故障，整体宕机 （3）提供fail-fast（快速失败）和快速恢复的支持 （4）提供fallback优雅降级的支持 （5）支持近实时的监控、报警以及运维操作 调用延迟+失败，提供容错 阻止故障蔓延 快速失败+快速恢复 降级 监控+报警+运维 ### Hystrix要解决的问题是什么？ 在复杂的分布式系统架构中，每个服务都有很多的依赖服务，而每个依赖服务都可能会故障 如果服务没有和自己的依赖服务进行隔离，那么可能某一个依赖服务的故障就会拖垮当前这个服务 举例来说，某个服务有30个依赖服务，每个依赖服务的可用性非常高，已经达到了99.99%的高可用性 那么该服务的可用性就是99.99%的30次方，也就是99.7%的可用性 99.7%的可用性就意味着3%的请求可能会失败，因为3%的时间内系统可能出现了故障不可用了 对于1亿次访问来说，3%的请求失败，也就意味着300万次请求会失败，也意味着每个月有2个小时的时间系统是不可用的 在真实生产环境中，可能更加糟糕 上面也就是说，即使你每个依赖服务都是99.99%高可用性，但是一旦你有几十个依赖服务，还是会导致你每个月都有几个小时是不可用的 画图分析说，当某一个依赖服务出现了调用延迟或者调用失败时，为什么会拖垮当前这个服务？以及在分布式系统中，故障是如何快速蔓延的？ ### 线程池隔离技术与信号量隔离技术的区别 1、线程池隔离技术与信号量隔离技术的区别 hystrix里面，核心的一项功能，其实就是所谓的资源隔离，要解决的最最核心的问题，就是将多个依赖服务的调用分别隔离到各自自己的资源池内 避免说对某一个依赖服务的调用，因为依赖服务的接口调用的延迟或者失败，导致服务所有的线程资源全部耗费在这个服务的接口调用上 一旦说某个服务的线程资源全部耗尽的话，可能就导致服务就会崩溃，甚至说这种故障会不断蔓延 hystrix，资源隔离，两种技术，线程池的资源隔离，信号量的资源隔离 信号量，semaphore 信号量跟线程池，两种资源隔离的技术，区别到底在哪儿呢？ 2、线程池隔离技术和信号量隔离技术，分别在什么样的场景下去使用呢？？ 线程池：适合绝大多数的场景，99%的，线程池，对依赖服务的网络请求的调用和访问，timeout这种问题 信号量：适合，你的访问不是对外部依赖的访问，而是对内部的一些比较复杂的业务逻辑的访问，但是像这种访问，系统内部的代码，其实不涉及任何的网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获timeout类似的问题，算法+数据结构的效率不是太高，并发量突然太高，因为这里稍微耗时一些，导致很多线程卡在这里的话，不太好，所以进行一个基本的资源隔离和访问，避免内部复杂的低效率的代码，导致大量的线程被hang住 3、在代码中加入从本地内存获取地理位置数据的逻辑 业务背景里面， 比较适合信号量的是什么场景呢？ 比如说，我们一般来说，缓存服务，可能会将部分量特别少，访问又特别频繁的一些数据，放在自己的纯内存中 一般我们在获取到商品数据之后，都要去获取商品是属于哪个地理位置，省，市，卖家的，可能在自己的纯内存中，比如就一个Map去获取 对于这种直接访问本地内存的逻辑，比较适合用信号量做一下简单的隔离 优点在于，不用自己管理线程池拉，不用care timeout超时了，信号量做隔离的话，性能会相对来说高一些 4、采用信号量技术对地理位置获取逻辑进行资源隔离与限流 super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")) .andCommandPropertiesDefaults(HystrixCommandProperties.Setter() .withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE))); ### hystrix配置 1、execution.isolation.strategy 指定了HystrixCommand.run()的资源隔离策略，THREAD或者SEMAPHORE，一种是基于线程池，一种是信号量 线程池机制，每个command运行在一个线程中，限流是通过线程池的大小来控制的 信号量机制，command是运行在调用线程中，但是通过信号量的容量来进行限流 如何在线程池和信号量之间做选择？ 默认的策略就是线程池 线程池其实最大的好处就是对于网络访问请求，如果有超时的话，可以避免调用线程阻塞住 而使用信号量的场景，通常是针对超大并发量的场景下，每个服务实例每秒都几百的QPS，那么此时你用线程池的话，线程一般不会太多，可能撑不住那么高的并发，如果要撑住，可能要耗费大量的线程资源，那么就是用信号量，来进行限流保护 一般用信号量常见于那种基于纯内存的一些业务逻辑服务，而不涉及到任何网络访问请求 ne