一种异步的方式达到缓存和DB数据一致的方案制造技术

本发明专利技术公开了一种异步的方式达到缓存和DB数据一致的方案，将商品信息缓存在redis这类的缓存中间件中，用来减少请求访问到数据库的次数，减轻数据库的压力，防止在过多的流量将数据库连接打满的情况出现；当商品信息发生修改时，特别是在修改发生极其频繁的背景下，并且该商品被频繁访问；这时在某些极端情况下，会出现缓存中存在脏数据的情况。本发明专利技术是采用异步的方式来达到缓存和DB一致性方法，通过基于消息机制的异步操作的方式替换了缓存和DB数据同步时的同步操作，主要考虑应对高流量、高QPS的场景，保障用户的使用体验、以及保障信息的时效性，使用户尽可能看到最新的消息。息。息。

【技术实现步骤摘要】
一种异步的方式达到缓存和DB数据一致的方案


[0001]本专利技术涉及数据同步领域，特别涉及一种异步的方式达到缓存和DB数据一致的方案。

技术介绍

[0002]业务背景是用户下单成功后，很难及时的看到订单的最新状态，为了提升用户的使用体验，于是与前端同事进行沟通与协商，通过一些交互上的设计与缓存和DB数据一致的方法设计，来提升用户的使用体验。
[0003]图3是本方案与其他几种传统方案的优缺点对比；除了第一次实现时需要较高的复杂度外，其他方面带来的优势是较为明显的，目前本方案应用相关的数据如下：
[0004]QPS：支持近万的QPS；
[0005]缓存数据更新延时：秒级。
[0006]传统的商品系统中，当我们修改商品时，由于商品是存储在缓存里面，可是在多线程以及高QPS的场景下，会出现缓存中仍然是脏数据的情况；
[0007]在修改商品数据时，由于多次的频繁修改，由于网络或其他原因，在多线程的情况下，而最终导致缓存数据库中与我们最后一次修改的数据不符。

技术实现思路

