跳表能否代替 B+ 树？为什么？ 答案是不能，原因就是因为跳表的不同层高节点的数量是随机的，也就是说在最坏的情况下一个查询的时间复杂度会退化成O(n),而b+树的查询时间复杂度却是很稳定的O(logmn),同时跳表高度的随机化也会导致在海量数据的情况下磁盘IO的次数要比b+树多。所以应用是磁盘-based 或需要高效范围查询的话，B+ 树更合适。 为什么 Redis 的有序集合不使用 B+ 树，而选择跳表？ 主要原因就是因为跳表的实现简单，代码易于理解和维护，没有了b+树随机插入一个节点的时候会出现的页分裂的问题 现有 1000 万条 URL，内存限制为 10 MB，如何对这些 URL 进行排序？ 先进性分块，然后对块中url进行排序，最后我们在内存中维护一个最小堆，然后遍历一次所有的分块push所有分块的最小元素，遍历完成后再pop堆顶元素到一个新的磁盘分块中，同时从被弹出URL所在的文件块读取下一条URL，保证堆的大小一直≤分块的数量。 现有 1000 万库存，要求设计一个支持 20 万 QPS 的秒杀系统，仅考虑减库存环节，如何实现？ 首先就是我们可以明确的知道数据库是支持不了这么高的QPS的，所以我们可以引入消息队列起到一个削峰的作用。同时还需要考虑消费函数的幂等性处理，我们可以给每一个商品的库存绑定一个当前版本号，然后生产者在生产扣减库存的操作的时候添加一个递增的操作版本号，这样我们在执行消费函数的时候需要比较当前版本号是不是大于数据库中的版本号，如果大于才执行扣减库存的操作。 当然还可以使用redis做一个预扣减库存的操作，库存预扣减成功后，并不会同步操作数据库生成订单。而是立即返回用户“抢购中”状态，同时将订单信息发送到消息队列