1 はじめに
同時実行性の高いシナリオは、現場での日常業務、特にインターネット企業で非常に一般的です。この記事では、製品を数秒で販売することで同時実行性の高いシナリオをシミュレートします。この記事のすべてのコード、スクリプト、テスト ケースは記事の最後に添付されています。
- この記事の環境: SpringBoot 2.5.7 + MySQL 8.0 X + MybatisPlus + Swagger2.9.2
- シミュレーションツール: Jmeter
- シミュレーション シナリオ:在庫の削減 -> 注文の作成 -> 支払いのシミュレーション
2. 商品のスパイク - 売られすぎ
@Transactional
開発では、トランザクション アノテーションと Lock ロックをサービスに追加するコードに精通しているかもしれません。
Spring Boot の基本については紹介しませんので、この無料チュートリアルを参照することをお勧めします。
制御層:コントローラー
@ApiOperation(value="秒杀实现方式——Lock加锁")
@PostMapping("/start/lock")
public Result startLock(long skgId){
try {
log.info("开始秒杀方式一...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByLock(skgId, userId);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂,人也太多了,请稍后!");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return Result.ok();
}
ビジネス層: サービス
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByLock(long skgId, long userId) {
lock.lock();
try {
// 校验库存
SecondKill secondKill = secondKillMapper.selectById(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
// 扣库存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
// 创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
// 模拟支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
lock.unlock();
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
上記のコードでビジネスメソッドにトランザクションを追加し、ビジネス処理時にロックをかけることは問題ないはずです。
ただし、上記の書き方には問題があり、売られすぎの状況が発生します。テスト結果を見てください: 1000 個の同時実行をシミュレートし、100 個の製品を取得します。
ここでは、ビジネスメソッドの開始時にロックが追加され、ビジネスメソッドの終了後にロックが解放されます。ただし、ここでのトランザクションの送信はそうではなく、トランザクションが送信される前にロックが解除されている可能性があり、商品が売れすぎてしまう可能性があります。ですのでロックするタイミングが非常に重要です!
3. 売られ過ぎを解決する
上記の売られすぎ現象の主な問題は、トランザクション内でロックが解放されるときに発生し、トランザクションがコミットされる前にロックが解放されます。(トランザクションの送信は、メソッド全体が実行された後に実行されます)。この問題を解決するには、ロックのステップを進めることです。
- コントローラー層でロック可能
- ビジネスメソッドが実行される前にAopを使用してロックできます
3.1 方法 1 (バージョンロックの改善)
@ApiOperation(value="秒杀实现方式——Lock加锁")
@PostMapping("/start/lock")
public Result startLock(long skgId){
// 在此处加锁
lock.lock();
try {
log.info("开始秒杀方式一...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByLock(skgId, userId);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂,人也太多了,请稍后!");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
// 在此处释放锁
lock.unlock();
}
return Result.ok();
}
上記のロックにより、トランザクションがコミットされる前にロックが解放される問題を解決でき、次の 3 つの状況でストレス テストを実行できます。
- 同時数1000、商品100
- 同時数1000、商品1000
- 同時数2000、商品1000
同時実行数が製品数よりも大きい場合、通常、製品セキュリティが過小販売されているようには見えませんが、同時実行数が製品数以下の場合、販売数が少なくなる可能性があります。商品の販売もとてもわかりやすいです。
問題がなければ、テクスチャはありません、方法がたくさんあるため、テクスチャが多すぎることになります
3.2 方法 2 (AOP バージョンロック)
制御層でロックする上記の方法は洗練されていないように見えるかもしれませんが、トランザクション前にロックする別の方法、つまり AOP があります。
オープンソースで無料の Spring Boot の最も完全なチュートリアルをお勧めします。
カスタム AOP アノテーション
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ServiceLock {
String description() default "";
}
アスペクトクラスを定義する
@Slf4j
@Component
@Scope
@Aspect
@Order(1) //order越小越是最先执行,但更重要的是最先执行的最后结束
public class LockAspect {
/**
* 思考:为什么不用synchronized
* service 默认是单例的,并发下lock只有一个实例
*/
private static Lock lock = new ReentrantLock(true); // 互斥锁 参数默认false,不公平锁
// Service层切点 用于记录错误日志
@Pointcut("@annotation(com.scorpios.secondkill.aop.ServiceLock)")
public void lockAspect() {
}
@Around("lockAspect()")
public Object around(ProceedingJoinPoint joinPoint) {
lock.lock();
Object obj = null;
try {
obj = joinPoint.proceed();
} catch (Throwable e) {
e.printStackTrace();
throw new RuntimeException();
} finally{
lock.unlock();
}
return obj;
}
}
AOP アノテーションをビジネス メソッドに追加する
@Override
@ServiceLock // 使用Aop进行加锁
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByAop(long skgId, long userId) {
try {
// 校验库存
SecondKill secondKill = secondKillMapper.selectById(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
//扣库存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
//创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
制御層:
@ApiOperation(value="秒杀实现方式二——Aop加锁")
@PostMapping("/start/aop")
public Result startAop(long skgId){
try {
log.info("开始秒杀方式二...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByAop(skgId, userId);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂,人也太多了,请稍后!");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
この方法は、ロックの使用においてより高度で、より美しくなります。
3.3 方法 3 (悲観的ロック 1)
上記のビジネス コード レベルでのロックに加えて、同時実行制御のためにデータベースに付属するロックを使用することもできます。
悲観的ロック、悲観的ロックとは何ですか? 平たく言えば、何かを行う前にロックの確認を実行する必要があります。このデータベース レベルのロック操作は効率が低くなります。
for update を使用する場合は、トランザクションを追加する必要があります。トランザクションが処理された後、for update は行レベルのロックを解放します。
リクエスト数がフラッシュ商品の数と同じ場合、売上は少なくなります
@ApiOperation(value="秒杀实现方式三——悲观锁")
@PostMapping("/start/pes/lock/one")
public Result startPesLockOne(long skgId){
try {
log.info("开始秒杀方式三...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByUpdate(skgId, userId);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂,人也太多了,请稍后!");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
ビジネスの論理
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByUpdate(long skgId, long userId) {
try {
// 校验库存-悲观锁
SecondKill secondKill = secondKillMapper.querySecondKillForUpdate(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
//扣库存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
//创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
ダオ層
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 将此行数据进行加锁,当整个方法将事务提交后,才会解锁
* @param skgId
* @return
*/
@Select(value = "SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
}
上記は、クエリデータをロックする更新に使用し、行ロックを追加します。
3.4 方法 4 (悲観ロック 2)
悲観的ロックの 2 番目の方法は、update update コマンドを使用してテーブル ロックを追加することです。
/**
* UPDATE锁表
* @param skgId 商品id
* @param userId 用户id
* @return
*/
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByUpdateTwo(long skgId, long userId) {
try {
// 不校验,直接扣库存更新
int result = secondKillMapper.updateSecondKillById(skgId);
if (result > 0) {
//创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
ダオ層
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 将此行数据进行加锁,当整个方法将事务提交后,才会解锁
* @param skgId
* @return
*/
@Select(value = "SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
@Update(value = "UPDATE seckill SET number=number-1 WHERE seckill_id=#{skgId} AND number > 0")
int updateSecondKillById(@Param("skgId") long skgId);
}
3.5 方法 5 (楽観的ロック)
オプティミスティック ロックは、その名前が示すように、バージョン フィールドを使用してデータが変更されたかどうかを判断することにより、操作の結果について非常に楽観的です。
楽観的ロック、在庫数量を確認せず、直接在庫控除を行う
ここで使用されるオプティミスティック ロックにより、多数のデータ更新例外が発生します (例外がスローされると購入が失敗します)。設定されたスナップアップの数が 120:100 (人数: 商品) など比較的小さい場合、 , 購入数が少なくなります. 楽観主義は推奨しません. ロック.
@ApiOperation(value="秒杀实现方式五——乐观锁")
@PostMapping("/start/opt/lock")
public Result startOptLock(long skgId){
try {
log.info("开始秒杀方式五...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
// 参数添加了购买数量
Result result = secondKillService.startSecondKillByPesLock(skgId, userId,1);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂,人也太多了,请稍后!");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByPesLock(long skgId, long userId, int number) {
// 乐观锁,不进行库存数量的校验,直接
try {
SecondKill kill = secondKillMapper.selectById(skgId);
// 剩余的数量应该要大于等于秒杀的数量
if(kill.getNumber() >= number) {
int result = secondKillMapper.updateSecondKillByVersion(number,skgId,kill.getVersion());
if (result > 0) {
//创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 将此行数据进行加锁,当整个方法将事务提交后,才会解锁
* @param skgId
* @return
*/
@Select(value = "SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
@Update(value = "UPDATE seckill SET number=number-1 WHERE seckill_id=#{skgId} AND number > 0")
int updateSecondKillById(@Param("skgId") long skgId);
@Update(value = "UPDATE seckill SET number=number-#{number},version=version+1 WHERE seckill_id=#{skgId} AND version = #{version}")
int updateSecondKillByVersion(@Param("number") int number, @Param("skgId") long skgId, @Param("version")int version);
}
楽観的ロックにより、多数のデータ更新例外が発生し (例外がスローされると購入が失敗します)、購入数が減ります。楽観的ロックは推奨されません。
3.6 方法 6 (キューをブロックする)
ブロッキング キューを使用すると、同時実行性の問題も解決できます。このアイデアは、受信したリクエストをキューに順番に格納し、コンシューマー スレッドがキューからデータを 1 つずつフェッチして処理するというものです。具体的なコードを参照してください。
ブロッキング キュー: ここでは、シングルトン モードの実装に静的内部クラスが使用されており、同時実行条件下では問題はありません。
// 秒杀队列(固定长度为100)
public class SecondKillQueue {
// 队列大小
static final int QUEUE_MAX_SIZE = 100;
// 用于多线程间下单的队列
static BlockingQueue<SuccessKilled> blockingQueue = new LinkedBlockingQueue<SuccessKilled>(QUEUE_MAX_SIZE);
// 使用静态内部类,实现单例模式
private SecondKillQueue(){};
private static class SingletonHolder{
// 静态初始化器,由JVM来保证线程安全
private static SecondKillQueue queue = new SecondKillQueue();
}
/**
* 单例队列
* @return
*/
public static SecondKillQueue getSkillQueue(){
return SingletonHolder.queue;
}
/**
* 生产入队
* @param kill
* @throws InterruptedException
* add(e) 队列未满时,返回true;队列满则抛出IllegalStateException(“Queue full”)异常——AbstractQueue
* put(e) 队列未满时,直接插入没有返回值;队列满时会阻塞等待,一直等到队列未满时再插入。
* offer(e) 队列未满时,返回true;队列满时返回false。非阻塞立即返回。
* offer(e, time, unit) 设定等待的时间,如果在指定时间内还不能往队列中插入数据则返回false,插入成功返回true。
*/
public Boolean produce(SuccessKilled kill) {
return blockingQueue.offer(kill);
}
/**
* 消费出队
* poll() 获取并移除队首元素,在指定的时间内去轮询队列看有没有首元素有则返回,否者超时后返回null
* take() 与带超时时间的poll类似不同在于take时候如果当前队列空了它会一直等待其他线程调用notEmpty.signal()才会被唤醒
*/
public SuccessKilled consume() throws InterruptedException {
return blockingQueue.take();
}
/**
* 获取队列大小
* @return
*/
public int size() {
return blockingQueue.size();
}
}
消費 seckill キュー: ApplicationRunner インターフェイスを実装する
// 消费秒杀队列
@Slf4j
@Component
public class TaskRunner implements ApplicationRunner{
@Autowired
private SecondKillService seckillService;
@Override
public void run(ApplicationArguments var){
new Thread(() -> {
log.info("队列启动成功");
while(true){
try {
// 进程内队列
SuccessKilled kill = SecondKillQueue.getSkillQueue().consume();
if(kill != null){
Result result = seckillService.startSecondKillByAop(kill.getSeckillId(), kill.getUserId());
if(result != null && result.equals(Result.ok(SecondKillStateEnum.SUCCESS))){
log.info("TaskRunner,result:{}",result);
log.info("TaskRunner从消息队列取出用户,用户:{}{}",kill.getUserId(),"秒杀成功");
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
@ApiOperation(value="秒杀实现方式六——消息队列")
@PostMapping("/start/queue")
public Result startQueue(long skgId){
try {
log.info("开始秒杀方式六...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
SuccessKilled kill = new SuccessKilled();
kill.setSeckillId(skgId);
kill.setUserId(userId);
Boolean flag = SecondKillQueue.getSkillQueue().produce(kill);
// 虽然进入了队列,但是不一定能秒杀成功 进队出队有时间间隙
if(flag){
log.info("用户:{}{}",kill.getUserId(),"秒杀成功");
}else{
log.info("用户:{}{}",userId,"秒杀失败");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
注: ビジネス層および AOP メソッドでは例外をスローできません。throw new RuntimeException() などの例外スロー コードはコメント アウトする必要があります。プログラムが例外をスローすると停止し、消費 seckill キュー プロセスが終了するためです。
ブロッキング キューを使用してスパイクを実装する場合は、いくつかの注意点があります。
seckillService.startSecondKillByAop()
また、消費 seckill キュー内のビジネス メソッドの呼び出しがロックされている場合とロックされていない場合、つまりseckillService.startSecondKillByLock()
メソッドの結果が同じであることも簡単に理解できます。- 行列の長さが商品の量と一致している場合、売上は少なくなり、価値は増加します
- 以下は、キューの長さが 1000、製品の数が 1000、同時実行数が 2000 の場合のアンダーセルです。
3.7. 方法 7 (ディスラプターキュー)
Disruptor は高性能キューです. 研究開発の本来の目的はメモリキューの遅延問題を解決することでした. 性能テストでは I/O 操作と同等の大きさであることがわかりました. Disruptor に基づいて開発されたシステムのスレッドは、1 秒あたり 600 万の注文をサポートできます。
// 事件生成工厂(用来初始化预分配事件对象)
public class SecondKillEventFactory implements EventFactory<SecondKillEvent> {
@Override
public SecondKillEvent newInstance() {
return new SecondKillEvent();
}
}
// 事件对象(秒杀事件)
public class SecondKillEvent implements Serializable {
private static final long serialVersionUID = 1L;
private long seckillId;
private long userId;
// set/get方法略
}
// 使用translator方式生产者
public class SecondKillEventProducer {
private final static EventTranslatorVararg<SecondKillEvent> translator = (seckillEvent, seq, objs) -> {
seckillEvent.setSeckillId((Long) objs[0]);
seckillEvent.setUserId((Long) objs[1]);
};
private final RingBuffer<SecondKillEvent> ringBuffer;
public SecondKillEventProducer(RingBuffer<SecondKillEvent> ringBuffer){
this.ringBuffer = ringBuffer;
}
public void secondKill(long seckillId, long userId){
this.ringBuffer.publishEvent(translator, seckillId, userId);
}
}
// 消费者(秒杀处理器)
@Slf4j
public class SecondKillEventConsumer implements EventHandler<SecondKillEvent> {
private SecondKillService secondKillService = (SecondKillService) SpringUtil.getBean("secondKillService");
@Override
public void onEvent(SecondKillEvent seckillEvent, long seq, boolean bool) {
Result result = secondKillService.startSecondKillByAop(seckillEvent.getSeckillId(), seckillEvent.getUserId());
if(result.equals(Result.ok(SecondKillStateEnum.SUCCESS))){
log.info("用户:{}{}",seckillEvent.getUserId(),"秒杀成功");
}
}
}
public class DisruptorUtil {
static Disruptor<SecondKillEvent> disruptor;
static{
SecondKillEventFactory factory = new SecondKillEventFactory();
int ringBufferSize = 1024;
ThreadFactory threadFactory = runnable -> new Thread(runnable);
disruptor = new Disruptor<>(factory, ringBufferSize, threadFactory);
disruptor.handleEventsWith(new SecondKillEventConsumer());
disruptor.start();
}
public static void producer(SecondKillEvent kill){
RingBuffer<SecondKillEvent> ringBuffer = disruptor.getRingBuffer();
SecondKillEventProducer producer = new SecondKillEventProducer(ringBuffer);
producer.secondKill(kill.getSeckillId(),kill.getUserId());
}
}
@ApiOperation(value="秒杀实现方式七——Disruptor队列")
@PostMapping("/start/disruptor")
public Result startDisruptor(long skgId){
try {
log.info("开始秒杀方式七...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
SecondKillEvent kill = new SecondKillEvent();
kill.setSeckillId(skgId);
kill.setUserId(userId);
DisruptorUtil.producer(kill);
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
テストの結果、Disruptor キューの使用にはカスタム キューと同じ問題があり、売られすぎの状況も発生することがわかりましたが、効率は改善されました。
4. まとめ
同時実行性を実現するための上記の 7 つの方法を要約します。
- 1 つ目と 2 つ目の方法は、コード内でロックとトランザクションを使用して同時実行性の問題を解決することです。主な解決策は、トランザクションの前にロックをロードする必要があることです。
- メソッド 3、4、および 5 は主にデータベース ロックを使用して並行性の問題を解決します。メソッド 3 はテーブルに行ロックを追加するために upate を使用します。メソッド 4 はテーブルをロックするために update を使用します。メソッド 5 はバージョン フィールドを追加することでデータベースを制御します。更新操作、方法 5 は最悪の効果をもたらします
- 方法 6 と 7 は同時実行性の問題を解決するためにキューを使用します。ここで特別な注意が必要なのは、コード内の throw によって例外をスローできないことです。そうしないと、消費スレッドが終了し、キューに入ってから出るまでの時間ギャップにより、キューの数が少なくなります。製品が販売されます
上記のすべての状況はコードによってテストされており、テストは 3 つの状況に分けられます。
- 同時実行数は 1000、製品数は 100
- 同時実行数は 1000、製品数は 1000
- 同時実行数は 2000、製品数は 1000
思考: 分散状況における同時実行性の問題を解決するにはどうすればよいでしょうか? 次回も実験を続けます。
著作権に関する声明: この記事は CSDN ブロガー「Stop Going Forward」のオリジナル記事です。CC 4.0 BY-SA 著作権契約に従って、転載する場合は元のソース リンクとこの声明を添付してください。元のリンク: https://blog.csdn.net/zxd1435513775/article/details/122643285
最近のおすすめ記事:
1. 1,000 を超える Java 面接の質問と回答 (2022 年最新バージョン)
3. Spring Boot 2.x チュートリアル、包括的すぎる!
4.画面を爆発や爆発で埋め尽くさないで、デコレーターモードを試してください。これがエレガントな方法です。!
5.最新リリースの「Java 開発マニュアル (松山編)」をすぐにダウンロードしてください!
気分がいいので、「いいね!」+「転送」を忘れないでください!