Memcached真的过时了吗

Posted 2023-04-17

这两年 Redis火得可以，Redis也常常被当作 Memcached的挑战者被提到桌面上来。关于Redis与Memcached的比较更是比比皆是。然而，Redis真的在功能、性能以及内存使用效率上都超越了Memcached吗？
没有必要过于关注性能，因为二者的性能都已经足够高了。由于Redis只使用单核，而Memcached可以使用多核，所以二者比较起来，平均每一个核上，Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis。虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。说了这么多，结论是，无论你使用哪一个，每秒处理请求的次数都不会成为瓶颈。
在内存使用效率上，如果使用简单的key-value存储，Memcached的内存利用率更高。而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。当然，这和你的应用场景和数据特性有关。
如果你对数据持久化和数据同步有所要求，那么推荐你选择Redis。因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失，选择Redis也是明智的。
当然，最后还得说到你的具体应用需求。Redis相比Memcached来说，拥有更多的数据结构，并支持更丰富的数据操作。通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果你需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。 参考技术A

这个其实没有什么过时不过时，都是依据你自己的需求和看法来选择。

memcached是一套分布式的快取系统，当初是Danga Interactive为了LiveJournal所发展的，但被许多软件（如MediaWiki）所使用。这是一套开放源代码软件，以BSD license授权协议。

memcached缺乏认证以及安全管制，这代表应该将memcached服务器放置在防火墙后。

memcached的API使用32位元的循环冗余校验（CRC-32）计算键值后，将资料分散在不同的机器上。当表格满了以后，接下来新增的资料会以LRU机制替换掉。

由于memcached通常只是当作快取系统使用，所以使用memcached的应用程式在写回较慢的系统时（像是后端的数据库）需要额外的程式码更新memcached内的资料。

memcached 是以LiveJournal 旗下Danga Interactive 公司的Brad Fitzpatric 为首开发的一款软件。已成为mixi、hatena、Facebook、Vox、LiveJournal等众多服务中提高Web应用扩展性的重要因素。

许多Web应用都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大、访问的集中，就会出现RDBMS的负担加重、数据库响应恶化、网站显示延迟等重大影响。

这时就该memcached大显身手了。memcached是高性能的分布式内存缓存服务器。一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。

Memcached 的守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。但是它并不提供冗余（例如，复制其hashmap条目）；当某个服务器S停止运行或崩溃了，所有存放在S上的键/值对都将丢失。

Memcached由Danga Interactive开发，其最新版本发布于2010年，作者为Anatoly Vorobey和Brad Fitzpatrick。用于提升LiveJournal . com访问速度的。LJ每秒动态页面访问量几千次，用户700万。

Memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。

参考技术B

memcache 本身是一款分布式的高速缓存系统，以 key-value 的形式常驻内存，一般用来做网站或者数据库的缓存使用。

特别是对以下场景非常适合用 memcache 来做缓存：

频繁访问的数据

 2. 安全性要求比较低的数据

3. 更新比较频繁的小表（用户状态表、物品库存等）

mysql memcached api MySQL 5.6 —— 开始支持MySQL 5.6 把 memcache 功能以插件形式集成到 MySQL 数据库中，称为 memcached api。这样一来，memcache 的数据以 InnoDB 关系表的形式同步于磁盘，解决了 memcache 的几个问题：

解决了 memcache 的数据持久化的问题；

2. 可以很方便的以 SQL 语句的形式直接访问 memcache 的数据；

3. 不需要单独安装 memcache，安装 MySQL 即可使用。

MySQL 5.7 —— 深入优化

MySQL 5.7 对 memcached api 做了深入优化，官方数据显示使用 memcached api，在只读的场景中，QPS 提升到 100W。 

MySQL 8.0 —— 新增特性

MySQL 8.0 发布后，又在功能上给 memcached api 增加了两个新特性。1. 批量获取 KEY相比原来一次只能读取一个 Key 来讲，减少了客户端与 MySQL 服务端的数据交互次数。2. 可以对 KEY 进行 RANGE 操作

可以直接类似于 select * from t1 where id between 10 and 20 这样的范围检索语句。

jQuery真的过时了!

前言

前几天知乎上有一个问题：jQuery真的过时了吗？我的答案是：jQuery确实过时了！感觉这个话题挺有趣，那咱们展开了聊聊。详细地说一下jQuery为什么过时了。

1

jQuery解决了哪些痛点

讨论一个库或者框架是否过时，应该先看看它解决了哪些问题，这些问题现在是否有更好的解决方案。

