wordpress开启redis缓存(wordpress redis缓存)

本文目录：

• 1、redis主要解决了什么问题
• 2、magento二次开发 - 在magento中配置使用redis缓存
• 3、web服务器怎么使用redis分步式缓存

redis主要解决了什么问题

redis是内存数据库，访问速度非常快，所以能够解决的也都是这些缓存类型的问题，如下：

1、会话缓存（Session

Cache）

最常用的一种使用Redis的情景是会话缓存（session

cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？

幸运的是，随着

Redis

这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

2、全页缓存（FPC）

除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。

再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。

此外，对WordPress的用户来说，Pantheon有一个非常好的插件

wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

3、队列

Reids在内存存储引擎领域的一大优点是提供

list

和

set

操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对

list

的

push/pop

操作。

如果你快速的在Google中搜索“Redis

queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。

排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted

Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：

当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：

ZRANGE

user_scores

10

WITHSCORES

Agora

Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。

5、发布/订阅

最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。

Redis提供的所有特性中，我感觉这个是喜欢的人最少的一个，虽然它为用户提供如果此多功能。

等等？

magento二次开发 - 在magento中配置使用redis缓存

php常用的缓存工具：memcached和redis,本文讲的是在magento框架中借助magento的模块来使用redis

确保你的电脑安装并启动了redis服务、配置了php的redis扩展

若没有，查看此文 《mac下安装配置redis》

6.22:

今天上午打开本地网站时报如下错误 connection to Redis failed ：

发现是因为redis服务没有开启导致的，开启redis即可

说明magento在配置了redis之后那么要保持reids服务一直处于开启状态

参考：

[1]在magento中配置redis文档：

[2]Cm_Cache_Backend_Redis配置

web服务器怎么使用redis分步式缓存

Redis复制流程概述

Redis的复制功能是完全建立在之前我们讨论过的基于内存快照的持久化策略基础上的，也就是说无论你的持久化策略选择的是什么，只要用到了Redis的复制功能，就一定会有内存快照发生，那么首先要注意你的系统内存容量规划，原因可以参考我上一篇文章中提到的Redis磁盘IO问题。

Redis复制流程在Slave和Master端各自是一套状态机流转，涉及的状态信息是：

Slave 端：

REDIS_REPL_NONEREDIS_REPL_CONNECTREDIS_REPL_CONNECTED

Master端：

REDIS_REPL_WAIT_BGSAVE_STARTREDIS_REPL_WAIT_BGSAVE_ENDREDIS_REPL_SEND_BULKREDIS_REPL_ONLINE

整个状态机流程过程如下：

Slave端在配置文件中添加了slave of指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT。

Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(最新版的Redis已经不需要让Slave阻塞)。

Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端。

Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并最终状态置位为 REDIS_REPL_CONNECTED状态，Slave状态机流转完成。

Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为 REDIS_REPL_ONLINE。

整个复制过程完成，流程如下图所示：

Redis复制机制的缺陷

从上面的流程可以看出，Slave从库在连接Master主库时，Master会进行内存快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，这会给整个集群搭建带来非常多的问题。

比如一台线上正在运行的Master主库配置了一台从库进行简单读写分离，这时Slave由于网络或者其它原因与Master断开了连接，那么当Slave进行重新连接时，需要重新获取整个Master的内存快照，Slave所有数据跟着全部清除，然后重新建立整个内存表，一方面Slave恢复的时间会非常慢，另一方面也会给主库带来压力。

所以基于上述原因，如果你的Redis集群需要主从复制，那么最好事先配置好所有的从库，避免中途再去增加从库。

Cache还是Storage

在我们分析过了Redis的复制与持久化功能后，我们不难得出一个结论，实际上Redis目前发布的版本还都是一个单机版的思路，主要的问题集中在，持久化方式不够成熟，复制机制存在比较大的缺陷，这时我们又开始重新思考Redis的定位：Cache还是Storage？

如果作为Cache的话，似乎除了有些非常特殊的业务场景，必须要使用Redis的某种数据结构之外，我们使用Memcached可能更合适，毕竟Memcached无论客户端包和服务器本身更久经考验。

如果是作为存储Storage的话，我们面临的最大的问题是无论是持久化还是复制都没有办法解决Redis单点问题，即一台Redis挂掉了，没有太好的办法能够快速的恢复，通常几十G的持久化数据，Redis重启加载需要几个小时的时间，而复制又有缺陷，如何解决呢？

Redis可扩展集群搭建1. 主动复制避开Redis复制缺陷。

