如果set test abc,然后继续执行setbit test 0 1；是会成功的。会造成test键内容被无意修改。可以增加一种编码encoding方式来加以区分。

rdb aof重写容易触发oom

网卡容易打满

40ms时延问题

数据过期清除策略不合适

热点数据需要统计，应对qps节点访问不均

大value统计，大value容易拖累整个业务时延

单台物理机多redis实例，如故避免多实例同时触发bgsave

主备模式，主复制积压缓冲区满造成主备反复整体同步。

多业务使用同一个redis集群，如何按照业务区分统计，例如不同业务的命中率，访问qps等

主备整体同步过程中，网络抖动，会引起反复整体同步

qps比较高的情况下，由于单线程的原因，时延会慢慢增大。

数据量大的集群迁移太慢，优化

hash结构存储的HGETALL  HDEL，如果hash上存储的kv对太多，容易造成redis阻塞，进一步引起集群节点反复掉线，集群抖动进一步引起整体同步

LPUSH是一直往链表追加，在集群跨机房同步的时候需要特别小心，集群数据迁移容易引起目的集群内存飙涨。

redis定时清理策略是定时随机循环取20个key来做判断，如果一次循环中至少有5个key过期，则继续循环，直到阻塞25ms时间到退出，然后过2ms继续清理。在实际业务使用中
可能业务数据都是匹配设置的过期时间，导致批量失效，进而触发这个过程中的redis访问阻塞，业务时延剧增。也就是27ms时间片中有25ms在做过期清理，2ms在做正常业务处理

redis集群跨机房同步工具，异常情况考虑。例如redis-migrate-tool第一次进行源目的整体同步的时候，存储耗大量内存情况，最坏情况该工具会用掉整个原集群内存容量，
如果原集群内存几百G，工具所在集群会炸掉,OOM, 如果源集群和目的集群长期失去联系，会造成redis-migrate-tool中KV积压严重，进一步触发OOM，集群状态变化无法自动感知等

改造点2:
	在对key-value对进行老化删除的过程中，采用从expire hash桶中随机取一个key-value节点，判断是否超时，超时则删除,这种方法每次采集点有很大
	不确定性，造成空转，最终由没有删除老化时间到的节点，浪费CPU资源。

	改造方法:在向expire hash桶中添加包含expire时间的key-value节点，在每个具体的table[i]桶对应的链中，可以按照时间从小到大排序，每次删除老化的时候
	直接取具体table[i]桶中的第一个节点接口判断出该桶中是否有老化时间到的节点，这样可以很准确的定位出那些具体table[i]桶中有老化节点，如果有则取出
	删除接口。

改造点3:
	主服务器同步rdb文件给从服务器的时候是采用直接读取文件，然后通过网络发送出去，首先需要把文件内容从内核读取到应用层，在通过网络应用程序从应用层
	到内核网络协议栈，这样有点浪费CPU资源和内存。

	改造方法:通过sendfile或者aio方式发送，避免多次内核与应用层交互，提高性能。

改造点4：
	主备同步每次都要写磁盘，然后从磁盘读，效率低下。
	
	改造方法：直接把内存中的key-value对由主传到备，不用落地。

改造点5：
	如果主备之间网络不好，例如rdb文件落地成功，主读取rdb文件，然后通过网络向备传输，如果传输一般网络断开，当网络重新恢复后，备有重新走
		之前的流程，主又要写rdb文件到磁盘，然后重新读磁盘往备传送。如此反反复复，主会不停额写磁盘，读磁盘，传输，永远传输不完。

权限控制能力不强，很容易被识破并攻击，就像wifi万能钥匙一样，很容易破密。