update blog

_posts/2020-1-28-redis_distributed_locks.md

@@ -11,7 +11,7 @@ author: lemonchann
 
 <!-- more -->
 
-抛砖引玉，今天就来说说其中一个技术细节，也是在我的上一篇文章[Linux后台开发C++学习路线技能加点](https://zhuanlan.zhihu.com/p/102048769)中提到但没展开讲的**redis分布式锁**。
+抛砖引玉，今天就来说说其中一个技术细节，也是在我的上一篇文章[Linux后台开发C++学习路线技能加点](https://zhuanlan.zhihu.com/p/102048769)中提到但没展开讲的高并发编程中的**redis分布式锁**。
 
 这里罗列出**3种redis实现的分布式锁**，并分别对比说明各自特点。
 

_posts/2020-1-29-red_packet_thinking_lock.md

@@ -46,7 +46,7 @@ author: lemonchann
 
 悲观锁把抢红包这三个步骤打包成一个整体做成互斥操作，**“在我抢了没更新数据之前你别来查余额，查到也不准确”**。也可以类比数据库的**事务**来理解。
 
-> **事务必须具备以下四个属性，简称ACID 属性：**
+> **事务必须具备以下四个属性，简称ACID 属性：**  
 > `原子性（Atomicity）`：事务是一个完整的操作。事务的各步操作是不可分的（原子的）；要么都执 行，要么都不执行   
 > `一致性（Consistency）`：当事务完成时，数据必须处于一致状态   
 > `隔离性（Isolation）`：对数据进行修改的所有并发事务是彼此隔离的，这表明事务必须是独立的，它不应以任何方式依赖于或影响其他事务   
@@ -64,7 +64,7 @@ CPU不断的切换线程上下文非常浪费服务器资源，严重的会导
 
 > 乐观锁是对悲观锁的改进，乐观的认为加锁的时候没有竞争，乐观锁不阻塞线程。
 
-一种实现乐观锁的方法是**数据库内红包余额增加版本号**，初始版本号是0，每次抢完红包版本号加一后再去更新余额，**只有更新的版本号大于数据库内的版本号才认为是合法的，予以更新；否则不予更新，线程不阻塞可以稍后重试，**避免频繁切换线程上下文。
+一种实现乐观锁的方法是**数据库内红包余额增加版本号**，初始版本号是0，每次抢完红包版本号加1后再去更新余额，**只有更新的版本号大于数据库内的版本号才认为是合法的，予以更新；否则不予更新，线程不阻塞可以稍后重试，**避免频繁切换线程上下文。
 
 乐观锁在抢红包的步骤1、2不做加锁判断，在步骤3的时候才做加锁判断版本号。