地理位置信息系统(uber)的一些问题

系统设计
1
  1. 监控警报availability监控的具体是什么，怎么监控一个server的availability？
  2. 关于怎么保证一个司机不会被同时assign给两个乘客感觉没有特别清楚，是不是driver table里面也要记录driver的status来保证，这样的话就要求driver table的consistency
1 个赞
2
  1. 比如可以检测一个服务器处理的 Request 量是不是正常；看用户访问的延迟；根据服务器发出的 heartbeat 看服务器是否宕机。
  2. 在完成匹配后，需要使用硬盘中的数据库来存储司机和乘客的对应状态，需要较高的 consistency。防止给一个乘客分配多个司机，或者给一个司机分配多个乘客。
3
  1. yelp里面关于geo hash不规则的划分shard，那你找某一个geohash数据的时候需要找到分片的机器的算法岂不是很复杂？
4

不规则的划分确实就导致在寻找分片的时候需要多做一层 lookup，需要 cluster 提供一个 lookup 的 config。

1 个赞
5

我也有关于availability的相同疑惑。

  1. 比如可以检测一个服务器处理的 Request 量是不是正常；看用户访问的延迟；根据服务器发出的 heartbeat 看服务器是否宕机。

看用户访问的延迟这件事情是不是需要mobile client传数据回到backend才能实现？
“根据服务器发出的heartbeat看服务器是否宕机” 是不是需要用到一个单独的metrics service来监控这个matching service的状态？

6

这一点在咱们uber的设计方案中是不是因为BigTable可以保证row-level atomic operation所以能保证trip Table的consistency? 因此解决了一个司机不会匹配给不同乘客的问题？

7

用户访问延迟一般就看 server 处理这个 request 用的时间就可以了，如果要考虑 network latency 才需要从 mobile 传过来。
监控一系列服务器的状态需要单独的 monitoring system，不仅仅是一个 service 还需要一个收集数据的系统，我们有一节专门 monitoring system 的课会讲这个话题。

8

课上讲的 BigTable 是用在使用来存储 Trip 信息的，没办法从司机来 lookup 乘客，所以还是需要一个额外的 High Consistency 的数据库（课上没有特别提到）来解决这个问题，可以考虑用一个 SQL DB 来做。