zoukankan      html  css  js  c++  java
  • 预告片优化方案

      看了一下代码,同时在线上做了观察压测。个人总结这个接口问题在于太过于依赖缓存,根本不会走DB。依赖缓存造成了依赖缓存的数据结构。首先要从缓存中取出一堆数据。而且要走两次,一次取正片的信息,一次取专辑内所有视频的信息。取出来的信息在CPU里计算筛选,排序。本身缓存取数据就比较快,再加上计算量大。其实我们并发量最大的api接口们都是采用这个模式设计的。调用的多了,我觉得我真是压测的狠的话,会造成CPU密集。其实现在的缓存之类的都可以持久化了,完全可以当数据库用。但是关系型数据作为一个长久的经典还有一个很重要的原因:保持一个IO和CPU使用的平衡。

      根据走索引每次穿透db按现在量也问题不大,mget本身key过多,性能下降快,导致其他服务处于等待超时。这个目前的问题和方针,将原有计算逻辑化简为几个简单的SQL:

         

    1. 中文站点,中文语言:

    SELECT * FROM con_video_info WHERE pid=专辑ID AND PLAY_PLATFORM LIKE '%,平台ID,%' AND PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY PORDER LIMIT 5;

    2. 中文站点,其他语言:

    1>SELECT ID FROM con_video_info WHERE pid=专辑ID AND PLAY_PLATFORM LIKE '%,平台ID,%' AND PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY PORDER LIMIT 5;
    2>从缓存按ID取信息

    3. 其他站点,中文语言:

    1> SELECT * FROM con_video_info as v INNER JOIN con_video_site_info as s ON v.ID=s.vid WHERE v.pid=专辑ID AND s.PLAY_PLATFORM LIKE '%,平台ID,%' AND v.PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY v.PORDER LIMIT 5;

    4. 其他站点,其他语言:

    1> SELECT ID FROM con_video_info as v INNER JOIN con_video_site_info as s ON v.ID=s.vid WHERE v.pid=专辑ID AND s.PLAY_PLATFORM LIKE '%,平台ID,%' AND v.PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY v.PORDER LIMIT 5;

    2>从缓存按ID取信息

      当然计算结果是要放到缓存中避免并发的。下面是部门两大明明可以靠颜值偏偏要靠才华的帅哥反馈:

     不论多么小一个功能,都能有人给你评价,提意见,帮助你提高。什么样的问题都会有人和你一起探讨。这样的部门你想来么?直接留言联系我哦~~

  • 相关阅读:
    最长连续子序列(dp,分而治之递归)
    判断线段是否相交
    1840: Jack Straws
    5065: 最长连续子序列
    TZOJ 4493: Remove Digits
    TZOJ 5271: 质因数的个数
    2019年天梯赛
    PTA 树的遍历
    TZOJ:3660: 家庭关系
    PTA 复数四则运算
  • 原文地址:https://www.cnblogs.com/xiexj/p/6604621.html
Copyright © 2011-2022 走看看