phpmagento面试技巧_今朝最全的Redis常识点及面试题汇总

Redis最大的特点有2个，一个是采取IO端口多路复用模型，极大的提升了处理IO的能力；其余一个是可以支持上述所说多种类型。
Redis的整体架构如图1所示，它可以监听多个句柄的事宜，并在有事宜的时候分发到详细的业务单元进行处理。

Redis已经是最火的KV数据库了，在各个领域运用广泛。
为了方便大家学习，本号整理了Redis的一些知识点和线上问题，希望对大家的日常开拓、运维或者跳槽有所帮助。

Redis实质上是一个Key-Value类型的内存数据库，很像memcached，全体数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。
由于是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据构造，此外单个value的最大限定是512MB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能。

速率快

Redis利用标准C编写实现，而且将所有数据加载到内存中，以是速率非常快。
官方供应的数据表明，在一个普通的Linux机器上，Redis读写速率分别达到81000/s和110000/s。

2）数据构造

可以将Redis看做“数据构造做事器”。
目前，Redis支持5种数据构造。

3）持久化

由于所有数据保持在内存中，以是对数据的更新将异步地保存到磁盘上，Redis供应了一些策略来保存数据，比如根据韶光或更新次数。
数据超过内存，利用swap，担保数据；

memcacache不能持久化，mongo是部分在内存；

4）自动操作

Redis对不同数据类型的操作是自动的，因此设置或增加key值，从一个凑集中增加或删除一个元素都能安全的操作。

5）支持多种措辞

Redis支持多种措辞，诸如Ruby,Python, Twisted Python, PHP, Erlang, Tcl, Perl, Lua, Java, Scala, Clojure等。

6）主-从复制

Redis支持大略而快速的主-从复制。

官方供应了一个数据，Slave在21秒即完成了对Amazon网站10Gkey set的复制。

7）Sharding

很随意马虎将数据分布到多个Redis实例中，但这紧张看该措辞是否支持。
目前支持Sharding功能的措辞只有PHP、Ruby和Scala。

1）String（字符串）

string 是 redis 最基本的类型，你可以理解成与 Memcached 千篇一律的类型，一个 key 对应一个 value。
string 类型是二进制安全的，也便是说 redis 的 string 可以包含任何数据。
比如jpg图片或者序列化的工具。
string 类型的值最大能存储 512MB。

2） Hash（哈希）

Redis hash 是一个键值(key=>value)对凑集。
Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特殊适宜用于存储工具。

3）List（列表）

Redis 列表是大略的字符串列表，按照插入顺序排序。
你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

4）Set（凑集）

Redis的Set是string类型的无序凑集。
凑集是通过哈希表实现的，以是添加，删除，查找的繁芜度都是O(1)。

5）zset(sorted set：有序凑集)

Redis zset 和 set 一样也是string类型元素的凑集,且不许可重复的成员。
不同的是每个元素都会关联一个double类型的分数。
redis正是通过分数来为凑集中的成员进行从小到大的排序。

1) memcached所有的值均是大略的字符串，redis作为其替代者，支持更为丰富的数据类型

2) redis的速率比memcached快很多

3) 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，你可以从这里去查看。

4）排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。
凑集（Set）和有序凑集（Sorted Set）也使得我们在实行这些操作的时候变的非常大略，Redis只是恰好供应了这两种数据构造。
以是，我们要从排序凑集中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只须要像下面一样实行即可：

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

ZRANGE user_scores 0 10 WITHSCORES

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

5）发布/订阅

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

noeviction:返回缺点当内存限定达到并且客户端考试测验实行会让更多内存被利用的命令（大部分的写入指令，但DEL和几个例外）

allkeys-lru: 考试测验回收最少利用的键（LRU），使得新添加的数据有空间存放。

volatile-lru: 考试测验回收最少利用的键（LRU），但仅限于在过期凑集的键,使得新添加的数据有空间存放。

allkeys-random: 回收随机的键使得新添加的数据有空间存放。

volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期凑集的键。

volatile-ttl: 回收在过期凑集的键，并且优先回收存活韶光（TTL）较短的键,使得新添加的数据有空间存放。

