uber的紧急按钮的第一个版本于 2015 年在印度推出。原始系统允许乘客和司机在留在应用程序内的同时联系当地警察当局，并自动提醒区域支持团队主动联系用户。2018 年，该团队利用增强功能改进系统，例如在应用程序中显示实时位置信息、与当局共享旅行详细信息以及制作紧急按钮可在全球市场的 Rider 和 Driver 应用程序上使用。从那时起，该团队通过引入用户可以谨慎地向当地警察发送短信而不是仅呼叫选项的功能，在特定市场进行了额外的改进。此外，在特定市场，我们推出了交互式语音响应解决方案，为我们的用户提供后续服务。
点击紧急援助功能后，您将看到您的 GPS 位置、汽车品牌和型号以及车牌。如果您刷卡拨打 911并连接到紧急调度员，这些行程详细信息将在美国和墨西哥的许多城市以数字方式提供给他们，并可用于促进紧急响应。优步的支持团队将跟进办理登机手续，以确保您的安全。
在紧急情况下，几秒钟都很重要。重要的是要确保人们在正确的时间拥有正确的信息（实时位置和行程信息），这样他们就能迅速与当局分享。如果出行信息和实时位置能自动与当局如911中心共享，那将更有帮助。
RapidSOS 集成和持续位置共享
团队与第三方RapidSOS合作，后者将数百万连接设备的潜在救生数据直接提供给 911 和紧急情况下的第一响应者。
紧急按钮与RapidSOS 的紧急 API集成，并向 911 急救人员提供行程信息（汽车品牌、型号、车牌和请求者姓名）和实时位置更新。
当有人点击应用程序中的紧急按钮时，移动客户端通过网关代理向紧急事件后台服务发出请求。然后，紧急服务将行程数据传递给RapidSOS的API。同时，移动客户端上的位置工作者每隔几秒钟就会收集并上传位置数据到位置服务。这些实时位置更新通过Kafka流向紧急服务。Emergency Service不断向RapidSOS的Location API发出HTTP请求，以提供实时位置数据。我们非常重视用户的隐私，所以系统严格尊重用户的许可，与RapidSOS和当局等第三方分享行程和位置信息。
这个来自华盛顿特区的NBC片段强调了这种整合如何帮助解决现实世界中的紧急事件。目前，RapidSOS的整合在大约1200个市场中可用，覆盖了美国74%以上的行程，以及墨西哥的几个城市。该团队正在继续努力将这一功能扩展到美国和全球越来越多的地区。
使用 Apache Kafka 进行可靠的再处理和 DLQ
警报通道采用技术堆栈实现，强调冗余和弹性。Uber的Kafka团队在Apache Kafka之上开发了内部的Kafka APIs，Uber的内部服务可以与之整合，以产生和消费Kafka事件。Kafka APIs提供了一个至少一次的交付保证：一个Kafka事件至少会被交付给它的消费者一次--换句话说，没有数据损失。另外，消费者可以为Kafka主题启用DLQ（死信队列）功能。
内部的Kafka APIs很适合增强应急服务的可靠性，以实现可靠的处理。对于每个警报通道，应急服务通过Kafka APIs向特定的Kafka主题生产和消费。对下游依赖的RPC在消费者处理程序中处理，紧急服务将向Kafka API返回ACK（成功）或NACK（失败）。对于紧急服务的服务器错误或互联网故障返回的任何类型的可重试错误，对Kafka服务器来说都会转化为NACK。Kafka服务器将继续重新处理该事件，进行配置的重试次数。如果在所有重试之后，Kafka事件仍然不能被成功处理，事件将被推送到DLQ中。存储在DLQ中的消息如果是坏消息可以被清除，或者在系统恢复后被合并（由消费者重新处理）。
一次性传递和DLQ机制有助于应急服务的容错性，没有数据损失，并且能够在恢复期间快速重新处理。
冗余是关键
任何系统都有可能出现一些意想不到的错误，紧急服务为每一个RPC或消息传递（Kafka）建立了多层冗余和备份，以便在处理紧急请求时尽最大努力。
每个RPC都是通过重试来实现的，重试的结果是指数级的。在Kafka APIs不可用的情况下，紧急服务会回落到对下游的RPC调用，并有一定数量的重试作为优雅的降级。
详细点击标题