与别人相比自己网站建设优势,销售计划方案怎么写,商丘软文推广,东莞毛织厂家东莞网站建设前言
由于缓存的高并发和高性能已经在各种项目中被广泛使用#xff0c;在读取缓存这方面基本都是一致的#xff0c;大概都是按照下图的流程进行操作#xff1a; 但是在更新缓存方面#xff0c;是更新完数据库再更新缓存还是直接删除缓存呢#xff1f;又或者是先删除缓存再…前言
由于缓存的高并发和高性能已经在各种项目中被广泛使用在读取缓存这方面基本都是一致的大概都是按照下图的流程进行操作 但是在更新缓存方面是更新完数据库再更新缓存还是直接删除缓存呢又或者是先删除缓存再更新数据库在这一点上就值得探讨了。
一致性方案
在实际项目开发中需要保证数据库和缓存中的数据一致否则人家充值了100块不断刷新却还是显示0.01元岂不是尴尬从理论上来说为缓存设置过期时间是最终保证数据一致性的解决方案采用这种方案的话所有的写操作都是以数据库为准如果数据库写入成功但是缓存更新失败只要缓存到过期时间之后后面读缓存时自然会在数据库中读取新的值然后更新缓存。接下来探讨的思路主要的方向是在不依赖为缓存设置过期时间的前提下如何保证数据一致性。这里主要探讨三种方案 ①先更新数据库再更新缓存 ②先删除缓存再更新数据库 ③先更新数据库再删除缓存 先更新数据库再更新缓存
这种方案是普遍被反对的(在我的认知范围中~)为啥呢为啥这种方案就被反对呢原因主要有两方面请听我细细道来
首先从数据安全方面考虑如果同时有请求A和请求B同时进行操作A先更新了数据库的一条数据随后B马上有更新了该条数据但是可能因为网络延迟等原因B却比A先更新了缓存就会出现一种什么情况呢缓存中的数据并不最新的B更新过的数据就导致了数据不一致的情况。
其次从业务场景方面考虑如果是一个写数据库较多而读数据库较少的业务如果采用这种方案就会导致数据还没读缓存就会被频繁更新白白浪费性能。
综合以上两方面的考虑这种方案果断pass。下面的两种方案就是争议较大的两种方案了到底是先删缓存再更新数据库还是先更新数据库再删除缓存
先删缓存再更新数据库
如果同时有一个请求A进行更新操作请求B进行查询操作就可能会出现A请求进行写操作前会删除缓存B请求刚好此时进来发现缓存是空的B请求就会查询数据库如果此时A请求的写操作还未完成B请求查询到的就还是旧的值还是会将旧的值写入缓存A请求将新的值写入数据库此时就会导致数据不一致的问题如果不采用给缓存设置过期时间的策略该数据永远都是脏数据。
解决这种情况可以采用延时双删的策略就是在更新数据库之前先删除缓存然后对数据库进行写入操作数据库更新完成之后再次进行删除缓存的操作目的是删除读请求可能造成的缓存脏数据第二次删除缓存之前可以休眠几秒具体时间开发者可以评估一下自己项目读数据业务逻辑的耗时然后在该耗时基础上加几百ms即可这么做的目的就是确保读请求结束写请求可以删除读请求造成的脏数据。如果MySQL采用的是读写分离的架构可能由于主从延时的原因造成数据不一致可以在写操作完成之后根据主从延时时间休眠一下然后再进行删除缓存的操作。延时双删的伪代码如下
# 伪代码
def delay_delete():redis.delete(name) # 更新数据库之前先删除缓存sql update info set namelili where id1; # 更新数据库cursor.execute(sql) time.sleep(1) # 如果mysql是主从架构则休眠主从延时的时间再多几百msredis.delete(name) # 再次删除缓存那会不会存在第二次删除缓存失败的情况呢如果第二次删除失败还是会造成缓存和数据库不一致的问题又如何解决呢且看下一种方案。
先更新数据库再删除缓存
老外提出了一个缓存更新方案Cache−AsidepatternCache-Aside patternCache−Asidepattern文章中提到**应用程序应该从cache中获取数据如果获取成功直接返回如果没有获取成功则从数据库中获取成功后放到缓存中更新数据时应该先把数据存到数据库中成功后再让缓存失效。**原文如下 If an application updates information, it can follow the write-through strategy by making the modification to the data store, and by invalidating the corresponding item in the cache. When the item is next required, using the cache-aside strategy will cause the updated data to be retrieved from the data store and added back into the cache. 这种方案会不会产生数据不一致的情况呢比如下述这种情况
有两个请求A和BA进行查询同时B进行更新假设发生下述情况
①此时缓存刚好失效
②请求A 就会去查询数据库得到一个旧的值
③请求B将新的值写入数据库
④请求B写入成功后删除缓存
⑤请求A将查到的机制写入缓存产生脏数据...
如果发声上述情况确实会产生数据不一致的情况但是XDM想一想发生这种情况的概率是多少呢如果先要产生这种结果就必须有一个条件就是请求B的操作时间非常短短到什么程度呢就是请求B写入数据库的操作要比请求A从数据库中读取数据的速度要快(因为redis非常快因此操作redis的时间可以暂且忽略)只有这种情况下④才可能比⑤先发声但是数据库的读操作要远比写操作快的多不然做读写分离干嘛呢所以这种情况发生的概率是非常非常非常的低但是如果强迫症患者出现必须要解决怎么办呢就可以采用给缓存设置过期时间或者采用第二种方案的延时双删策略保证读请求完成之后在进行删除操作。
最后的问题
还有问题呀就是最终解决方案三可能 出现的极低概率的数据不一致的方案是采用方案二的延时双删策略可是在方案二中也说了如果出现缓存删除失败的情况咋办那不是还会出现数据不一致的问题吗这个问题到底如何解决呢这里提供一个重试机制删除失败就重试一次呗这里提供一种重试的方案。 ①更新数据库 ②由于各种原因缓存删除失败 ③将删除失败的缓存放入消息队列中 ④业务代码从消息队列中获取需要删除的key ⑤继续尝试删除操作直到成功
