其实互联网的高并发架构解决方案很多，而且大多都存在很多共同的地方，我们常常用秒杀来作为高并发设计的案例，因为秒杀的单点时间内的请求量是非常高的。如果我们把场景换成滴滴打车的话，其实也有很多共通的部分。

现在我们就来简单的分析一下滴滴打车的架构可能是怎么设计的吧我们先看看一个打车的场景，都会经过多少流程吧。

当我们需要打车的时候，我们打开APP，选择自己想要的车辆类型，然后发起请求。这时我们的请求进入到应用服务器，应用服务器进行处理以后，按照一定的算法，找到最近的空闲的车辆，然后指派车辆，如果没有找到合适的车辆，就会进入等待状态。当找到合适的车辆时，将我们的所在地推送给司机，然后把司机的相关数据返回给我们的APP。

那么，在这个过程中，就会遇到几个问题，如果打车的人太多怎么办？如果同时存在的车辆非常多，怎么来找到合适的车？

1. 我们先来解决打车的人多的问题

当打车的人非常多的时候，例如：早晚高峰，这时我们要保证每个用户的打车请求都要接收，并且顺序的执行。这里，我们就需要用到队列和缓存，队列用来保证消息的安全和顺序执行，缓存用来缓解用户请求对于服务器的压力并给用户展示结果。

当用户向滴滴发起一个打车请求的时候，我们先生成一个订单号，然后就把这个请求丢到队列中去并把订单号结果返回给用户，并从缓存中取出当前的等待人数返回给用户。

这时，用户的这个请求并不会直接的接触到数据库，订单其实是在队列里，可能1-2秒钟以后才创建的，但是没关系，用户并不知道，用户已经以为自己早就开始等待了。当队列执行成功后，订单创建了，一个算法程序就开始进行车辆的匹配。

按照先进先出的规则，一个一个的匹配，并且根据结果，刷新缓存中的数据。而这时，对于等待的用户来说，只是不停的通过APP去读缓存数据而已。当用户的订单被匹配到以后，我们才真正的把用户需要的司机数据推送给用户，然后把用户数据推送给司机。

2. 那么怎么来找到合适的车呢？

要知道，全国的范围那么大，车辆那么多，而且很多车辆的实时数据在不停的刷新，怎么保证系统能够很快的计算出哪辆车才是里乘客最近而且可以使用的车辆呢？

如果我们实时的去拿全国的所有车辆经纬度来计算，估计滴滴平台早就挂了。那么怎么来设计架构，我们才能够更快找到合适的车呢？我们可以把地理信息划分成为很多很多的正方形，例如：2公里*2公里。

然后对每个正方形方块都进行命名，例如：10012001。然后，我们每5秒钟去同步一下车辆的地利信息数据，更新到对应的方块数据中，并且这些都放在缓存之中。这样，我们就可以知道哪些方块中有哪些车辆。

然后，当用户发起请求的时候，我们也按照地利信息数据，把客户划分到方块中，当这个方块中有车辆的时候，就分配给用户。如果车辆很多的时候，我们再来计算距离或者随机分配都可以。无论怎么分，反正距离都不会超出方块。

如果方块内没有车辆信息，我们也可以很快的告诉用户，对不起，你需要等。

这样，就减少了实时计算的时间，系统的响应速度提高了，并发能力自然也就更高了。

当然，滴滴这么庞大的系统，里面还有很多的分库分表的规则，这都会和他的业务相挂钩。由于我也没有去做过滴滴的系统，所以也只能猜测。如果要继续深入，那东西就太多了，还涉及到很多的线路算法，这里就只有到此为止了。