这次聊聊业务中经常出现的重试现象，可能很多运维都被开发莫名其妙的艾特然后让查一查业务中出现失败的情况，很不巧刚接手MongoDB的运维就碰到了一个案例。

前段时间与业务开发讨论过某业务服务的超时重试问题，这项业务依赖的数据库是一直很热门的MongoDB数据库，这里采用了复制集的模式架构，且底层硬件采用KVM。业务开发反映数据库实例慢，最近超时的业务较少，重试后都能正常进行。我与开发沟通了半小时后大致了解他的意思，又花了大半天的时间去沟通并解决这个问题，过程就不详细赘述了。大概的意思就是这项短信服务平台业务实时性要求非常高，出现过一些业务超时现象，重试后仍然都能执行成功，希望我们排查下问题并对MongoDB集群进行一次优化。经i过与业务开发进一步的沟通，知晓他的需求和业务逻辑后，初步判断问题不出现在数据库集群在，业务逻辑并没有真正的串行话执行，意思就是B发生的前提是A发生了，然而这里程序设计没有去判断这个A有没有发生就去执行B。另一个问题是他觉得所谓的慢，通过超时现象变少，业务场景要求的实时性采用读写分离添加secondary节点满足他的横向扩容并不能有效解决他的问题，这些通过监控和服务器的CPU、IO、数据库实例的真实负载都可以看到性能没有到瓶颈。

最终我完善了集群的延迟监控，发现最多有1s到2s的延迟，且这个延迟反复出现，显然这个现象并不能通过secondary节点来缓解他的超时问题，对于这种实时性非常高的业务我们可以通过采用更好的硬件去解决或者其他优化手段。对于MongoDB的写入，我查阅了部分资料也建议他采用getlasterror的程序判断写入MongoDB是否成功，以及完善业务逻辑两种措施解决。

对于getlasterror的安全写入问题，总结如下，仅供参考阅读：

getlasterror的安全写入

Mongodb的写操作默认是没有任何返回值的，这减少了写操作的等待时间，也就是说，不管有没有写入到磁盘或者有没有遇到错误，它都不会报错。但一般我们是不放心这么做的，这时候就调用getlastError命令，得到返回值。

getLastError 是Mongodb的一个命令，它好像是取得最后一个error，但其实它是Mongodb的一种客户端阻塞方式，用这个命令来获得写操作是否成功的信息。getlastError有几个参数:j，w，fsync。

在多线程模式下读写Mongodb的时候，如果这些读写操作是有逻辑顺序的，那么这时候也有必要调用getlasterror命令，用以确保上个操作执行完下个操作才能执行，因为两次执行的连接有可能是不同的。在大多数情况下，我们都会使用连接池去连接mongodb，所以这是需要注意的。

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是否采用，需要考虑业务的具体场景和业务逻辑设计，并不是所有的场景都能适用。以我这次遇到的案例，对于短信类的服务平台，本身对实时性要求非常高，且会调用第三方的短信服务平台，逻辑存在漏洞但是为了保证实时性，数据库层面不建议他进行这样的安全写入机制，业务开发也觉得这种限制不可行。