干货 ：携程实时用户行为系统实践

正文

请到「今天看啥」查看全文

：目前公司内部Java化的氛围比较浓厚，并且Java有比较成熟的大数据组件

Kafka/Storm ：Kafka作为分布式消息队列已经在公司有比较成熟的应用，流计算框架Storm也已经落地，并且有比较好的运维支持环境。

Redis ： Redis的HA，SortedSet和过期等特性比较好地满足了系统的需求。

MySQL: 作为基础系统，稳定性和性能也是系统的两大指标，对比nosql的主要选项，比如hbase和elasticsearch，十亿数据级别上mysql在这两方面有更好的表现，并且经过设计能够有不错的水平扩展能力。

目前系统每天处理20亿左右的数据量，数据从上线到可用的时间在300毫秒左右。查询服务每天服务8000万左右的请求，平均延迟在6毫秒左右。下面从实时性/可用性/性能/部署几个维度来说明系统的设计。

二、实时性

作为一个实时系统，实时性是首要指标。线上系统面对着各种异常情况。例如如下几种情况：

1. 突发流量洪峰，怎么应对；

2. 出现失败数据或故障模块，如何保证失败数据重试并同时保证新数据的处理；

3. 环境问题或bug导致数据积压，如何快速消解；

4. 程序bug，旧数据需要重新处理，如何快速处理同时保证新数据；

系统从设计之初就考虑了上述情况。

首先是用storm解决了突发流量洪峰的问题。storm具有如下特性：

图2：Storm特性

作为一个流计算框架，和早期大数据处理的批处理框架有明显区别。批处理框架是执行完一次任务就结束运行，而流处理框架则持续运行，理论上永不停止，并且处理粒度是消息级别，因此只要系统的计算能力足够，就能保证每条消息都能第一时间被发现并处理。

对当前系统来说，通过storm处理框架，消息能在进入kafka之后毫秒级别被处理。此外，storm具有强大的scale out能力。只要通过后台修改worker数量参数，并重启topology（storm的任务名称），可以马上扩展计算能力，方便应对突发的流量洪峰。

对消息的处理storm支持多种数据保证策略，at least once，at most once，exactly once。对实时用户行为来说，首先是保证数据尽可能少丢失，另外要支持包括重试和降级的多种数据处理策略，并不能发挥exactly once的优势，反而会因为事务支持降低性能，所以实时用户行为系统采用的atleast once的策略。这种策略下消息可能会重发，所以程序处理实现了幂等支持。

storm

请到「今天看啥」查看全文