feat: chapter 13

Author: honkinglin

docs/grokking/chapter-13.md

@@ -207,3 +207,21 @@ Struct {
 
 **是否始终通知用户有新动态？**  
 **桌面端** 可以开启通知，而 **移动端** 由于流量成本较高，可以采用 **“下拉刷新”（Pull to Refresh）** 机制，让用户主动获取新动态，减少不必要的流量消耗。
+
+## 8. 动态排名  
+
+最简单的动态排序方式是按照帖子创建时间排序，但如今的排名算法远不止于此，它们会确保“重要”的帖子排名更靠前。排名的核心思路是先选取能衡量帖子重要性的关键“信号”，然后找出合适的方法将这些信号结合起来计算最终的排名分数。  
+
+具体而言，我们可以选取与帖子重要性相关的特征，例如点赞数、评论数、分享次数、更新时间、是否包含图片/视频等，并基于这些特征计算评分。对于一个简单的排名系统来说，这通常已经足够。但更高级的排名系统会通过持续评估用户粘性、留存率、广告收入等指标，来不断优化自身的排序效果。  
+
+## 9. 数据分区  
+
+**a. 文章及元数据分片**  
+
+由于每天都会产生大量新帖子，并且读取负载极高，我们需要将数据分布到多个机器上，以实现高效的读写操作。对于存储帖子及其元数据的数据库，我们可以采用与**Twitter 设计**部分讨论的类似分片方案。  
+
+**b. 动态数据分片**  
+
+对于存储在内存中的动态数据，我们可以按照**用户 ID** 进行分区。我们可以尝试将某个用户的所有数据存储在同一台服务器上。在存储时，我们可以将**用户 ID** 传递给哈希函数，使其映射到特定的缓存服务器，并在该服务器上存储该用户的动态对象。此外，由于对于任何用户来说，我们通常不会存储超过 **500 条动态 ID**，因此不会出现单台服务器无法容纳该用户动态数据的情况。因此，获取某个用户的动态时，我们始终只需查询一台服务器。  
+
+为了支持未来的扩展和数据复制，我们必须使用**一致性哈希（Consistent Hashing）**。