目前数据中央做事真个软件大都是运行在Linux操作系统上的，Windows运用处景不多；其余Linux版本已经相称稳定，windows环境用户量小，开拓的必要性不大，反而会带来兼容性等问题。

最大支持值的大小是512M，其余键（Key）的最大长度也是512MB。

根据性能金字塔我们知道内存的性能是机器磁盘的百万倍，如果不将数据放在内存中，磁盘I/O速率为严重影响redis的性能。
在内存越来越便宜的本日，redis将会越来越受欢迎。

如果设置了最大利用的内存，则数据已有记录数达到内存限值后不能连续插入新值。

10 Redis集群方案该当怎么做？都有哪些方案？

1.twemproxy，大概观点是，它类似于一个代理办法，利用方法和普通redis无任何差异，设置好它下属的多个redis实例后，利用时在本须要连接redis的地方改为连接twemproxy，它会以一个代理的身份吸收要求并利用同等性hash算法，将要求转接到详细redis，将结果再返回twemproxy。
利用办法简便(相对redis只需修正连接端口)，对旧项目扩展的首选。
问题：twemproxy自身单端口实例的压力，利用同等性hash后，对redis节点数量改变时候的打算值的改变，数据无法自动移动到新的节点。

2.codis，目前用的最多的集群方案，基本和twemproxy同等的效果，但它支持在 节点数量改变情形下，旧节点数据可规复到新hash节点。

3.redis cluster3.0自带的集群，特点在于他的分布式算法不是同等性hash，而是hash槽的观点，以及自身支持节点设置从节点。
详细看官方文档先容。

4.在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key 进行hash打算，然后去对应的redis实例操作数据。
这种办法对hash层代码哀求比较高，考虑部分包括，节点失落效后的替代算法方案，数据震荡后的自动脚本规复，实例的监控，等等。

有A，B，C三个节点的集群,在没有复制模型的情形下,如果节点B失落败了，那么全体集群就会以为短缺5501-11000这个范围的槽而不可用。

redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

Redisson、Jedis、lettuce等等，官方推举利用Redisson。

Redisson是架设在Redis根本上的一个Java驻内存数据网格（In-Memory Data Grid）。
充分的利用了Redis键值数据库供应的一系列上风，基于Java实用工具包中常用接口，为利用者供应了一系列具有分布式特性的常用工具类。
使得原来作为折衷单机多线程并发程序的工具包得到了折衷分布式多机多线程并发系统的能力，大大降落了设计和研发大规模分布式系统的难度。
同时结合各富特色的分布式做事，更进一步简化了分布式环境中程序相互之间的协作。

Jedis是Redis的Java实现的客户端，其API供应了比较全面的Redis命令的支持；Redisson实现了分布式和可扩展的Java数据构造，和Jedis比较，功能较为大略，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。
Redisson的宗旨是促进利用者对Redis的关注分离，从而让利用者能够将精力更集中地放在处理业务逻辑上。

设置密码：config set requirepass 123456

授权密码：auth 123456

Redis集群没有利用同等性hash,而是引入了哈希槽的观点，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点卖力一部分hash槽。

为了使在部分节点失落败或者大部分节点无法通信的情形下集群仍旧可用，以是集群利用了主从复制模型,每个节点都会有N-1个复制品.

Redis并不能担保数据的强同等性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

节点之间是采取的异步复制（asynchronous replication），因此Redis集群是无法担保数据的强同等性的。

21 Redis集群最大节点个数是多少？

16384个。

Redis集群目前无法做数据库选择，默认在0数据库。

ping

一次要求/相应做事器能实现处理新的要求纵然旧的要求还未被相应。
这样就可以将多个命令发送到做事器，而不用等待回答，末了在一个步骤中读取该答复。

这便是管道（pipelining），是一种几十年来广泛利用的技能。
例如许多POP3协议已经实现支持这个功能，大大加快了从做事器下载新邮件的过程。

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地实行。
事务在实行的过程中，不会被其他客户端发送来的命令要求所打断。

事务是一个原子操作：事务中的命令要么全部被实行，要么全部都不实行。

MULTI、EXEC、DISCARD、WATCH

EXPIRE和PERSIST命令。

