unber的博客

但是这样使用的风险在于 Redis 的不稳定性，因为其事务和存储都存在不稳定的因素，所以更多的时候，笔者都建议使用独立 Redis 服务器做高并发业务，一方面可以提高 Redis 的性能，另一方面即使在高并发的场合，Redis 服务器宕机也不会影响现有的其他业务，同时也可以使用备机等设备提高系统的高可用，保证网站的安全稳定。互联网的高并发应用，先谈及了一些常用的系统设计理念，用以搭建高可用的互联网应用系统，着重介绍了抢红包的高并发应用，还讨论了数据不一致的超发问题。并且还论述了乐观锁、悲观锁和。

数据库最终会将数据保存到磁盘中，而使用的是内存，内存的速度比磁盘速度快得多，所以这里将讨论使用 Redis 实现抢红包。对于使用 Redis 实现抢红包，首先需要知道的是 Redis 的功能不如数据库强大，事务也不完整，因此要保证数据的正确性，数据的正确性可以通过严格的验证得以保证。而 Redis 的 Lua 语言是原子性的，且功能更为强大，所以优先选择使用 Lua 语言来实现抢红包。

在 CAS 原理中，对于多个线程共同的资源，先保存一个旧值（Old Value），比如进入线程后，查询当前存量为 100 个红包，那么先把旧值保存为 100，然后经过一定的逻辑处理。当需要扣减红包的时候，先比较数据库当前的值和旧值是否一致，如果一致则进行扣减红包的操作，否则就认为它已经被其他线程修改过了，不再进行操作，CAS 原理流程如图 1 所示。图 1 CAS原理CAS 原理并不排斥并发，也不独占资源，只是在线程开始阶段就读入线程共享数据，保存为旧值。

如果使用的是非主键查询，要考虑是否对全表加锁的问题，加锁后可能引发其他查询的阻塞），那就意味着在高并发的场景下，当一条事务持有了这个更新锁才能往下操作，其他的线程如果要更新这条记录，都需要等待，这样就不会出现超发现象引发的数据一致性问题了。线程 n，开始抢夺资源的步骤了，这里假设线程 3 抢到资源，如图 4 所示。对于悲观锁来说，当一条线程抢占了资源后，其他的线程将得不到资源，那么这个时候，CPU 就会将这些得不到资源的线程挂起，挂起的线程也会消耗 CPU 的资源，尤其是在高并发的请求中，如图 3 所示。

在《》教程中介绍了抢红包的场景，现在模拟 20 万元的红包，共分为 2 万个可抢的小红包，有 3 万人同时抢夺的场景，模拟讲解出现超发和如何保证数据一致性的问题。在高并发的场景下，除了数据的一致性外，还要关注性能的问题，因为一般而言，超过 5 秒用户体验就不太好了，所以要测试数据一致性和系统的性能。

任何系统都不是独立于业务进行开发的，真正的系统是为了实现业务而开发的，所以开发高并发网站抢购时，都应该先分析业务需求和实际的场景，在完善这些需求之后才能进入系统开发阶段。没有对业务进行分析就贸然开发系统是开发者的大忌。对于业务分析，首先是有效请求和无效请求，有效请求是指真实的需求，而无效请求则是虚假的抢购请求。

通过这些简单的判断就能够快速发现无效请求，并把它们排除在 Web 服务器之外，从而降低 Web 服务器的压力，提高互联网系统的响应速度，不过在进一步分析之前，我们还要鉴别无效请求，教程后面会讨论有效请求和无效请求。2）提供路由算法，它可以提供一些负载均衡的算法，根据各个服务器的负载能力进行合理分发，每一个 Web 服务器得到比较均衡的请求，从而降低单个服务器的压力，提高系统的响应能力。对于防火墙，无非是防止互联网上的病毒和其他攻击，正常的请求通过防火墙后，最先到达的就是负载均衡器，这是关注的核心。