高并发业务--------抢红包模拟

(大概要讲解的东西，待更新)

悲观锁

悲观锁，假定会发生并发冲突，在你开始改变此对象之前就将该对象给锁住，直到更改之后再释放锁。

利用数据库内部机制提供的锁方法，也就是对更新的数据加锁，这样在并发期间一旦有一个事务持有了数据库记录的锁，其他线程将不能对数据进行更新。

悲观锁的实现方式: SQL + FOR UPDATE

 <!--悲观锁-->
    <select id="getRedPacketForUpdate" parameterType="int" resultType="com.demo.entity.RedPacket">
        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
    </select>

 

根据加锁的粒度，当对主键查询进行加锁时，意味着将持有对数据库记录的行更新锁（因为这里使用主键查询，所以只会对行加锁。如果使用的是非主键查询，要考虑是否对全表加锁的问题，加锁后可能引发其他查询的阻塞〉，那就意味着在高并发的场景下，当一条事务持有了这个更新锁才能往下操作，其他的线程如果要更新这条记录，都需要等待，这样就不会出现超发现象引发的数据一致性问题了。

对于悲观锁来说，当一条线程抢占了资源后，其他的线程将得不到资源，那么这个时候， CPU 就会将这些得不到资源的线程挂起，挂起的线程也会消耗CPU 的资源，尤其是在高井发的请求中。

一旦线程l 提交了事务，那么锁就会被释放，这个时候被挂起的线程就会开始竞争资源，那么竞争到的线程就会被CPU 恢复到运行状态，继续运行。

于是频繁挂起，等待持有锁线程释放资源，一旦释放资源后，就开始抢夺，恢复线程，周而复始直至所有红包资源抢完。试想在高并发的过程中，使用悲观锁就会造成大量的线程被挂起和恢复，这将十分消耗资源，这就是为什么使用悲观锁性能不佳的原因。有些时候，我们也会把悲观锁称为独占锁，毕竟只有一个线程可以独占这个资源，或者称为阻塞锁，因为它会造成其他线程的阻塞。无论如何它都会造成并发能力的下降，从而导致CPU频繁切换线程上下文，造成性能低下。为了克服这个问题，提高并发的能力，避免大量线程因为阻塞导致CPU进行大量的上下文切换，程序设计大师们提出了乐观锁机制，乐观锁已经在企业中被大量应用了。

乐观锁

乐观锁是一种不会阻塞其他线程并发的机制，它不会使用数据库的锁进行实现，它的设计里面由于不阻塞其他线程，所以并不会引发线程频繁挂起和恢复，这样便能够提高井发能力，所以也有人把它称为非阻塞锁。使用了CAS原理

实现方法：

1、乐观锁，无重入

读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提 交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

    <!--乐观锁-->
    <update id="decreaseRedPacketByVersion">
        update t_red_packet
        set
          stock = stock - 1,
          version = version + 1
        where
          id = #{id}
        and version = #{version}
    </update>

但是，仅仅这样是不行的，在高并发的情景下，由于版本不一致的问题，存在大量红包争抢失败的问题。为了提高抢红包的成功率，我们加入重入机制。

2、乐观锁，通过时间戳重入

• 按时间戳重入(比如100ms时间内) 
  示例代码:

        // 记录开始的时间
        long start = System.currentTimeMillis();

        // 无限循环，当抢包时间超过100ms或者成功时退出
        while(true) {
            // 循环当前时间
            long end = System.currentTimeMillis();
            // 如果抢红包的时间已经超过了100ms,就直接返回失败
            if(end - start > 100) {
                return FAILED;
            }
            ....

        }

3、乐观锁，通过重试次数提高抢红包成功率

• 按次数重入(比如3次机会之内) 
  示例代码：

        // 允许用户重试抢三次红包
        for(int i = 0; i < 3; i++) {
            // 获取红包信息, 注意version信息
            RedPacket redPacket = redPacketDao.getRedPacket(redPacketId);

            // 如果当前的红包大于0
            if(redPacket.getStock() > 0) {
                // 再次传入线程保存的version旧值给SQL判断，是否有其他线程修改过数据
                int update = redPacketDao.decreaseRedPacketByVersion(redPacketId, redPacket.getVersion());
                // 如果没有数据更新，说明已经有其他线程修改过数据，则继续抢红包
                if(update == 0) {
                    continue;
                }
            ....
            }
            ...
        }

使用Redis

 

总结

悲观锁使用了数据库的锁机制，可以消除数据不一致性，对于开发者而言会十分简单，但是，使用悲观锁后，数据库的性能有所下降，因为大量的线程都会被阻塞，而且需要有大量的恢复过程，需要进一步改变算法以提高系统的井发能力。

使用乐观锁有助于提高并发性能，但是由于版本号冲突，乐观锁导致多次请求服务失败的概率大大提高，而我们通过重入（按时间戳或者按次数限定）来提高成功的概率，这样对于乐观锁而言实现的方式就相对复杂了，其性能也会随着版本号冲突的概率提升而提升，并不稳定。使用乐观锁的弊端在于， 导致大量的SQL被执行，对于数据库的性能要求较高，容易引起数据库性能的瓶颈，而且对于开发还要考虑重入机制，从而导致开发难度加大。

使用Redis去实现高并发，消除了数据不一致性，并且在整个过程中尽量少的涉及数据库。但是这样使用的风险在于Redis的不稳定性，因为其事务和存储都存在不稳定的因素，所以更多的时候，建议使用独立Redis服务器做高并发业务，一方面可以提高Redis的性能，另一方面即使在高并发的场合，Redis服务器岩机也不会影响现有的其他业务，同时也可以使用备机等设备提高系统的高可用，保证网站的安全稳定。