Java生鲜电商平台-Redis缓存如何应对亿级流量峰值(小程序/APP)

Java生鲜电商平台-Redis缓存如何应对亿级流量峰值(小程序/APP)

说明：Java生鲜电商平台-缓存如何应对亿级流量峰值许多大型互联网系统，如：电商、社交、新闻等App  或网站，动辄日活千万甚至上亿，每分钟的峰值流量也在数十万以上，架构上

如何应对如此高的流量峰值？

　　   本节给大家介绍，通过使用“缓存”技术来给系统减压。流量峰值对系统带来的主要危害   在于，它会瞬间造成大量对磁盘数据的读取和搜索，通常的数据源是数据库或文件系统，

当数   据访问量次数增大的时候，过多的磁盘读取可能会最终成为整个系统的性能瓶颈，甚至是压垮   整个数据库，导致系统卡死、服务不可用等严重后果。

          常规的应用系统中，我们通常会在需要的时候对数据库进行查找，因此系统的大致结构如  下所示：

 图 1.0 常规应用系统

                当数据量较高的时候，需要减少对于数据库里面的磁盘读写操作，因此通常都会选择在业  务系统和数据库之间加入一层缓存从而减少对数据库方面的访问压力，如图下图所示。

图1.1 增加了缓存层的应用系统

当数据量较高的时候，需要减少对于数据库里面的磁盘读写操作，因此通常都会选择在业  务系统和MySQL 数据库之间加入一个缓存层，从而减少对数据库方面的访问压力。

缓存在实际场景的应用当中并非这么简单，下边我们来通过几个比较经典的缓存应用场景  来列举一些问题：

1）缓存和数据库之间数据一致性问题常用于缓存处理的机制有以下几种：

Cache Aside 模式。这种模式处理缓存通常都是先从数据库缓存查询，如果缓存没有命中则从数据库中进行查找。

这里面会发生的三种情况如下：

缓存命中：当查询的时候发现缓存存在，那么直接从缓存中提取。

缓存失效：当缓存没有数据的时候，则从 database 里面读取源数据，再同步到 cache 里面去。

缓存更新：当有新的写操作去修改database 里面的数据时，需要在写操作完成之后，让

cache 里面对应的数据失效，作缓存同步。

这种Cache aside 模式，通常是我们在实际应用开发中最为常用到的模式。但是并非说这种模式的缓存处理就一定能做到完美。

这种模式下依然会存在缺陷。比如，一个是读操作，但是没有命中缓存，然后就到数据库   中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后之前的那个读操作再把老   的数据放进去，所以会造成脏数据。

分布式环境中要想完全的保证数据一致性，是一件极为困难的事情，我们只能够尽可能的  降低这种数据不一致性问题产生的情况。

Read Through 模式。是指应用程序始终从缓存中请求数据。如果缓存没有数据，则它负责使用底层提供程序插件从数据库中检索数据。检索数据后，缓存会自行更新并将数据返回给调   用应用程序。

使用Read Through 有一个好处，我们总是使用key 从缓存中检索数据, 调用的应用程序不知道数据库，由存储方来负责自己的缓存处理，这使代码更具可读性，代码更清晰。

但是这也有相应的缺陷，开发人员需要编写相关的程序插件，增加了开发的难度性。

Write Through 模式。和Read Through 模式类似，当数据发生更新的时候，先去Cache 里面进行更新，如果命中了，则先更新缓存再由Cache 方来更新database。如果没有命中的话， 就直接更新Cache 里面的数据。

Write Behind Caching 模式。这种模式通常是先将数据写入到缓存里面，然后再异步的写入到database 中进行数据同步。

这样的设计既可以直接的减少我们对于数据的database 里面的直接访问，降低压力，同时对于database 的多次修改可以进行合并操作，极大的提升了系统的承载能力。