浅谈名人业务的优化

前一段时间做了写关于名人的优化，主要解决的问题:

系统加载时数据load非常慢，系统重启后到前台页面展现最少也要1分钟，旧的service比这种情况更严重。

以我的性格，我不愿意让出自己手下的代码如此低效并且丑陋的完成功能，于是乎便向组织提交了关于名人业务优化的申请没想到灰常顺利批准我做了。

下面就开始了我优化的流程：

寻找为什么慢：

1.数据库的拉去名人等级竟然用了字符串匹模糊匹配去拉取每个分类，并且这种拉取是单线程的，即顺序拉取

2.拉取完数据还不够，底层接口不给力只能以固定的数量的批量调用拉取用户最后发言。

3.拉取到了给定数量的人的发言，还要根据产品策略进行过滤、排序，由于存在过滤策略，所以本来不给力的接口，所以说就做很多无用的调用，费事又不讨好！

 

方案1：

首先将名人的等级字符串映射为一个数字。数据库Load数据出来，先不过滤也不拉接口排序、直接吐给前台，然后后台异步线程拉接口或得发言时间，排序过滤。最终完成排序过滤。

缺点：数据刚开始Load后就给的名人的数据完全是不正确的，只能等到所有的拉接口过滤排序完成后才可以给用户最优的体验，其次没有从根本上解决无效地拉接口耗时。

方案2：

在一个后台应用中拉取接口更新每个名人的最后一条发言时间，然后以最后一次拉接口更新该名人时间戳做升序分页来循环拉接口更新。然后后台的service来Load时按照等级和最后一条微博时间直接用SQL过滤加排序来完成对需要展示的这些名人的产品策略。Load线程依旧是单线程。

优点：

相比方案1增加了一个异步的计算线程，直接性降低了service去Load掉接口的次数，前台service只需要Load就行，数据的写入和读取分离。

缺点：

由于是异步的过程计算数据，所以前台load数据和后台存在时间差，而前台展示却以后台异步计算的顺寻去拉取消息，会造成展示数据错乱。但相比一打打减少了接口调用。

方案3：

结合了1、2产生了不妨就让后台写入最新发言时间的任务作为一个模糊计算的职责，而后台的service可以直接按照这个顺序来load、并排序、并过滤拉出指定需要展示人数即可，然后为了做到实时的顺序，service只要在去异步盗用接口，来实时拉取最新消息，排序即可。由于load的出来的人是完全有效的并按照分类分批多线程拉取接口排序，因此实时接口调用全部有效。这样就形成了后台去近似计算、service去先近似再实时的计算过程，层层向上越来越精确。

优点：

每一个接口调用都是有效的包括后台异步拉取最新发言、到service来实时拉取都是有效的，并且后天异步线程可以根据配置来调整更新频率，可以根据不同等级的人数配置，轮训拉取最后一条发言，从而提高前台service的精确度。

 

 

名人优化做完了，总体达到了我们的效果，级别越高在最前面，同级别发言时间最新在最前面，并且数据load的到前台展现时间大幅缩减。让自己也悟出了一个道理，精确未必一开就精确，可以先模糊再逐步精确，步步逼近，层层提升精确度

 

 

评论

1 楼 draem0507 2013-07-11  

咋看以为是微博回复里头用户信息的展示
应该是新浪首页名人最新微博的展示吧哈
LZ的做法是省去了从大数据里头获取名人更新微博的最新时间
但是增加了一个插入删除的接口(然道是写触发器么)猜测而已