尽可能利用散列表（hashes），散列表（是说散列表里面存储的数少）利用的内存非常小，以是你该当尽可能的将你的数据模型抽象到一个散列表里面。
比如你的web系统中有一个用户工具，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是该当把这个用户的所有信息存储到一张散列表里面.

一个客户端运行了新的命令，添加了新的数据。

Redi检讨内存利用情形，如果大于maxmemory的限定, 则根据设定好的策略进行回收。

一个新的命令被实行，等等。

以是我们不断地穿越内存限定的边界，通过不断达到边界然后不断地回收回到边界以下。

如果一个命令的结果导致大量内存被利用（例如很大的凑集的交集保存到一个新的键），不用多久内存限定就会被这个内存利用量超越。

Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于实行大量数据插入事情。

分区可以让Redis管理更大的内存，Redis将可以利用所有机器的内存。
如果没有分区，你最多只能利用一台机器的内存。
分区使Redis的打算能力通过大略地增加打算机得到成倍提升,Redis的网络带宽也会随着打算机和网卡的增加而成倍增长。

客户端分区便是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。
大多数客户端已经实现了客户端分区。

代理分区 意味着客户端将要求发送给代理，然后代理决定去哪个节点写数据或者读数据。
代理根据分区规则决定要求哪些Redis实例，然后根据Redis的相应结果返回给客户端。
redis和memcached的一种代理实现便是Twemproxy

查询路由(Query routing) 的意思是客户端随机地要求任意一个redis实例，然后由Redis将要求转发给精确的Redis节点。
Redis Cluster实现了一种稠浊形式的查询路由，但并不是直接将要求从一个redis节点转发到另一个redis节点，而是在客户真个帮助下直接redirected到精确的redis节点。

涉及多个key的操作常日不会被支持。
例如你不能对两个凑集求交集，由于他们可能被存储到不同的Redis实例（实际上这种情形也有办法，但是不能直策应用交集指令）。

同时操作多个key,则不能利用Redis事务.

分区利用的粒度是key，不能利用一个非常长的排序key存储一个数据集（The

partitioning granularity is the key, so it is not possible to shard a

dataset with a single huge key like a very big sorted set）.

当利用分区的时候，数据处理会非常繁芜，例如为了备份你必须从不同的Redis实例和主机同时网络RDB / AOF文件。

分区时动态扩容或缩容可能非常繁芜。
Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。
然而，有一种预分片的技能也可以较好的办理这个问题。

如果Redis被当做缓存利用，利用同等性哈希实现动态扩容缩容。

如果Redis被当做一个持久化存储利用，必须利用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变革。
否则的话(即Redis节点须要动态变革的情形），必须利用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

既然Redis是如此的轻量（单实例只利用1M内存）,为防止往后的扩容，最好的办法便是一开始就启动较多实例。
即便你只有一台做事器，你也可以一开始就让Redis以分布式的办法运行，利用分区，在同一台做事器上启动多个实例。

一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点捐躯是值得的。

这样的话，当你的数据不断增长，须要更多的Redis做事器时，你须要做的便是仅仅将Redis实例从一台做事迁移到其余一台做事器而已（而不用考虑重新分区的问题）。
一旦你添加了另一台做事器，你须要将你一半的Redis实例从第一台机器迁移到第二台机器。

Twemproxy是Twitter掩护的（缓存）代理系统，代理Memcached的ASCII协议和Redis协议。
它是单线程程序，利用c措辞编写，运行起来非常快。
它是采取Apache 2.0 license的开源软件。

Twemproxy支持自动分区，如果其代理的个中一个Redis节点不可用时，会自动将该节点打消（这将改变原来的keys-instances的映射关系，以是你该当仅在把Redis当缓存时利用Twemproxy)。

Twemproxy本身不存在单点问题，由于你可以启动多个Twemproxy实例，然后让你的客户端去连接任意一个Twemproxy实例。

Twemproxy是Redis客户端和做事器真个一个中间层，由它来处理分区功能该当不算繁芜，并且该当算比较可靠的。

Redis-rb、Predis等。

Redis有着更为繁芜的数据构造并且供应对他们的原子性操作，这是一个不同于其他数据库的进化路径。
Redis的数据类型都是基于基本数据构造的同时对程序员透明，无需进行额外的抽象。

