|
|
|
|
公众号矩阵

【高并发】ReadWriteLock怎么和缓存扯上关系了?

在实际工作中,有一种非常普遍的并发场景:那就是读多写少的场景。在这种场景下,为了优化程序的性能,我们经常使用缓存来提高应用的访问性能。

作者:冰河 来源:冰河技术|2021-01-20 05:33

作者个人研发的在高并发场景下,提供的简单、稳定、可扩展的延迟消息队列框架,具有精准的定时任务和延迟队列处理功能。自开源半年多以来,已成功为十几家中小型企业提供了精准定时调度方案,经受住了生产环境的考验。为使更多童鞋受益,现给出开源框架地址:https://github.com/sunshinelyz/mykit-delay

写在前面

在实际工作中,有一种非常普遍的并发场景:那就是读多写少的场景。在这种场景下,为了优化程序的性能,我们经常使用缓存来提高应用的访问性能。因为缓存非常适合使用在读多写少的场景中。而在并发场景中,Java SDK中提供了ReadWriteLock来满足读多写少的场景。本文我们就来说说使用ReadWriteLock如何实现一个通用的缓存中心。

本文涉及的知识点有:

文章已收录到:

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

读写锁

说起读写锁,相信小伙伴们并不陌生。总体来说,读写锁需要遵循以下原则:

  • 一个共享变量允许同时被多个读线程读取到。
  • 一个共享变量在同一时刻只能被一个写线程进行写操作。
  • 一个共享变量在被写线程执行写操作时,此时这个共享变量不能被读线程执行读操作。

这里,需要小伙伴们注意的是:读写锁和互斥锁的一个重要的区别就是:读写锁允许多个线程同时读共享变量,而互斥锁不允许。所以,在高并发场景下,读写锁的性能要高于互斥锁。但是,读写锁的写操作是互斥的,也就是说,使用读写锁时,一个共享变量在被写线程执行写操作时,此时这个共享变量不能被读线程执行读操作。

