From eb7e82cc60c00310eb965bbc1e6e2925d8b26223 Mon Sep 17 00:00:00 2001 From: lemonchann Date: Thu, 30 Jan 2020 14:04:19 +0800 Subject: [PATCH] update blog --- _posts/2020-1-29-red_packet_thinking_lock.md | 22 ++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/_posts/2020-1-29-red_packet_thinking_lock.md b/_posts/2020-1-29-red_packet_thinking_lock.md index 0b59ded..7724231 100644 --- a/_posts/2020-1-29-red_packet_thinking_lock.md +++ b/_posts/2020-1-29-red_packet_thinking_lock.md @@ -7,13 +7,13 @@ comments: true author: lemonchann --- -今年春节响应国家号召在家宅着抵抗疫情，发了很多也抢了很多微信红包，今年拜年也改用微信红包，如今微信抢红包已经是非常平常的事情。 +今年春节响应国家号召在家宅着抵抗疫情，今年拜年也改用微信红包，春节发了很多也抢了很多微信红包，如今微信抢红包已经是非常平常的事情。 抢红包这一简单的动作，每一次都是对红包服务后台的一次请求，在春节期间海量的服务请求下，其实是一个很典型的高并发编程模型。后台开发程序员都有一个共识：**实现一个功能很容易，难的是大量请求下提高服务性能**。 在程序员眼里，大家抢的不是红包，是红包后台服务的**锁** ！这里的**锁**不是我们日常生活中的锁，后台服务编程中锁的概念： -> **实现多个进程或线程互斥的访问共享资源的一种机制** +> 实现多个进程或线程互斥的访问共享资源的一种机制 ### 今天和大家聊聊后台服务编程中的锁。 @@ -32,7 +32,7 @@ author: lemonchann - 导致最后的红包余额只记录了最后一次更新的数据。 - 很明显，这就可能出现1000个人都抢到红包，但是红包余额还没分完的情况，这就乱了。 -怎么解决这个问题呢? 就用到我们上面说的**加锁**来解决，把抢红包这三个步骤做成互斥操作，**在我抢了没更新数据之前你别来查余额，查到也不准确**。也可以类比数据库的**事务**来理解。 +怎么解决这个问题呢? 就用到我们上面说的**加锁**来解决。 @@ -44,6 +44,14 @@ author: lemonchann > 顾名思义就是悲观的做最坏打算的锁机制，占有锁期间独占资源。 +悲观锁把抢红包这三个步骤打包成一个整体做成互斥操作，**“在我抢了没更新数据之前你别来查余额，查到也不准确”**。也可以类比数据库的**事务**来理解。 + +> **事务必须具备以下四个属性，简称ACID 属性：** +> `原子性（Atomicity）`：事务是一个完整的操作。事务的各步操作是不可分的（原子的）；要么都执 行，要么都不执行 +> `一致性（Consistency）`：当事务完成时，数据必须处于一致状态 +> `隔离性（Isolation）`：对数据进行修改的所有并发事务是彼此隔离的，这表明事务必须是独立的，它不应以任何方式依赖于或影响其他事务 +> `永久性（Durability）`：事务完成后，它对数据库的修改被永久保持，事务日志能够保持事务的永久性 + 它假设你每次去抢红包必然有其他人也在跟你同时在抢，所以你这条线程在抢的时候要独占资源，其他线程需要阻塞挂起等待你抢完才能进来，挂起的线程就干不了其他事了，何其浪费！ 而一旦你抢完红包释放了锁，其他在等待中的线程又要抢占资源、抢到了又要恢复线程上下文。 @@ -52,9 +60,11 @@ CPU不断的切换线程上下文非常浪费服务器资源，严重的会导 ### 乐观锁 -> 乐观锁是对悲观锁的改进，乐观锁不阻塞线程。 +> 乐观锁是对悲观锁的改进，乐观的认为加锁的时候没有竞争，乐观锁不阻塞线程。 -一种实现乐观锁的方法是，数据库内红包余额增加版本号。初始版本号是0，每次抢完红包版本号加一后再去更新余额，只有更新的版本号大于数据库内的版本号才认为是合法的，予以更新；否则不予更新，线程不阻塞可以稍后重试，避免频繁切换线程上下文。 +一种实现乐观锁的方法是**数据库内红包余额增加版本号**，初始版本号是0，每次抢完红包版本号加一后再去更新余额，**只有更新的版本号大于数据库内的版本号才认为是合法的，予以更新；否则不予更新，线程不阻塞可以稍后重试，**避免频繁切换线程上下文。 + +乐观锁在抢红包的步骤1、2不做加锁判断，在步骤3的时候才做加锁判断版本号。 - 第一个人抢到版本号是0的红包，第二个人也抢到版本号是0的红包 - 第一个人更新红包余额并设置版本号为1 @@ -74,5 +84,5 @@ redis分布式锁： > 利用Redis的SET操作在内存中保存key-value键值对，加锁就是获取这个键值对的值，解锁就是删除这个键值对。 -关于这种分布式锁的实现，在我的另一篇文章说明，[文章链接](1) +分布式锁也不阻塞线程，关于这种分布式锁的实现不在这里展开说明，参考我公众号文章，[文章链接](1)