仿it快播顶部button点击背景滑动切换的效果

<mongo:mongo host="${mongo.location}" port="${mongo.port}">
<mongo:options
connections-per-host="100"
threads-allowed-to-block-for-connection-multiplier="10"
connect-timeout="10000"
max-wait-time="120000"
auto-connect-retry="false"
socket-keep-alive="false"
socket-timeout="0"
slave-ok="false"
write-number="1"
write-timeout="0"
write-fsync="true"
/>
</mongo:mongo>
<mongo:db-factory mongo-ref="mongo"
dbname="${mongo.dbName}" username="${mongo.username}" password="${mongo.password}" id="mongoDbFactory" />
<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
<constructor-arg name="mongoDbFactory" ref="mongoDbFactory" />
</bean>

各个参数说明：

#对mongo实例来说，每个host允许链接的最大链接数,这些链接空闲时会放入池中,如果链接被耗尽，任何请求链接的操作会被阻塞等待链接可用,推荐配置10
connectionsPerHost=10
#当链接空闲时,空闲线程池中最大链接数
minPoolsSize=5
#此参数跟connectionsPerHost的乘机为一个线程变为可用的最大阻塞数，超过此乘机数之后的所有线程将及时获取一个异常.eg.connectionsPerHost=10 and threadsAllowedToBlockForConnectionMultiplier=5,最多50个线程等级一个链接，推荐配置为5
threadsAllowedToBlockForConnectionMultiplier=5
#一个线程等待链接可用的最大等待毫秒数，0表示不等待，负数表示等待时间不确定，推荐配置120000
maxWaitTime=120000
#链接超时的毫秒数,0表示不超时,此参数只用在新建一个新链接时，推荐配置10,000.
connectTimeout=10000
#此参数表示socket I/O读写超时时间,推荐为不超时，即 0 Socket.setSoTimeout(int)
socketTimeout=0
#该标志用于控制socket保持活动的功能，通过防火墙保持连接活着
socketKeepAlive=false
#true:假如链接不能建立时,驱动将重试相同的server,有最大的重试次数,默认为15次,这样可以避免一些server因为一些阻塞操作零时down而驱动抛出异常,这个对平滑过度到一个新的master,也是很有用的,注意:当集群为复制集时,驱动将在这段时间里,尝试链接到旧的master上,而不会马上链接到新master上
#false 当在进行socket读写时,不会阻止异常抛出,驱动已经有自动重建破坏链接和重试读操作. 推荐配置false
autoConnectRetry=false
#重新打开链接到相同server的最大毫秒数,推荐配置为0，如果 autoConnectRetry=true,表示时间为15s
#com.jd.mongodbclient2.mongo.JDClientMongo.maxAutoConnectRetryTime=false
#表示当没有手动关闭游标时,是否有一个自动释放游标对象的方法,如果你总是很小心的关闭游标,则可以将其设为false 推荐配置true

#com.jd.mongodbclient2.mongo.JDClientMongo.cursorFinalizerEnabled=true

#安全模式

com.jd.mongodbclient2.driver.MongoDBDriver.safe=true
#为true表示读写分离

com.jd.mongodbclient2.driver.MongoDBDriver.slaveOk=false

1. MongoClientOptions中的连接池配置:

配置如下:

connectionPoolSettings = ConnectionPoolSettings.builder()

                                                       .minSize(getMinConnectionsPerHost())

                                                       .maxSize(getConnectionsPerHost())

                                                       .maxWaitQueueSize(getThreadsAllowedToBlockForConnectionMultiplier()

                                                                         * getConnectionsPerHost())

                                                       .maxWaitTime(getMaxWaitTime(), MILLISECONDS)

                                                       .maxConnectionIdleTime(getMaxConnectionIdleTime(), MILLISECONDS)

                                                       .maxConnectionLifeTime(getMaxConnectionLifeTime(), MILLISECONDS)

                                                       .build();

minSize: 线程池空闲时保持的最小连接数, 默认是0.

maxSize: 线程池允许的最大连接数,默认是100.

maxWaitQueueSize: 线程池等待队列的大小, 默认是500.

maxWaitTime: 线程等待连接变为可用的最长时间.默认为2分钟. 值为0意味着它不会等待. 负值意味着它将无限期地等待

maxConnectionIdleTime: 线程池中连接的最大空闲时间, 0标志Udine空闲时间没有限制,超过这个时间会被关闭.

