本文共 1735 字，大约阅读时间需要 5 分钟。

       首先说明， 我不是做微信的， 和微信也没有半毛钱的关系， 本文仅仅是用大家熟悉的微信举例。  文中所有数据并非真实数据， 仅为用作举例

       年末的时候， 微信经常会搞一些年末盘点类的页面活动， 上面写着： 今年发了多少条朋友圈， 赞了多少个好友， 被多少个好友点赞等众多数据， 实际上可以简化为：微信号------>微信数据  （key--->value）

       这里有个问题， 根据key来获取value是一个比较耗时的过程， 尤其是对于一些微信重度用户， 天天发朋友圈， 1天发10多条。  假设， 对于微信重度用户， 根据key来获取value需要5s的时间。 那你想想， 等活动开始时， 在海量用户的高并发请求下， 用户点击页面， 页面调取后台接口， 需要5s才获取数据， 用户肯定会发疯啊， 体验很差。更关键的是， 在高并发请求下， 如果后端服务是同步服务， 那要被彻底拉死！！！

       那怎么办？ 怎么优化这5秒？ 

       想想生活中的场景吧？   如果领导找你喝茶， 需要你尽快现场提供某资料， 但当场你又无法及时提供， 怎么办？ 那就平时把功课做足呗， 平时准备好， 等领导要的时候， 把已经准备好的资料给他， 领导不需要等那么长的时间， 领导满意了。 这和计算机中的cache是不是很类似？  说多了， 我又要扯冷热数据了。

       所以， 我们可以采用同样的方法来优化这5s时间， 对的， 提前准备好， 就这么简单！ 具体来说， 可以把key和value数据提前准备好， 写入到一个快存储中， 保存下来， 实际上， 这就是cache的思想。

       可是， 活动马上就要上线了， 总不能拖到明年年初再盘点今年的数据吧？  这些cache数据怎么准备？ 这也是个问题。 

       一般来讲， 对于微信重度用户， 都会有一个账号记录的， 也就是有一个重度用户的key集合， 我们只需要关注这些重度用户（轻度用户的value数据一般可以实时拉取， 不太费时， 假设在1s之内吧， 这个值， 用户是可以接受的， 毕竟有加载时间是合理的）。

       问题是， 微信重度用户很多， 假设有5亿（5亿的key存放在txt文件中）， 要用程序获取所有key的value, 也是蛮耗时的， 怎么办？ 写程序从文件头跑到文件尾？ 那估计要世界末日了， 你算算就知道时间了！

       怎么办？ 既然一个人干活太累， 那就多招聘一些人吧。 我们可以考虑开多个进程来跑数据获取value,  这就涉及到对大文件进行分割了， 请参考我之前的博文：http://blog.csdn.net/stpeace/article/details/53856225   《 linux中split命令的重要用途------文件分割》

       分割后， 让多进程在后台并发地静默执行， 请参考我之前的博文：http://blog.csdn.net/stpeace/article/details/53856277  《如何让你的linux程序在后台静默执行？》

       可是, 一个机器上的进程数目毕竟有限， 开多了， 有可能会适得其反。 怎么办？ 这个好说， 在多机器上跑， 搞100台机器跑， 在互联网公司， 找100台机器跑程序， 是轻而易举的事情。

       可是， 还是有点慢， 检查一下程序吧， 发现程序有非常频繁的打开文件和关闭文件操作， 我靠！ 写log也不能这样啊！ 优化一下。

       然而， 假设在极端情况下， 跑的任务突然异常中断， 那是不是要重新跑所有的帐号数据呢？ 谁让你不提前记录跑号成功、失败的状态信息啊？

       假设上面所有的情况你都考虑到了， 领导某天突然问， 你那个跑帐号包的进度如何？ 你有可能就懵逼了， 所以要在程序中记录进度和速度， 要有时间预计。

       是的， 你都做好了， 可是页面活动上线前， 你发现写到快存储中的数据都是错的， 那就完蛋了， 你怎么不提前check呢？ 跑帐号之前、之中、之后都要经常关注快存储中的数据啊。

       至此， 基本没啥大问题了， 一个小小的需求， 涉及的东西还挺多的。 很多时候， 思路比执行更重要。 思路错误， 再怎么执行， 也是白搭， 最后任务肯定完不成， 年终奖就别要了吧。 思路对了， 执行起来就是顺理成章的事了。

       先扯到这里， 以后有空再扯。