第二点，笔者在后续测试本地副本集的时候，尝试读secondary节点的数据，结果遇到了读延迟很高的情况。在网上研究了一下发现是因为，MongoDB 复制集里 Secondary 不断从主上批量拉取 oplog，然后在本地重放，以保证数据与 Primary 一致。这里为了防止脏读，会加一个锁阻塞所有的读请求。
所以如果遇到 Secondary 重放 oplog 占用锁时间长，读取的延时也会对应变长。这个锁最高能锁多久呢，看到有个案例锁了接近一个小时。。。看到的人内心一定是崩溃的，而在云Mongo测试的时候没有遇到这个情况，我想这一定是针对这个缺陷做了很大的改进，使用了其他方法实现同步。
总的来说，MongoDB确实可以不借助其他第三方工具实现高可用和分片功能，具备的高可用的故障切换，分片可以实现数据的分部均衡，大数据量的时候通过路由实现了服务器的负载均衡。所以MongoDB自身的可用性较高，也难怪会在短短时间内成为流行的nosql数据库。
但是MongoDB也存在着一些坑：如对内存的占用过高、对网络的占用过高、存在从节点锁导致读几乎不可用的情况，这些情况在实际业务使用的时候会导致很严重的问题，集群宕机、服务瘫痪、数据丢失无时不刻不是覆盖在运维同学心头的阴影。这个时候云MongoDB几乎就是救星，弹性伸缩、随时扩容、真正安全的数据热备以及强大的专业运维架构师团队，才能真的确保业务安全无故障的运行下去。
写到这里，笔者也在思考，云数据库到底是什么，它仅仅是把数据库封装一下，改改内核，提供给使用者吗？不，云数据库应当是一整套专业服务，除了数据库之外，还有监控、安全、迁移、灾备、运维等一系列的服务提供。能让业务开发专注于业务本身，把专业的交给专业的人去做。
此文已由腾讯云+社区在各渠道发布