feat: chapter 8

docs/grokking/chapter-8.md

@@ -143,7 +143,7 @@ streamVideo(api_dev_key, video_id, offset, codec, resolution)
 该服务以读操作为主，因此我们将专注于构建一个能够快速检索视频的系统。预计读写比为200:1，这意味着每上传一个视频，会有200次视频观看。  
 
 **视频存储在哪里？**  
-视频可以存储在分布式文件存储系统中，例如 HDFS 或 GlusterFS。  
+视频可以存储在分布式文件存储系统中，例如 [HDFS](https://en.wikipedia.org/wiki/Apache_Hadoop#HDFS) 或 [GlusterFS](https://en.wikipedia.org/wiki/Gluster#GlusterFS)。  
 
 **如何高效管理读流量？**  
 需要将读流量与写流量分离。由于每个视频会有多份副本，可以将读流量分布到不同的服务器上。对于元数据，可以使用主从配置，写操作会首先写入主节点，然后同步到所有从节点。这种配置可能导致数据短暂的不一致，例如，当新增视频时，其元数据会先插入主节点，在同步到从节点之前，从节点无法看到该数据，因此会向用户返回过时结果。然而，这种不一致性是可以接受的，因为它持续时间很短，用户将在几毫秒后看到新视频。  
@@ -155,7 +155,7 @@ streamVideo(api_dev_key, video_id, offset, codec, resolution)
 
 如果将所有缩略图存储在磁盘上，由于文件数量庞大，读取这些文件需要频繁进行磁盘寻道操作，这是非常低效的，会导致更高的延迟。  
 
-Bigtable 是一个合理的选择，因为它将多个文件合并为一个块存储在磁盘上，在读取少量数据时非常高效。这两个特点正好满足我们的服务需求。将热门缩略图缓存起来也能帮助减少延迟。由于缩略图文件体积较小，可以轻松在内存中缓存大量此类文件。  
+[Bigtable](https://en.wikipedia.org/wiki/Bigtable) 是一个合理的选择，因为它将多个文件合并为一个块存储在磁盘上，在读取少量数据时非常高效。这两个特点正好满足我们的服务需求。将热门缩略图缓存起来也能帮助减少延迟。由于缩略图文件体积较小，可以轻松在内存中缓存大量此类文件。  
 
 **视频上传**：由于视频可能非常大，如果上传过程中连接中断，系统应支持从断点继续上传。