分类树，我从2s优化到0.1s( 二 ) _分类树

如果Redis中也没有数据（说明Redis挂了），则从数据库中查询数据，更新到Redis中（万一Redis恢复了呢），然后更新到本地缓存中，返回返回数据。

需要注意的是，需要改本地缓存设置一个过期时间，这里设置的5分钟，不然的话，没办法获取新的数据。

这样优化之后，再次做网站首页的压力测试，qps提升到了500多，满足上线要求。
第4次优化之后，这个功能顺利上线了。
使用了很长一段时间没有出现问题。
两年后的某一天，有用户反馈说，网站首页有点慢。
我们排查了一下原因发现，分类树的数据太多了，一次性返回了上万个分类。
原来在系统上线的这两年多的时间内，运营同学在系统后台增加了很多分类。
我们需要做第4次优化。
这时要如何优化呢？
限制分类树的数量？
答：也不太现实，目前这个业务场景就是有这么多分类，不能让用户选择不到他想要的分类吧？
这时我们想到最快的办法是开启Nginx的GZip功能。
让数据在传输之前，先压缩一下，然后进行传输，在用户浏览器中，自动解压，将真实的分类树数据展示给用户。
之前调用接口返回的分类树有1MB的大小，优化之后，接口返回的分类树的大小是100Kb，一下子缩小了10倍。
这样简单的优化之后，性能提升了一些。
第5次优化经过上面优化之后，用户很长一段时间都没有反馈性能问题。
但有一天公司同事在排查Redis中大key的时候，揪出了分类树。之前的分类树使用key/value的结构保存数据的。
我们不得不做第5次优化。
为了优化在Redis中存储数据的大小，我们首先需要对数据进行瘦身。
只保存需要用到的字段。
例如：

@AllArgsConstructor@Datapublic class Category {private Long id;private String name;private Long parentId;private Date inDate;private Long inUserId;private String inUserName;private List<Category> children;}

像这个分类对象中inDate、inUserId和inUserName字段是可以不用保存的。
修改自动名称。
例如：

@AllArgsConstructor@Datapublic class Category {/*** 分类编号*/@JsonProperty("i")private Long id;/*** 分类层级*/@JsonProperty("l")private Integer level;/*** 分类名称*/@JsonProperty("n")private String name;/*** 父分类编号*/@JsonProperty("p")private Long parentId;/*** 子分类列表*/@JsonProperty("c")private List<Category> children;}

由于在一万多条数据中，每条数据的字段名称是固定的，他们的重复率太高了。
由此，可以在json序列化时，改成一个简短的名称，以便于返回更少的数据大小。
这还不够，需要对存储的数据做压缩。
之前在Redis中保存的key/value，其中的value是json格式的字符串。
其实RedisTemplate支持，value保存byte数组。
先将json字符串数据用GZip工具类压缩成byte数组，然后保存到Redis中。
再获取数据时，将byte数组转换成json字符串，然后再转换成分类树。
这样优化之后，保存到Redis中的分类树的数据大小，一下子减少了10倍，Redis的大key问题被解决了。