建设网站好公司简介,网页导航栏设计图片,网络营销调研名词解释,深圳网站开发工程师简介#xff1a;并发问题是电商系统最常见的问题之一#xff0c;例如库存超卖、抽奖多发、券多发放、积分多发少发等场景#xff1b;之所以会出现上述问题#xff0c;是因为存在多机器多请求同时对同一个共享资源进行修改#xff0c;如果不加以限制#xff0c;将导致数据…简介并发问题是电商系统最常见的问题之一例如库存超卖、抽奖多发、券多发放、积分多发少发等场景之所以会出现上述问题是因为存在多机器多请求同时对同一个共享资源进行修改如果不加以限制将导致数据错乱和数据不一致性解决并发问题的方式有很多例如队列、异步、响应式、锁都可以由于当前互联网都是分布式系统因此本文只针对使用较为广泛的分布式锁的方式来进行叙述如何进行质量保障。 作者 | 靖北 来源 | 阿里技术公众号
一 背景
并发问题是电商系统最常见的问题之一例如库存超卖、抽奖多发、券多发放、积分多发少发等场景之所以会出现上述问题是因为存在多机器多请求同时对同一个共享资源进行修改如果不加以限制将导致数据错乱和数据不一致性解决并发问题的方式有很多例如队列、异步、响应式、锁都可以由于当前互联网都是分布式系统因此本文只针对使用较为广泛的分布式锁的方式来进行叙述如何进行质量保障。
二 分布式锁介绍
1 什么是分布式锁
先了解一下什么是锁在单机系统中多个线程同时改变一个变量时需要对变量或者代码块做同步从而保证串行修改变量该同步实质上就是通过锁来实现。为了实现多个线程在同一个时刻针对同一块代码串行执行就需要在某个地方做个标记该标记必须每个线程都能看到当标记不存在时可以设置该标记其余后续线程发现已经有标记了则等待拥有标记的线程结束同步代码块取消标记后再去尝试设置标记此标记可以理解为锁。分布式锁就是在多机系统下的该标记。 2 实现分布式锁的主流方式
目前分布式锁的实现方式有3种主流方法即 基于数据库实现分布式锁此处的数据库指的是MySQL关系型数据库 基于MySQL锁表数据库版本号乐观锁基于缓存实现分布式锁此处的缓存指的是Redis基于zookeeper/etcd实现分布式锁
具体的关于锁的实现方式已经有太多的文章进行介绍本文就不再赘述。
三 质量保障
并发问题一旦涉及到钱通常都会导致不同程度的资损而且在我们的功能测试中是很难发现因此对于并发的质量保障显得尤为的重要可以抽象为3层来保障事前、事中、事后三大步骤事前保障通过Review 方式提前规避技术上的风险事中保障验证在技术实现过程中是否存在漏洞事后保障校验数据是否符合预期对于有并发风险的项目上述三个步骤的保障缺一不可。
1 事前质量保障
事前保障的阶段发生在技术评审阶段在此阶段我们需要评估出当前业务场景下是否存在并发风险如果存在确定我们的技术选型。
评估并发风险
评估并发风险的关键点在于是否存在多个进程同时访问共享资源简单来说是否存在多个进程在同一时间对同一个数据进行更新的操作例如电商中的库存多人同时购买同一个商品也就是会存在同一时间对同一个商品的库存进行更新此处就存在并发风险。
技术选型
要做到正确的技术选型我们就需要对上述3种方式实现的锁的优缺点以及应用场景需要进行了解。 MySQL数据库表的乐观锁适用于读多写少的场景且共享资源为数据库的单行数据MySQL表锁实现的锁一般都不推荐使用ZooKeeper分布式锁虽然适用于大部分分布式场景但是由于其实现复杂度相对较高以及需要额外引入中间件在大部分业务场景中的应用比较少而基于Redis的缓存分布式锁应用较为广泛但是具体业务实现采用哪种类型的分布式锁还是需要基于当前的业务特性来进行决定
在技术评审阶段一方面我们要评估出是否存在并发风险另外一方面我们需要识别开发同学在技术的实现上可能存在的漏洞针对分布式锁的实现漏洞可参考下文的CodeReview的关注点。
2 事中保障
CodeReview
1Redis缓存分布式锁
Redis通常可以使用setnx(key,value)函数来实现分布式锁。key和value就是基于缓存的分布式锁的两个属性其中key表示锁id。setnx函数返回1表示获得锁返回0表示其他服务器已经获得了锁;
Redis缓存分布式锁CodeReview注意点
1、Redis Key
全面梳理业务场景对于同一共同资源key要保持一致key是识别共享资源的唯一键key的设计既需要能够锁住当前共享资源又不能影响到其他资源
例如商品库存我们的key应该是具体到某个商品而不是所有商品锁住A商品不会影响B商品。
2、锁释放
锁一定需明确释放try/finally 结构加锁解锁finally内释放锁;锁只能被加锁的对象释放此处是经常出问题的点如下图所示A加锁被B释放锁导致锁失效锁被C抢占到针对上述问题释放锁时需要先读取当前key的value,再和传入的value进行比较上述是两个步骤一定要保证原子性,如果原生Redis可采用lua脚本保证原子性如果tair可采取TairString的cad方法value必须是一个唯一值唯一标记是当前对象加的锁。
3、锁超时
一定要设置key的超时时间例如:客户端A 抢到锁后系统突然异常A就无法释放锁变成死锁设置超时时间就是为了防止此种情况发生在时间到期后自动删除key间接释放锁;超时时间的设置一般来讲大于服务的最大执行时间即可但是服务最大的执行时间会受很多因素影响是不可控的例如A服务一般执行时间是30ms设置的锁超时时间为100ms受网络影响服务执行时间变成了200ms在100ms的时候锁就会被释放了在大部分场景下开发不会处理此种情况此种极端情况是否需要处理需要进行协商处理方式如下2种可以再开启一个线程为当前超时时间续时但增加了系统的复杂度将过期时间设置非常长一定能保证逻辑在锁释放之前能够执行完成此方案简单但是有缺陷当遇到系统突发异常时锁无法被释放只能等待redis key超时而超时时间又设置的较长因此在当前时间内谁都无法获取到锁阻断业务执行很有可能造成故障4、锁粒度
如果针对某个共享资源的写是基于另外一个共享资源的值计算而来那么锁的范围必须包含读共享资源范围不包含读共享资源会导致脏读最终导致数据的错误如下图所示Client B最终计算的B的结果就是错误的。 5、获取锁失败
由于其他线程已经获取到了锁当前线程获取锁失败后有3种处理方式异常抛出让用户重试通过自旋再次进行抢锁发布订阅订阅锁释放消息在并发度低的场景下异常抛出以及自旋抢锁都可以在高并发场景下异常抛出和自旋抢锁都不可取。
2MySQL数据库锁CR点
数据库版本号乐观锁
在数据库的表中需要包含一个数字类型的字段version读取数据时把version字段读出来更新数据时判断当前version是否等于读取出来的version并对当前version1如果等于就更新成功不等于表示数据已过期更新失败。例如以积分体系为例存在多种场景增加积分通过乐观锁来保证数据的正确性。 乐观锁CR注意点:
where 条件一定要命中索引(最好是主键或者唯一索引)否则会锁表update table set 中必须要包含version version 1update 返回结果为0时一定要根据业务场景进行相应的处理自主重试或者抛异常
基于MySQL锁表
其实现原理是创建一张锁表对临界资源做唯一性约束通过增加一条记录对某一资源上锁释放锁时删除记录一般不推荐此种用法。
并发测试
并发测试总体上可以分为3大类
复杂的并发场景一次请求共享资源存在多个且前后存在各种依赖关系此种场景适合于链路级别压测压测模型需要精心设计。 单一并发场景一个共享资源可以处理多次例如扣除某个商品的库存可以反复调用。 可以通过接口压测的方式进行测试通过查看最终数据是否会存在与预期不一致情况即可压测工具jmeter 即可进行压测集团可直接采用pas-server进行压测方便快捷 单一并发场景一个共享资源且只能处理1次例如用户只有一次抽奖机会连续点2次会不会抽2次 可以利用JVM的并发函数CountDownLatchCyclicBarrier等CountDownLatch片段代码public void invokeAllTask(ConcurrencyRequest request, Runnable task) {final CountDownLatch startCountDownLatch new CountDownLatch(1);final CountDownLatch endCountDownLatch new CountDownLatch(request.getConcurrency());for (int i 0; i request.getConcurrency(); i) {Thread t new Thread(() - {try {startCountDownLatch.await();try {task.run();} finally {endCountDownLatch.countDown();}} catch (Exception ex) {log.error(异常, ex);}});t.start();}startCountDownLatch.countDown();try {endCountDownLatch.await();} catch (InterruptedException ex) {log.error(线程异常中断, ex);}}利用jmeter的定时器 Synchronizing Timer也可以实现此功能
3 事后保障
数据对账
数据对账(数据一致性校验)是我们在系统上线后对并发问题的最后一道防线通过对账来识别我们的数据的不一致性问题压测有成本且受技巧熟练度和压测设计的影响不一定能暴露问题如果被测场景评估并发问题的发生概率极低即使发生了影响也比较小此时review对账方式也不失为一种好的选择
如何进行对账不同的业务场景有不同的对账方法例如
互动积分体系每个用户的扣除以及增加积分都会落流水表每个用户目前有多少积分都会放在积分表只需要把流水表的积分加总和积分表的积分进行对账互动任务体系一笔订单只能推进一个任务对账只需要检查任务记录中一笔订单是否存在多条记录
select count(*) as task_count,scene_code,order_idfrom task_recordwhere unique_id is not nullgroup by scene_code,order_id
having count(*) 1
四 总结
作为质量保障同学一定要时刻绷着一根弦当前场景下是否会存在并发问题并发问题的识别简单而言就是是否存在同时更新同一个数据如果是就一定要注意开发同学是否处理了并发并发的实现主要是上面阐述的几种然后按照场景进行分析即可关于并发场景的质量保障大体原则可以概括为如下
1、梳理并发场景
2、带着注意点CR 代码
3、并发测试(非银弹不是所有场景都具备可测性)
4、监控对账进行兜底识别并发问题
原文链接
本文为阿里云原创内容未经允许不得转载。
