高并发热点/单点数据_性能问题解决方案

https://blog.csdn.net/sjyttkl/article/details/75208412

数据的热点单点问题由于其独有的高访问特性，在性能上一直都一大难题，IT界的大牛们也一直在寻求一种更为优化的解决方案！其中也不乏很多优秀的解决方案，但随着业务的不断攀升和互联网的高速发展，也就显得捉襟见肘，可见对此探索的重要性！

最近项目中也遇到了此瓶颈，请容我将前因后果以及我自己设想的粗陋方案娓娓道来，欢迎大神们拍砖，在下感激不尽！

前段时间接了一个双11的活动，业务逻辑：用户购买某一类商品后，活动期间的4个整点在活动页点击按钮领取支付宝红包，每个时段奖品数量有限，先到先得。听着很简单，可是活动开始时，异常火热，流量超过了我们的预估，本来是分时段领取奖品，结果演变为了秒杀。

当时每个整点的QPS瞬间飙高，响应时间RT短时间内居高不下，但是整个Check下来应用全部机器的负载都非常正常，后来全面查找原因，才找到问题的根源，是由于每个时段更新数据库同一条奖品导致超时！

整点开抢后瞬时巨量的请求同时涌入，即使我们Apache端做过初步限流，应用也做了信号量的控制，而且加上分布式缓存的使用，减缓了相当大的压力，整个业务逻辑校验阶段运作良好，但是系统的瓶颈就转移到其他环节：减奖品库存!因为我们每个时段只有一个奖品A，每次减库存都是update奖品A中的奖品余额字段！大量符合发奖要求的用户请求瞬时涌入数据库去更新此条记录，update锁行，导致后面的请求全部排队等待，等前面一个update完成释放行锁后才能处理下一个请求，大量请求等待，占用了数据库的连接！一旦数据库同一时间片内的连接数被打满，就会导致这个时间片内其他后来的全部请求因拿不到连接而超时，导致访问此数据库的其他环节也出现问题！所以RT就会异常飙高！

根据木桶理论，我们后续肯定必须得优化这个最短板，将这个瓶颈解决!针对这样的情况，我们这边出了两套方案：1、强依赖分布式缓存达到减库存的目的；2、热点/单点数据拆分，弱依赖分布式缓存，采用分散热点的方式减库存.下面请允许我详细分解下这两套方案，也希望大家提各种建设性意见！

一、强依赖分布式缓存

应用中使用分布式缓存来存储当前时间段的奖品余额，有用户中奖则将此缓存中的余额减一，不需要查询和实时更新数据库，而是每隔自定义的一段时间将缓存中的余额异步更新至数据库中。

优点：这种方式完全依赖于缓存，读写速度快，不需要实时更新数据库，降低了数据库相当大的压力；

缺点：缓存不是100%稳定，很容易丢，即使采用持久化的缓存，在高并发下有时也会出问题；一旦丢失数据，这样就导致数据库记录的奖品余额比实际真实存在的奖品余额要多，这个时候读数据库，就会导致奖品多发，也就是所谓的超卖！

二、热点/单点数据拆分，弱依赖分布式缓存

某时段的一个奖品拆分为多条后，如何能保证先到先得的业务需求将奖品准确发完，这里就引入分布式缓存作为辅助，缓存不完全稳定没关系，只是借助其在多条奖品中进行准确分发，当数据库所有奖品都有余额的情况时，能减少查询操作！只有当某一条奖品余额为0时缓存中的数据才会失效，这时才需要查询一次数据库！

步骤：

