携程实时用户行为服务作为基础服务，目前普遍应用在多个场景中，比如猜你喜欢（携程的推荐系统）、动态广告、用户画像、浏览历史等等。
以猜你喜欢为例，猜你喜欢为应用内用户提供潜在选项，提高成交效率。旅行是一项综合性的需求，用户往往需要不止一个产品。作为一站式的旅游服务平台，跨业务线的推荐，特别是实时推荐，能实际满足用户的需求，因此在上游提供打通各业务线之间的用户行为数据有很大的必要性。
携程原有的实时用户行为系统存在一些问题，包括：1）数据覆盖不全；2）数据输出没有统一格式，对众多使用方提高了接入成本；3）日志处理模块是web service，比较难支持多种数据处理策略和实现方便扩容应对流量洪峰的需求等。
而近几年旅游市场高速增长，数据量越来越大，并且会持续快速增长。有越来越多的使用需求，对系统的实时性，稳定性也提出了更高的要求。总的来说，当前需求对系统的实时性/可用性/性能/扩展性方面都有很高的要求。
一、架构
这样的背景下，我们按照如下结构重新设计了系统：
图1：实时用户行为系统逻辑视图
新的架构下，数据有两种流向，分别是处理流和输出流。
在处理流，行为日志会从客户端（App/Online/H5）上传到服务端的Collector Service。Collector Service将消息发送到分布式队列。数据处理模块由流计算框架完成，从分布式队列读出数据，处理之后把数据写入数据层，由分布式缓存和数据库集群组成。
输出流相对简单，Web Service的后台会从数据层拉取数据，并输出给调用方，有的是内部服务调用，比如推荐系统，也有的是输出到前台，比如浏览历史。系统实现采用的是Java+Kafka+Storm+Redis+MySQL+Tomcat+Spring的技术栈。
Java：目前公司内部Java化的氛围比较浓厚，并且Java有比较成熟的大数据组件 Kafka/Storm：Kafka作为分布式消息队列已经在公司有比较成熟的应用，流计算框架Storm也已经落地，并且有比较好的运维支持环境。 Redis： Redis的HA，SortedSet和过期等特性比较好地满足了系统的需求。 MySQL: 作为基础系统，稳定性和性能也是系统的两大指标，对比NoSQL的主要选项，比如HBase和ElasticSearch，十亿数据级别上MySQL在这两方面有更好的表现，并且经过设计能够有不错的水平扩展能力。
目前系统每天处理20亿左右的数据量，数据从上线到可用的时间在300毫秒左右。查询服务每天服务8000万左右的请求，平均延迟在6毫秒左右。下面从实时性/可用性/性能/部署几个维度来说明系统的设计。
二、实时性
作为一个实时系统，实时性是首要指标。线上系统面对着各种异常情况。例如如下几种情况：
突发流量洪峰，怎么应对； 出现失败数据或故障模块，如何保证失败数据重试并同时保证新数据的处理； 环境问题或bug导致数据积压，如何快速消解； 程序bug，旧数据需要重新处理，如何快速处理同时保证新数据；
系统从设计之初就考虑了上述情况。
首先是用storm解决了突发流量洪峰的问题。storm具有如下特性：
图2：Storm特性
作为一个流计算框架，和早期大数据处理的批处理框架有明显区别。批处理框架是执行完一次任务就结束运行，而流处理框架则持续运行，理论上永不停止，并且处理粒度是消息级别，因此只要系统的计算能力足够，就能保证每条消息都能第一时间被发现并处理。
对当前系统来说，通过storm处理框架，消息能在进入kafka之后毫秒级别被处理。此外，storm具有强大的scale out能力。只要通过后台修改worker数量参数，并重启topology（storm的任务名称），可以马上扩展计算能力，方便应对突发的流量洪峰。
对消息的处理storm支持多种数据保证策略，at least>
图3：Storm架构
在部分情况下数据处理需要重试，比如数据库连接超时，或者无法连接。连接超时可能马上重试就能恢复，但是无法连接一般需要更长时间等待网络或数据库的恢复，这种情况下处理程序不能一直等待，否则会造成数据延迟。实时用户行为系统采用了双队列的设计来解决这个问题。