高并发问题——抢红包案例分析（一）
学习了大佬的博客，跑了下demo，但是失败了。
MVC那里也不知道为啥拦截不到我的请求，大佬原文地址
https://blog.csdn.net/yangshangwei/article/details/82975845。
1.问题描述：
模拟 20 万元的红包，共分为 2 万个可抢的小红包，有 3 万人同时抢夺的场景 ，模拟出现超发和如何保证数据一致性的问题。
案例关注点：
数据一致性和系统的性能
使用 SQL 去查询红包的库存、发放红包的总个数、总金额，我们发现了错误，红包总额为 20 万元，两万个小红包，结果发放了 200020元的红包， 20002 个红包。现有库存为-2，超出了之前的限定，这就是高并发的超发现象，这是一个错误的逻辑 。
2.问题分析
针对这个案例，用户抢到红包后，红包总量应-1，当多个用户同时抢红包，此时多个线程同时读得库存为n，相应的逻辑执行后，最后将均执update T_RED_PACKET set stock = stock - 1 where id = #{id} ，很明显这是错误的。
2.1使用数据库锁的解决方案
2.1.1 悲观锁
1.线程1在查询红包数时使用排他锁 select id, user_id as userId, amount, send_date as sendDate, total, unit_amount as unitAmount, stock, version, note from T_RED_PACKET where id = #{id} for update
2.然后进行后续的操作(redPacketDao.decreaseRedPacket 和 userRedPacketDao.grapRedPacket)，更新红包数量，最后提交事务。
3.线程2在查询红包数时，如果线程1还未释放排他锁，它将等待
4.线程3同线程2，依次类推
一致性数据统计：
性能数据统计：
2.1.2 乐观锁
1. 在红包表添加version版本字段或者timestamp时间戳字段，这里我们使用version
2. 线程1查询后，执行更新变成了update T_RED_PACKET set stock = stock - 1, version = version + 1 where id = #{id} and version = #{version}
这样，保证了修改的数据是和它查询出来的数据是一致的，而其他线程并未进行修改。当然，如果更新失败，表示在更新操作之前有其他线程已经更新了该红包数，那么就可以尝试重入机制来保证更新成功。
在扣减红包的时候 ， 增加了对版本号的判断，其次每次扣减都会对版本号加一，这样保证每次更新在版本号上有记录 ， 从而避免 ABA 问题
一致性数据统计：
性能数据统计：
解决因version导致失败问题
为提高成功率，可以考虑使用重入机制 。 也就是一旦因为版本原因没有抢到红包，则重新尝试抢红包，但是过多的重入会造成大量的 SQL 执行，所以目前流行的重入会加入两种限制
1.一种是按时间戳的重入，也就是在一定时间戳内（比如说 100毫秒），不成功的会循环到成功为止，直至超过时间戳，不成功才会退出，返回失败。
2.一种是按次数，比如限定 3 次，程序尝试超过 3 次抢红包后，就判定请求失效，这样有助于提高用户抢红包的成功率。
乐观锁重入机制-按时间戳重入
/**
*
*
* 乐观锁，按时间戳重入
*
* @Description: 乐观锁，按时间戳重入
*
* @param redPacketId
* @param userId
* @return
*
* @return: int
*/
@Override
@Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED)
public int grapRedPacketForVersion(Long redPacketId, Long userId) {
// 记录开始时间
long start = System.currentTimeMillis();
// 无限循环，等待成功或者时间满100毫秒退出
while (true) {
// 获取循环当前时间
long end = System.currentTimeMillis();
// 当前时间已经超过100毫秒，返回失败
if (end - start > 100) {
return FAILED;
}
// 获取红包信息,注意version值
RedPacket redPacket = redPacketDao.getRedPacket(redPacketId);
// 当前小红包库存大于0
if (redPacket.getStock() > 0) {
// 再次传入线程保存的version旧值给SQL判断，是否有其他线程修改过数据
int update = redPacketDao.decreaseRedPacketForVersion(redPacketId, redPacket.getVersion());
// 如果没有数据更新，则说明其他线程已经修改过数据，则重新抢夺
if (update == 0) {
continue;
}
// 生成抢红包信息
UserRedPacket userRedPacket = new UserRedPacket();
userRedPacket.setRedPacketId(redPacketId);
userRedPacket.setUserId(userId);
userRedPacket.setAmount(redPacket.getUnitAmount());
userRedPacket.setNote("抢红包 " + redPacketId);
// 插入抢红包信息
int result = userRedPacketDao.grapRedPacket(userRedPacket);
return result;
} else {
// 一旦没有库存，则马上返回
return FAILED;
}
}
}
当因为版本号原因更新失败后，会重新尝试抢夺红包，但是会实现判断时间戳，如果时间戳在 100 毫秒内，就继续，否则就不再重新尝试，而判定失败，这样可以避免过多的SQL 执行 ， 维持系统稳定。
一致性测试：
性能测试：
乐观锁重入机制-按次数重入
/**
*
*
* @Title: grapRedPacketForVersion
*
* @Description: 乐观锁，按次数重入
*
* @param redPacketId
* @param userId
*
* @return: int
*/
@Override
@Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED)
public int grapRedPacketForVersion(Long redPacketId, Long userId) {
for (int i = 0; i < 3; i++) {
// 获取红包信息，注意version值
RedPacket redPacket = redPacketDao.getRedPacket(redPacketId);
// 当前小红包库存大于0
if (redPacket.getStock() > 0) {
// 再次传入线程保存的version旧值给SQL判断，是否有其他线程修改过数据
int update = redPacketDao.decreaseRedPacketForVersion(redPacketId, redPacket.getVersion());
// 如果没有数据更新，则说明其他线程已经修改过数据，则重新抢夺
if (update == 0) {
continue;
}
// 生成抢红包信息
UserRedPacket userRedPacket = new UserRedPacket();
userRedPacket.setRedPacketId(redPacketId);
userRedPacket.setUserId(userId);
userRedPacket.setAmount(redPacket.getUnitAmount());
userRedPacket.setNote("抢红包 " + redPacketId);
// 插入抢红包信息
int result = userRedPacketDao.grapRedPacket(userRedPacket);
return result;
} else {
// 一旦没有库存，则马上返回
return FAILED;
}
}
return FAILED;
}
通过 for 循环限定重试 3 次， 3 次过后无论成败都会判定为失败而退出 ， 这样就能避免过多的重试导致过多 SQL 被执行的问题，从而保证数据库的性能.
数据一致性和性能截图