maxConnectionLifeTime: 线程池中连接的最长生存时间. 0表示没有限制. 超过寿命的会被关闭,必要时通过新连接进行替换.

2. MongoClientOptions初始化

mongodb驱动中 MongoClientOptions 使用Buidler模式配置,有关所有属性的默认值,都是在Builder里边配置的.

关于Builder 的配置如下:

    public static class Builder {

        private String description;

        private String applicationName;

        //读取偏好, 这里默认的是从主节点读取.

        private ReadPreference readPreference = ReadPreference.primary();

        //使用服务器默认的写关注?

        private WriteConcern writeConcern = WriteConcern.ACKNOWLEDGED;

        //使用服务的默认读关注,默认是local

        private ReadConcern readConcern = ReadConcern.DEFAULT;

        private CodecRegistry codecRegistry = MongoClient.getDefaultCodecRegistry();

        private final List<CommandListener> commandListeners = new ArrayList<CommandListener>();

        private final List<ClusterListener> clusterListeners = new ArrayList<ClusterListener>();

        private final List<ServerListener> serverListeners = new ArrayList<ServerListener>();

        private final List<ServerMonitorListener> serverMonitorListeners = new ArrayList<ServerMonitorListener>();

        private int minConnectionsPerHost;

        private int maxConnectionsPerHost = 100;

        private int threadsAllowedToBlockForConnectionMultiplier = 5;

        //设置服务器选择超时（以毫秒为单位），它定义驱动程序在抛出异常之前等待服务器选择成功的时间

        //值为0表示如果没有可用的服务器，它将立即超时。 负值意味着无限期等待

        private int serverSelectionTimeout = 1000 * 30;

        //线程等待连接变为可用的最长时间

        private int maxWaitTime = 1000 * 60 * 2;

        // 线程池中连接的最大空闲时间

        private int maxConnectionIdleTime;

        private int maxConnectionLifeTime;

        //连接超时时间,必须大于0

        private int connectTimeout = 1000 * 10;

        //socket超时时间

        private int socketTimeout = 0;

        //socket是否保活

        private boolean socketKeepAlive = false;

        private boolean sslEnabled = false;

        private boolean sslInvalidHostNameAllowed = false;

        private boolean alwaysUseMBeans = false;

        //设置心跳频率。 这是驱动程序将尝试确定群集中每个服务器的当前状态的频率。 默认值为10,000毫秒

        private int heartbeatFrequency = 10000;

        //设置最小心跳频率。 如果驱动程序必须经常重新检查服务器的可用性，它将至少在上一次检查后等待很长时间，以避免浪费精力。 默认值为500毫秒。

        private int minHeartbeatFrequency = 500;

        //设置用于集群心跳的连接的连接超时

        private int heartbeatConnectTimeout = 20000;

        //设置用于集群心跳的连接的套接字超时

        private int heartbeatSocketTimeout = 20000;

        //本地阈值

        private int localThreshold = 15;

        private String requiredReplicaSetName;

        private DBDecoderFactory dbDecoderFactory = DefaultDBDecoder.FACTORY;

        private DBEncoderFactory dbEncoderFactory = DefaultDBEncoder.FACTORY;

        private SocketFactory socketFactory;

        private boolean cursorFinalizerEnabled = true;

...}

3. 需要关心的配置

这里就因人而异了, 我这列出比较重要的几个配置,具体的值看业务场景.

3.1 读写相关

这应该是程序最应该关注的配置了,读关注,写关注,读取偏好.

//读取偏好, 首先从从节点读取.
private ReadPreference readPreference = ReadPreference.secondaryPreferred();
//写关注为1 ,写入主节点即返回.
private WriteConcern writeConcern = WriteConcern.W1;
//使用服务的默认读关注,默认是local(决定到某个读取数据时，能读到什么样的数据)
private ReadConcern readConcern = ReadConcern.LOCAL;

3.2 线程池配置

//线程池空闲时保持的最小连接数

minConnectionsPerHost=20

//线程池允许的最大连接数

connectionsPerHost=100

//connectionsPerHost* 5 =最大队列数

threadsAllowedToBlockForConnectionMultiplier=5

//线程池中连接的最大空闲时间,5分钟

maxConnectionIdleTime = 5*60*1000

// 线程池中连接的最长生存时间,采用默认值

maxConnectionLifeTime

3.3 连接配置

//设置服务器选择超时（以毫秒为单位），它定义驱动程序在抛出异常之前等待服务器选择成功的时间
//值为0表示如果没有可用的服务器，它将立即超时。负值意味着无限期等待
private int serverSelectionTimeout = 1000 * 30;

