一次Redis调优经历及思考

https://www.cnblogs.com/benwu/articles/8616141.html

https://my.oschina.net/haogrgr/blog/228591

先放两个链接。工作中优化后达到预期效果再着手写细节。

https://www.cnblogs.com/me115/p/4337733.html

背景:自己写的redis相关组件,每秒处理1600数据都无法胜任。将优化过程记录一下。

一、二级缓存。

使用本地缓存,存储部分redis返回结果,减少连接。我使用的Guava的LoadingCache.

二、连接池参数调优。

我使用的Jedis包。在连接池部分做参数调优。这部分细节只能根据自己的实际因素,调节参数后自己试,得到较优参数。

参数意义具体看上面连接。

三、Client工具选择。

扫描二维码关注公众号,回复: 9533199 查看本文章

上面说到我使用的Jedis,但是SpringBoot2.x开始使用的却是Lettuce,这种Client支持异步调用,切连接是线程安全的。

理论上异步优于同步,但是经我本地测试4个线程,20连接,10W数据经历时间优化不大。最重要的是,没有找到Lettuce连接Codis的资料。如果只考虑单机、哨兵、RedisCluster可以考虑使用这种。但是我还是选择了Jedis.

四、连接预热。

在单例的连接池实例化后,手动创建MinIdle个数的Jedis连接。然后close归还连接池。

五、减少连接。

我本地封装了一层dao,dao的每个方法都从池中拿连接做逻辑,在业务中调了dao里的多个方法。我这里将业务逻辑进行一定合并。在dao里加了使用同一连接做多个指令的方法。

六、减少select db

业务需要每条数据可能要从使用者配置的不同redis实例中获取。经过4个线程,20连接,10W次测试,select指令消耗的时间约为get指令的三倍。所以减少频繁select是一个方向。配置文件加defaultDB,连接池实例化过程指定defaultDB后,select时做判断,是

defaultDB就不用select了

七、数据预加载。

在数据处理前,加载一批数据到二级缓存。我使用的jedis scan指令。加载本地缓存cacheSize * critical个数的数据。

cacheSize为本地缓存设置的大小。critical为自定义的配置0-1之间。最好再加一个scanKey配置,默认为*。

八、合理使用Pipeline模式。

因为我的业务场景每次都要拿到明确返回才行,在处理中pipeline对我不适用,但是数据预加载时我使用了pipeline,效率明显提升。

九、跑下BenchMark.

本地测试连接开发环境的redis,发现只有3000/s.而使用jedis连接池同等连接、线程、数据下只有1000/s.在git上找了个三方的Jedis BenchMark发现也就只有1000/s。redis本地跑BenchMark30000-40000/s。虽然unix domain比TCP性能高,但是看资料应该只有近两倍出入。网络IO也是瓶颈之一!

Redis对带宽需求很高!

写在最后:这只是我的一些思考和优化的方式。优化的成果还待生产环境的验证。希望给需要的人一定帮助!

发布了78 篇原创文章 · 获赞 6 · 访问量 8540

猜你喜欢

转载自blog.csdn.net/MrBack/article/details/102616616