4

面试官让我5分钟内写一个抢红包程序,我和他说了半小时原理!

 2 years ago
source link: https://www.cnblogs.com/NanoDragon/p/12639969.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

微信搜「程序员柠檬」分享编程学习路线和学习资源,本文已收录于Github:https://github.com/imcoderlemon/CodeClass
内含原创干货文章,千本计算机电子书,谷歌、阿里大神开源LeetCode题解,各类编程资源。

今年春节响应国家号召在家宅着抵抗疫情,拜年也改用微信红包,春节发了很多也抢了很多微信红包,也算支持了公司业务,微信支付融入生活,抢红包已经是非常平常的事情。

抢红包这一简单的动作,每一次都是对红包服务后台的一次请求,在春节期间海量的服务请求下,其实是一个很典型的高并发编程模型。后台开发程序员都有一个共识:实现一个功能很容易,难的是大量请求下提高服务性能

在程序员眼里,大家抢的不是红包,是红包后台服务的 !这里的不是我们日常生活中的锁,后台服务编程中锁的概念:

实现多个进程或线程互斥的访问共享资源的一种机制

今天和大家聊聊后台服务编程中的锁。

为便于说明,我们简化模型,约定抢红包服务是多线程服务,抢红包操作包含以下3个步骤:

  1. 查询数据库内红包余额
  2. 扣除抢到的红包金额
  3. 更新红包余额到数据库

假设你发了100块钱红包,1000个人1秒内同时来抢(高并发),如果不加锁是这样的情况:

  • 第一个人查余额得到100元,他在此基础上扣除抢到的假设2元,准备步骤3更新到数据库。
  • 在第一个人更新进去之前,此时剩下的人查到的余额也是100,他们各自扣除抢到的金额,准备按步骤3更新。
  • 导致最后的红包余额只记录了最后一次更新的数据。
  • 很明显,这就可能出现1000个人都抢到红包,但是红包余额还没分完的情况,这就乱了。

怎么解决这个问题呢? 就用到我们上面说的加锁来解决。

实现锁的方式有很多,这里列举几种常见的分类

顾名思义就是悲观的做最坏打算的锁机制,占有锁期间独占资源。

悲观锁把抢红包这三个步骤打包成一个整体做成互斥操作,“在我抢了没更新数据之前你别来查余额,查到也不准确”。也可以类比数据库的事务来理解。

事务必须具备以下四个属性,简称ACID 属性:
原子性(Atomicity):事务是一个完整的操作。事务的各步操作是不可分的(原子的);要么都执 行,要么都不执行
一致性(Consistency):当事务完成时,数据必须处于一致状态
隔离性(Isolation):对数据进行修改的所有并发事务是彼此隔离的,这表明事务必须是独立的,它不应以任何方式依赖于或影响其他事务
永久性(Durability):事务完成后,它对数据库的修改被永久保持,事务日志能够保持事务的永久性

它悲观的认为你每次去抢红包必然有其他人也同时在抢,所以你这条线程在抢的时候要独占资源,其他线程需要阻塞挂起等待你抢完才能进来抢,挂起的线程就干不了其他事了。

鲁迅先生说过,浪费CPU资源就是浪费生命!

而一旦你抢完红包释放了锁,其他在等待中的线程又要抢占资源、抢到了还要恢复线程上下文。

CPU不断的切换线程上下文非常浪费服务器资源,严重的会导致不能及时处理后续抢红包请求,需要想办法提高效率,于是有了乐观锁

乐观锁是对悲观锁的改进,乐观的认为加锁的时候没有竞争,乐观锁不阻塞线程。

一种实现乐观锁的方法是数据库内红包余额增加版本号,初始版本号是0,每次抢完红包版本号加1后再去更新余额,只有更新的版本号大于数据库内的版本号才认为是合法的,予以更新;否则不予更新,线程不阻塞可以稍后重试,避免频繁切换线程上下文。

乐观锁在抢红包的步骤1、2不做加锁判断,在步骤3的时候才做加锁判断版本号。

  • 第一个人抢到版本号是0的红包,第二个人也抢到版本号是0的红包
  • 第一个人更新红包余额并设置版本号为1
  • 第二个人更新红包余额设置版本号为1的时候发现余额版本号已经为1,更新失败
  • 第二个人更新失败后,线程不阻塞,继续处理其他抢红包抢请求,按一定策略重试(超时重试、有限次数重试)第二个人的更新操作
  • 其他请求以此类推

可以看到,乐观锁在加锁失败的时候不挂起线程等待,避免了线程上下文频繁的切换,提高红包服务处理性能。

上面两种锁的形式都是基于对数据库的更新来做的,在大请求高并发的时候,频繁的存取数据库,尤其是乐观锁重试会对数据库产生很大的冲击,在实际生产环境要尽量减少对数据库的访问。

Redis 是一个开源(BSD许可)的,内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件。也可以用redis实现分布式锁,与数据库交互两次:第一次获取红包余额,第二次抢完更新红包状态。抢红包和中间过程更新操作都在内存中进行,这可比数据库操作快了几个数量级,显著改善服务并发性能。

redis分布式锁:

利用Redis的SET操作在内存中保存key-value键值对,加锁就是获取这个键值对的值,解锁就是删除这个键值对。

分布式锁也不阻塞线程,关于这种分布式锁的实现不在这里展开说明,可以参考我另一篇公众号文章: redis分布式锁的3种实现方式分析详细分析了几种分布式锁特点和利弊。


原创不易,看到这里动动手指,各位的「三连」是对我持续创作的最大支持,我们下篇文章再见。

微信搜「程序员柠檬」分享编程学习路线和学习资源,本文已收录于Github:https://github.com/imcoderlemon/CodeClass
内含原创干货文章,千本计算机电子书,谷歌、阿里大神开源LeetCode题解,各类编程资源。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK