基于Tair存储的广告服务性能优化总结及思考

 

2016年8月28号

      这两个周主要是在对基于Tair存储的广告服务性能进行优化，批量100条数据平响由65ms降低到36ms，tp99有120+降低到70+。

      主要对三方面内容进行优化，分别为Tair存储模式问题、数据结构设计模式优化以及相关代码优化。

     Tair存储模式选择出现问题原因是之前同学的调研不充分，错误使用了prefix模式存储数据。Tair提供了两种存储方式，分别是kv结构和prefix结构；kv结构是常规的存储结构，数据分布式存储，而prefix结构内部会存储一套kv结构，但每一个prefix存储在一台服务器上，其目的我想是为了提供给用户更大的灵活性，让用户自己来细分数据，分配服务器，从而提高服务处理效率。但由于相关同学调研不充分，把所有数据都存储在少量prefix下，根本无法发挥Tair的分布式优势，根本无法满足服务的性能需求。我是通过服务器数据分析发现服务性能太差，而且无论怎么优化都无法提高性能，便于相同Tair同学沟通，才弄明白问题原因。

      这个过程中存在几个问题，一是相关开发同学的并未在wiki中对两者不同应用场景进行说明，只是介绍下函数接口，并未详细说明，容易给别人造成误解，也给自己增加工作量。二是调研的同事按照自己的惯性思维来考虑问题，没有对这个问题深究一下，导致误用错误存储模式，存在的问题就是需要总结的教训，如果我是Tair相关开发同学，我会把Tair的这两种模式的应用场景在wiki中用大标题写清楚，避免不了解的同学再去踩坑，不能想当然的认为大家都知道这个问题。作为调研的同学看到两个不同的调用模式，没有文档的详细介绍的话，应该跟Tair同学问清楚差异，不能自己想当然，偷懒一下，结果是浪费时间浪费精力去反复调试效果，最终还得去弄清楚，就不如开始费点时间把问题搞清楚，免得以后走弯路，其实这也是一种严谨的态度，虽然不是我犯得错误，自己也要注意。

     数据结构设计模式问题这应该说是大家考虑问题偏重不同，也缺乏经验导致的。有三张表A（单value大概1k左右），B（单value大概40B）以及C（单value大概40B），应用场景是由A表查询出的结构查询B表，由B表查询出的结构查询C表。简单的逻辑就是A、B

以及C分别存储，就按照这种结构来存储查询，好处是逻辑简单，更新方便，但需要至少三次查表，耗时比较大，这是之前采用的方案。另一种方案是将三张表聚合，以A内容key作为key，ABC聚合的信息作为value存储，好处是查询次数少，读取时间短，但修改BC表内容比较麻烦。我们应用场景其实对修改效率要求不高，对读取要求比较高，所以应该采用第二种方案，这段时间主要是对两种方案进行对比，批量100条数据，方案一大概需要接近50ms，方案二需要接近30ms，方案一比方案二多消耗接近20ms，所以方案二是符合我们应用场景需求的。

      相关代码优化上，主要是之前同学将string转换为date，来比较时间的早晚，此简单过程导致消耗10+ms，将其转换为简单的分钟数进行比较，仅需1-2ms时间，节省不少时间。

      在性能优化过程中，接触到一个很有意思的问题，就是并发用户数，遇到问题是当我们平响时间在60+ms时，随着并发数的增加，平响迅速增加；但当我优化到平响36ms时，并发数增加对平响基本没有影响。我推测导致这个问题的原因是应该线程切换消耗时间过大导致的，linux系统时间片通常为100ms，在平响60ms时，TP90都在100ms以上，这样会有大量的线程切换消耗，所以随着并发数增加，线程切换消耗越来越大，会导致响应时间明显增加；而平响36ms时，服务的Tp99才70+ms，都在100ms以内，根本不存在线程切换消耗，所有其响应时间不受并发数量的影响，我想从逻辑上应该是对的。

      另外，这两周感冒，英语口语练习往前进展不大，也是想回去复习一下以前的内容，时间长了不复习很多都给忘了，需要抓紧时间巩固下。