[0008]本专利技术要解决的技术问题是克服现有技术的缺陷，提供一种异步的方式达到缓存和DB数据一致的方案。
[0009]本专利技术提供了如下的技术方案：
[0010]本专利技术提供一种异步的方式达到缓存和DB数据一致的方案，包括以下步骤：
[0011]S1、将商品信息缓存在redis这类的缓存中间件中，用来减少请求访问到数据库的次数，减轻数据库的压力，防止在过多的流量将数据库连接打满的情况出现；
[0012]S2、当商品信息发生修改时，特别是在修改发生极其频繁的背景下，并且该商品被频繁访问；这时在某些极端情况下，会出现缓存中存在脏数据的情况；
[0013]S3、原先采用同步修改缓存的方式，可是这种方式仍会导致缓存中出现脏数据；于是采用异步的方式，来修改缓存；
[0014]S4、异步的方式无法保证消息一定不会丢失，于是采用业务DB存储消息和定时重新发送消息的方式，来保证消息的不丢失；
[0015]S5、由于数据可能会被多次修改，于是需要保证消息的有序性；将消息放入消息中间价的内存队列中，保证一条消息只会对应一个内存队列；采用此种方式可以保证消息的有序性，同时提升了消息中间件的性能；及时某条消息出现消费阻塞的情况，也不会导致影响其他的内存队列。
[0016]与现有技术相比，本专利技术的有益效果如下：
[0017]1.本专利技术是采用异步的方式来达到缓存和DB一致性方法，通过基于消息机制的异
步操作的方式替换了缓存和DB数据同步时的同步操作，主要考虑应对高流量、高QPS的场景，保障用户的使用体验、以及保障信息的时效性，使用户尽可能看到最新的消息；
[0018]2.既保证了缓存数据与DB数据的一致性，同时也支持了高QPS和高流量的场景；采用异步更新缓存的方式，减少了同步操作缓存所消耗的时间以及同步操作带来的缓存中脏数据的情况；
[0019]3.引入了消息中间件，采用生产者与消费者的模型以及业务DB的方式，实现了消息不丢失和高效率消费消息
[0020]4.使用多个内存队列以及将同一消息放入同一队列，保证了消息的有序性以及高性能。
附图说明
[0021]附图用来提供对本专利技术的进一步理解，并且构成说明书的一部分，与本专利技术的实施例一起用于解释本专利技术，并不构成对本专利技术的限制。在附图中：
[0022]图1是本专利技术的应用架构图；
[0023]图2是本专利技术的流程图；
[0024]图3是本专利技术方案与其他几种传统方案的优缺点对比示意图；
[0025]图4是本专利技术的实施例示意图之一；
[0026]图5是本专利技术的实施例示意图之二。
具体实施方式
[0027]以下结合附图对本专利技术的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本专利技术，并不用于限定本专利技术。其中附图中相同的标号全部指的是相同的部件。
[0028]实施例1
[0029]如图1
‑
5，本专利技术提供一种异步的方式达到缓存和DB数据一致的方案，包括以下步骤：
[0030]S1、将商品信息缓存在redis这类的缓存中间件中，用来减少请求访问到数据库的次数，减轻数据库的压力，防止在过多的流量将数据库连接打满的情况出现；
[0031]S2、当商品信息发生修改时，特别是在修改发生极其频繁的背景下，并且该商品被频繁访问；这时在某些极端情况下，会出现缓存中存在脏数据的情况；
[0032]S3、原先采用同步修改缓存的方式，可是这种方式仍会导致缓存中出现脏数据；于是采用异步的方式，来修改缓存；
[0033]S4、异步的方式无法保证消息一定不会丢失，于是采用业务DB存储消息和定时重新发送消息的方式，来保证消息的不丢失；
[0034]S5、由于数据可能会被多次修改，于是需要保证消息的有序性；将消息放入消息中间价的内存队列中，保证一条消息只会对应一个内存队列；采用此种方式可以保证消息的有序性，同时提升了消息中间件的性能；及时某条消息出现消费阻塞的情况，也不会导致影响其他的内存队列。
[0035]具体示例说明如下：
[0036]图1中缓存更新平台由本方案实现，其他部分则是业务实现。
[0037]在我们的业务场景中是要求DB与缓存的数据能够快速达到最终一致，如果采取同步操作，在极端的情况下，可能会出现下面的执行时序，如图4所示，可以发现，如果已这样的时序来进行操作，那么缓存中的key将是已经过期的v1，而不是数据库最新的v2，这种问题极其难以发现，同时会严重影响用户体验。
[0038]如果这里采用Redis的SETNX命令的话，仍然会出现SETNX命令执行不成功的情况，从而导致应该更新的缓存而没有更新。
[0039]上面出现的问题时由于大量操作针对同一个key而导致的，所以这里通过引入消息机制来异步执行缓存操作，这样可以使同一个key的并行操作变为串行操作。
[0040]异步操作带来的问题：
[0041]由于缓存操作由同步操作变为异步操作，这里又会出现两个新的问题：
[0042]1、消息投递失败了怎么办？
[0043]2、业务希望数据更新成功之后缓存必然更新成功，这该怎么做？
[0044]为了解决上面的问题，通过将针对DB操作的消息记录存放在DB中来解决此问题，相当于是一个容灾方案，只要消息进入这张表，那么消息就一定会被消费。
[0045]缓存更新平台：
[0046]缓存更新平台主要是执行实际的缓存增、删、改命令。我们为了规避并行操作同一个key导致缓存中存储旧值而非新值的问题，引入消息机制将缓存操作串行化，缓存更新平台采用串行的方式从消息队列中消费缓存操作消息。
[0047]这里我们的核心需求是：单线程处理同一个key的缓存操作消息且不让旧的缓存覆盖新的缓存。于是产生了下面的问题：
...

【技术保护点】

【技术特征摘要】
1.一种异步的方式达到缓存和DB数据一致的方案，其特征在于，包括以下步骤：S1、将商品信息缓存在redis这类的缓存中间件中，用来减少请求访问到数据库的次数，减轻数据库的压力，防止在过多的流量将数据库连接打满的情况出现；S2、当商品信息发生修改时，特别是在修改发生极其频繁的背景下，并且该商品被频繁访问；这时在某些极端情况下，会出现缓存中存在脏数据的情况；S3、原先采用同步修改缓存的方式，可是这种方式仍会导致缓存中出...

【专利技术属性】
技术研发人员：郑奕凯，曹向丽，
申请(专利权)人：天翼电子商务有限公司，
类型：发明
国别省市：