应用性能优化列表
應用開發完了，但是隨著用戶規模的上升，數據量的積累，系統會越來越慢，性能優化將會伴隨著項目一直持續下去
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前缀