既然Redis的复制功能有缺陷，那么我们不妨放弃Redis本身提供的复制功能，我们可以采用主动复制的方式来搭建我们的集群环境。

所谓主动复制是指由业务端或者通过代理中间件对Redis存储的数据进行双写或多写，通过数据的多份存储来达到与复制相同的目的，主动复制不仅限于用在Redis集群上，目前很多公司采用主动复制的技术来解决MySQL主从之间复制的延迟问题，比如Twitter还专门开发了用于复制和分区的中间件gizzard() 。

主动复制虽然解决了被动复制的延迟问题，但也带来了新的问题，就是数据的一致性问题，数据写2次或多次，如何保证多份数据的一致性呢？如果你的应用对数据一致性要求不高，允许最终一致性的话，那么通常简单的解决方案是可以通过时间戳或者vector clock等方式，让客户端同时取到多份数据并进行校验，如果你的应用对数据一致性要求非常高，那么就需要引入一些复杂的一致性算法比如Paxos来保证数据的一致性，但是写入性能也会相应下降很多。

通过主动复制，数据多份存储我们也就不再担心Redis单点故障的问题了，如果一组Redis集群挂掉，我们可以让业务快速切换到另一组Redis上，降低业务风险。

2. 通过presharding进行Redis在线扩容。

通过主动复制我们解决了Redis单点故障问题，那么还有一个重要的问题需要解决：容量规划与在线扩容问题。

我们前面分析过Redis的适用场景是全部数据存储在内存中，而内存容量有限，那么首先需要根据业务数据量进行初步的容量规划，比如你的业务数据需要100G存储空间，假设服务器内存是48G，那么根据上一篇我们讨论的Redis磁盘IO的问题，我们大约需要3~4台服务器来存储。这个实际是对现有业务情况所做的一个容量规划，假如业务增长很快，很快就会发现当前的容量已经不够了，Redis里面存储的数据很快就会超过物理内存大小，那么如何进行Redis的在线扩容呢？

Redis的作者提出了一种叫做presharding的方案来解决动态扩容和数据分区的问题，实际就是在同一台机器上部署多个Redis实例的方式，当容量不够时将多个实例拆分到不同的机器上，这样实际就达到了扩容的效果。

拆分过程如下：

在新机器上启动好对应端口的Redis实例。

配置新端口为待迁移端口的从库。

待复制完成，与主库完成同步后，切换所有客户端配置到新的从库的端口。

配置从库为新的主库。

移除老的端口实例。

重复上述过程迁移好所有的端口到指定服务器上。

以上拆分流程是Redis作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。

Redis复制的改进思路

我们线上的系统使用了我们自己改进版的Redis,主要解决了Redis没有增量复制的缺陷，能够完成类似Mysql Binlog那样可以通过从库请求日志位置进行增量复制。

我们的持久化方案是首先写Redis的AOF文件，并对这个AOF文件按文件大小进行自动分割滚动，同时关闭Redis的Rewrite命令，然后会在业务低峰时间进行内存快照存储，并把当前的AOF文件位置一起写入到快照文件中，这样我们可以使快照文件与AOF文件的位置保持一致性，这样我们得到了系统某一时刻的内存快照，并且同时也能知道这一时刻对应的AOF文件的位置，那么当从库发送同步命令时，我们首先会把快照文件发送给从库，然后从库会取出该快照文件中存储的AOF文件位置，并将该位置发给主库，主库会随后发送该位置之后的所有命令，以后的复制就都是这个位置之后的增量信息了。

Redis与MySQL的结合

目前大部分互联网公司使用MySQL作为数据的主要持久化存储，那么如何让Redis与MySQL很好的结合在一起呢？我们主要使用了一种基于MySQL作为主库，Redis作为高速数据查询从库的异构读写分离的方案。

为此我们专门开发了自己的MySQL复制工具，可以方便的实时同步MySQL中的数据到Redis上。

（MySQL-Redis 异构读写分离）

总结：

Redis的复制功能没有增量复制，每次重连都会把主库整个内存快照发给从库，所以需要避免向在线服务的压力较大的主库上增加从库。

Redis的复制由于会使用快照持久化方式，所以如果你的Redis持久化方式选择的是日志追加方式(aof),那么系统有可能在同一时刻既做aof日志文件的同步刷写磁盘，又做快照写磁盘操作，这个时候Redis的响应能力会受到影响。所以如果选用aof持久化，则加从库需要更加谨慎。

可以使用主动复制和presharding方法进行Redis集群搭建与在线扩容。

【wordpress开启redis缓存】的内容来源于互联网，如引用不当，请联系我们修改。