为什么打车和宇宙大爆炸有关

分享人:Digoal,阿里云数据库产品经理

正文:

本篇内容将从6个部分为读者介绍Ÿ打车和宇宙大爆炸有什么共同点?从打车和秒杀之间的共同点切入,分析其难点并提出解决方案。

Ÿ 为什么要讨论这个问题?

Ÿ 打车和宇宙大爆炸有什么共同点?

Ÿ 打车和秒杀是不是也有共同点?

Ÿ 秒杀的难点是什么?

Ÿ 打车的难点是什么?

Ÿ 应该如何解决?

 

话题开始之前,首先要庆祝PostgreSQL 13于2020年 9月24日正式发布,PostgreSQL 13展示了全球社区的协作和奉献精神。PostgreSQL核心团队成员Peter Eisentraut说:"每个发行版带来的创新,以及PG在可靠性和稳定性方面的声誉,是越来越多的企业选择使用PostgreSQL的原因"


一、Ÿ为什么要讨论这个问题?

互联网行业的加班文化是一个经久不衰的热门话题,夜晚11点多的阿里巴巴大厦、网易、腾讯的办公楼依旧灯火通明,加班加到深夜的互联网人还要排队打车。作为一名互联网老兵来说,下班打车这事真的很重要,累了一天还打不到车,所以今天必须讨论一下打车这个问题。


二、打车和宇宙大爆炸有什么共同点?

从技术角度来看,打车和宇宙大爆炸是有共同点的。996或007的小伙伴在半夜打车或者高峰期打车的时候,都是一群人从一个点要回到随机的外面的点,就像一次爆炸一样。宇宙大爆炸也是这个样,一个点一下子散开来,像天女散花一样。


三、打车和秒杀是不是也有共同点?

打车和秒杀就更像了,当高峰期打车的时候,附近车的数量远远少于打车人数,这时候就需要靠秒杀的速度来抢到车了。


四、秒杀的难点是什么?

用一句话来讲,秒杀的难点就是等待。如果大家都抢一个商品,那么大家都会等待其中一个人的更新,才会进行下一个更新,等待的过程就导致了堵塞。影响整体的处理吞吐。我们可以从5个角度分析:

懒人视角:秒杀时间在0点,懒人一般都要睡觉了,不管秒杀什么都没有兴趣参加。

用户视角:用户通常会抱怨网速太慢,手速太慢,货太少,关键时刻卡死。

商家视角:担心秒杀到后买家不付款,等超时后才能释放;秒杀的每一笔都是亏本生意,千万不能超卖了。

工程师视角:每卖出去一单都不能出错,每一次秒杀都不能卡。

产品视角:秒杀这个需求很简单,必须实现。


五、打车的难点是什么?

乘客视角:在打车高峰期,需要提前半小时打车,先排队这样才能确保下班的时候顺利打到车。

出租车视角:提前半小时就需要到附近蹲点,浪费了空闲时间。

平台视角:如何提高车辆利用率, 减少空闲时间。司机在送乘客的过程,是只有少量的放空,对于乘客、对于司机、对于平台都是最有利的。


六、应该如何解决?

打车过程中有没有发现几个诡异的现象?第一个就是来得早不如来得巧,有的时候我们打车或者秒杀,人家已经提前在这蹲点了,结果发现我打到车了,他没打到,秒的早不如秒的巧。有些司机距离上车地点特别远,定位也经常不准。另外就是拼车,拼车的搭档永远是同性、同路人。

这些问题如何解决呢?我还是那句话:没有MyBase解决不了的问题,如果有,就多买几台

比方说我们的秒杀场景是买家多、商品少。对于对同一个商品其实是单车道,就一个人在买的时候,其他人都在等。我们可以把它扩展成无限车道,实际上来讲是在同一个时刻产生交易,但最后交易成功的只有一个人,没有交易成功的就直接跳出页面了,这样就不会堵塞。

为什么打车和宇宙大爆炸有关

常用的秒杀优化手段是先使用for update nowait的方式来避免等待,即如果无法即刻获得锁,那么就不等待。这种方法可以减少用户的等待时间,因为无法即刻获得锁后就直接返回了。第二个是合并请求,即将多个更新合并到一个更新的请求,这种做法需要修改内核,同时会破坏ACID,因为如果合并后的请求失败了,会导致合并中的所有人的请求失败。(与分组提交不一样,分组提交是不会破坏ACID的)。

AD LOCK是一种面向用户的轻量级锁,锁的目标是一个整型,分为事务级和会话级的锁,以及共享和排他锁。因为AD LOCK很轻量化,不需要访问数据,不需要执行冗长的代码,所以很高效。使用AD LOCK不破坏ACID,单个请求单个事务,不影响其他的事务。

解决高峰打车难又是什么技术呢?利用PostGIS & 阿里云Ganos;运用GiST 时空索引模块;skip lock,消除等待;随机位置漂移 order by (lat,lon) <-> 就近找车,消除offset浪费;时空多模混合索引。

 

 

上一篇:在数据库中跑全文检索、模糊查询SQL会不会被开除


下一篇:SaaS行业需要什么样的数据库