首页 > 代码库 > Java面试6-10

Java面试6-10

6、数据库与缓存不一致问题

 

本文主要讨论这么几个问题: 

(1)“缓存与数据库”需求缘起 

(2)“淘汰缓存”还是“更新缓存” 

(3)缓存和数据库的操作时序 

(4)缓存和数据库架构简析 

 

一、需求缘起 

场景介绍 

缓存是一种提高系统读性能的常见技术,对于读多写少的应用场景,我们经常使用缓存来进行优化。 

例如对于用户的余额信息表account(uid, money),业务上的需求是: 

(1)查询用户的余额,SELECT money FROM account WHERE uid=XXX,占99%的请求 

(2)更改用户余额,UPDATE account SET money=XXX WHERE uid=XXX,占1%的请求 

技术分享
由于大部分的请求是查询,我们在缓存中建立uid到money的键值对,能够极大降低数据库的压力。 

读操作流程 

有了数据库和缓存两个地方存放数据之后(uid->money),每当需要读取相关数据时(money),操作流程一般是这样的: 

(1)读取缓存中是否有相关数据,uid->money 

(2)如果缓存中有相关数据money,则返回【这就是所谓的数据命中“hit”】 

(3)如果缓存中没有相关数据money,则从数据库读取相关数据money【这就是所谓的数据未命中“miss”】,放入缓存中uid->money,再返回 

缓存的命中率 = 命中缓存请求个数/总缓存访问请求个数 = hit/(hit+miss) 

上面举例的余额场景,99%的读,1%的写,这个缓存的命中率是非常高的,会在95%以上。 

那么问题来了 

当数据money发生变化的时候: 

(1)是更新缓存中的数据,还是淘汰缓存中的数据呢? 

(2)是先操纵数据库中的数据再操纵缓存中的数据,还是先操纵缓存中的数据再操纵数据库中的数据呢? 

(3)缓存与数据库的操作,在架构上是否有优化的空间呢? 

这是本文关注的三个核心问题。

 

二、更新缓存 VS 淘汰缓存 

什么是更新缓存:数据不但写入数据库,还会写入缓存 

什么是淘汰缓存:数据只会写入数据库,不会写入缓存,只会把数据淘汰掉 

更新缓存的优点:缓存不会增加一次miss,命中率高 

淘汰缓存的优点:简单(我去,更新缓存我也觉得很简单呀,楼主你太敷衍了吧)

 

那到底是选择更新缓存还是淘汰缓存呢,主要取决于“更新缓存的复杂度”。

 

例如,上述场景,只是简单的把余额money设置成一个值,那么: 

(1)淘汰缓存的操作为deleteCache(uid) 

(2)更新缓存的操作为setCache(uid, money) 

更新缓存的代价很小,此时我们应该更倾向于更新缓存,以保证更高的缓存命中率

 

如果余额是通过很复杂的数据计算得出来的,例如业务上除了账户表account,还有商品表product,折扣表discount 

account(uid, money) 

product(pid, type, price, pinfo) 

discount(type, zhekou) 

业务场景是用户买了一个商品product,这个商品的价格是price,这个商品从属于type类商品,type类商品在做促销活动要打折扣zhekou,购买了商品过后,这个余额的计算就复杂了,需要: 

(1)先把商品的品类,价格取出来:SELECT type, price FROM product WHERE pid=XXX 

(2)再把这个品类的折扣取出来:SELECT zhekou FROM discount WHERE type=XXX 

(3)再把原有余额从缓存中查询出来money = getCache(uid) 

(4)再把新的余额写入到缓存中去setCache(uid, money-price*zhekou) 

更新缓存的代价很大,此时我们应该更倾向于淘汰缓存。 

however,淘汰缓存操作简单,并且带来的副作用只是增加了一次cache miss,建议作为通用的处理方式。 

 

三、先操作数据库 vs 先操作缓存 

OK,当写操作发生时,假设淘汰缓存作为对缓存通用的处理方式,又面临两种抉择: 

(1)先写数据库,再淘汰缓存 

(2)先淘汰缓存,再写数据库 

究竟采用哪种时序呢?  

还记得在《冗余表如何保证数据一致性》文章(点击查看)里“究竟先写正表还是先写反表”的结论么? 

对于一个不能保证事务性的操作,一定涉及“哪个任务先做,哪个任务后做”的问题,解决这个问题的方向是: 

如果出现不一致,谁先做对业务的影响较小,就谁先执行。 

由于写数据库与淘汰缓存不能保证原子性,谁先谁后同样要遵循上述原则。 

技术分享
假设先写数据库,再淘汰缓存:第一步写数据库操作成功,第二步淘汰缓存失败,则会出现DB中是新数据,Cache中是旧数据,数据不一致。 

