1.扩容
例如存储资源mysql无法满足高并发要求。
增加读性能:memcahe,redis,CDN缓存等。
增加写性能:habse
2.缓存
(1)本地缓存:Guava Cache
Guava Cache类似于cocurrentHashMap,每个节点存储的数据达到上限使用LRU置换算法。
(2)分布式:memcache,redis
memcache: 每次客户端请求数据,才有 ip一致性算法 找到指定ip的服务器去处理。在一个有效的ip范围内,通过ip取模,找到大于且距离最近的服务器作为处理服务器,增加和删除单个节点,也可以保证服务正常运行。
memcache储存数据:每个chunk存储数据,其他的节点都是起到索引的作用。
每个slab都是以1.25倍递增的,比如slab[1]=80M,那么slab[2]=100M,slab[3]=125M.
如果此时进入一个value为85M的数据,会被放入slab[2]中,这样也导致,memcache储存数据必然存在资源浪费。
因为page大小固定式1M,所以单个数据最大是1M大小。
redis
redis作为主流缓存机制,支持的数据结构较多,还有持久化等。
(3)缓存雪崩:缓存无法使用,数据直接访问DB,缓存并发和缓存击穿等等都有可能导致缓存雪崩,还有一种可能就是所有数据同时过期(所以给不同的key需要设置不同的过期时间)
3.消息队列
消息队列可以错峰,避免大量数据同时访问数据库
4.系统拆分
微服务化或者dubbo
5.限流
5.1 计数器算法
限制每分钟100条数据,到达100条数据,就无法接受请求了。
缺陷:临界问题,如果用户在59秒的时候发送100条数据,1:00的时候发送100条请求,也就是1秒内发送200个请求,那么数据库原本只能一秒处理2-3个请求,此时可能直接崩溃。
5.2 滑动窗口算法
红色的是滑动窗口,于是相比计数器算法,我们多了一个限制,就是除了0-60秒的数据限制100条以外,我们窗口内的数据条数也最多100。
解决临界问题:如果59秒时请求100条数据,1:00请求100条数据,那么我们的窗口限流100发挥作用,拒绝请求。
5.3 漏桶算法
无论流入的数据量有多大,一旦总数据量超过桶的容量限制就会拒绝数据请求。而且可以保证流出的数据速率恒定。
5.4 令牌桶算法
向桶中放入令牌的速率是恒定的,每有一个处理过来就去拿一个令牌。
6.服务熔断和降级
熔断和降级的区别:
熔断:多次尝试失败以后放弃该方案。
降级:主方案调用失败,采用备用方案处理。
7.分库分表
分库–读写分离:常见的就是为了应对并发问题,读写分离,读数据库和写数据库区分,分出很多读数据库,可减轻主库的压力读取压力。(从数据读取主数据库日志实现数据同步)。
一主多从,主数据库为写入数据,从数据库负责读取。主数据库永远不需要担心读取问题了,从数据也只是从binlog读取数据。
分库–分数据源 :行情服务的数据放入一个库中,订单数据放入一个数据库中,实现分库。
分表 :某一张表,数据量太大影响读写效率。
横向分表:每张分表的表结构是一样的,但是每张表管理一部分id的数据。
纵向分表:可以将一个表里的内容划分成多个表,每个表存储一部分的字段,比如博客中的标题字段划分在一个表中,将内容字段划分在另一个表中。