每天一道面試題-CPU偽共享
前言：了不起：又到了每天一到面試題的時候了！學弟，最近學習的怎么樣啊 了不起學弟：最近學習的還不錯，每天都在學習，每天都在進步！ 了不起：那你最近學習的什么呢？ 了不起學弟：最近在學習C
最近在本地調(diào)試的時候發(fā)現(xiàn)，項目本地啟動比較慢，對啟動日志進行分析，Sharding-JDBC 在加載元數(shù)據(jù)的過程中中耗時 116 秒 ，占用了項目啟動時間的一半。
[org.apache.shardingsphere.core.log.ConfigurationLogger:104] : [0||0] Properties:max.connections.size.per.query: '1'[org.apache.shardingsphere.core.metadata.ShardingMetaDataLoader:131] : [0||0] Loading 2 logic tables' meta data.[org.apache.shardingsphere.sql.parser.binder.metadata.schema.SchemaMetaDataLoader:70] : [0||0] Loading 401 tables' meta data.[org.apache.shardingsphere.shardingjdbc.jdbc.core.context.MultipleDataSourcesRuntimeContext:59] : [0||0] Meta data load finished, cost 115930 milliseconds.分析加載流程，核心部分在 SchemaMetaDataLoader#load。
List<List<String>> tableGroups = Lists.partition(tableNames, Math.max(tableNames.size() / maxConnectionCount, 1));Map<String, TableMetaData> tableMetaDataMap = 1 == tableGroups.size() ? load(dataSource.getConnection(), tableGroups.get(0), databaseType) : asyncLoad(dataSource, maxConnectionCount, tableNames, tableGroups, databaseType);進入代碼看一下，發(fā)現(xiàn)這里會根據(jù) maxConnectionCount 對數(shù)據(jù)庫的表分組進行不同的加載策略，往上游看一下這個 maxConnectionCount 來源于 Sharding-JDBC 的配置，默認為 1。
public enum ConfigurationPropertyKey implements TypedPropertyKey { //....... /** * Max opened connection size for each query. */ MAX_CONNECTIONS_SIZE_PER_QUERY("max.connections.size.per.query", String.valueOf(1), int.class) //......}那是不是把這個配置擴展一下就可以提高啟動速度了？在將配置隨意設置成 8 之后由 116s 提升至 15s。
從這里來看啟動問題解決了，同時也產(chǎn)生了疑問，為什么 max.connections.size.per.query 默認值設置為 1。
這里是官網(wǎng)對于配置的解釋，物理數(shù)據(jù)庫為每次查詢分配的最大連接數(shù)量。
光看字面意思無法評估影響面，那就從 Sharding-JDBC 的查詢?nèi)肟陂_始看一下 ShardingPreparedStatement#executeQuery
public ResultSet executeQuery() throws SQLException { ResultSet result; try { clearPrevious(); prepare(); initPreparedStatementExecutor(); MergedResult mergedResult = mergeQuery(preparedStatementExecutor.executeQuery()); result = new ShardingResultSet(preparedStatementExecutor.getResultSets(), mergedResult, this, executionContext); } finally { clearBatch(); } currentResultSet = result; return result;}......
SQLExecutePrepareTemplate#getSQLExecuteGroups
private List<InputGroup<StatementExecuteUnit>> getSQLExecuteGroups( final String dataSourceName, final List<SQLUnit> sqlUnits, final SQLExecutePrepareCallback callback) throws SQLException { List<InputGroup<StatementExecuteUnit>> result = new LinkedList<>(); int desiredPartitionSize = Math.max(0 == sqlUnits.size() % maxConnectionsSizePerQuery ? sqlUnits.size() / maxConnectionsSizePerQuery : sqlUnits.size() / maxConnectionsSizePerQuery + 1, 1); List<List<SQLUnit>> sqlUnitPartitions = Lists.partition(sqlUnits, desiredPartitionSize); ConnectionMode connectionMode = maxConnectionsSizePerQuery < sqlUnits.size() ? ConnectionMode.CONNECTION_STRICTLY : ConnectionMode.MEMORY_STRICTLY; List<Connection> connections = callback.getConnections(connectionMode, dataSourceName, sqlUnitPartitions.size()); int count = 0; for (List<SQLUnit> each : sqlUnitPartitions) { result.add(getSQLExecuteGroup(connectionMode, connections.get(count++), dataSourceName, each, callback)); } return result;}這里可以看到，根據(jù) maxConnectionsSizePerQuery 選擇了不同的模式 CONNECTION_STRICTLY 、 MEMORY_STRICTLY
這里先說一下 sqlUnits 是什么，在分表之后進行查詢，如果查詢參數(shù)中不帶分片參數(shù)的話，Sharding-JDBC 會將 SQL 進行處理，例：
select * from table where field= “測試查詢”;實際執(zhí)行的過程中會被處理成
select * from table0 where field = “測試查詢”; select * from table1 where field = “測試查詢”; select * from table2 where field = “測試查詢”; ...... select * from table(n-1) where field = “測試查詢”;Sharding-JDBC 會將真實 SQL 查詢的數(shù)據(jù)進行聚合，聚合的方式根據(jù) maxConnectionsSizePerQuery 配置有兩種，即 CONNECTION_STRICTLY、MEMORY_STRICTLY。
CONNECTION_STRICTLY 可以理解為對同一數(shù)據(jù)源最多創(chuàng)建 maxConnectionsSizePerQuery 個連接。
MEMORY_STRICTLY 則是對一次操作的數(shù)據(jù)庫連接不做限制，同一數(shù)據(jù)源 n 張分表就創(chuàng)建 n 個連接，多線程并發(fā)處理。
從理論上看，是不是可以將 max.connections.size.per.query 設置的大一點，只要單次操作創(chuàng)建的數(shù)據(jù)源不超過數(shù)據(jù)庫連接上限就可以了？其實不一定，這里進入 UPDATE 的方法看一下。
public int executeUpdate() throws SQLException { try { clearPrevious(); prepare(); initPreparedStatementExecutor(); return preparedStatementExecutor.executeUpdate(); } finally { clearBatch(); }}發(fā)現(xiàn)這里在執(zhí)行 SQL 前同 SELECT 執(zhí)行了一樣的預處理邏輯 initPreparedStatementExecutor() ，那么在 max.connections.size.per.query > 1 的情況下，無論是那種模式都可能會根據(jù)配置的不同獲取多個數(shù)據(jù)源，執(zhí)行 UPDATE 就有可能存在死鎖問題。
例：
@Transactionalpublic void test(){ updateByID(1); updateByKey(1);}
圖片
所以最終得出結論目前狀態(tài)下，測試環(huán)境、預發(fā)環(huán)境可對max.connections.size.per.query 進行配置，提高啟動速度，在線上環(huán)境 max.connections.size.per.query 默認為 1 保證應用的穩(wěn)定。
在分析啟動問題的過程中對 Sharding-JDBC 查詢過程進行了簡單的了解，規(guī)避了線上可能引發(fā)的問題，同時也提醒了自己在改動一些配置時需要對配置所涉及的影響面進行充分評估后再進行改動。
本文鏈接：http://www.www897cc.com/showinfo-26-17373-0.htmlShardingjdbc啟動優(yōu)化，你學會了嗎？
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 開發(fā)微服務的九個最佳實踐
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號