设计背景中的 LLD 数据结构: 为什么有些问题需要“ 最佳” 结果而不是任何结果

"迅速找到东西,迅速找到最好的东西是两个完全不同的工程问题". 到目前为止,我们探索了软件系统中最常见的行为之一: 快速检查。 当一个系统已经知道它在找什么——一个用户ID、产品ID、命令ID或会话ID——一个HashMap就成了一个很好的选择。 但并不是每个软件问题都这样工作。 想象一下你正在构建一个共享的应用程序。 骑手要求出租车 系统已经不知道要分派哪个驱动程序. 相反,它必须回答另一个问题:“在所有可用的驱动器中,谁是最好的选择?” 现在考虑一个任务调度员。 数以百计的工作在等待着运行。 排行者不问:"找到工作#123". 它问:"下一步该做什么工作?" 或者想象一个游戏平台。 上千名球员在竞争. 没有人问:"寻找玩家编号1057". 取而代之的是,用户问道:"谁是前十名的玩家? 这些问题与快看根本不同. 他们不是要找到一个特定的物体。 它们是根据某种优先性找到最佳对象. 思想的这种转变引入了另一种重要的设计行为. Fast Lookup vs Best Choice 让我们来比较两个不同的要求. 所需经费1 该系统已经知道它需要什么。 挑战在于如何有效地收回它。 所需经费2 系统还不知道答案 在作出决定之前,必须比较多个候选人。 这两种行为可能看起来相似。 在现实中,他们解决了完全不同的工程问题. 每个软件系统不搜索同样的方法 考虑这些问题。 对曰:相也. 第一个问题总是提供一个识别符。 第二个问题需要比较。 这种区别改变了一切。 理解优先权 我们想象一下医院的急诊室 五个病人到了。 如果患者被简单地按照他们到达的顺序进行治疗,结果可能是这样的. 技术