我们知道Redis使用单线程读写数据，一旦有BigKey产生，则在对BigKey读写时很可能造成Redis单线程阻塞，从而影响整个Redis响应。
一般来说BigKey的情况有两种：
比如String类型的时，value的值保存了1M的数据，针对这种情况建议在业务设计时就要注意，尽量对Key或者Value进行再进行拆分，如果实在避免不了，可以考虑对数据进行压缩后再传输。
除此之外，Key的长度也尽量要短。
除了String，其他集合类型如：Hash、Set、List等，如果存放的集合元素过多，一旦要取全量数据，则也会存在BigKey的问题，针对这类问题，解决方式和前面的方式一样，要么进行拆分，要么考虑使用压缩，尽量精简存放的字段（包括字段名、字段类型等）。
还是由于Redis单线程读写的原因，所以线上应当禁用一些涉及到全量数据的命令，否则会影响整个Redis响应。
这部分命令包括如下一些：
这是一个时间复杂度为O(N)的命令， N为Redis数据库中Key的数量。
实际上KEYS的速度是很快的，但如果在一个大的数据库中使用它，则还是会对Redis带来影响，建议使用SCAN命令来代替Keys命令，或者使用Set集合来代替。
同样的，一些查全量集合数据的命令，也可能带来隐患，比如HGETALL、SMEMBERS等，这些命令的时间复杂度都是取决于集合中Key的元素个数，随着元素个数的增加，响应时间变的越来越慢，同样建议对其进行拆分存储。
一个是清空当前数据库中的数据，一个是清空整个Redis实例中的数据，如果数据量很大，则同样会阻塞线程，避免在线上运行时执行，一般可以让运维对这个命令进行重命名，避免客户端调用的隐患。
理论上所有Key都应该有过期时间，除非有非常明确的业务应用场景，Key设置过期时间主要是为了避免无效的Key还一直占用内存资源，最后触发内存淘汰机制，淘汰了一些相对的热Key数据，甚至直接导致内存不足，服务崩溃。
大多数情况下，要尽量避免通过无限增加Redis内存来解决单机内存瓶颈的问题，因为内存越大就意味着在进行RDB快照，主从复制等操作时阻塞时间越长，所以一般建议单机内存最好不要超过8G，内存不足的情况下应当通过集群部署来解决。
虽然Redis有RBD+AOF的持久化机制，但这只是Redis自身数据高可靠的保证，最终目的并不是为了让客户端把它当做数据库使用，毕竟内存容量有限，使用Redis最主要的原因还是为了对热数据进行缓存。
Key的集中过期对于Redis来说并没有什么影响，主要还是在业务上可能会因为大量Key的集中失效，导致在失效那一时刻，如果存在大量访问，则会对数据库带来巨大的压力，所以一般情况下，可以在失效时间上加上毫秒级别的随机数。
Redis中大部分命令都不支持批量的，比如一次性有1000个String类型的Key需要写入，正常情况下只能一个个写入，每一次写入都要经过从客户端发起命令到服务端执行命令、返回结果的过程，如果这样执行1000次，则会有大量的时间都消耗在了网络上，客户端会非常的慢。
针对这种情况，建议使用Pipeline功能，这是由客户端提供的API，它可以一次性传一批命令给到服务端，从而减少了客户端与服务端的交互次数，避免了网络消耗的问题，当然批命令在使用时也要注意，批量的命令也不是无上限的，其不能超过缓冲区的大小，还要注意一次传入过多的命令也必然会造成服务端执行时间较长，造成阻塞问题。
非必要时不建议开启AOF，就算开启也不要实时刷盘，建议按照每秒1次来设置，避免磁盘I/O的消耗给Redis造成不稳定。