dot Redis 8 来了——而且是开源的

了解更多

使用实时记录跟踪处理大量数据

在汇总了来自数百或数千个不同系统和位置的大量不同数据后,DigitalRoute 的 Usage Data Platform (UDP) 然后会分析并处理所有这些数据……实时处理! UDP 不仅转换数据,还过滤和转发数据,从而在公司的基础设施中创建一个智能层。 听起来令人生畏,对吧?

令人生畏的,但在大型复杂环境中跟踪客户消费正是 DigitalRoute 的 Usage Data Platform 旨在做的事情,不仅适用于电信行业的组织,也适用于公用事业、金融服务和旅游等其他行业。

我们的技术每天处理 3000 亿笔交易,其中大部分数据都是流式的。 无需多说,我们的平台确实需要速度。 行业基准要求端到端处理时间少于 500 毫秒,这很容易达到每个客户每秒数千笔交易。 更苛刻的是我们的客户,他们指望我们提供实时洞察,然后他们可以实时采取行动来改善用户体验。

使用 Redis 进行实时记录跟踪

我的应用程序开发团队最近在 DigitalRoute 的平台产品中引入了一项新的跟踪功能。 此功能跟踪任何给定记录通过客户系统的路径:它的来源、当前所在位置以及沿途对其应用的转换类型。 由于单个事务可以传播到系统的许多区域以进行细粒度关联,因此我们需要一个强大的后端,能够有效地存储此信息并将其动态呈现给请求的应用程序。 就像我们平台的其他方面一样,它需要速度快。

Chart describing DigitalRoute's trace flow from workers, to platform, to backend services

最初,我们使用在自己的“抽象执行器”之上运行的 Akka 集群作为这些通信的后端工具,但这种部署对我们来说管理起来非常痛苦,因为每次连接丢失时,我们都必须执行一系列繁琐的管理步骤来恢复集群。 在收到几个问题报告后,我们决定尝试 Redis 的发布/订阅 消息传递功能。

在发布/订阅通信模式下,发布者发布数据状态已更改(以及更改本身),而订阅者(处于持续侦听模式)会更新其内部状态作为响应。 事实证明,Redis 的发布/订阅消息代理非常易于设置且速度非常快。 我们使用它来交换跟踪消息。 由于我们的界面有很多实例,Redis 频道会监听任何给定时间点活动的 worker 报告的跟踪。 然后,使用报告的 ID,我们可以找到按正确顺序保存跟踪的排序集。 我们受益于随时订阅频道并监听任何 worker 报告的任何新跟踪的能力;无需创建单独的服务。

展望 Redis Streams

在 RedisConf18 上听到 Redis Streams 后,我做了一些研究,并相信这种新的数据结构将更适合我们的用例。 发布/订阅消息传递模式是一种“发后即忘”模式,但 Redis Streams 会持久保存数据——即使数据消费者离线或断开连接也是如此。 这种内置的数据持久性是我们跟踪功能希望提供的历史视图的完美补充。 Redis Streams 还在生产者和消费者之间创建了一个多对多的数据通道,这对我们来说非常理想,因为我们的平台最常处理来自多个来源的数据,这些数据注定要被多个消费者消费。

Redis 的帮助下,DigitalRoute 正全速前进!

了解您也可以如何在您的 应用程序中使用 Redis Streams,并在他们的 Twitter 上关注 Digital Route,了解他们的下一步计划。