网站建设的流程该怎么确定,wordpress注册可见插件,网站工信部不备案吗,wordpress 中文 图片不显示目录 Redis自增功能解决全局唯一IDRedis实现优惠券秒杀的主要思路实现过程中出现的问题及解决方法超卖问题方案1 悲观锁方案2 乐观锁 一人一单问题分布式锁如何用Redis实现分布式锁#xff1f; Redis优化秒杀消息队列实现异步秒杀List发布订阅模式Stream Redis自增功能解决全局… 目录 Redis自增功能解决全局唯一IDRedis实现优惠券秒杀的主要思路实现过程中出现的问题及解决方法超卖问题方案1 悲观锁方案2 乐观锁 一人一单问题分布式锁如何用Redis实现分布式锁 Redis优化秒杀消息队列实现异步秒杀List发布订阅模式Stream Redis自增功能解决全局唯一ID
如果用MySQL的自增长IDID的规律性太明显会暴漏一些信息比如销量等数据量太大时一张表存不下需要多张表MySQL多张表的自增长都是独立的会出现重复ID需要一种在分布式系统下可以生成全局唯一ID的工具必须唯一且递增在某项目里不管数据库的表有多少个Redis只有一个因此Redis递增功能生成的ID一定是全局唯一的为了保证递增的同时且没有规律保证安全性可以在Redis自增数值的基础上拼接一些其它信息
Redis实现优惠券秒杀的主要思路 实现过程中出现的问题及解决方法
超卖问题
在高并发场景下多个线程同时操作共享的资源库存导致实际卖出的数量超出了库存数量
方案1 悲观锁
态度比较悲观认为线程安全问题肯定会发生在操作数据之前提前获取锁例子Synchronized、Lock优点安全性高缺点性能低实现简单
方案2 乐观锁
态度比较乐观认为线程安全问题不一定会发生因此不加锁只在数据更新时去判断在它之前有没有其它线程修改数据。如果没有修改认为是安全的直接更新数据如果已经被修改说明不安全重试或报异常版本号法给库存增加一个版本字段线程1查询并记录下库存和版本号然后将库存-1版本号1来表示线程1修改了一次数据然后在更新数据之前再判断一下版本号是否是自己当时记录的版本号1若是说明没有并发线程在期间修改过数据安全可以放心更新若不是说明正好有并发线程在期间修改过了数据不安全重试或者报异常CAS法版本号法的简化版本去掉版本号这个多余的字段直接用库存本身代替版本号根据库存本身有没有发生变化来确定是否更新优点性能高缺点实现复杂
一人一单问题
常见的业务问题要求同一个优惠券一个用户只能下一单在库存充足判断成功后再增加一个判断用用户ID和优惠券ID联合查询来判断该用户是否已经买过一优惠券在单机模式下可以加Synchronized锁来保证线程安全在集群模式下Synchronized锁无效需要用分布式锁来确保线程安全。Synchronized锁无效的原因是因为每台服务器有自己的常量池锁监视器便保存在常量池中用户尝试获取锁便是访问锁监视器因此主要问题是因为多个服务器的锁监视器是独立的所以多个服务器上的用户能在同一时刻同时获取锁进而导致线程安全问题
分布式锁
在单机情况下只有一个JVMJVM中只有一个锁监视器只有一个程序可以获取到锁。但在集群情况下有多个JVM多个JVM中有多个锁监视器程序可以获取到多个锁甚至同一个程序也可以获得多个锁就会出现线程安全问题需要在多个JVM之外做一个共享的 多进程可见的 互斥的 锁监视器——分布式锁实现分布式锁的三大方式MySQL、Redis、ZookeeperMySQL和Zookeeper比Redis安全性更好Redis性能比二者更好
如何用Redis实现分布式锁
获取互斥锁SET lock thread1 NX EX 10NX是互斥确保只有一个线程可以获取到锁EX是设置超时时间。释放锁直接手动删除。死锁问题若获取到锁后线程宕机容易出现死锁应该增加过期时间超时自动释放锁。误删问题若线程获取到锁但业务执行时间过长超过了TTL会自动释放锁此时线程尝试获取锁成功并正常执行业务但期间线程业务执行完毕正常执行释放锁操作此时就会把线程的锁误删。为了避免这种情况应该在获取锁时增加一个标识来表示谁占有了这个锁且只有它才有资格释放锁因此在释放锁之前需要增加判断步骤基于setnx实现的分布式锁存在的问题不可重入同一个线程无法多次获取同一把锁不可重试获取锁只尝试一次失败不会重试超时释放业务执行耗时较长会导致锁释放存在安全隐患Redission组件Redis基础上实现的分布式工具集合
Redis优化秒杀
优化主要思路将涉及到数据库的减库存创建订单等耗时操作用异步独立线程慢慢做Redis只需要判断用户有没有抢成功并返回结果原来的秒杀流程主要是Tomcat里面的一系列操作有四个会直接操作数据库耗时非常久。相当于一个饭店来了一位顾客派了一个服务员为这位顾客一条龙服务从点菜查询秒杀资格到做饭减库存和创建订单都是这一个服务员做效率非常低下。优化后的秒杀流程在NGINX和Tomcat之家增加Redis用于判断该用户能不能抢上优惠券并将判断结果和优惠券id、用户id、订单id一起保存到阻塞队列然后Tomcat从队列中读取消息进行比较耗时的减库存和创建订单操作 其中Redis判断秒杀库存的操作可以封装到Lua脚本中执行以确保该操作的原子性 基于阻塞队列的异步秒杀存在的问题阻塞队列用的时JDK的会占用JVM内存大量消息会造成内存溢出
消息队列实现异步秒杀
消息队列存储管理消息生产者发送消息到消息队列消费者从消息队列获取消息并处理消息Redis实现消息队列的三种方式List、发布订阅模式、Stream
List
链式的双端队列LPUSH存RPOP取但并没有阻塞效果队列空时不会阻塞等待BRPOP有阻塞效果。优点独立于JVM存在不占JVM内存不担心上限且可以持久化还能保证消息有序性缺点无法避免消息丢失只支持一对一
发布订阅模式
消费者订阅一个或多个channel生产者向对应channel发送消息优点支持一对多一个生产者可以把消息发给多个消费者。天生支持阻塞缺点不支持数据持久化无法避免消息丢失消息堆积有上限
Stream
优点消息可回溯支持一对多支持阻塞读取缺点可能会漏读消息消费者组将多个消费者划分到一个组中监听同一个消息队列那么多个消费者就会竞争这些消息可以加快处理消息的速度避免消息堆积。消费者组还会维护一个标识记录最后一个被处理的消息可以很快恢复突发情况避免漏读消息。此外消费者拿到消息后Redis并不会直接不管这条消息而是将消息置为pending状态表示这条消息取上了但还没处理完处理完后通过XACK确认消息标记为已处理此时Redis才会放心地把消息从队列中移除可以防止消息丢失。消费者组优点消息可回溯可以多消费者争抢消息加快消费速度可以阻塞读取不会漏读消息有消息确认机制保证消息至少被消费一次
三种消息队列对比总结
