文|好史多磨
編輯|好史多磨
引言：
随着資訊技術的發展，各企業日常運作所産生的資料量激增，采用集中式存儲的系統在讀寫混合的資料處理模式中逐漸出現了各種性能問題。
為解決該問題，資料讀寫分離機制應運而生，讀寫分離資料處理模式是提高資料庫性能的一種重要方式，主要通過增加備援，主從伺服器分别負責讀寫的方式，緩解了伺服器的壓力。
分布式資料管理系統在讀寫混合資料處理模式下的适用性會優于集中式存儲的資料庫：集中式存儲的資料庫在業務高峰期易出現存儲瓶頸。
集中式存儲的資料庫中，undo日志帶來臨時空間的消耗使得資料庫性能下降，以上兩種問題分布式資料管理系統均不存在，相反，分布式資料管理系統在讀寫混合模式下還有以下優勢：節省資源，減少備援消耗。
資料同步，無需資料遷移，且沒有資料遷移造成的系列問題，資料時效性高。
但是，讀寫分離場景下的資料備援帶來的安全性保證是讀寫混合模式所不具備的，是以在選擇讀寫混合模式時，需做好資料保護與備份。
項目背景
由于項目建構的大資料平台具有資料強一緻性和實時性保障的需求，并且是一個寫多讀少、低并發的場景，是以平台更傾向于選擇并推行讀寫混合資料處理模式。
在存儲方式層面，由于資料量龐大，平台選擇了分布式存儲系統，雖然資料的強一緻性和實時性的需求得到解決，但當資料量龐大且頻繁寫入時，讀寫混合模式又會造成查詢速度慢等問題。
為此在讀寫混合模式下的分布式資料管理系統基礎上，還通過記憶體使用、寫入線程、段合并和FinalRef等方面的優化，設計相應的具體解決方案。
實際運作的結果表明，優化後的系統在性能上有顯著的提升，基本達到了預期的性能效果。
基于業務層考量，項目選擇了TDDMS作為底層資料管理系統。
TDDMS是一款自主研發的分布式資料庫管理系統，作為基座産品，TDDMS可以為不同存儲引擎提供公共的存儲管理服務，包括保障資料均勻分布、負載均衡等資料分片服務。
TDDMS可以為不同存儲引擎提供公共的存儲管理服務，與開源方案相比，TDDMS的叢集節點上限得到擴充，為保障資料分布變動時，不會影響叢集總體服務。
在絕大多數的分布式資料庫下，讀寫混合模式往往需要對功能或者性能做出一定犧牲。
TDDMS作為一類分布式搜尋引擎的資料管理系統，其最主要特色展現在檢索方面，這勢必會在入庫性能等方面存在取舍，導緻入庫吞吐量較大時會給叢集的檢索帶來不穩定因素。
本次的性能優化，是探究在寫入達到一定基準的情況下，如何降低寫入對查詢帶來的影響，以及查詢自身是否存在優化點，進而提升産品的讀寫混合能力，若解決了讀寫混合的問題，将對産品相容性的提高有着重要意義。
此次問題中産品性能達不到預期的原因，在于寫入和查詢的混合場景上沒有很好的打磨，過往TDDMS雖然具備讀寫混合模式的基礎條件。
但其重點場景依舊在讀寫分離的模式下，這樣寫入和查詢帶來的一系列互相影響都是以前沒有重點關注的内容。
在優化措施的段合并以及寫入線程優化部分，都是通過控制如何降低寫入帶來的開銷來提升産品整體的性能。
除上述處理問題帶來的解決思路外，針對讀寫混合模式下的各類優化手段還有很多，cache在讀寫的合理配置設定、基于硬體的IOPS優化、查詢的索引樹優化等，對資料庫提升讀寫混合模式下的性能都有一定的借鑒意義。
問題排查
針對目前混合負載的業務場景下，TDDMS的表現沒有展現出其原有的性能水準：在寫入上，通過kafka+logstash的入庫模式，資料開始存在積壓，證明搜尋引擎存在寫入瓶頸。
在查詢方面，查詢能力在大規模寫入後有明顯的衰退，不再保持原有的毫秒級檢索能力，如何有效運用已有的CPU、記憶體等資源并降低開銷就成為了提升産品性能和能力的核心問題。
對于此種情況，我們采取了多種方式對TDDMS和業務叢集進行全面性的分析。
日志調整日志級别下調，在不影響業務的情況下調整日志級别，将QUERY、SCAN、FETCH等一次查詢的多個階段性日志充分展示并加以分析，分階段排查查詢耗時中占比較大的階段有無調優空間。
記憶體分析平台通過JAVA封裝了底層的搜尋引擎，是以在JAVA側，堆的開銷和使用同樣是重要的排查一環。
通過jvm相關參數調整，包括堆内堆外記憶體使用，新生代老年代占比，GC日志開啟，jmap觀察對象的開銷和使用以及jstat工具觀測叢集在不同業務時刻下YGC的頻率與時長等多種手段細緻分析了服務的壓力表現和可能的影響因素。
叢集資源開銷分析叢集在混合負載下的業務整體表現也是問題排查的重要一環，叢集的磁盤IO、整體網絡、CPU的開銷、記憶體與緩存的使用程度都與性能息息相關。
分析過程中，對于業務在不同時間段的整體表現，也進行了綜合的記錄，以此确定和論證産品是否受到資源瓶頸限制、産品的寫入壓力是否是導緻查詢表現不佳的重要原因等多個猜想。
基于業務應用的實際分析除卻産品和叢集相關的排查外，從應用使用角度也進行了排查。
應用上，業務調用的分頁查詢等查詢接口是否存在使用不當的問題；查詢的複雜度是否因為過高進而帶來資料庫計算量和開銷加重的問題。
解決方案
通過上述的排查，我們從搜尋引擎的設計層面提出4點優化措施，可以比較好地解決目前的産品性能問題。
同時也可以為類似的搜尋産品在處理混合負載場景下提供一定的借鑒意義，特别是方案中的中間兩項，對于通過lucene建構分布式搜尋引擎的同類産品從業務使用上和産品優化上均有适用價值。
高頻業務的查詢接口是否需要特殊的優化以及查詢結果集是否過大，都是排查中的考量因素。
記憶體洩漏優化在jstat中明确觀察到随着服務的長時間運作，old區的累積加重，但是majorGC回收率較低。
Jmap中存在大量SearchContext對象未被釋放，這類對象會持有lucenesnapshot，snapshot會使得資料的索引資訊在查詢未命中後長時間無法傳回資料結果，也無法接受到clear請求并進行對象的釋放，導緻堆内記憶體使用率急劇提升。
在預期邏輯中，每次查詢開始後，會在資料分片上建構SearchContext對象，并持有索引的快照資訊，這些資訊包括segment等索引資料，用于資料的檢索查詢。
查詢結束後，SearchContext會存活一小段時間後進行釋放，一方面是對對象的合理引用和銷毀；另一方面，短時間的存活可以ScrollScan這類查詢的開銷，不用再反複建構SearchContext重新周遊索引資料，起到類似cache的作用。
但是在實際表現中，用戶端發起請求對每個分片查詢後，由于存在檢索資料在某些資料分片中不存在的情況無法命中。
無法被預設的fetchthenclear機制進行清理和回收，其他資料分片的SearchContext對象皆無法釋放，其最終釋放依賴于引擎的定時任務。
針對這種情況，我們降低了對象的存活時間，使預設的SearchContext存活時長從過去相對較長的預設值(1h)下降到分鐘級。
同時補足了用戶端邏輯，在傳回結果後同樣會發起一次對每個查詢分片的clear請求來處理SearchContext的持有問題。
應用成果
在經過上面的問題定位和調優後，結合實際在生産環境中的業務驗證，産品性能相比過去在以下幾方面有了明顯的進步和提升。
垃圾回收表現更合理，性能抖動現象明顯下降，在原先的叢集表現下，定期的高頻查詢會出現偶發性的響應時長為6~8squery，在出現慢查詢時同時存在長時間的GC現象。
而調優後，在GC整體表現更符合預期的情況下，查詢受GC影響的時間也下降至百ms級别，做到了客戶視角下的延遲無感覺和查詢的高速響應。
寫入吞吐大幅度提升，叢集壓力下降通過對Client端寫入線程和對server發起的請求的合并收束，寫入時CPU的開銷不增反降，同時大幅度提升了寫入性能，也對查詢留有了更多的計算資源。
在實際業務測試中，針對不同業務量入庫的表現下也有了數量級的提升，以下是産品調優後的分頁查詢的業務性能。
目前的叢集，在性能上滿足了業務對于查詢響應和寫入的訴求，基本滿足了資料種類多、資料量大、重寫入、輕修改、低并發的資料檔案化管理系統對于資料庫的需求。
結語
在分布式搜尋引擎技術的基礎上，根據大資料平台的目标與需求，提供了針對資源有限、資料量龐大、寫多讀少的混合場景下性能優化的解決方案。
并針對業務需求，改善了性能抖動的現象，大幅度提升了寫入吞吐量，降低了叢集壓力，提高了分頁查詢的業務性能，實作了分布式資料庫在混合負載場景下的應用。