1、同个时段的奖品拆为多份(比如10份），加行号N区分（1~10），奖1~10的数值存入数组M中；

2、根据行号1~10 ，查询分布式缓存中是否存在各行奖品对应的记录（缓存中存放没余额的奖品行）；

是：将存在的行号存入数组P；

否：数组P值为NULL；

3、数组M-数组P=数组R；

4、判断数组R是否为空 ;

是：没有奖品余额，返回未中奖！

否：在数组R中随机一个行号L；

5、更新数据库表，将L行奖品余额减一；

更新成功：减奖品库存成功，直接返回发奖成功！

更新失败：极大可能原因是由于没有奖品导致

5.1、查询数据库中这10个奖品List（全量list）；

5.2、将List中没有奖品余额的行同步至对应的缓存（第2 步），并判断List中是否所有奖品行余额全为0；

是：无奖品，返回未中奖；

否： List中选择一个有余额的奖品，最好是余额最多的，将行号存入L，执行第5 步；

流程图:

优点：此方案不会发生奖品多发的情况，将单行数据分拆为多行，分散了热点，同样可以减轻数据库更新时超负荷长链等待导致的连接被等待用户占用而后续请求超时，可以通过拆分为适量的行来解决单点热点数据带来的性能问题！

缺点：此方案需要做业务拆解，增加了业务的复杂性！奖品拆分为多条，数据量太大时，不是很便捷，可能会带来数据库性能问题，但这个可以通过分库分表，旧数据迁移备份的方式解决！在奖品快被抽完的那么几微秒的用户可能存在误杀！

这就是目前针对数据库的单点热点问题，我个人的一些见解，也只是初步构想，还没有进入完全的实践中，还希望各位大神多指点一二！

高并发热点/单点数据_性能问题解决方案相关推荐

高并发热点缓存数据可能出现问题及解决方案
背景电商场景促销活动的会场页由于经常集中在某个时间点进行"秒杀"促销,这些页面的QPS(服务器每秒可以处理的请求量)往往特别高,数据库通常无法直接支撑如此高QPS的请求,常见的解 ...
[分布式][高并发]热点缓存的架构优化
目录 (1)为什么要用缓存集群 (2)20万用户同时访问一个热点缓存的问题 (3)基于流式计算技术的缓存热点自动发现 (4)热点缓存自动加载为JVM本地缓存 (5)限流熔断保护 (6)总结 (1)为什 ...
高并发编程-线程通信_使用wait和notify进行线程间的通信2_多生产者多消费者导致程序假死原因分析
文章目录概述 jstack或者可视化工具检测是否死锁(没有) 原因分析概述高并发编程-线程通信_使用wait和notify进行线程间的通信 - 遗留问题我们看到了应用卡住了 .... 怀疑是 ...
Web网站架构演变—高并发、大数据
转 Web网站架构演变-高并发.大数据 2018年07月25日 17:27:22 gis_morningsun 阅读数:599 前言我们以javaweb为例,来搭建一个简单的电商系统,看看这个系统可 ...
高并发-----高并发和大数据的处理
随着网络的普遍,我们的生活慢慢被信息所包围.我们做web开发的,遇到高并发和大数据的情况很正常,那么我们需要怎么做才能解决这些问题? 高并发的解决方案说到高并发,我们遇到的高并发是如何产生的呢?大家 ...
高并发-------------高并发和大数据的处理
随着网络的普遍,我们的生活慢慢被信息所包围.我们做web开发的,遇到高并发和大数据的情况很正常,那么我们需要怎么做才能解决这些问题? 高并发的解决方案说到高并发,我们遇到的高并发是如何产生的呢?大家 ...
如何掌握java多线程，高并发，大数据方面的技能？
https://www.zhihu.com/question/27575123 如何掌握java多线程,高并发,大数据方面的技能? 因为想进入互联网公司,然后发现互联网类型的公司问的主要问题都离不开这 ...
centos 多台文件夹同步_在Centos下对高并发web框架Tornado的性能进行测试
原文转载自「刘悦的技术博客」https://v3u.cn/a_id_89 在之前的一篇文章中,我们在1g1核的惨淡硬件环境下,对 uwsgi + django 和 gunicorn+ django 的 ...
Java面试总结如何处理项目的高并发、大数据
1.HTML静态化如果网站的请求量过大,我们可以将页面静态化提供访问来缓解服务器压力,能够缓解服务器压力加大以及降低数据库数据的频繁交换.适合于某些访问了过大,但是内容不经常改变的页面,如首页.新闻 ...

高并发热点/单点数据_性能问题解决方案

高并发热点/单点数据_性能问题解决方案相关推荐

最新文章

热门文章