0

高并发,你真的理解透彻了吗?

高并发,几乎是每个程序员都想拥有的经验。原因很简单:随着流量变大,会遇到各种各样的技术问题,比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等,这些问题能推动我们在技术深度上不断精进。在过往的面试中,如果候选人做过高并发的项目,我通常会让对方谈谈对于高并发的理解,但是能系统性地回答好此问题的人并不多。大概分成这样几类:1、对数据化的指标没有概念:不清楚选择什么样的指标来衡量高并发系统?分不清并发量和QPS,甚至不知道自己系统的总用户量、活跃用户量,平峰和高峰时的QPS和TPS等关键数据。2、设计了一些方案,但是细节掌握不透彻:讲不出该方案要关注的技术点和可能带来的副作用。...

阅读全文>>

0

简单列一下分布式高并发要做的事情

数据库以MySQL为例。慢查询日志,索引优化(explain),覆盖索引。数据库一主多从或者双主多从。读写分离。然后对表进行垂直划分,例如一张字段很多的宽表转为子母表。水平划分,根据业务特性,对表进行分区(现在应该很少用),分表,甚至分库。数据该归档的归档,日表变月表,年表,或者变地域表等。使用sharding-jdbc等。甚至可以给数据库硬盘换上SSD。数据量再大,就该考虑大数据了。缓存以Redis为例。哨兵保证高可用,集群(最低3主3从)保证吞吐量(相当于MySQL的分库)。要注意缓存与DB的数据一致性(更新后删),缓存穿透(布隆过滤器),缓存雪崩(预热,随机时间过期)问题。还要关注持久化...

阅读全文>>

0

分布式高并发服务三种常用限流方案简介

服务限流场景在高并发大流量系统中,由于并发大造成服务资源不足,负载过高,进而引发致一系列问题,这里的流量一般都是突发性的,由于系统准备不足,很难短期扩容来应对 ,进行限流是最常用的手段,所以说限流也是服务稳定性治理重要的手段。限流可能发生在多个层面:用户网络层:突发的流量场景如热点事件流量(秒杀事件、热门抢购,微博热搜),恶意刷流,竞对爬虫等。内部应用层:上游服务的异常调用,脚本异常请求,失败重试策略造成流量突发。实现限流方案常用的限流方法主要有三种:计数器算法,漏斗桶算法,令牌桶算法。1.计算器限流1.1 实现原理设计限流条件,如根据用户id/商户id/IP/UUID+请求url作为限流对象...

阅读全文>>

0

高并发下的抽奖优化

一. 项目思考由于项目发起了一个抽奖活动,发起活动之前给所有用户发短信提示他们购买了我们的产品有抽奖权益。然后用户上来进入抽奖页面点击爆增,过了一会儿页面就打不开了。后面查看了下各种日志,发现了瓶颈在数据库,由于读写冲突严重,导致响应变慢,有不少连接都超时了。后面看到监控和日志留下的数据,发现负责抽奖的微服务集群qps暴涨12倍,db的qps也涨了10倍。这很明显是一个高并发下如何摆脱数据库读写,I/O瓶颈的问题。整点开抢后瞬时巨量的请求同时涌入,即使我们Nginx端做过初步限流,整个业务逻辑校验阶段运作良好,但是系统的瓶颈就转移到其他环节:大量的读写请求,导致后面的请求全部排队等待,等前面一...

阅读全文>>

0

高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!

前言很多小伙伴反馈说,高并发专题学了那么久,但是,在真正做项目时,仍然不知道如何下手处理高并发业务场景!甚至很多小伙伴仍然停留在只是简单的提供接口(CRUD)阶段,不知道学习的并发知识如何运用到实际项目中,就更别提如何构建高并发系统了!究竟什么样的系统算是高并发系统?今天,我们就一起解密高并发业务场景下典型的秒杀系统的架构,结合高并发专题下的其他文章,学以致用。电商系统架构在电商领域,存在着典型的秒杀业务场景,那何谓秒杀场景呢。简单的来说就是一件商品的购买人数远远大于这件商品的库存,而且这件商品在很短的时间内就会被抢购一空。 比如每年的618、双11大促,小米新品促销等业务场景,就是典型的秒杀...

阅读全文>>

0

高并发环境下,先操作数据库还是先操作缓存?

前言在分布式系统中,缓存和数据库同时存在时,如果有写操作的时候,先操作数据库还是先操作缓存呢?先思考一下,可能会存在哪些问题,再往下看。下面我分几种方案阐述。 缓存维护方案一假设有一写(线程A)一读(线程B)操作,先操作缓存,在操作数据库,如下流程图所示:1)线程A发起一个写操作,第一步del cache2)线程A第二步写入新数据到DB3)线程B发起一个读操作,cache miss,4)线程B从DB获取最新数据5)请求B同时set cache这样看,没啥问题。我们再看第二个流程图,如下:1)线程A发起一个写操作,第一步del cache2)此时线程B发起一个读操作,cache miss3)线程...

阅读全文>>