什么为分布式缓存?

发布网友 发布时间：2022-04-14 06:20

我来回答

共3个回答

懂视网 时间：2022-04-14 10:41

背景说明 分布式缓存中为了可用性及高性能的考虑，可以使用如下一种master/slave设计模式。 图中的proxy是逻辑的概念，可以是基于client的包装实现，也可以是独立的proxy服务，但本文大部分是指独立的服务。几个主要的问题说明如下。 为什么cache要使用两个

背景说明

分布式缓存中为了可用性及高性能的考虑，可以使用如下一种master/slave设计模式。

图中的proxy是逻辑的概念，可以是基于client的包装实现，也可以是独立的proxy服务，但本文大部分是指独立的服务。几个主要的问题说明如下。

为什么cache要使用两个集群((master/slave)来存放？

主要出于可用性及高性能的考虑。传统的架构使用基于一致性哈希的分布式缓存，数据只存在一份副本，在出现cache节点单点故障时，虽然可以由一致性哈希算法将请求均匀落到其他节点，但由于穿透的请求较多，仍然给数据库带来较大的访问压力。为了避免对数据穿透带来的冲击，数据使用两份副本可以避免穿透的问题。同时在数据访问较大时候，也可以更好的分担流量，避免峰值单份数据跑满对系统带来的冲击。

为什么两份副本要使用master/slave结构？

由于大型系统中通常存在多个client同时操作同一份数据，需要确保所有client对数据修改时数据的一致性。为了避免两cluster两份副本数据不一致带来的困扰，使用了一个简单的做法，在配置中人为指定一个cluster为master，所有的数据以master为准。

为什么一些场景需要使用CAS？

CAS在计算机并发领域通常指Compare-and-swap，在memcached中，也称为Check And Set.?在分布式系统中，一份数据可能同时被多个调用修改，比如微博中的@箱，一个用户同时收到多个@的情况还是比较常见，比如当原来@箱里面记录是{1，2，3}时，4和5由不同的调用来源同时到达，如果没有同步的保护，系统的数据有可能最终被写成{1,2,3,4}或{1,2,3,5}，由于memcached没有原生的list结构，list都是一个自定义的value, 则很容易出现client A覆盖了同时在写的client B的数据。因此假如两个调用方同时读到{1,2,3}时，第一个写入{1,2,3,4}会成功，后续的{1,2,3,5}CAS写入就会失败，因为此时服务器已经不是{1,2,3}了，失败的调用向服务端取回{1,2,3,4}，最终写入{1,2,3,4,5}

在master/slave场景，比起普通的memcache CAS有什么区别？

目前的做法是master cas成功之后，直接修改slave，并不同时在slave执行cas操作。由于数据存在两份副本，当数据不一致时，无法自动处理数据的不一致冲突。因此在实践上只以master操作为准。

为什么使用proxy？

使用proxy主要是出于可用性、命中率以及可运维方面的考虑
可用性与可运维：当进行服务器增容或缩容时，如果client的数量较大，如果未使用proxy模式，client所在服务器通常需要修改配置并且逐个重启。重启（系统维护）一方面带来可用性方面的问题，运维方面也较为繁琐。
命中率：如果业务场景需要较高的命中率（比如>90%），则增容或缩容就变得较为复杂，需要client配合做一些策略，比如扩容后仍然访问扩容前旧的节点的数据以保证命中率。如果用proxy模式则极大降低client的访问复杂性，将相关逻辑都封装在proxy之后。

分布式缓存的一起问题

最近某业务有一起master单点故障，导致在问题的时间段内，用户看不到最近发生变更的数据。由于在上述场景中，实现cas时候的流程如下
1) master.cas(k,v)
2) 如果1成功，slave.set(k,v)
3) 如果1失败，不执行slave.set()，直接return;

由于第三步在失败时，并不会set slave，导致数据出现一致性问题，即使slave依然可用，新的数据不会写入cache。

首先看在master failure时，为什么不切换到slave cas?
先说自动切换的问题
上文也提过，两份数据副本在出现数据不一致后，并不能自动仲裁达到最终一致性，但是指定master角色可以达到最终一致性。如果master角色可以由调用方自动切换，则会带来数据的混乱。调用方存在多个节点，至少需要统一的config server来保证切换的一致性。另外，自动切换发生后，无法达到两份数据的最终一致性。
再说由运维手工切换
由于不牵涉到代码的逻辑判断，虽然切换也会带来一些数据一致性问题，在具体场景下（比如master长久宕机）切换可以接受。

在出现上述问题后，其他一些解决方案如下。
1. proxy在master cas失败时候delete slave data
2. client在master cas失败时set slave, 并且将数据过期时间设成5分钟

上述方案很难完美，一些明显存在的问题如下
方案1：
命中率的问题。由于delete导致修改的数据迅速失效，会导致读取量的增加，在读写均密集的业务场景，可能会导致数据访问出现波动。
接口职责单一性的问题。proxy在cas调用中隐藏了删除数据的逻辑，这是一个未在正常期望范围内的额外操作，在特殊情况下，可能会导致不可预料的情况出现。(尽管在实际操作中proxy提供配置开关选项)

方案2：
依然是命中率的问题，5分钟过期延缓了过期的访问数据库的压力，但相关压力仍然会传递到数据库。

希望通过上面说明读者能理解这个场景的问题。在这个场景下，完美的方案应当如何设计？

原文地址：分布式缓存的一起问题, 感谢原作者分享。

热心网友 时间：2022-04-14 07:49

分布式缓存主要用于在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显著提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID操作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等操作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的复制和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。
当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。

热心网友 时间：2022-04-14 09:07

分布式缓存是专业术语，拼音为fèn bù shì huǎn cún，缓存这种能够提升指令和数据读取速度的特性，随着本地计算机系统向分布式系统的扩展，在分布式计算领域中得到了广泛的应用，称为分布式缓存