java多线程学习笔记 --七.高并发处理思路和手段

高并发处理思路和手段

扩容

扩容—概念

  • 垂直扩容:提高系统部件能力(提升每辆卡车的运木材的多少)
  • 水平扩容:增加更多系统成员实现(增加卡车数量,例如集群)

扩容—数据库

  • 读操作扩展:memcache,redis,CDN等缓存
  • 写操作扩展:Cassandra,Hbase等

缓存

在这里插入图片描述

缓存的特征
  • 命中率:命中数/(命中数+没有命中数)
  • 最大元素(空间)
  • 清空策略:FIFO,LFU,LRU,过期时间,随机等
缓存命中率影响因素
  • 业务场景和业务需求
  • 缓存的设计(粒度和策略)
  • 缓存容量和基础设施
缓存分类和应用场景
  • 本地缓存:编程实现(成员变量、局部变量、静态变量)GuavaCache
    在这里插入图片描述

  • 分布式缓存:Memcache、redis

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

高并发环境下缓存常见问题
  • 缓存一致性
    在这里插入图片描述

  • 缓存并发问题
    在这里插入图片描述

  • 缓存穿透问题
    在这里插入图片描述

  • 缓存雪崩现象
    在这里插入图片描述

消息队列

在这里插入图片描述

  • 业务无关:只做消息分发
  • 容灾:节点的动态增删和消息的持久化
  • FIFO:先投递先到达
  • 性能:吞吐量提升,系统内部通信效率提高
为甚么要使用消息队列
  • 生产和消费的速度或稳定性等因素不一致
消息队列的好处
  • 业务解耦
  • 最终一致性
  • 广播
  • 错峰与流控

应用拆分

在这里插入图片描述

业务拆分的原则

  • 业务优先
  • 循序渐进
  • 兼顾技术:重构、分层
  • 可靠测试

微服务

在这里插入图片描述

应用限流

在这里插入图片描述

应用限流—算法

计数器法

在这里插入图片描述

滑动窗口

在这里插入图片描述

漏桶算法

在这里插入图片描述

令牌桶算法

在这里插入图片描述

服务降级与服务熔断

服务降级

当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作

简单理解,就是对目前不想做处理的服务和页面 给一个默认的返回

举例1:大家都见过女生旅行吧,大号的旅行箱是必备物,平常走走近处绰绰有余,但一旦出个远门,再大的箱子都白搭了,怎么办呢?常见的情景就是把物品拿出来分分堆,比了又比,最后一些非必需品的就忍痛放下了,等到下次箱子够用了,再带上用一用。而服务降级,就是这么回事,整体资源快不够了,忍痛将某些服务先关掉,待渡过难关,再开启回来

举例2:假如目前有很多人想要给我付钱,但我的服务器除了正在运行支付的服务之外,还有一些其它的服务在运行,比如搜索、定时任务和详情等等。然而这些不重要的服务就占用了JVM的不少内存与CPU资源,为了能把钱都收下来(钱才是目标),我设计了一个动态开关,把这些不重要的服务直接在最外层拒掉,这样处理后的后端处理收钱的服务就有更多的资源来收钱了(收钱速度更快了),这就是一个简单的服务降级的使用场景

自动降级:超时、失败次数、故障、限流
人工降级:秒杀、双11大促销
服务降级要考虑的问题
  • 核心服务、非核心服务
  • 是否支持降级、降级策略
  • 业务放通场景、策略

服务熔断

在股票市场,熔断这个词大家都不陌生,是指当股指波幅达到某个点后,交易所为控制风险采取的暂停交易措施。相应的,服务熔断一般是指软件系统中,由于某些原因使得服务出现了过载现象,为防止造成整个系统故障,从而采用的一种保护措施,所以很多地方把熔断亦称为过载保护

服务降级和服务熔断的比较

  1. 目的很一致,都是从可用性可靠性着想,为防止系统的整体缓慢甚至崩溃,采用的技术手段;
  2. 最终表现类似,对于两者来说,最终让用户体验到的是某些功能暂时不可达或不可用;
  3. 粒度一般都是服务级别,当然,业界也有不少更细粒度的做法,比如做到数据持久层(允许查询,不允许增删改);
  4. 自治性要求很高,熔断模式一般都是服务基于策略的自动触发,降级虽说可人工干预,但在微服务架构下,完全靠人显然不可能,开关预置、配置中心都是必要手段;

​ 而两者的区别也是明显的:

  1. 触发原因不太一样,服务熔断一般是某个服务(下游服务)故障引起,而服务降级一般是从整体负荷考虑;
  2. 管理目标的层次不太一样,熔断其实是一个框架级的处理,每个微服务都需要(无层级之分),而降级一般需要对业务有层级之分(比如降级一般是从最外围服务开始)
  3. 实现方式不太一样,这个区别后面会单独来说;

Hystrix

  • 再通过第三方客户端访问(通常是通过网络)依赖服务出现高延迟或者失败时,为系统提供保护和控制
  • 在分布式系统中防止级联失败
  • 快速失败同时能快速恢复
  • 提供失败回退和优雅的服务降级

数据库切库、分库、分表

数据库瓶颈

  • 单个数据库量太大(1T~2T):多个库
  • 单个数据库服务器压力过大、读写瓶颈:多个库
  • 单个表数据量过大:分表

数据库切库

  • 切库的基础及实际应用:读写分离

    • 使用一个主库和多个从库,主库负责数据更新和实时数据的查询,从库负责非实时数据的查询

    • 数据库读多写少,读取数据耗时长,把查询从主库中抽取出来,使用多个从库采取负载均衡

    • 自定义注解实现切库

数据库分库

数据库分表

什么时候考虑分表
横向分表与纵向分表

具体见具体笔记

数据库分表:mybatis分表插件

shardbatis2.0

高可用的一些手段

  • 任务调度系统分布式:elastic-job + zookeeper
  • 主备切换:apache curator + zookeeper分布式锁实现
  • List item
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值