下订单减库存的方式 现在,连农村的大姐都会用手机上淘宝购物了,相信电商对大家已经非常熟悉了,如果熟悉电商开发的同学,就知道在买家下单购买商品的时候,是需要扣减库存的,当然有2种扣减库存的方式, 一种是预扣库存,相当于锁定库存, 一种是直接扣减库存. 我们采用的是预扣库存的方式,预扣库存的时候,在SalesInfo表中,将最大可售数量MaxSalesNum减去购买数量,用一条SQL语句来表示这个业务,就是下面这个样子的: update salesinfo set MaxSalesNum=MaxSa…
参考文章:https://www.cnblogs.com/zhangxiaoyong/p/8317229.html 顺丰需求文档: 链接:https://pan.baidu.com/s/16EEaphJu2MI9gEvR30pDwQ 提取码:ogry 我用的web API实现功能的 电商专递下单功能 static string xmlstr = "<Request service='OrderService' lang='zh-CN'><Head>erptest</…
原文:http://blog.csdn.net/heyewu4107/article/details/71009712 高并发场景系列(一) 利用redis实现分布式事务锁,解决高并发环境下减库存 问题描述:某电商平台,首发一款新品手机,每人限购2台,预计会有10W的并发,在该情况下,如果扣减库存,保证不会超卖 方案一 利用数据库锁机制,对记录进行锁定,再进行操作 SELECT * from goods where ID =1 for update; UPDATE goods set stock…
package tech.codestory.zookeeper.aalvcai.ConcurrentHashMapLock; import lombok.AllArgsConstructor; import lombok.Getter; import lombok.Setter; import org.redisson.Redisson; import org.redisson.api.RBucket; import org.redisson.api.RLock; import org.red…
问题引入 本文介绍的是最常用的也是mysql默认的innoDB引擎 Read committed隔离级别下事物的并发.这种情况下的事物特点是 读:在一个事物里面的select语句 不会受到其他事物(不管其他事物有没有commit)的影响. 写:对一条记录而言,一个事物一旦update一条记录,其他事物只能等待这个事物commit才能update那条记录. 举例并发分析: 比如表中num字段=10 需要根据num字段的数值做一些业务处理 事物A  begin   事物B begin   selec…
这里我借鉴了网上其他大佬的观点: 一:高并发带来的挑战 原因:秒杀抢购会经常会带来每秒几万的高并发场景,为了更快的返回结果给用户. 吞吐量指标QPS(每秒处理请求数),假设一个业务请求响应耗时为100ms,我们有10台Web服务器,每台给它最大连接数500. 理想化计算方式: 10 * 500/0.1 = 50000 难道我们真的有处理5万并发? 不然.高并发场景下,Web服务器打开了越多的连接进程,CPU切换上下文的也越多.会增加CPU的压力,导致CPU业务请求响应耗时 会超出预期很多.可能你…
1.悲观锁与乐观锁机制 为控制并发问题,我们通常采用锁机制.分为悲观锁和乐观锁两种机制. 悲观锁:很悲观,所有情况都上锁.此时只有一个线程可以操作数据.具体例子为数据库中的行级锁.表级锁.读锁.写锁等. 特点:优点是方便,直接加锁,对程序透明.缺点是效率低,并发能力非常弱. 乐观锁:很乐观,对数据本身不加锁.提交数据时,通过一种机制验证是否存在冲突,如es中通过版本号验证. 特点:优点是并发能力高.缺点是操作繁琐,在提交数据时,高并发的情况下,可能反复重试多次. 2.内部基于_version乐观…
购物车是电商APP的一个关键功能点,一般购物车包含 3-4 个页面,分别是: 1.购物车的商品列表页 2.商品下单页 3.订单付款页面 4.订单付款成功页面 由于现有购物车逻辑相对混乱,这里重新整理一下商品下单页的业务流程设计 1.生成订单 这里在业务层面把订单的生命周期划分为4个阶段,分别是: 订单的初始阶段 订单的完备阶段 订单的支付阶段 订单的服务阶段 1.1 订单的初始阶段 订单的初始阶段是在 购物车商品列表页开始的,订单的初始阶段确定了商品的种类和各个商品的初始数量, 此时订单金额只包…
场景描述: 表t2 中 有 自增主键 id  和 字段v  当插入记录的时候 要求 v与id 的值相等(按理来说这样的字段是需要拆表的,但是业务场景是 只有某些行相等 ) 在网上搜的一种办法是 先获取自增ID from t2 然后给v字段插入获取到的值 但是这样的做法在有删除行+调整过自增值的表中是不准确的 于是换个思路 从 information_schema 下手 读取表的信息 INSERT INTO `t2` VALUES ( NULL, ( SELECT `AUTO_INCREMENT`…
案例说明: 银行两操作员同时操作同一账户.比如A.B操作员同时读取一余额为1000元的账户,A操作员为该账户增加100元,B操作员同时为该账户扣除50元,A先提交,B后提交.最后实际账户余额为1000-50=950元,但本该为1000+100-50=1050.这就是典型的并发问题. 乐观锁机制在一定程度上解决了这个问题.乐观锁,大多是基于数据版本(Version)记录机制实现.何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version”…