redis常见问题和解决方案

转载：https://www.cnblogs.com/aspirant/p/6820262.html

redis常见问题和解决方案

持久化、主从问题

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

(a)Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。

(b)Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

(c)Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

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

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

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…
这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

Hashtag(可以实现批量操作)

Redis计算槽时并非只简单的计算键值内容，当键值内容包括大括号时，则只计算括号内的内容（Hashtag）。比如：key为user:{10000}:books，计算hash值只计算10000。

Redis事务

Redis事务是一些列redis命令的集合：watch redisKey；multi .......exec。

生产上采用的是Redis Cluster集群架构，不同的key是有可能分配在不同的Redis节点上的，在这种情况下Redis的事务机制是不生效的。其次，Redis事务不支持回滚操作，简直是鸡肋！所以基本不用！

Redis的多数据库机制

Redis支持多个数据库，并且每个数据库的数据是隔离的不能共享，单机下的redis可以支持16个数据库（db0 ~ db15）。

但是，在Redis Cluster集群架构下只有一个数据库空间，即db0。因此，我们没有使用Redis的多数据库功能！

Redis集群机制不足的地方

1. 键的批量操作支持有限，比如mset, mget，如果多个键映射在不同的槽，就不支持了

2. 键事务支持有限，当多个key分布在不同节点时无法使用事务，同一节点是支持事务

3. 键是数据分区的最小粒度，不能将一个很大的键值对映射到不同的节点

4. 不支持多数据库，只有0，select 0

5. 复制结构只支持单层结构，不支持树型结构

Redis集群模式下，如何进行批量操作

如果执行的key数量比较少，就不用mget了，就用串行get操作。如果真的需要执行的key很多，就使用Hashtag保证这些key映射到同一台redis节点上。

如果你用的是Proxy分片集群架构，例如Codis这种，会将mget/mset的多个key拆分成多个命令发往不同得redis实例。

Redis做读写分离有什么问题

不做读写分离。我们用的是Redis Cluster的架构，是属于分片集群的架构。而redis本身在内存上操作，不会涉及IO吞吐，即使读写分离也不会提升太多性能，Redis在生产上的主要问题是考虑容量，单机最多10-20G，key太多降低redis性能.因此采用分片集群结构，已经能保证了我们的性能。其次，用上了读写分离后，还要考虑主从一致性，主从延迟等问题，徒增业务复杂度。