复述要比Memcached更火的原因有哪些 - 行业资讯 - 肥雀云

介绍

本篇内容介绍了“复述要比Memcached更火的原因有哪些”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

<>强要分析它们的区别,主要从以下几个方面对比:

<李>

,线程模型

<李>

,数据结构

<李>

,淘汰策略

<李>

,管道与事务

<李>

,持久化

<李>

,高可用

<李>

,集群化

<强>线程模型

要说性能,必须要分析它们的服务模型。

Memcached处理请求采用多线程模型,并且基于输入输出多路复用技术,主线程接收到请求后,分发给子线程处理。

这样做好的好处是,当某个请求处理比较耗时,不会影响到其他请求的处理。

当然,缺点是CPU的多线程切换必然存在性能损耗,同时,多线程在访问共享资源时必然要加锁,也会在一定程度上降低性能。

复述,同样采用输入输出多路复用技术,但它处理请求采用是单线程模型,从接收请求到处理数据都在一个线程中完成。

这意味着使用复述,一旦某个请求处理耗时比较长,那么整个复述,就会阻塞住,直到这个请求处理完成后返回,才能处理下一个请求,使用复述时一定要避免复杂的耗时操作。

单线程的好处是,少了CPU的上下文切换损耗,没有了多线程访问资源的锁竞争,但缺点是无法利用CPU多核的性能。

由于复述是内存数据库,它的访问速度非常地快,所以它的性能瓶颈不在于CPU,而在于内存和网络带宽,这也是作者采用单线程模型的主要原因。同时,单线程对于程序开发非常友好,调试起来也很方便。开发多线程程序必然会增加一定的调试难度。

因此,当我们的业务使用关键的数据比较大时,Memcached的访问性能要比复述,好一些。如果关键的数据比较小,两者差别并不大。

,”,,严格来说，Redis的单线程指的是处理请求的线程，它本身还有其他线程在工作，例如有其他线程用来异步处理耗时的任务。

Redis6.0又进一步完善了多线程，在接收请求和发送请求时使用多线，进一步提高了处理性能。

数据结构

Memcached支持的数据结构很单一，仅支持string类型的操作。并且对于value的大小限制必须在1MB以下，过期时间不能超过30天。

而Redis支持的数据结构非常丰富，除了常用的数据类型string、list、hash、set、zset之外，还可以使用geo、hyperLogLog数据类型。

使用Memcached时，我们只能把数据序列化后写入到Memcached中。然后再从Memcached中读取数据，再反序列化为我们需要的格式，只能“整存整取”。

而Redis对于不同的数据结构可以采用不同的操作方法，非常灵活。

总之，Redis正是因为提供了这么丰富的数据结构，近几年在内存数据库领域大放异彩，为我们的业务开发提供了极大的便利。

淘汰策略

Memcached必须设置整个实例的内存上限，数据达到上限后触发LRU淘汰机制，优先淘汰不常用使用的数据。

但它的数据淘汰机制存在一些问题：刚写入的数据可能会被优先淘汰掉，这个问题主要是它本身内存管理设计机制导致的。

Redis没有限制必须设置内存上限，如果内存足够使用，Redis可以使用足够大的内存。

同时Redis提供了多种淘汰策略：

我们可以针对业务场景，使用不同的数据淘汰策略。