前段时间优化线上业务代码时，发现软端同步地址簿的数据时请求很缓慢，平均时延也在几百ms左右，平且这个接口的数据是缓存在redis中的。结果利用redis客户端工具，连接redis实例，查看这个数据，发现点击后，客户端直接崩溃、卡死了。后来通过命令行查询，发现这个单key返回的数据结果超级大（一般建议小于10kb），有接近700kb！终于定位到原因了。
    我们知道，redis早期版本（6.0以前）内部线程模型是基于单线程的，往往业务系统的访问量都很高，为了提升查询速度，才将数据存储在redis中。但是如果单key存储的数据较大，或者数据结构等等过于复杂，redis在处理这个数据的时候，延迟就会增高，进而也会阻塞队列中的其他请求，最终导致整个实例的查询时延都会增高。此外，在并发较高时，redis的带宽占用也会增高，假设单key大小为700kb时，并发为1024，那么每秒产生的流量就有接近700M，这对服务器的IO压力是十分巨大的。

    1.     所以，我们在使用redis时，尽量要避免bigkey的存在，通过设计上来避免这个问题，如对数据做一些拆分等等。甚至说对查询性能要求不高的业务系统，完全不需要使用redis，带来的好处是系统更加的轻量化，提高可维护性。