浅谈 日访问量8000万——App插件升级统计系统

   在上一篇文章中，我们谈到了Weex、ReactNative等方案，那么如何设计一个下载量统计方案呢。

   1.传统的tomcat + mysql批量写入更新

   如果数据量不大很好办，传统的tomcat处理客户端上报http数据，通过mysql进行存储，在数据量较大时，可以通过定时任务批量写入到mysql。用户查询上报数据时，只需要从mysql中存储即可。

   但是数据量逐渐变大呢，如果是一个超级App怎么办？

  2.负载均衡+容器化+阻塞队列+mysql索引

   前端通过HA负载均衡分发到多个docker上，每个docker有两个tomcat实例，我们可以通过上百个实例来承载客户端上报的数据，然后通过一个写入线程写入内存阻塞队列，排队到一定长度，通过读取线程批量写入数据库，这样的好处是非阻塞。

   但是这样有个问题，每次App插件上报时，如果数据库里存储了相关插件数据，就要更新数据，在mysql数据量过大时，更新数据涉及到查找数据，比较困难，在这里我们可以通过建立索引字段来实现。

  数据量积累到过大，必然涉及分库分表，多维度查找效率越来越难，问题越来越多。

   3.更新数据通过Hbase

   但是我们发现Hbase scan的效率太低，虽然有Coopressor，但是我们并没有用过。

   在这里Hbase的RowKey涉及也是大学问，可以参考openTSDB。

   4.异步化采用Kafka，存储采用Elasticsearch

   在2的基础上，我们通过Kafka生产消费实现异步化，在消费到一定长度时，ES批量存储所有的时间积累数据。

   这里有个问题，时间积累的数据，可能是同一个用户uuid发过来的，数据积累越来越大。假设App上报App已经更新的10个插件数据，500个字节，每天上报8000万次，那么每天的数据量约为0.5kb*8000w = 4M*1w=约为40Gb左右，那么假设存储一个月，40Gb*30 = 1.2Tb，一年的数据将达到14.4Tb，数据量虽然很大，但是最大的问题并不是存储，而是ES Aggregation中的多维度集合计数怎么办，ES的计数功能采用了HyperLogLog算法，节约内存，在我亲测数据量在1000万的时候查看多维度的插件升级计数还是ok的，但是上亿级别已经超时。那么怎么办？

   我们不能采用时间累积数据的方案，而是通过ES存储的时候有个唯一ID，再次插入这个唯一ID的数据将覆盖之前的数据，那么这个ID我们设计为 “插件名+用户uuid”，存储的数据就是插件的具体数据info，这样的好处是每个用户每个插件只能有一份数据，如果只用uuid做这个id值，坏处是，我们后面查找相关插件数据的个数时候，必须要从插件里过滤。

   这样的话，如果独立用户为2亿，1个插件，那只能上报2亿条数据，如果是50个字节一个插件数据，数据量是0.05kb*1w*1w =0.5kb*1000w = 5GB，固定在5Gb，如果10个插件，固定在50Gb，我们估计一个App中最多100个插件（这已经很多了），那么只需要500Gb的存储空间。

  这对ES的查询来说，压力并不大。