《唯品会峰值系统架构演变 》
Posted wjwjs
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《唯品会峰值系统架构演变 》相关的知识,希望对你有一定的参考价值。
唯品会每年最大力度的促销活动在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没有受到很大的压力。
以上是关于《唯品会峰值系统架构演变 》的主要内容,如果未能解决你的问题,请参考以下文章
Redis中国用户组|唯品会Redis cluster大规模生产实践