1）redis的优势
- 使用redis有哪些好处？ (1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1) (2) 支持丰富数据类型，支持string，list，set，sorted set，hash (3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行 (4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
- redis相比memcached有哪些优势？ (1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型 (2) redis的速度比memcached快很多 (3) redis可以持久化其数据
- redis常见性能问题和解决方案： (1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件 (2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3... 这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。 4.redis集群的工作原理 1主多从+哨兵模式
2）redis集群 Redis集群的几个重要特征： (1).Redis 集群的分片特征在于将键空间分拆了16384个槽位，每一个节点负责其中一些槽位。 (2).Redis提供一定程度的可用性,可以在某个节点宕机或者不可达的情况下继续处理命令. (3).Redis 集群中不存在中心(central)节点或者代理(proxy)节点， 集群的其中一个主要设计目标是达到线性可扩展性(linear scalability)。 集群客户端连接集群中任一Redis Instance即可发送命令，当Redis Instance收到自己不负责的Slot的请求时，会将负责请求Key所在Slot的Redis Instance地址返回给客户端，客户端收到后自动将原请求重新发往这个地址，对外部透明。一个Key到底属于哪个Slot由crc16(key) % 16384 决定。
- Redis的数据分片(Sharding) Redis 集群的键空间被分割为 16384 (2^14)个槽(slot)， 集群的最大节点数量也是 16384 个(推荐的最大节点数量为 1000 个)，同理每个主节点可以负责处理1到16384个槽位。 当16384个槽位都有主节点负责处理时，集群进入“稳定”上线状态，可以开始处理数据命令。当集群没有处理稳定状态时，可以通过执行重配置(reconfiguration)操作，使得每个哈希槽都只由一个节点进行处理。 重配置指的是将某个/某些槽从一个节点移动到另一个节点。一个主节点可以有任意多个从节点， 这些从节点用于在主节点发生网络断线或者节点失效时， 对主节点进行替换。 集群的使用公式HASH_SLOT=CRC16(key) mod 16384 计算key属于哪个槽。CRC16其结果长度为16位。
3）Redis 慢查询 Redis 的慢查询日志功能用于记录执行时间超过给定时长的命令请求， 用户可以通过这个功能产生的日志来监视和优化查询速度。 服务器配置有两个和慢查询日志相关的选项： slowlog-log-slower-than 选项指定执行时间超过多少微秒（1 秒等于 1,000,000 微秒）的命令请求会被记录到日志上。默认是10000. 举个例子， 如果这个选项的值为 100 ， 那么执行时间超过 100 微秒的命令就会被记录到慢查询日志； 如果这个选项的值为 500 ， 那么执行时间超过 500 微秒的命令就会被记录到慢查询日志； 诸如此类。 slowlog-max-len 选项指定服务器最多保存多少条慢查询日志。默认是128条。 服务器使用先进先出的方式保存多条慢查询日志： 当服务器储存的慢查询日志数量等于 slowlog-max-len 选项的值时， 服务器在添加一条新的慢查询日志之前， 会先将最旧的一条慢查询日志删除。 举个例子， 如果服务器 slowlog-max-len 的值为 100 ， 并且假设服务器已经储存了 100 条慢查询日志， 那么如果服务器打算添加一条新日志的话， 它就必须先删除目前保存的最旧的那条日志， 然后再添加新日志。 例：首先用 CONFIG_SET 命令将 slowlog-log-slower-than 选项的值设为 0 微秒， 这样 Redis 服务器执行的任何命令都会被记录到慢查询日志中； 接着将 slowlog-max-len 选项的值设为 5 ， 让服务器最多只保存5个；最后使用 SLOWLOG GET 命令查看服务器所保存的慢查询日志
一、持久化 AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。比如在不同的时间中调用了INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的(仅有最后一次incr test才有效)。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的增长。由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是fork一个子进程，直接遍历整个内存中的数据库内容，并写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件。(提示：正因为bgrewriteaof时需要大量的内存，所以一般情况下会将maxmemory的大小指定为服务器内存大小的50%，这也是为了防止在bgrewriteaof时内存溢出)
在数据恢复方面： RDB的启动时间会更短，原因有两个： 1)、RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。 2)、原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载
二、性能与监控 1、redis 是一个单线程的APP，除了bgsave或bgrewriteaof时它会启动另一个线程外，其它时间都是一个线程，且它并不支持cpu rebalance，它只会占用一颗CPU的资源，所以在多处理器环境中，尽量手工将不同redis实例绑定到不同的CPU上 2、为了提高性能，建议: 在cluster中所有的master上关闭 各种持久化功能，在cluster中所有的slave上开启持久化； 为了防止master/slave的自动切换，调整优先级( redis 优先级数字越小 优先级越高) 如果某个shard 宕掉，尽量先启动原slave( 该主机已持久化)，然后再启动原 master ，等数据稳定后，再cluster failover 3、关于监控项，监控内容如下： 进程数量 / 端口状态(port 是否存在) 进程占内存的情况 master的数量 / cluster_slots_ok 的数量是否为16384 / cluster_state
三、关于cluster-require-full-coverage 如果 cluster-require-full-coverage no，某个shard down掉，使用cluster info 命令时 cluster_state: ok，其它shard 照常可以get/set key 。 如果 cluster-require-full-coverage yes，某个shard down掉，使用cluster info 命令时 cluster_state: fail ，其它shard 不能get/set key， 在 get 或 set key 时 系统提示：(error) CLUSTERDOWN The cluster is down；可以使用 keys * 获取 key 名称 在每隔0.1s插入一个数据时，手工cluster failover 不会影响写入数据，数据没有丢失。
