使用Redis的TairHash结构遇到的问题
Redis是当前最流行的KV数据库，其支持丰富的数据结构，其中一种常见的数据结构是Hash； 阿里在Redis的Hash结构之上又引入了一个新的数据结构TairHash.
官方对TairHash的说明最核心只有一句话：
TairHash, 可实现 field 级别的过期 以及设置version
官方文档：help.aliyun.com/document_de…
前段时间在设计技术方案的时候当时判断到我们需要用到支持hash的field过期，然后看到TairHash支持这个特效，就欣然引入了...
但是在真正使用的过程中，有点小痛苦... 也遇到一些问题供大家参考。因为官方文档上说的全部都是优点，但是在一件事物解决了问题时候，会引入新的问题
解决的问题
如文档所说：
- 支持Hash的field过期
- 支持Hash的feild设置版本
- 主动过期和被动过期策略... (用处不大)
新的问题
内存空间膨胀
TairHash支持单独的过期时间，和版本，那这些数据存在哪里呢？ 肯定还是在内存中了，所以如果说RDB的内存资源比较紧张，用TairHash的话内存很快就不行了
TairHash的存储空间占用情况大约是普通Hash数据结构的4倍；
CPU利用率飙高，QPS下降
仍然由于做了过期时间控制，版本控制，在取数据的时候性能表现比Hash差很多，压测数据我不披露了，但是比正常的Hash结构性能消耗很严重。 官方文档提到的760WQPS，应该是get和set这种基本操作，但是到了TairHash在一定Key(Key个数不多)的时候，有100W左右的QPS；
总结
TairHash的优点确实如其所说，支持field版本和过期时间； 但是其负面作用就是内存利用率提升，同时在使用的时候CPU利用率也提升，QPS下降。最后演变成了，我的存储空间申请的很大，但是能支持的QPS很低； 有点往数据库方向靠了。 内存的费用和磁盘的费用对比下看看？
功能特性越多，越不像缓存，（个人认为使用Redis的最主要目的还是用来抗流量），这个特效很明显在抗流量的时候还是不如原生的好。
从经济上看成本增加了很多，因为Redis的存储比数据库贵很多，但我们用Redis的目的不是为了存储
如果现在还要支持filed的过期时间，还可以考虑的方案：
- hash的value种存储json数据结构，{v:"",d:""},d表示过期时间，取回来自己解析过期时间，计算放在服务器上；
- 拆成不同的hash，为什么需要不同的过期时间，拆分hash存储。不同的hash对应不同的过期时间
事物有好必有坏，看到一项技术带来的便捷时，也要关注其带来的负面作用..