压测QPS 过低

Question

老师，好久不见，最近业务上遇到些问题，有些问题想跟您讨论下，希望您可以帮忙解答下：

1. 乐观锁问题。
   乐观锁失败重试的问题，在免费领券的场景下，如果控制失败重试的次数，比如3次，其实并发量也可以上去的，只不过前端交互信息的展示并不友好，重试3次未领到，提示，系统繁忙，如果在业务场景允许的情况下是否也可以？

2. redis 缓存内存使用过量 的问题
   
   我们线上的redis是主备模式的，内存单台8G,开启了rdb 持久化，当我们的有效缓存数据达到单机内存量的50%时，bgsave 开始的时候，我们的应用服务响应能力就慢了下来，因为copy on write 对当前内存数据的copy 使用了将近48% 的物理内存。
   我能想到的方式都被运维怼了回来
   1.持久化是要做的，提升我们的单机内存量到16 G？我觉得并不是长久之计。因为有效内存只增加 了4G.
   2.开启AOF,但是rewrite 还是会遇到同样的问题。
   3.分布式缓存，缓存数据切片 replication，但是他们坚决不同意，说什么要经过老板同意，我觉得这是在搪塞。
   还请老师指点下。

3. 我们线上的服务 响应能力过低。
   
   当前我们的服务配置如下，API业务服务器4台，主备redis 2台，主备mysql 2台，负载均衡器主备2台，但是单独请求一个查询缓存的接口 ab -c100 -n 2000 https://xxxx.phicomm.com/Service/Kcode/KcodeAllGoods?pageNo=1 接口 QPS 只有200多，这个接口只是查询redis 中 sortedset 中的value,并根据score 进行降序排序，业务逻辑并不复杂，其他的单台服务器配置没有太大问题，QPS 压不上去的原因是什么呢？
   还请老师帮忙解答下。

4. 
   

Answer 1

Jeson 2018-05-30 10:36:22

你好，你的问题中，我可以依据我之前的管理经验回答你问题2、问题3。问题1这个问题并不是我擅长的部分，所以这个问题就不回答你了。

问题2回答：

其实你想解决的就是“copy on write”带来了redis性能响应的延迟问题。这个问题我觉得你可以这么尝试去出方案和运维或者开发讨论。

方案1、提升内存不是一个好方法，因为瓶颈不在内存使用上导致的。

方案2、开启AOF，关闭rdb,这个我觉得可以尝试，但记住需要关闭rdb。

方案3、分布式缓存，这个方案是可以的，因为采用了集群的方案也能有效的提高整体的性能。但需要注意：你使用分布式缓存的模式 ，是redis cluster？还是走代理模式，通常通过redis走代理工具，不能建议这么作，反而会有额外的性能消耗。

最后呢，你还可以考虑下方案4、方案5:

方案4、使用redis的主从分离，主库不开启持久化，可以利用Redis复制功能将持久化功能转移到从库上，让这种方式保障数据库数据丢失的风险，同时提高Redis的服务响应能力。

方案5、程序端，采用hash的方式，将数据打散，存储到后台多个redis实例上。

问题3回答：

这个性能瓶颈的问题，虽然你们的业务逻辑不复杂，但原因有很多可能性。你还是需要继续排查，找到压测的瓶颈。

如：如果你怀疑Redis读取有瓶颈，建议你考虑将代码这块逻辑去掉，进行压测，看看是否有提升 等等

• 提问者 mark_fork #1

  谢谢老师！！我再看下