redis和mysql数据同步原理-redis保证和数据库事务一致

序

因为缓存文件的分布式系统性和性能卓越在各种各样新项目中取得了普遍的运用，因此在载入缓存文件时基本一致，全是依照下边的步骤开展使用的:

可是说到升级缓存文件，是在升级数据库查询后升级缓存文件，或是立即删掉缓存文件？或是在升级数据库查询前删掉缓存文件？在这里一点上，非常值得探讨。

一致性计划方案

在具体的工程开发设计中，必须确保数据库查询和缓存文件中的统计数据是一致的。不然，假如大家在线充值100元，在持续更新时依然表明0.01元。是否会非常尴尬？理论上，设定缓存文件的期满时间保证数据信息一致性的最后解决方法。应用这类计划方案，全部写实际操作都根据数据库查询。假如数据库查询载入取得成功，但缓存文件更新失败，只需在过期時间后载入缓存文件，新值当然会在数据库系统中载入，随后缓存文件会升级。下一个探讨的关键方位是怎样在不依赖于设定缓存文件期满時间的情形下保证数据信息一致性。这儿关键探讨三种计划方案:

①先升级数据库查询，再升级缓存文件。

②先删掉缓存文件，再升级数据库查询。

③先升级数据库查询，随后删掉缓存文件。

在升级缓存文件以前升级数据库查询。

这类计划方案广泛抵制(在我的认知能力范畴内~)，为何？为何这一方案遭受抵制？关键有两个缘故，请细心请听我说:

最先从网络信息安全层面而言，假如要求A和要求B二者与此同时实际操作，A先升级数据库查询中的一条数据信息，随后B马上升级那一条数据信息，但或许是由于网络延时等缘故，B在A以前升级缓存文件，会产生什么原因呢？缓存文件中的数据信息并不是B升级的最新数据，造成数据信息不一致。

次之，从业务场景看来，如果是写数据库查询多，读数据库查询少的业务流程，假如选用这类计划方案，数据信息缓存文件会在载入前经常升级，消耗特性。

充分考虑之上2个层面，这一计划方案是坚决根据的。下列2个计划方案是有异议的。是在升级数据库查询以前删掉缓存文件，或是在删掉缓存文件以前升级数据库查询？

在升级数据库查询以前删掉缓存文件。

与此同时，如果有A升级，B查看的要求，很有可能会产生A写前要求删掉缓存文件，B要求发觉缓存文件为空，因此B要求数据库查询。假如这时A要求的写实际操作沒有进行，B要求查看旧值或将旧值写入缓存，A要求将新值载入数据库查询，会产生数据信息不一致。

对于这样的状况，我们可以选用延迟时间和双向删掉的对策，即在升级数据库查询以前删掉缓存文件，随后载入数据库查询，在升级数据库查询以后再度删掉缓存文件，以删掉缓存文件中很有可能由读要求造成的脏数据。在第二次删掉缓存文件以前，您能够休眠状态几秒。针对实际的時间，开发者能够评定载入其新项目的数据服务逻辑性的時间耗费，随后在这个時间耗费上提升好几百ms。那样做的效果是保证写要求能够在学要求完毕时删掉读要求造成的脏数据。假如MySQL选用读写分离的构架，因为主从关系延迟时间，数据信息很有可能会不一致。写实际操作进行后，能够依据主从关系时间延迟休眠状态，随后删掉缓存文件。双向删掉的邻接矩阵如下所示:

# 伪代码def delay_delete(): redis.delete('name') # 升级数据库查询以前先删掉缓存文件 sql = 'update info set name='lili' where id=1;' # 升级数据库查询 cursor.execute(sql) time.sleep(1) # 假如mysql是主从关系构架则休眠状态主从关系延迟的时间段再多好几百ms redis.delete('name') # 再度删掉缓存文件复制代码

是不是会产生缓存文件删掉第二次不成功的状况？假如第二次删掉不成功，它依然会造成缓存文件和数据库查询中间的不一致。怎么解决？看一下下一个方案。

删掉缓存文件以前，请升级数据库查询。

这一老外明确提出了一个缓存文件升级计划方案，cacheasidepattern cache-average方式cache aside pattern。文章内容提及* *运用需要从缓存文件中读取数据，取得成功得话立即回到，失败得话从数据库查询中获得，取得成功后放进缓存文件。升级数据信息时，应当先将数据储存在数据库系统中，随后使缓存文件失效。* *全文如下所示。

假如应用软件升级信息内容，它能够遵循直写对策，对数据储存开展改动，并使缓存文件中的相对应新项目失效。

下一次必须该工程时，应用缓存文件预留对策将造成从数据储存中查找升级的信息并将其加上回缓存文件中。

这一计划方案是否会造成不一致的数据信息？比如，下列状况:

假定产生下列状况，有两个要求a和b，a与此同时查看和b与此同时升级:

(1)缓存文件刚不成功。

(2)要求A将数据库查询以得到旧值。

③要求B将新值载入数据库查询。

④要求B写取得成功后删掉缓存文件。

⑤要求A将寻找的体制写入缓存，造成脏数据…

假如说出之上状况，数据信息会不一致，但XDM会考虑到。这类状况产生的几率有多大？要想先造成这种結果，务必有一个标准，那便是Request B的实际操作時间很短，短到啥子水平，也就是Request B向数据库查询中载入数据信息的实际操作比Request A从数据库查询中获取数据的实际操作要快(由于redis十分快，因此redis的实际操作時间临时能够忽视)。仅有在这样的情形下④才可以在于⑤发音，可是数据库查询的载入实际操作要比载入实际操作快得多。不然，为何要做读写分离呢？因此这个状况产生的几率十分极低，可是假如强迫症患者发生了，务必要处理该怎么办？您能够设定缓存文件的期满時间，或是选用第二种计划方案的延迟时间双删掉对策，以保证删掉实际操作在载入要求成功后实行。

最后一个难题

还有一个难题，便是最后计划方案3中数据不一致几率非常低的预案是选用计划方案2的延迟时间双删掉对策，可是计划方案2中也讲了，缓存文件删掉不成功该怎么办？并不是也有数据信息不一致的难题吗？如何解决这个问题？这儿，给予了再试体制。假如删掉不成功，请再试。这儿，给予了再试计划方案。

①升级数据库查询。

②各种各样因素造成缓存文件删掉不成功。

③将删掉不成功的缓存文件放进线程池。

(4)业务流程编码从线程池中获得要删掉的密匙。

⑤再次试着删掉实际操作，直至取得成功。