标签：hive 无法 dfs 定位 search cart 服务器 cront 数据可视化
唯品会每年最大力度的促销活动在4月19日，就是419（For One Night），意在告诉唯品会用户只有这一晚有这么大的折扣力度（本文中用“大促”就指代419） 。唯品会是一个闪购网站，用户来得越早，越能买到又便宜又好的东西，所以在大促的一开始，会涌入大量用户，形成系统流量峰值。
本文总结了唯品会419时日志平台遇到的问题和解决方案，同时根据实践经验，整理了在面对峰值前要做的准备。
唯品会的日志平台，包括消息中间件、计算和数据可视化。前两者和峰值系统相关度更大一些。在2013年419时，我们使用Flume来收集日志，RabbitMQ作为传输日志的消息中间件，用Storm和Redis进行计算，然后通过脚本将Redis的数据写入MySQL，前端从MySQL中获取数据做数据可视化。
实际上，计算Nginx日志非常简单，就是分割和计算。将一条Nginx日志分割后，就能知道这次访问的状态码是什么，响应时间是多少。然后DB中会有不同的key，如domain是cart，那么cart域的响应时间在Redis DB里的key就是cart_resp_time，访问量就是cart_count，2xx数量就是cart_2xx_count。根据从日志获取的值，我们会使用Redis的incrby来操作（incrby和incr类似，incr是value加1，incrby可以指定增加的数字）。然后在计算metrics时，脚本先获取当前的cart_count，然后sleep 1秒，再获取一次cart_count，这两个的差值是这1秒钟内cart域的访问量。同样的方法，可以获取这1秒的响应时间，与访问量相除，就可以计算出这1秒的平均响应时间。
介绍完计算逻辑，可以了解到，Storm的处理逻辑非常简单，主要工作就是“分割日志”和“操作Redis计数”。
为了判断到底是RabbitMQ慢还是Storm慢，我们先将Storm停了，然后用一个Python脚本向Queue发送数据和消费Queue里的数据，这样来减小Producer和Consumer性能对RabbitMQ的性能影响。这样测试后发现，每台RabbitMQ的吞吐大概是1w条数据每秒，而且负载很高。后来，我们使用Erlang的HiPE特性（即High Performance Erlang），将性能提升20%，大概达到1.2w条数据每秒。但仍然不能满足我们的要求。我们要求达到15w msg/s，加上25%的冗余，此时需要15×(1+25%)/1.2≈16台服务器，比较多。再考虑到唯品会正处于快速增长期，目前是15w msg/s，很有可能明年就翻几番。使用RabbitMQ似乎不太符合我们的需求，因为在可预见的将来，需要大量服务器来支撑。此外，RabbitMQ对服务器的CPU消耗非常大。
RabbitMQ的消费者除了Storm外，还有Elastic-Search（ES）。使用ES来做日志的全文检索，包括Nginx日志和PHP错误日志，因为Nginx日志的计算只能帮助运维人员和开发人员定位到某个域出问题，再深入地分析，就要从出错时的日志入手了。我们的日志还会有一份全量流入HDFS，原本用日志的搜索直接从HDFS来获取，但发现用Hive查询速度非常慢，大约需要几分钟。ES是基于Solr的一个全文检索引擎，有一个很好用的前端Kibana。在这次大促中，由于前端的RabbitMQ挂了，所以ES没有受到很大的压力。
标签：hive 无法 dfs 定位 search cart 服务器 cront 数据可视化
原文地址：https://www.cnblogs.com/wjwjs/p/11053788.html
