feat: chapter 15

Author: honkinglin

docs/grokking/chapter-15.md

@@ -172,3 +172,23 @@ DriverLocationHT 需要存储 **DriverID** 以及司机的**当前和上一位
   - **提升性能**，避免过于频繁的分区操作。
 
 ![图15-1](/grokking/f15-1.png)
+
+### “请求乘车”用例如何运作？
+
+1. 乘客发起乘车请求。  
+2. 其中一个聚合服务器（Aggregator server）接收该请求，并向四叉树（QuadTree）服务器请求附近的司机信息。  
+3. 聚合服务器收集所有结果，并按照司机评分进行排序。  
+4. 聚合服务器会同时向评分最高的前三名司机发送通知，最先接受请求的司机将被指派该订单，其余司机会收到取消请求。如果这三名司机都未响应，聚合服务器会继续向排序靠后的三名司机发起请求。  
+5. 一旦有司机接受请求，乘客将收到通知。
+
+## 5. 容错性与数据复制  
+如果 **司机位置服务器** 或 **通知服务器** 宕机，我们需要这些服务器的副本，以便在主服务器故障时，备用服务器可以接管。此外，我们可以将数据存储在 **SSD** 等高性能持久化存储中，以提供快速 I/O。这可以确保即使主服务器和备用服务器同时宕机，我们仍然可以从持久化存储中恢复数据。  
+
+## 6. 排序机制  
+**如果我们不仅想按距离排序搜索结果，还想按受欢迎程度或相关性排序，该如何处理？**    
+我们可以在数据库和四叉树（QuadTree）中维护每位司机的**整体评分**，例如，司机的评分可以用 10 分制的星级表示。在搜索给定半径内的**前 10 名司机**时，我们可以让 **四叉树的每个分区** 返回其评分最高的 10 名司机。然后，**聚合服务器** 从所有分区返回的结果中，最终选出评分最高的 10 名司机。  
+
+## 7. 高级问题  
+1. 如何处理 **网络较慢或不稳定** 的客户端？  
+2. 如果客户端在行程中 **断开连接**，如何处理 **计费**？  
+3. 如果客户端**主动拉取信息**，而不是服务器**主动推送**，系统该如何设计？