最近重新阅读了《Designing Data-Intensi - 沸点

技术副总监 @金山办公

最近重新阅读了《Designing Data-Intensive Applications》, 突然想到了微博热搜连续挂机问题, 整理了一些肤浅的想法.

我们回顾微博热搜的挂机事件, 从分区模型来考虑, 如果微博搜索用的是类似ElasticSearch的模型, 那么会是一个固定数量分区方案. 在再平衡过程中(即扩容过程), 首先要增加节点, 然后移动分区. 在分区移动完毕之前, 系统仍然会面临高压力的情况. 尤其是系统特别庞大的情况下, 移动分区很可能在热点事件热度消散后, 分区仍然没有全部移动完毕. 因此分区的粒度决定了集群压力下降曲线的平滑程度和延时. 精确的分区大小, 分区迁移速度和降级策略将会是保证服务可用性的关键.

而数据的分区形式和二级索引的分区形式也会直接影响集群扩容的迅捷程度. 热搜数据注定会是一个头部巨大而尾部特别长的模型. 导致热搜挂掉也是头部数据. 因此为了降低系统查询延时(这将直接影响QPS和CPU占用, 最终影响服务质量). 头部数据的分区形式肯定是基于关键字的hash分区. 由此造成损失范围查询特性是可以接受的. 头部数据应该尽可能分布在多个节点上以提升性能, 并且头部数据应尽可能内聚, 减少跨节点查询. 二级索引也是同样的道理, 应尽可能在单节点完成全部查询以提升性能. 为此Build二级索引可能还需要跨区事务. 这进一步加剧了实现的复杂程度.

整个微博热搜系统实现的复杂度是由于头部热点数据的体积和访问量异常庞大导致的. 而社交网络消息传递的速度则在时间维度上提出了新的挑战, 二级索引虽然是异步的, 但也要快! 不然大家热搜看不到事态的新进展, 慢慢兴趣就丧失掉了. 所以, 这个系统比看上去要难实现太多了.

展开

赞过