Redis运行在内存中但是可以持久化到磁盘，以是在对不同数据集进行高速读写时须要权衡内存，应为数据量不能大于硬件内存。
在内存数据库方面的另一个优点是，

比较在磁盘上相同的繁芜的数据构造，在内存中操作起来非常大略，这样Redis可以做很多内部繁芜性很强的事情。

同时，在磁盘格式方面他们是紧凑的以追加的办法产生的，由于他们并不须要进行随机访问。

给你举个例子： 100万个键值对（键是0到999999值是字符串“hello world”）在我的32位的Mac条记本上 用了100MB。
同样的数据放到一个key里只须要16MB， 这是由于键值有一个很大的开销。
在Memcached上实行也是类似的结果，但是相对Redis的开销要小一点点，由于Redis会记录类型信息引用计数等等。

当然，大键值对时两者的比例要好很多。

64位的系统比32位的须要更多的内存开销，尤其是键值对都较小时，这是由于64位的系统里指针占用了8个字节。
但是，当然，64位系统支持更大的内存，所以为了运行大型的Redis做事器或多或少的须要利用64位的系统。

如果你利用的是32位的Redis实例，可以好好利用Hash,list,sorted set,set等凑集类型数据，由于常日情形下很多小的Key-Value可以用更紧凑的办法存放到一起。

info

如果达到设置的上限，Redis的写命令会返回缺点信息（但是读命令还可以正常返回。
）或者你可以将Redis当缓存来利用配置淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。

可以在同一个做事器支配多个Redis的实例，并把他们当作不同的做事器来利用，在某些时候，无论如何一个做事器是不足的，

以是，如果你想利用多个CPU，你可以考虑一下分片（shard）。

1) Master最好不要做任何持久化事情，如RDB内存快照和AOF日志文件

2) 如果数据比较主要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

3) 为了主从复制的速率和连接的稳定性，Master和Slave最好在同一个局域网内

4) 只管即便避免在压力很大的主库上增加从库

5) 主从复制不要用图状构造，用单向链表构造更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...

这样的构造方便办理单点故障问题，实现Slave对Master的更换。
如果Master挂了，可以急速启用Slave1做Master，其他不变。

RDB持久化办法能够在指定的韶光间隔能对你的数据进行快照存储.

AOF持久化办法记录每次对做事器写的操作,当做事看重启的时候会重新实行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末端.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

如果你只希望你的数据在做事器运行的时候存在,你也可以不该用任何持久化办法.

你也可以同时开启两种持久化办法, 在这种情形下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,由于在常日情形下AOF文件保存的数据集要比RDB文件保存的数据集要完全.

最主要的事情是理解RDB和AOF持久化办法的不同,让我们以RDB持久化办法开始。

46 如何选择得当的持久化办法？

一样平常来说， 如果想达到足以媲美PostgreSQL的数据安全性， 你该当同时利用两种持久化功能。
如果你非常关心你的数据， 但仍旧可以承受数分钟以内的数据丢失，那么你可以只利用RDB持久化。

有很多用户都只利用AOF持久化，但并不推举这种办法：由于定时天生RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 规复数据集的速率也要比AOF规复的速率要快，除此之外， 利用RDB还可以避免之条件到的AOF程序的bug

1）在指定的韶光间隔内，实行指定次数的写操作

2）实行save（壅塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令

3） 实行flushall 命令，清空数据库所有数据，意义不大。

4） 实行shutdown 命令，担保做事器正常关闭且不丢失任何数据，意义...也不大。

将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis做事即可。
在实际开拓中，一样平常会考虑到物理机硬盘破坏情形，选择备份dump.rdb 。
可以从下面的操作演示中可以体会到。

优点：

1 适宜大规模的数据规复。

2 如果业务对数据完全性和同等性哀求不高，RDB是很好的选择。

缺陷：

1 数据的完全性和同等性不高，由于RDB可能在末了一次备份时宕机了。

2 备份时占用内存，由于Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），末了再将临时文件更换之前的备份文件。

以是Redis 的持久化和数据的规复要选择在夜深人静的时候实行是比较合理的。

针对运行实例，有许多配置选项可以通过 CONFIG SET命令进行修正，而无需实行任何形式的重启。