标签:lin ast width redis集群 应该 redis 对象 sub 结果
redis环境:redis集群(含哨兵模式,部在了两台Linux系统的机器上,每台机器四个节点,2主2备)
存储内容:Submit对象(公司代码里面的,对象里只有手机号码和短信内容不同,其他字段值都一样)
主要逻辑:存:生成submit对象-->对象转json/byte数组-->向redis存入json字符串/byte数组
取:根据key值(先设定好)从redis值-->转化为json/byte数组
其中,submit对象和json的转化是用的alibaba的fastjson,对比了几种jar,只有这个最快。项目中每个过程都是记录时间的,比如说最开始记录时间,生成完所有的submit对象,记录一次,转化成json字符串/byte数组,记录一次.....为的就是对比之后得出结论,能优化的优化,不能优化的看时间。
还有,由于组长说实际的环境上应该是redis集群部在四台机器上,所以我把每个过程用四个线程来跑。然后所有的线程跑完后在用jedis.info(()来统计下每种存储方式存完数据机器内存的变化。
直接贴结果:
10w数据 | 时间 | 内存占用 |
存json | 10s | 14M |
存byte | 6s | 6M |
存jsonMap | 10s | 20M |
存byteMap | 4s | 4M |
取json | 7s | |
取byte | 4s | |
取jsonmap | 7s | |
取bytemap | 4s |
最后的结果就是:10w数据的时候,submit转json的过程要比submit转byte数组慢了2-3s,存redis的时候又慢了2s;100w数据的时候,存string的方式直接3个线程挂了,存byte也挂了1个线程。综上来说,存byte的方式要优于存string。
标签:lin ast width redis集群 应该 redis 对象 sub 结果
原文地址:https://www.cnblogs.com/e-x-c-e-ption/p/13187633.html