技术分享
假设先淘汰缓存,再写数据库:第一步淘汰缓存成功,第二步写数据库失败,则只会引发一次Cache miss。 

结论:数据和缓存的操作时序,结论是清楚的:先淘汰缓存,再写数据库。 

 

四、缓存架构优化

 

技术分享

 

上述缓存架构有一个缺点:业务方需要同时关注缓存与DB,有没有进一步的优化空间呢?有两种常见的方案,一种主流方案,一种非主流方案(一家之言,勿拍)。  

技术分享
主流优化方案是服务化:加入一个服务层,向上游提供帅气的数据访问接口,向上游屏蔽底层数据存储的细节,这样业务线不需要关注数据是来自于cache还是DB。 

技术分享
非主流方案是异步缓存更新:业务线所有的写操作都走数据库,所有的读操作都总缓存,由一个异步的工具来做数据库与缓存之间数据的同步,具体细节是: 

(1)要有一个init cache的过程,将需要缓存的数据全量写入cache 

(2)如果DB有写操作,异步更新程序读取binlog,更新cache 

在(1)和(2)的合作下,cache中有全部的数据,这样: 

(a)业务线读cache,一定能够hit(很短的时间内,可能有脏数据),无需关注数据库 

(b)业务线写DB,cache中能得到异步更新,无需关注缓存 

这样将大大简化业务线的调用逻辑,存在的缺点是,如果缓存的数据业务逻辑比较复杂,async-update异步更新的逻辑可能也会比较复杂。

 

五、其他未尽事宜 

本文只讨论了缓存架构设计中需要注意的几个细节点,如果数据库架构采用了一主多从,读写分离的架构,在特殊时序下,还很可能引发数据库与缓存的不一致,这个不一致如何优化,后续的文章再讨论吧。  

六、结论强调 

(1)淘汰缓存是一种通用的缓存处理方式 

(2)先淘汰缓存,再写数据库的时序是毋庸置疑的 

(3)服务化是向业务方屏蔽底层数据库与缓存复杂性的一种通用方式 

 

本文主要讨论这么几个问题:

(1)数据库主从延时为何会导致缓存数据不一致

(2)优化思路与方案

一、需求缘起

上一篇《缓存架构设计细节二三事》中有一个小优化点,在只有主库时,通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步,读写分离的数据库架构下,有可能出现脏数据入缓存的情况,此时串行化方案不再适用了”,这就是本文要讨论的主题。

二、为什么数据会不一致

为什么会读到脏数据,有这么几种情况:

(1)单库情况下,服务层的并发读写,缓存与数据库的操作交叉进行

技术分享

虽然只有一个DB,在上述诡异异常时序下,也可能脏数据入缓存:

1)请求A发起一个写操作,第一步淘汰了cache,然后这个请求因为各种原因在服务层卡住了(进行大量的业务逻辑计算,例如计算了1秒钟),如上图步骤1

2)请求B发起一个读操作,读cache,cache miss,如上图步骤2

3)请求B继续读DB,读出来一个脏数据,然后脏数据入cache,如上图步骤3

4)请求A卡了很久后终于写数据库了,写入了最新的数据,如上图步骤4

这种情况虽然少见,但理论上是存在的,后发起的请求B在先发起的请求A中间完成了。

(2)主从同步,读写分离的情况下,读从库读到旧数据

在数据库架构做了一主多从,读写分离时,更多的脏数据入缓存是下面这种情况:

技术分享

1)请求A发起一个写操作,第一步淘汰了cache,如上图步骤1

2)请求A写数据库了,写入了最新的数据,如上图步骤2

3)请求B发起一个读操作,读cache,cache miss,如上图步骤3

4)请求B继续读DB,读的是从库,此时主从同步还没有完成,读出来一个脏数据,然后脏数据入cache,如上图步4

5)最后数据库的主从同步完成了,如上图步骤5

这种情况请求A和请求B的时序是完全没有问题的,是主动同步的时延(假设延时1秒钟)中间有读请求读从库读到脏数据导致的不一致。

那怎么来进行优化呢?

三、不一致优化思路

有同学说“那能不能先操作数据库,再淘汰缓存”,这个是不行的,在《缓存和数据库先操作谁》的文章中介绍过。

出现不一致的根本原因:

(1)单库情况下,服务层在进行1s的逻辑计算过程中,可能读到旧数据入缓存

(2)主从库+读写分离情况下,在1s钟主从同步延时过程中,可能读到旧数据入缓存

既然旧数据就是在那1s的间隙中入缓存的,是不是可以在写请求完成后,再休眠1s,再次淘汰缓存,就能将这1s内写入的脏数据再次淘汰掉呢?

