分享人：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浪费；时空多模混合索引。