读写锁支持公平模式和非公平模式,具体是在ReentrantReadWriteLock的构造方法中传递一个boolean类型的变量来控制。

  1. public ReentrantReadWriteLock(boolean fair) { 
  2.     sync = fair ? new FairSync() : new NonfairSync(); 
  3.     readerLock = new ReadLock(this); 
  4.     writerLock = new WriteLock(this); 

另外,需要注意的一点是:在读写锁中,读锁调用newCondition()会抛出UnsupportedOperationException异常,也就是说:读锁不支持条件变量。

缓存实现

这里,我们使用ReadWriteLock快速实现一个缓存的通用工具类,总体代码如下所示。

  1. public class ReadWriteLockCache<K,V> { 
  2.     private final Map<K, V> m = new HashMap<>(); 
  3.     private final ReadWriteLock rwl = new ReentrantReadWriteLock(); 
  4.     // 读锁 
  5.     private final Lock r = rwl.readLock(); 
  6.     // 写锁 
  7.     private final Lock w = rwl.writeLock(); 
  8.     // 读缓存 
  9.     public V get(K key) { 
  10.         r.lock(); 
  11.         try { return m.get(key); } 
  12.         finally { r.unlock(); } 
  13.     } 
  14.     // 写缓存 
  15.     public V put(K key, V value) { 
  16.         w.lock(); 
  17.         try { return m.put(key, value); } 
  18.         finally { w.unlock(); } 
  19.     } 

可以看到,在ReadWriteLockCache中,我们定义了两个泛型类型,K代表缓存的Key,V代表缓存的value。在ReadWriteLockCache类的内部,我们使用Map来缓存相应的数据,小伙伴都都知道HashMap并不是线程安全的类,所以,这里使用了读写锁来保证线程的安全性,例如,我们在get()方法中使用了读锁,get()方法可以被多个线程同时执行读操作;put()方法内部使用写锁,也就是说,put()方法在同一时刻只能有一个线程对缓存进行写操作。

这里需要注意的是:无论是读锁还是写锁,锁的释放操作都需要放到finally{}代码块中。

在以往的经验中,有两种向缓存中加载数据的方式,一种是:项目启动时,将数据全量加载到缓存中,一种是在项目运行期间,按需加载所需要的缓存数据。

接下来,我们就分别来看看全量加载缓存和按需加载缓存的方式。

全量加载缓存

全量加载缓存相对来说比较简单,就是在项目启动的时候,将数据一次性加载到缓存中,这种情况适用于缓存数据量不大,数据变动不频繁的场景,例如:可以缓存一些系统中的数据字典等信息。整个缓存加载的大体流程如下所示。

将数据全量加载到缓存后,后续就可以直接从缓存中读取相应的数据了。

全量加载缓存的代码实现比较简单,这里,我就直接使用如下代码进行演示。

  1. public class ReadWriteLockCache<K,V> { 
  2.     private final Map<K, V> m = new HashMap<>(); 
  3.     private final ReadWriteLock rwl = new ReentrantReadWriteLock(); 
  4.     // 读锁 
  5.     private final Lock r = rwl.readLock(); 
  6.     // 写锁 
  7.     private final Lock w = rwl.writeLock(); 
  8.      
  9.     public ReadWriteLockCache(){ 
  10.         //查询数据库 
  11.         List<Field<K, V>> list = .....; 
  12.         if(!CollectionUtils.isEmpty(list)){ 
  13.             list.parallelStream().forEach((f) ->{ 
  14.     m.put(f.getK(), f.getV); 
  15.    }); 
  16.         } 
  17.     } 
  18.     // 读缓存 
  19.     public V get(K key) { 
  20.         r.lock(); 
  21.         try { return m.get(key); } 
  22.         finally { r.unlock(); } 
  23.     } 
  24.     // 写缓存 
  25.     public V put(K key, V value) { 
  26.         w.lock(); 
  27.         try { return m.put(key, value); } 
  28.         finally { w.unlock(); } 
  29.     } 

按需加载缓存

按需加载缓存也可以叫作懒加载,就是说:需要加载的时候才会将数据加载到缓存。具体来说:就是程序启动的时候,不会将数据加载到缓存,当运行时,需要查询某些数据,首先检测缓存中是否存在需要的数据,如果存在,则直接读取缓存中的数据,如果不存在,则到数据库中查询数据,并将数据写入缓存。后续的读取操作,因为缓存中已经存在了相应的数据,直接返回缓存的数据即可。

这种查询缓存的方式适用于大多数缓存数据的场景。

我们可以使用如下代码来表示按需查询缓存的业务。

  1. class ReadWriteLockCache<K,V> { 
  2.     private final Map<K, V> m = new HashMap<>(); 
  3.     private final ReadWriteLock rwl =  new ReentrantReadWriteLock(); 
  4.     private final Lock r = rwl.readLock(); 
  5.     private final Lock w = rwl.writeLock(); 
  6.     V get(K key) { 
  7.         V v = null
  8.         //读缓存 
  9.         r.lock();         
  10.         try { 
  11.             v = m.get(key); 
  12.         } finally{ 
  13.             r.unlock();     
  14.         } 
  15.         //缓存中存在,返回 
  16.         if(v != null) {   
  17.             return v; 
  18.         }   
  19.         //缓存中不存在,查询数据库 
  20.         w.lock();      
  21.         try { 
  22.      //再次验证缓存中是否存在数据 
  23.             v = m.get(key); 
  24.             if(v == null){  
  25.                 //查询数据库 
  26.                 v=从数据库中查询出来的数据 
  27.                 m.put(key, v); 
  28.             } 
  29.         } finally{ 
  30.             w.unlock(); 
  31.         } 
  32.         return v;  
  33.     } 

这里,在get()方法中,首先从缓存中读取数据,此时,我们对查询缓存的操作添加了读锁,查询返回后,进行解锁操作。判断缓存中返回的数据是否为空,不为空,则直接返回数据;如果为空,则获取写锁,之后再次从缓存中读取数据,如果缓存中不存在数据,则查询数据库,将结果数据写入缓存,释放写锁。最终返回结果数据。

这里,有小伙伴可能会问:为啥程序都已经添加写锁了,在写锁内部为啥还要查询一次缓存呢?

这是因为在高并发的场景下,可能会存在多个线程来竞争写锁的现象。例如:第一次执行get()方法时,缓存中的数据为空。如果此时有三个线程同时调用get()方法,同时运行到 w.lock()代码处,由于写锁的排他性。此时只有一个线程会获取到写锁,其他两个线程则阻塞在w.lock()处。获取到写锁的线程继续往下执行查询数据库,将数据写入缓存,之后释放写锁。

此时,另外两个线程竞争写锁,某个线程会获取到锁,继续往下执行,如果在w.lock()后没有v = m.get(key); 再次查询缓存的数据,则这个线程会直接查询数据库,将数据写入缓存后释放写锁。最后一个线程同样会按照这个流程执行。

这里,实际上第一个线程已经查询过数据库,并且将数据写入缓存了,其他两个线程就没必要再次查询数据库了,直接从缓存中查询出相应的数据即可。所以,在w.lock()后添加v = m.get(key); 再次查询缓存的数据,能够有效的减少高并发场景下重复查询数据库的问题,提升系统的性能。

读写锁的升降级

关于锁的升降级,小伙伴们需要注意的是:在ReadWriteLock中,锁是不支持升级的,因为读锁还未释放时,此时获取写锁,就会导致写锁永久等待,相应的线程也会被阻塞而无法唤醒。

虽然不支持锁升级,但是ReadWriteLock支持锁降级,例如,我们来看看官方的ReentrantReadWriteLock示例,如下所示。

  1. class CachedData { 
  2.     Object data; 
  3.     volatile boolean cacheValid; 
  4.     final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); 
  5.  
  6.     void processCachedData() { 
  7.         rwl.readLock().lock(); 
  8.         if (!cacheValid) { 
  9.             // Must release read lock before acquiring write lock 
  10.             rwl.readLock().unlock(); 
  11.             rwl.writeLock().lock(); 
  12.             try { 
  13.                 // Recheck state because another thread might have 
  14.                 // acquired write lock and changed state before we did. 
  15.                 if (!cacheValid) { 
  16.                     data = ... 
  17.                     cacheValid = true
  18.                 } 
  19.                 // Downgrade by acquiring read lock before releasing write lock 
  20.                 rwl.readLock().lock(); 
  21.             } finally { 
  22.                 rwl.writeLock().unlock(); // Unlock write, still hold read 
  23.             } 
  24.         } 
  25.  
  26.         try { 
  27.             use(data); 
  28.         } finally { 
  29.             rwl.readLock().unlock(); 
  30.         } 
  31.     } 
  32. }} 

数据同步问题

首先,这里说的数据同步指的是数据源和数据缓存之间的数据同步,说的再直接一点,就是数据库和缓存之间的数据同步。

这里,我们可以采取三种方案来解决数据同步的问题,如下图所示

超时机制

这个比较好理解,就是在向缓存写入数据的时候,给一个超时时间,当缓存超时后,缓存的数据会自动从缓存中移除,此时程序再次访问缓存时,由于缓存中不存在相应的数据,查询数据库得到数据后,再将数据写入缓存。

采用这种方案需要注意缓存的穿透问题,有关缓存穿透、击穿、雪崩的知识,小伙伴们可以参见《【高并发】面试官:讲讲什么是缓存穿透?击穿?雪崩?如何解决?》

定时更新缓存

这种方案是超时机制的增强版,在向缓存中写入数据的时候,同样给一个超时时间。与超时机制不同的是,在程序后台单独启动一个线程,定时查询数据库中的数据,然后将数据写入缓存中,这样能够在一定程度上避免缓存的穿透问题。

实时更新缓存

这种方案能够做到数据库中的数据与缓存的数据是实时同步的,可以使用阿里开源的Canal框架实现MySQL数据库与缓存数据的实时同步。也可以使用我个人开源的mykit-data框架哦(推荐使用)~~

本文转载自微信公众号「冰河技术」,可以通过以下二维码关注。转载本文请联系冰河技术公众号。

【编辑推荐】

  1. 高并发场景下,到底先更新缓存还是先更新数据库?
  2. SSD为何掉速、SLC缓存有啥用?
  3. 分布式缓存数据库Redis教程(Java、大数据通用教程)
  4. Redis缓存总结:淘汰机制、缓存雪崩、数据不一致....
  5. SSD为何掉速、SLC缓存有啥用?
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月获赞

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

3人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

30人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

210人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微