答案是可以的。

写请求的步骤由2步升级为3步:

(1)先淘汰缓存

(2)再写数据库(这两步和原来一样)

(3)休眠1秒,再次淘汰缓存

这样的话,1秒内有脏数据如缓存,也会被再次淘汰掉,但带来的问题是:

(1)所有的写请求都阻塞了1秒,大大降低了写请求的吞吐量,增长了处理时间,业务上是接受不了的

再次分析,其实第二次淘汰缓存是“为了保证缓存一致”而做的操作,而不是“业务要求”,所以其实无需等待,用一个异步的timer,或者利用消息总线异步的来做这个事情即可:

技术分享

写请求由2步升级为2.5步:

(1)先淘汰缓存

(2)再写数据库(这两步和原来一样)

(2.5)不再休眠1s,而是往消息总线esb发送一个消息,发送完成之后马上就能返回

这样的话,写请求的处理时间几乎没有增加,这个方法淘汰了缓存两次,因此被称为“缓存双淘汰”法。这个方法付出的代价是,缓存会增加1次cache miss(代价几乎可以忽略)。

而在下游,有一个异步淘汰缓存的消费者,在接收到消息之后,asy-expire在1s之后淘汰缓存。这样,即使1s内有脏数据入缓存,也有机会再次被淘汰掉。

上述方案有一个缺点,需要业务线的写操作增加一个步骤,有没有方案对业务线的代码没有任何入侵呢,是有的,这个方案在《细聊冗余表数据一致性》中也提到过,通过分析线下的binlog来异步淘汰缓存:

技术分享

业务线的代码就不需要动了,新增一个线下的读binlog的异步淘汰模块,读取到binlog中的数据,异步的淘汰缓存。

提问:为什么上文总是说1s,这个1s是怎么来的?

回答:1s只是一个举例,需要根据业务的数据量与并发量,观察主从同步的时延来设定这个值。例如主从同步的时延为200ms,这个异步淘汰cache设置为258ms就是OK的。

四、总结

在“异常时序”或者“读从库”导致脏数据入缓存时,可以用二次异步淘汰的“缓存双淘汰”法来解决缓存与数据库中数据不一致的问题,具体实施至少有三种方案:

(1)timer异步淘汰(本文没有细讲,本质就是起个线程专门异步二次淘汰缓存)

(2)总线异步淘汰

(3)读binlog异步淘汰

 

7、LinkedHashMap的应用

 

LinkedHashMap维护着一个运行于所有条目的双重链接列表。此链接列表定义了迭代顺序,该迭代顺序可以是插入顺序(insert-order)或者是访问顺序,其中默认的迭代访问顺序就是插入顺序,即可以按插入的顺序遍历元素。基于LinkedHashMap的访问顺序的特点,可构造一个LRU(Least Recently Used)最近最少使用简单缓存。也有一些开源的缓存产品如ehcache的淘汰策略(LRU)就是在LinkedHashMap上扩展的。

public class LruCache<K, V> extends LinkedHashMap<K, V> {  
            /** 最大容量 */  
            private int maxCapacity;  
         
            public LruCache(int maxCapacity) {  
                super(16, 0.75f, true);  
                this.maxCapacity = maxCapacity;  
            }  
         
            public int getMaxCapacity() {  
                return this.maxCapacity;  
            }  
         
            public void setMaxCapacity(int maxCapacity) {  
                this.maxCapacity = maxCapacity;  
            }  
         
            /** 
             * 当列表中的元素个数大于指定的最大容量时,返回true,并将最老的元素删除。 
             */  
            @Override  
            protected boolean removeEldestEntry(java.util.Map.Entry<K, V> eldest) {  
                if (super.size() > maxCapacity) {  
                    return true;  
                }  
                return false;  
            }  
        }  

  

public class LruCacheTest {  
         
            public static void main(String[] args) {  
                LruCache<String, Object> cache = new LruCache<String, Object>(10);  
         
                for (int i = 1; i <= 15; i++) {  
                    cache.put(i + "", i);  
                }  
         
                // 此时访问指定KEY的元素  
                cache.get("10");  
         
                Iterator<Entry<String, Object>> iterator = cache.entrySet().iterator();  
                for (; iterator.hasNext();) {  
                    Entry<String, Object> entry = iterator.next();  
                    System.out.println("key=" + entry.getKey() + ",value="http://www.mamicode.com/+ entry.getValue());  >

输出如下:

key=7,value=http://www.mamicode.com/7  >

  

 

8、Git产生冲突的解决方案

 

 

 

 

 

 

 

 

Java面试6-10