redis查询优化

  最近公司运维提示线上redis出现报警，排查下来是redis存储的value过大导致查询的时候耗时过高。虽然redis单key最大可以存储1G(单key建议不要超过10kb)，但是当单key过大时，每一次访问都会造成redis阻塞，由于redis是单线程的，其他请求只能等待了。在我们的这个场景下，主要是hash存储的json串太大。这里提供两种优化方案，可以根据具体的业务场景进行选择。

序列化压缩

  Protobuf是Google提供的一种平台无关、语言无关、可扩展且轻便高效的序列化数据结构的协议,可以用于网络通信和数据存储。但相比于Json，Protobuf有更高的转化效率，时间效率和空间效率都是JSON的3-5倍。
  我们之前用的fastjson序列化，使用Protobuf序列化之后相较于JSON大概可以节省30%的空间，时间有50%的提升。但是内存空间还是需要优化，只能通过压缩存储了，这里使用GZIP压缩存储，测试下来大概能节省50%以上的内存空间，符合我们的预期。但是GZIP的缺点是比较耗CPU，时间换空间，如果对于性能要求不是很高的地方可以考虑一下。

大key拆分

Redis使用过程中经常会有各种大key的情况， 比如：
1： 单个简单的key存储的value很大
2： hash， set，zset，list 中存储过多的元素（以万为单位）
由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，所以，业务上能拆则拆，下面举几个典型的分拆方案。

1、单个简单的key存储的value很大