淘宝大秒系统设计详解( 四 )


除去前面介绍的这些热点问题外 , 淘系还有多种其他数据热点问题:

  • 数据访问热点 , 比如Detail中对某些热点商品的访问度非常高 , 即使是Tair缓存这种Cache本身也有瓶颈问题 , 一旦请求量达到单机极限也会存在热点保护问题 。有时看起来好像很容易解决 , 比如说做好限流就行 , 但你想想一旦某个热点触发了一台机器的限流阀值 , 那么这台机器Cache的数据都将无效 , 进而间接导致Cache被击穿 , 请求落地应用层数据库出现雪崩现象 。这类问题需要与具体Cache产品结合才能有比较好的解决方案 , 这里提供一个通用的解决思路 , 就是在Cache的client端做本地Localcache , 当发现热点数据时直接Cache在client里 , 而不要请求到Cache的Server 。
  • 数据更新热点 , 更新问题除了前面介绍的热点隔离和排队处理之外 , 还有些场景 , 如对商品的lastmodifytime字段更新会非常频繁 , 在某些场景下这些多条SQL是可以合并的 , 一定时间内只执行最后一条SQL就行了 , 可以减少对数据库的update操作 。另外热点商品的自动迁移 , 理论上也可以在数据路由层来完成 , 利用前面介绍的热点实时发现自动将热点从普通库里迁移出来放到单独的热点库中 。
按照某种维度建的索引产生热点数据 , 比如实时搜索中按照商品维度关联评价数据 , 有些热点商品的评价非常多 , 导致搜索系统按照商品ID建评价数据的索引时内存已经放不下 , 交易维度关联订单信息也同样有这些问题 。这类热点数据需要做数据散列 , 再增加一个维度 , 把数据重新组织 。




推荐阅读