jQuery解决了哪些问题呢？

浏览器兼容问题

IE678横行的年代，浏览器兼容问题是前端小伙伴们必须掌握的技能，IE6有哪些bug，这得倒背如流。IE不识别哪些标准的JavaScript方法和对象，这也得记住，写个ajax，别人都用XMLHttpRequest,到IE就得用ActiveXObject。苦逼的前端程序员不能专心研究技术，只能天天为浏览器厂商擦屁股。直到jQuery的出现，大家解脱了，DOM操作也好,事件绑定也好，ajax也好，jQuery为我们封装了兼容各个浏览器的方法，感觉整个世界都和平了。

选择器

没有jQuery，我们要用getElementById、getElementsByTagName这些方法获取DOM对象。为列表所有元素绑定事件，要么事件委托，要么遍历所有元素。为了搞定操蛋的DOM接口，我们掌握了各种奇淫技巧，其实毛用没有。有了jQuery,我们可以用css选择器获取元素，绑定事件也不在需要遍历元素列表了，整个人都清爽了。

动画效果

我清晰地记得第一次用计时器写动画，如何让一个元素动起来，再如何让它停止运动。调试完，无bug，这就用了一堆代码了，更不用说做一个完整的页面效果，想想就让人崩溃。在看看jQuery为我们提供的动画效果，简直不敢想象没有jQuery，我们如何在IE678里面实现我们想要的效果。

总结 

jQuery解决的痛点还远不止这些：它的DOM操作，样式操作，属性操作，事件绑定，还有遍历，表单序列化，ajax封装，这些功能给前端开发带入了一个崭新的世界。一直到今天，jQuery仍然是被前端开发者使用最多的库，没有之一！

2

替代jQuery的解决方案

jQuery给前端带来的影响是空前的，但是随着前端的发展，jQuery也进入了一个过时的状态，它为我们解决的痛点都已经有了替代方案。

浏览器兼容

浏览器的兼容问题越来越不是问题，IE6可以说已经被淘汰了（目前只有大型国企、事业单位、机关部门还有医院中的XP系统还保留着IE6，但是也开始逐步淘汰中）。天猫去年已经宣布不再支持IE8。虽然浏览器兼容问题仍然存在，但是已经不是当年那个坑翻天的时代了。

选择器

CSS3新增了大量选择器，操作样式，想怎么找就怎么找，不必麻烦jQuery。

原生的JavaScript也新增了querySelector和querySelectorAll方法，可以直接通过css选择器获取元素。

动画效果

css3提供了丰富的过渡和动画效果，让我们不再依赖jQuery。

ajax

fetch和axios这些第三方模块已经将ajax封装得相当出色了，我们再也不用为了一个$.ajax就引入jQuery。

DOM操作和事件绑定

抛开动画的问题，剩下主要就是数据的增删改，这种操作用jQuery，不管从性能的角度，还是易于开发和维护的角度来看，mvvm框架都要超jQuery很多。

组件化和模块化

组件化和模块化的开发是现在前端开发的主流，优点简单的说就是易于开发、易于维护、易于团队分工。

jQuery是可以组件化开发的，但是用jQuery写组件，就用两个字形容：蛋疼，谁用谁知道。

模块化不管是用ES2015也好（import,export），用webpack也好（require,module.exports），再不行，咱们复古有点用require.js或者sea.js,这显然和jQuery都没什么关系

综上所述

jQuery所有的优点都有更优秀的解决方案，可以肯定的说，jQuery已经过时了！

（如果贵公司要求兼容IE678,那就另当别论了。）

3

jQuery并没有被淘汰

jQuery虽然已经过时了，但是并没有被淘汰，而且近几年也不会。

• 现在市面上的大部分网站和应用还是基于jQuery，在此后的几年，他们仍然需要用jQuery维护。

• 很多公司没有专职的前端开发，他们的前端工作由后台负责，这些人更喜欢用jQuery加后台模板的工作模式。

• 部分两三年以上工作经验的前端开发，他们安于现状，排斥css3新特性，也没耐心学习mvvm框架，jQuery仍是他们的主要工具。

• IE678并没有消失，所以jQuery仍有用武之地。

• jQuery易于上手，仍然很适合做一些简单的网站。

综上所述，jQuery并没有被淘汰，仍然是新人必须技能之一。

4

总结

jQuery虽然过时了，但是jQuery仍然是前端开发的必备技能，对于一个前端新人，这个坑一定得踩。

5

尾声