//连接超时时间,必须大于0
private int connectTimeout = 1000 * 5;

//线程等待连接变为可用的最长时间.

maxWaitTime=6000

这里建议这两个参数: maxWaitTime,connectTimeout,根据公司具体的业务来..

四个方面进行 cpu/io 方面的优化处理：

1.集群架构上进行读写分离。所有查询优先考虑在从库上读取，写操作在主库上执行。避免主库混合读写压力过大，也减少主库上读写记录的锁冲突。

connection string中readPreference 设置成secondarypreferred，C++ 驱动版本升级为3.1.3 mongo-cxx-driver（驱动升级，读写分离才生效）。

2.热表msg_traces 索引优化

针对该慢查询创建联合索引 {"_id": 1, "account": 1, "app_key": 1, "s_pc": 1}。

3.mongodb 历史数据归档和删除

和开发同事沟通，根据实际业务需求，保留msgs、msg_traces 集合中一年左右的文档。在timestamp 字段上创建TTL索引。设置文档的过期时间为 3153600秒（365*24*3600）。

db.msgs.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )

db.msg_traces.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )

mongodb TTL索引将每隔60秒对过期数据执行一次删除操作。删除操作的持续实际取决于mongod 实例的负载。

4 .journal 日志的 commitIntervalMs 参数调整。

从默认的100ms调大到500ms。

目前通过读写分离和索引优化之后，原来分片1在业务高峰期间的cpu load 值由最高值250降低到5以内，优化效果非常明显。

mongodb 分片集群优化思路总结：

分片集群中出现某个分片负载特别高的情况。（往往是某个分片负载高，如果是多个分片节点负载都高，则需要逐个进行分析）

第一步：

首先通过top、iostat、vmstat、mongostat 等工具了解系统大致并发负载和读写比例，观察系统具体瓶颈所在。

第二步：

如果负载只是集中出现在某一个节点上，则通过 mongotop 工具先分析该mongodb实例的热点表是哪些并记录下来。

第三步：

通过 mlogfilter / mloginfo 工具分析业务高峰期间出现的TOP10 慢查询。

第四步：

定位需要优化的目标表,并进行查询优化。

通常第二步和第三步会出现很多相同的表。因为热点数据表和慢查询表往往存在相同的一些表。这些表就是我们需要优化的目标。

mongodb 分片表的优化大致从以下几方面着手：

1.查看表分片键、数据分布、数据总量、数据占用空间等信息。着重看数据分片键设置是否合理、数据分布是否均匀；

2.mloginfo 工具打印出来的慢查询信息中有每个慢查询的查询条件。确认慢查询表上是否有合适的索引满足查询条件执行。需要结合explain() 分析慢查询的具体执行计划。

3.选取业务高峰阶段的mongodb实例原始日志，搜索慢查询表相关的原始查询语句。记录这些原始查询语句，方便后续与开发同事沟通，看能否从业务场景上进行相应的优化。

4.对于日志、事件、会话信息等日志类型的表，可以按照业务需求，根据事件字段，只保留一定时间内的有效数据。通常这要与开发业务

沟通清楚。确认保留时间后，可以利用mongodb TTL索引特性，在特定时间字段上创建索引，设置记录过期时限。

第五步：

架构上做读写分离优化

如果在第三步找出来的 TOP10 慢查询不少是能有效利用索引的简单查询，正常情况下，执行应该很快（200ms之内）。

则需要考虑在架构上做读写分离的优化。因为热点表高并发的读写会让cpu 忙不过来，导致原本正常的查询都出现阻塞。

总之，mongodb 优化关键之处是找出系统瓶颈和问题根源。定位出需要优化的目标表后，简单地加个索引或者做个读写分离，性能问题往往就迎刃而解。

这个和医生看病颇为相似，通过望闻问切和各种医疗检验设备所反馈的数据和报告，再依据丰富的临床经验诊断出病因所在。找出病因后，开什么方子用什么药就是水到渠成的事了。当然，医生看病比给数据库做性能诊断复杂多了，误诊几率也不小。而且，数据库性能优化没找准原因还有不少试错的机会，但是医生试错成本就比较高了。所以当个好医生貌似比做个好DBA更难！

以上插了些题外话。优化上过程中，也需要和开发同事保持有效沟通。当我们理解慢查询产生的业务场景后，有时让开发同事配合做个简单的功能优化，头痛的性能问题也能随之解决。