首页 > 应用开发 > Java > 用了redis一定可以保证原子性吗
什么原子性?程序在执行过程中,要么全部都执行,要么全部都不执行,不可能执行了一半,滞留了一半。我们知道redis是IO多路复用模型,即一个线程来处理多个TCP连接,这样的好处就是,即使客户端并发请求,也得排队处理,一定程度上解决了多线程模型带的并发问题,所以redis是并发安全的?从redis本身的架构模式来说,并发是安全的,不存在同时执行两个客户端的命令。但是如果因为某些业务场景用的有问题,那么即使是单线程的redis也无能为力。
假设现在redis有个叫stock的key,用于存放商品的库存数据,只要进货了库存就加一,出货了库存就减一。于是这时候机智的程序员小王这样设计了一下,每次通过get获取stock的值,然后再set stock=stock+1。这时候有两个业务员A、B分别进货了,由于时间线的问题,程序大概是这样跑的:
整个流程下来,发现库存丢了一个,这正是因为整个操作不是原子性的,导致A影响了B,或者B影响了A。
incr是原子操作的,对于这种场景,可以不用获取原来的值,直接用redis的incr实现read和write的打包原子操作,就不会出现读了一半,然后被别人篡改了。真实场景可能不仅仅是这种库存问题,那么像批量设置多个值的场景可以用
mset,批量获取多个值的
mget,与
incr相对应的
decr,这些都是原子的。
加锁可以解决,先抢占了锁的用户,可以去操作,没抢到锁的,自旋等待下次去获取锁,然后操作。如果不是分布式系统,可以用类似golang sync.mutex锁,如果是分布式系统得用分布式锁了,可以用类似zookeeper或者redis本身的setnx。
结合watch和事务也可以解决,每个客户端可以通过watch来监控自己即将要更新的key,这样在事务更新的时候,如果发现自己监控的key被修改了,那么拒绝执行,事务执行失败,这样就不会存在更新覆盖的问题。watch的本质还是乐观锁,当客户端执行watch的时候,实际上是watch的key会维护一个客户端的队列,这样就知道这个key被哪些客户端监视了。当其中的一个客户端执行完毕之后,那么它会从这个队列中移除,并且会把这个列表中剩余的所有客户端的
CLIENT_DIRTY_CAS标识打开,这样剩余的客户端在执行exec的时候,发现自己的
CLIENT_DIRTY_CAS已经被打开,那么就会拒绝执行。
客户端1:
客户端2:
客户端1和客户端2都尝试来修改store的值,然而客户端2修改失败了。
即使redis支持很多原子命令,但是还是无法满足所有场景,于是redis在2.6之后开始支持开发者编写lua脚本传到redis中,使用lua脚本的好处就是:
通过eval关键字指明导入lua,在redis收到lua指令时,会把整个lua指令作为一个整体,比如上面的set和expire之间不会有其他客户端请求的指令,一定是set和expire一起做完之后,其他的命令才能执行。
对于程序员来说,要学习的知识内容、技术有太多太多,要想不被环境淘汰就只有不断提升自己,从来都是我们去适应环境,而不是环境来适应我们!
不用多说,相信大家都有一个共识:无论什么行业,最牛逼的人肯定是站在金字塔端的人。所以,想做一个牛逼的程序员,那么就要让自己站的更高,成为技术大牛并不是一朝一夕的事情,需要时间的沉淀和技术的积累。
现在竞争这么激烈,只有通过不断学习,提高自己,才能保持竞争力。
对于一些不知道学习什么,没有一个系统路线的程序员,这里给大家提供一些学习资料
需要的小伙伴,可以一键三连, 点击这里获取免费领取方式!
内容涵盖:Java基础、JVM、高并发、多线程、分布式、设计模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat、数据库、云计算等
需要的小伙伴,可以一键三连, 点击这里获取免费领取方式!
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70000438/viewspace-2787785/ ,如需转载,请注明出处,否则将追究法律责任。