原因:
由于开发设计时对mongo不熟悉，只设计了结构和索引，并没有设计片键，在经过巡检发现mongo业务库没有添加片键，导致数据都集中在某个shard中，数据分布不均衡.
处理过程：
1.规划片键，经过与架构师讨论，设计片键为operate_date,但是没有想到这里有坑，开发为了解决时区问题，将operate_date类型设置为了字符串，
但是没有告知我，我还是以date 去建立片键，导致业务库 无法访问，紧急粗暴的把config中业务库的集合分片数据干掉了。这种方式为下个线上问题留下隐患.
2.由于线上有二十多个业务库，我先按数据量从小到大依次处理，最后还剩下两个大库，待时处理.
3.一个晚上8点多，客户访问数减少了，开始处理 大库A，将其中一个数据量大的集合加上片键后，触发均衡，CPU一直涨，最后飙到100%，过了一个小时，开始有客户反馈，说无法进行操作，影响生产了。
还是按上次粗暴处理，直接动了config库，将 大库A的 chunks,collections,locks直接干掉了,过了一会 CPU降下来了，再过了一会，客户反馈部分数据找不到，经过紧急对比发现大库A中数据量最大的一个集合丢失10%左右的数据,
没办法，从备份中恢复.
4.反思:
通过阅读官方文档 官方说明 禁止直接操作config库，由于直接干掉了chunks数据,导致部分chunk无法访问到，导致表现为部分数据无法找到.
5.降cpu处理
1.sh.stopBalancer()
2.待Balancer状态为false后 通过top 找出cpu占用最高的进行，找到相应的mongo进程.
3.找出问题shard,shard我部署为PSS模式，一般是在P节点，执行db.stepDown(120) 降级，然后将P节点shutdown，然后再启动，如果因为locks 导致无法 shutdown,那就没办法了优先让客户先生产，ps找到pid,直接kill掉，
复制集故障转移会自动在两个S中选举一个为P，依次将问题shard的所有节点都重启一次，释放负载. 主要原因是 均衡过程中 有些lock的问题，可以通过db.currentOp() 找到对应的耗时操作.
4.重启后 CPU会逐渐将下来。