开发规范

一、数据库连接

使用时，可能会遇到因为Mongod/Mongos的连接数满了，导致客户端无法连接的问题。在Mongod/Mongos的服务端，收到一个新的连接由一个单独的线程来处理，每个线程配置了1MB的栈空间，当网络连接数太多时，过多的线程会导致上下文切换开销变大，同时内存开销也会上涨。

1、客户端连接数据库的时候，要计算业务一共有多少个客户端，每个客户端配置的连接池大小是多少，总的连接数不要超过当前实例能承受的最大连接数的80%。

2、客户端与数据库的连接应尽量保持相对稳定的状态，每秒新增连接数建议保持在10以下。

3、建议客户端的连接超时时间至少设置为最大业务执行时长的3倍。

4、对于副本集实例，客户端需要同时配置主备节点的IP地址；对于集群实例，至少配置两个mongos的IP地址。

二、可靠性

write concern设置规则：对于关键业务，write concern设置为{w:n},n>0，数字越大，一致性实现更好，但性能较差。

w:1表示实际写入主节点完成返回。

w:1,journal:true表示写主节点和日志后返回。

w:majority表示大多数备节点写入后返回。

如果没有以w:majority写入数据，则发生主备倒换时，未同步到备机的数据有丢失风险。

三、性能相关

规范

1、业务程序禁止执行全表扫描的查询。

2、执行查询时，只选择需要返回的字段，不需要的字段不要返回。从而减少网络和进程处理的负载，修改数据时，只修改变化需要修改的字段，不要整个对象直接存储全部修改。

3、避免使用$not。DDS并不会对缺失的数据进行索引，因此$not的查询条件将会要求在一个结果集中扫描所有记录。如果$not是唯一的查询条件，会对集合执行全表扫描。

4、用$and时把匹配最少结果的条件放在最前面，用$or时把匹配最多结果的条件放在最前面。

5、单个实例中，数据库的总的个数不要超过200个，总的集合个数不要超过500个。

6、业务上线前，一定要对数据库进行性能压测，评估业务峰值场景下，对数据库的负载情况。

7、禁止同时执行大量并发事务，且长时间不提交。

8、业务正式上线前， 所有的查询类别，都应该先执行查询计划检查查询性能。

建议：

1、每个连接在后台都是由一个单独线程处理，每个线程会分配1MB的栈内存。所以连接数不宜过多，否则会占用过多的内存。

2、使用连接池，避免频繁的建立连接和断开连接，否则会导致CPU过高。

3、减少磁盘读写：避免使用不必要的upsert命令，避免查询不必要的数据。

4、优化数据分布：对数据进行分片，同时分散热点数据，均衡地使用实例资源。如何进行数据分片，请参见设置数据分片。

5、减少锁冲突：避免对同一个Key过于频繁地操作。

6、减少锁等待：避免前台创建索引。