Uber支持复杂逻辑和防拒载算法的讨论
发布于 9 年前 作者 Antoni1883 6950 次浏览 最后一次编辑是 8 年前 来自 问答

近来新在大陆推出的Uber pool给滴滴用车造成很大的市场冲击。另外防拒载算法简单来说就是在Uber司机接单的时候不让看乘客的目的地,在乘客上车的时候输入目的地即可。想知道这个过程与滴滴打车的招车过程相比有什么不同?

14 回复

防拒载根本不存在算法……

@ravenwang 正式的叫“自动匹配算法”(对乘客来说咱们就不妨叫更通俗的防拒载算法吧):

自动匹配就是说他会找到离乘客最近的司机,然后把单派给最近的司机。专车市场还有易到用车,易到用车是周围有好几辆车,车型司机都不同,你看你自己喜欢哪个,但是他们不一定是距离乘客最近的那一辆。

所以Uber主要是以提高了打车的效率。

再打一个不恰当比方,这有点像做沐足和做桑拿。桑拿是不一样的,我们都来自己选择自己长相姣好的技师,根据自己的趣味性来满足个性化,而沐足的时候,一般有一个技术师就够了,所以这两个是不同的玩法,就像是Uber和易到用车的区别。

标题党,我是来学习算法的。可你却给我说上车录入目的地,我书读的少,什么叫算法。

@haozxuan Uber新的调度系统主要有两个服务:供应司机和乘客招车需求,这些服务会跟踪供应和需求所有的能力和状态机。例如,供应服务会知道一个车辆有几个座位适合乘坐或是否容纳残疾轮椅。调度系统也第三个服务,称为Disco(调度优化),其主要功能是匹配供应和需求,Disco会让Uber展望未来,比如,老的调度系统只看到目前的供应量,因为大部分车辆都很忙,这个新的优化能够让Uber维持一个全局指数,新系统更有效率,也需要更多数据,Uber希望新系统能够处理每秒1百万写操作和更高的读操作,因此需要shard分片数据。

为了完成这种扩展,Uber使用Google的S2 Geometry Library,S2能够将球体分为小区cell,每个小区有一个id,地球大致是一个球形。S2有两个重要特性:它能够定义每个cell的分辨率,它能发现需要覆盖区域的cell。Uber使用3,31平方公里的cell来分片其数据。所有这些让Uber降低乘客等待时间,司机的额外驾驶以及到达乘客招车点的时间(ETA),当一个乘客使用Uber会发生什么?Uber会使用乘客的当时地理位置和S2的面积覆盖函数来寻找其周围适配的司机,Uber然后选择更短的ETA, Uber寻找的不仅是可搭载乘客的司机,而且还包括那些正在行驶到目标地可搭顺路车的司机。

传送门

@Antoni1883 我已经报警了。。。。

Uber Pool不仅能形成车主与乘客之间的拼车合乘,更可以使多位乘客拼车合乘,共享重合路程,共同承担车费。如果说人民优步是“车主+乘客”的拼车行为,那么Uber Pool就是“车主+乘客1+乘客2”之间的拼车行为,一辆汽车在同一段里程中可能装载多名乘客。

乘坐Uber Pool,乘客只需要选择App中的Uber Pool按钮,输入自己的上车地点和目的地,一键呼叫司机便可成功上车。司机接载乘客后,可能会在行驶过程中接到另一个乘客的拼车订单,系统会根据两位乘客的行程安排计算最优化的路径,显示在司机的导航系统中,司机可依据导航接载第二位乘客,分别将两位乘客送到目的地,完成整个行程。这款新产品于2014年4月5日在美国旧金山发布并开始内测,目前已在旧金山、洛杉矶、纽约、巴黎、奥斯丁等五个城市运营。

Uber还声称自己的UberPool具有很高的技术壁垒,言外之意就是说,滴滴啊,你们不行。Uber在内部资料里分析称,Uber Pool首先需要确保乘客的体验,这是一切的关键。在保证乘客拥有和独自乘坐Uber一样流畅、可靠体验的同时,系统需要实时计算拼车的可能路线,完成乘客间拼车的匹配。也就是说,乘客可以像呼叫人民优步一样随时发起拼车,无需预约,无需等待系统匹配即可上车,同行拼车乘客的匹配是动态进行的,是与目前乘客所在的位置及其目的地进行实时计算的。在旧金山,Uber Pool的系统匹配成功率高达90%,已经能够保证在乘客每次行程只比单独乘车多花出几分钟的基础上,让每位乘客享受到Uber X一半价格的便捷出行。

TSP需要计算密集型整数线性规划技术方能找出解决方案。由于问题存在太多的排列可能,需要开发出复杂的启发式逼近法才能精确解决。而为Uber Pool开发算法要比简单的TSP问题还要复杂一点,因为“旅行商不止一位”、目的地是动态的、不断有新的“旅行商”进入和离开系统、车的载客量有限、不断有新的打车需求流入。

不知道诸位小伙伴对于Uber的这款新产品的核心算法怎么看?

原来Uber服务端用的是NodeJS? 高并发

@pangguoming 2014年以前是,滴滴打车也是用的NodeJS。高并发已经不再是亮点。

但是现在Uber使用更高级的技术平台已经完全超越了仍在使用 NodeJS的滴滴用车软件系统平台。

简单来说就是Uber新后台服务器系统软件已经开始支持复杂动态商业逻辑,滴滴的服务器后台系统还只停留在对数据简单操作和网络中转的低级层面。

那滴滴打车想必是NodeJS做的 REST API服务吧,他们用的 Express 还是Restify ? 你知道不?

@pangguoming 选Express 还是Restify区别真心不大。

滴滴打车完全靠Memcach来转发数据的方式也太TM简陋了点。

除了用Redis 、Memcach 等高速缓存 来查询转发实时信息,这个应该是常规解决方案,Uber是怎么做的?

Uber使用的是黑科技,世界上很多人包括我都在好奇中。

当你打开Uber,看到屏幕上有像蟑螂一样的小Uber车,在你的位置附近扭来扭去,会不会以为棒棒哒~附近又有好多车? b8014a90f603738d4d012524b51bb051f819ec69.jpg 然而最近,有两名研究猿跳出来说,Uber的这些小黑车都是骗人的。

大家怎么从纯技术角度来看这个问题呢?滴滴到目前为止好像还做不到这么高大上的算法吧,就是无法给乘客看到周围的实时车况。

回到顶部