应用性能优化列表
應用開發完了,但是隨著用戶規模的上升,數據量的積累,系統會越來越慢,性能優化將會伴隨著項目一直持續下去
1、總原則
- 可擴展性架構,堆機器能不能解決問題是最最優先考慮的問題
- 去中心化的點對點通信,優于通過中心代理的通信
- 池化的長連接,優于短連接
- 二進制數據,優于文本數據
- 盡量減少交互,一次調用的粗粒度聚合接口 優于 多次調用的細粒度接口,批量接口優于循環調用
- 盡量只交互必要的數據
- 盡量就近訪問
- 盡量使用緩存
- 總是設定超時
- 在合適的場景,并行化執行、異步化執行
2、環境準備
保證開發環境、測試環境、驗證環境、正式環境的配置一致,包括但不限于以下內容:
3、數據庫
- 必須使用prepareStatement,提升性能與防注入
- 根據一切皆有超時的原則,配置SQL執行的超時。可在連接池里設置default值,可在MyBatis的Mapper定義里可設置每個請求的超時,可惜規范是秒級的。
- 根據盡量少交互與盡量少數據的原則,需使用對SQL完全可控的DAO框架,建議為MyBatis 或 Spring JDBC Template。
3.1 事務
- 不使用事務,連接池設置autocommit,使用其他方式來保持數據一致性。
- 通過Transaction Annotation控制事務,事務跨度盡量短,把非事務范圍內的業務邏輯剔除到被標注的函數之外。
- 只讀事務可以不加事務標注。
3.2 連接池
- 在分庫分表時,根據點對點通信優先的原則,盡量使用客戶端分片的實現。功能不滿足時才用MyCat中央代理。
- 推薦使用性能最高HikariCP,或者Druid,不推薦c3p0與DBCP。
連接池的配置:
- 配置初始值,再聯系DBA獲得線上數據庫支持的連接數,計算最大連接數。
- 連接有效性檢查,只在連接空閑檢測時執行,不在拿出和歸還連接時執行,最好是直接使用數據的Ping方案,不要配置檢查SQL。
- 根據總是設置超時的原則,配置獲取連接超時的時間。
- 配置合理的空閑連接回收間隔和空閑時間。
- 番外篇:在分庫分表時,可考慮基于HikariCP二次開發,減少總的空閑連接檢查線程數(比如128個分區,可能有256條線程),重用同一個實例上的庫的連接等。
4、緩存
4.1 多級緩存
- 根據緩存原則, 緩存 > 數據庫/遠程調用
- 根據就近原則, 堆內緩存 > 堆外緩存 > 集中式緩存
- 堆內緩存受大小限制,并影響GC
- 堆內緩存與堆外緩存,分布在每一臺應用服務器上,刷新方式比集中式緩存復雜
- 堆外緩存與集中式緩存,需要序列化/反序列化對象
- 集中式緩存,有網絡傳輸的成本,特別是數據超過一個網絡包的大小。
- 集中式緩存,一次獲取多個鍵時,在有分區的情況下,需要收發多個網絡包。
- 使用上述條件選擇合適的緩存方案,或同時使用多級緩存,逐層回源。
4.2 綜述
- 需要對回源進行并發控制,當key失效時,只有單一線程對該key回源。
- 基于二進制優于文本數據的原則,JSON的序列化方案較通用與更高的可讀性。而對于較大,結構較復雜的對象,基于Kyro,PB,Thrift的二進制序列化方案的性能更高,見后面的序列化方案部分。
4.3 堆內緩存
選型:
-
推薦Guava Cache。
- 正確設置并行度等參數。
- 重載load()參數,實現單一線程回源。
- Guava Cache能后臺定時刷新,在刷新的過程中,依然使用舊數據響應請求,不會造成卡頓,但需要重載實現reload()函數。
- Guava Cache同時還支持并發安全版的WeakHashMap。
- Ehcache較重,性能也較差。更不要使用存在嚴重bug的Jodd Cache。
4.4 堆外緩存
選型:
- 推薦Cassandra的OHC 或者 OpenHFT的Chronical map2。
- OHC夠簡單,其實R大不喜歡Chronical,玩的太深,換個JDK都可能跑不起來。
- Chronical map3的license則較不友好,復雜度高且要求JDK8。
- 其他的Ehcache的Terracota Offheap 一向不喜歡。
4.5 Memcached
?客戶端:
- 基于點對點通信優于網關的原則,使用客戶端一致性哈希分區。
- 推薦Spymemcached。 XMemcached 太久沒更新,Folsom知名度不高。
- 注意Spymemcached為單線程單連接架構(一個MemcachedClient只有一條IO線程,與每臺Memcached只有一條連接),必要時可多建幾個MemcachedClient隨機選擇,但不要用Commons Pool去封裝它,把Spy原本的設計一筆抹殺。
- 根據在合適場景使用并發的原則,Spymemcached支持異步API。
- 根據一切皆設超時的原則,可在連接工廠中設置最大超時數,默認值兩秒半太長。
數據結構:
- Key必須設置失效時間。
- Key必須有長度限制。
- Value長度需要控制,以不超過1個網絡包(MTU,千五字節)為佳。
- Value大小差別較大的緩存類型,建議拆分到不同MC集群,否則會造成低使用率并且產生踢出。
4.6 Redis as Cache
Redis拓撲:
-
基于點對點通信優于網關的原則,使用如下兩種拓撲
- 無HA的普通分片:由Jedis客戶端完成分片路由。
- Redis Cluster:同樣由Jedis客戶端封裝分區,跳轉,重試等邏輯,需要使用最新版的Jedis版本。
服務端:
- Cache節點與持久化數據節點不要混用。
- Cache節點是否需要持久化要仔細衡量。
- 由于Redis是單線程,使用taskset進行cpu綁定后可以有效地利用cpu,并在單機上運行多個redis實例。
+對熱鍵進行監控,發現不合理的熱健要進行分拆等處理。
客戶端:
- Jedis基于Apache Commons Pool進行了多連接的封裝,正確配置總連接數不超過Redis Server的允許連接數。
- 性能考慮,空閑連接檢查不要過于頻繁(建議30秒以上),另不要打開testOnBorrow等測試參數。
- 根據一切皆有超時的原則,設定統一的調用超時,獲取連接的最長等待時間參數,重試次數
- 根據在合適的地方異步的原則,Jedis本身沒有異步API,只在PipleLine模式下支持。
數據結構:
- 必須對Key設置失效時間。
- Key必須有長度限制。
- Value長度需要控制,不要超過一個網絡包。另外集合的元素不要超過五千個。
- 除了使用序列化的String,同樣可以考慮用Hash來存儲對象,注意內部結構為ZipList與HashTable時,hmget 與hgetall的不同復雜度。
命令:
- 慎用的命令:LANGE(0, -1), HGETALL, SMEMBER
- 高復雜度的命令: ZINTERSTORE, SINTERSTORE, ZUNIONSTORE, ZREM
- 盡量使用多參數的命令:MGET/MSET,HMGET/HMSET, LPUSH/RPUSH, LRANGE
- 盡量使用pipeline
- 根據減少交互的原則,必要時可使用Redis的Lua腳本
5、服務調用
5.1 接口設計
- 支持批量接口,最大的批量,綜合考慮調用者的需求與 后端存儲的能力。
- 支持粗粒度接口,在支持原子細粒度接口的同時,支持粗粒度接口/聚合層接口,將多個數據源的獲取,多個動作,合并成一個粗粒度接口。
- 在提供返回所有數據的大接口的同時,提供只提供滿足部分調用者需要的輕量接口。
- 最好再提供能定制返回字段的接口。
- 同樣是一個簡單通用性,與性能的選擇,特別是大數據量時。
5.2 RESTful
-
僅以Apache HttpClient為例,大部分Restful框架都是對Apache HttpClient的封裝。另外OkHttp也值得看看。
- 不要重復創建ApacheClient實例,使用連接池,正確配置連接池的連接數。
- 連接池總是有鎖,針對不同的服務,使用不同的Apache HttpClient實例,將鎖分散開來。在高并發時比使用全局單例的ApacheClient,有很大的性能提升。
- 根據一切調用皆有超時的原則,每次調用均設置超時時間。RequestConfig里共有Connect Timeout, Socket Timout 和 從Pool中獲取連接的Timeout三種超時。
- 需要異步或并行的場景,使用Apache AsyncHttpClient項目。但要注意AsyncHttpClient項目,檢查調用超時的周期默認為1秒。
5.3 自家RPC框架
每家的RPC框架特性不同,但考慮點都類似。
6、消息異步
6.1 選型
- 根據就近原則,可以先嘗試用JVM內的隊列來解決,然后再考慮中央消息系統。
- 可靠性要求極高的選擇RabbitMQ,可支持單條消息確認。
- 海量消息場景,允許極端情況下少量丟失則使用Kafka。
6.2 Kafka
- 在同步和異步之間做好權衡,異步批量發送可以極大的提高發送的速度。
- 關注消費者如下參數:commitInterval(自動提交offset間隔),prefetchSize(指單次從服務器批量拉取消息的大小),過大和過小都會影響性能,建議保持默認。
6.3 RabbitMQ
- 根據擴展性原則,RabbitMQ本身沒有分片功能,但可以在客戶端自行分片。
- 如非必要情況,應該保持默認的同步發送模式。
- 關注消費者如下參數:autocommit(自動提交確認,默認false) ,在消息拉取到本地即認為消費成功,而不是真正消費成功后提交。prefetchCount(預取消息條數,默認64條)
- 生產者在必要時也可以臨時降級不進行confirm。
7. 日志
7.1 綜述
- Log4j2或logback,不要再使用Log4j。
- 除了應用啟停日志,不允許使用超慢的System.out.println() 或 e.printStack();
- 嚴格控制日志量避免過高IO,對海量日志,應該有開關可以動態關停。
- 如果可能出現海量異常信息,可仿效JDK的優化,用RateLimiter進行限流,丟棄過多的異常日志。
7.2 內容
- 嚴格控制日志格式,避免出現消耗較大的輸出如類名,方法名,行號等。
- 業務日志不要濫用toJSONString()來打印對象,盡量使用對象自身的toString()函數,因為JSON轉換的消耗并不低。
- 在生產環境必定輸出的日志,不要使用logger.info("hello {}", name)的模式,而是使用正確估算大小的StringBuilder直接拼裝輸出信息。
7.3 異步日志
- 同步日志的堵塞非常嚴重,特別是發生IO的時候,因此盡量使用異步日志。
- Logback的異步方案存在一定問題,需要正確配置Queue長度,閥值達到多少時丟棄Warn以下的日志,最新版還可以設置如果隊列已滿,是等待還是直接丟棄日志。
- 如果覺得Logback的異步日志每次插入都要詢問隊列容量太過消耗,可重寫一個直接入列,不成功則直接丟棄的版本。
8、工具類
8.1 JSON
- 使用Jackson 或 FastJSON。GSON的性能較前兩者為差,尤其是大對象時。
- 超大對象可以使用Jackson或FastJSON的流式 API進行處理。
- 將不需要序列化的屬性,通過Annotation排除掉。
FastJson:
- 盡量使用最新的版本。
- SerializerFeature.DisableCircularReferenceDetect 關閉循環引用檢查。
Jackson:
- 設置參數,不序列化為空的屬性,等于默認值的屬性。
- 除了jackson-databinding,可試用簡化版沒那么多花樣的jackon-jr。
8.2 二進制序列化
需要定義IDL的PB與Thrift,不需要定義的Storm等用的Kyro 都可選擇,其他一些比較舊就算了。
8.3 Bean復制
在VO,BO之間復制時,使用Orika(生成代碼) 或 Dozer(緩存反射),不要使用需要每次進行反射的Apache BeanUitls,Spring BeanUtils。
8.4 日期
- JDK的日期類與字符串之間的轉換很慢且非線程安全。
- 繼續用Java日期不想大動作的,就用CommonsLang的FastDateFormat。
- 能大動作就用joda time,或者JDK8的新日期API。
9、Java代碼優化 與 業務邏輯優化
- 規則前置,將消耗較大的操作放后面,如果前面的條件不滿足時可。
- 另外前面提到的一堆原則,比如盡量緩存,盡量少交互,盡量少數據,并行,異步等,都可在此使用。
歡迎訂閱「K叔區塊鏈」 - 專注于區塊鏈技術學習
博客地址:http://www.jouypub.com
簡書主頁:https://www.jianshu.com/u/756c9c8ae984
segmentfault主頁:https://segmentfault.com/blog/jouypub
騰訊云主頁:https://cloud.tencent.com/developer/column/72548
總結
- 上一篇: webpack/gulp的z-index
- 下一篇: python 字符串格式化,使用f前缀