mysql事务解读，共享锁测试结果记录，为何要用redis取代排他锁 相比rabbitmq，redis优势在哪？

未加锁时：

事务之间互不影响，都是在初始值基础上，进行数据修改，产生问题比较严重，取决于先来后到，不会抛异常；

共享锁：

1，不同时间，A先开启，B后开启，A执行10s，B执行15s，A写入之后，B不能写入

2，不同时间，A先开启，B后开启，A执行15s，B执行5s，B先写入，A不能写入

 

结论：

1，跟先后开启事务时间无关，谁先写入提交，数据就是谁的，其他的线程统统都抛错误；

 

排他锁（队列锁）：

1，A先开启，B后开启，A执行15s，B执行5s，B仍然等待15s之后，才能执行，中间不会抛出异常，除非链接中断；

 

结论：

排它锁就是队列，严格按照排队时间来处理

 

为何要用redis取代排他锁

排他锁是作用在表层面，如果一个逻辑要修改多个表，我们就要同时锁住一堆表，再此期间，其他用户都不能再访问这几个表了，如果当前排队用户比较多，那么前端接口也被阻塞了，整个系统都不能正常访问，只有等待订单处理完成之后才能访问，这是不合理的，如果使用共享锁，又会导致下单用户失败率增多，因此采用redis解决了以上所有问题

redis锁，可以在线程级别进行阻挡，保证同一时间段内，只有一个线程在执行，类似于排队，保证了不锁表的情况下，前端用户正常访问，又使得下单用户正常排队，不会造成大量用户下单请求报错，相比数据库层面处理，redis处理的更完美

相比rabbitmq，redis优势在哪？

rabbitmq适用场景和redis还是有点小区别的，rabbitmq往往用来处理一些耗时但又必需排队的任务，又或者处理一些要一次性开多线程处理任务的场景，例如说发短信；相比rabbitmq，redis更轻量级一些；

此外rabbitmq的进程和下单进程是不在同一个主进程中，因此rabbitmq在传统的php-fpm中，是无法给前端返回实时结果的，除非使用hyperf这种自带服务的框架，并且借助websocket，或者用ajax的方式来轮询结果，而这无疑加重了开发者的负担。所以一般来说轻量级秒杀大家不用rabbitmq

而为何大流量情况下又要采用rabbitmq了呢？因为rabbitmq自带限流能力，满了之后，就开始拒绝了，这样保证服务器不至于被无限的请求阻塞到崩溃