这次聊聊业务中经常出现的重试现象，可能很多运维都被开发莫名其妙的艾特然后让查一查业务中出现失败的情况，很不巧刚接手mongodb的运维就碰到了一个案例。
前段时间与业务开发讨论过某业务服务的超时重试问题，这项业务依赖的数据库是一直很热门的mongodb数据库，这里采用了复制集的模式架构，且底层硬件采用kvm。业务开发反映数据库实例慢，最近超时的业务较少，重试后都能正常进行。我与开发沟通了半小时后大致了解他的意思，又花了大半天的时间去沟通并解决这个问题，过程就不详细赘述了。大概的意思就是这项短信服务平台业务实时性要求非常高，出现过一些业务超时现象，重试后仍然都能执行成功，希望我们排查下问题并对mongodb集群进行一次优化。经i过与业务开发进一步的沟通，知晓他的需求和业务逻辑后，初步判断问题不出现在数据库集群在，业务逻辑并没有真正的串行话执行，意思就是b发生的前提是a发生了，然而这里程序设计没有去判断这个a有没有发生就去执行b。另一个问题是他觉得所谓的慢，通过超时现象变少，业务场景要求的实时性采用读写分离添加secondary节点满足他的横向扩容并不能有效解决他的问题，这些通过监控和服务器的cpu、io、数据库实例的真实负载都可以看到性能没有到瓶颈。
最终我完善了集群的延迟监控，发现最多有1s到2s的延迟，且这个延迟反复出现，显然这个现象并不能通过secondary节点来缓解他的超时问题，对于这种实时性非常高的业务我们可以通过采用更好的硬件去解决或者其他优化手段。对于mongodb的写入，我查阅了部分资料也建议他采用getlasterror的程序判断写入mongodb是否成功，以及完善业务逻辑两种措施解决。
对于getlasterror的安全写入问题，总结如下，仅供参考阅读：
getlasterror的最佳实践
1、如果没有特殊要求，最低级别也要使用writerconcern.safe，即w=1。
2、对于不重要的数据，比如log日志，可以使用writerconcern.none或者writerconcern.normal，即w=-1或者w=0,省去等待网络的时间。
3、对大量的不连续的数据写入，如果每次写入都调用getlasterror会降低性能，因为等待网络的时间太长，这种情况下，可以每过n次调用一下getlasterror。但是在shard结构上，这种方式不一定确保之前的写入是成功的。
4、对连续的批量写入（batchs of write），要在批量写入结束的时候调用getlasterror，这不仅能确保最后一次写入正确，而且也能确保所有的写入都能到达服务器。如果连续写入上万条记录而不调用getlasterror，那么不能确保在同一个tcp socket里所有的写入都成功。这在并发的情况下可能就会有问题。避免这个并发问题
5、对数据安全要求非常高的的配置：j=true，w="majority" db.runcommand({getlasterror:1,j:true,w:'majority',wtimeout:10000})
对于getlasterror是否采用，需要考虑业务的具体场景和业务逻辑设计，并不是所有的场景都能适用。以我这次遇到的案例，对于短信类的服务平台，本身对实时性要求非常高，且会调用第三方的短信服务平台，逻辑存在漏洞但是为了保证实时性，数据库层面不建议他进行这样的安全写入机制，业务开发也觉得这种限制不可行。
如对本文有疑问， 点击进行留言回复！！
express+mongoose实现对mongodb增删改查操作详解
修复 Mac brew 安装 mongodb 报 Error: No available formula with the name ‘mongodb’ 问题详解
我要评论
网友评论