文|好史多磨
编辑|好史多磨
引言：
随着信息技术的发展，各企业日常运行所产生的数据量激增，采用集中式存储的系统在读写混合的数据处理模式中逐渐出现了各种性能问题。
为解决该问题，数据读写分离机制应运而生，读写分离数据处理模式是提高数据库性能的一种重要方式，主要通过增加冗余，主从服务器分别负责读写的方式，缓解了服务器的压力。
分布式数据管理系统在读写混合数据处理模式下的适用性会优于集中式存储的数据库：集中式存储的数据库在业务高峰期易出现存储瓶颈。
集中式存储的数据库中，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的开销不增反降，同时大幅度提升了写入性能，也对查询留有了更多的计算资源。
在实际业务测试中，针对不同业务量入库的表现下也有了数量级的提升，以下是产品调优后的分页查询的业务性能。
目前的集群，在性能上满足了业务对于查询响应和写入的诉求，基本满足了数据种类多、数据量大、重写入、轻修改、低并发的数据档案化管理系统对于数据库的需求。
结语
在分布式搜索引擎技术的基础上，根据大数据平台的目标与需求，提供了针对资源有限、数据量庞大、写多读少的混合场景下性能优化的解决方案。
并针对业务需求，改善了性能抖动的现象，大幅度提升了写入吞吐量，降低了集群压力，提高了分页查询的业务性能，实现了分布式数据库在混合负载场景下的应用。