前言：这是我最近在公司内部分享的一篇文章，大家反响比较强烈，所以也分享到博客里来。 一转眼，来公司已经三年多了。 这三年里，所属部门在变，地理位置在变，技术也日新月异，但是有很多设计原则却是一直不曾改变的，而这次就是我用自身的实践来谈谈我对其中的一个的理解---有损服务。 记得当年qwang用一个很形象的比喻来解释有损（原话记不太清楚了）： 比如一个人在沙漠里迷失了寻找水源，那么在他还能走的时候，就尽量走；实在走不动了，用爬的；最后爬也爬不了了，起码要保证自己活着。 所以我们从这个比喻中起码可以获得如下几个信息：

1. 问题时，优先保证关键功能
2. 非关键功能不可以影响关键功能
3. 在条件允许的情况下，损失越少越好

接下来就从自己印象比较深刻的有损服务项目讲起吧。

一、空间应用列表有损服务优化

想当年，苍井空还是处女，玛利亚还姓圣母。好吧，扯远了，想当年第一款国民级应用《QQ农场》横空出世，其空前的火爆导致空间个人中心应用列表的农场图标变得如此重要。 然而由于各种网络等各种原因，这个列表的展现总是会有一定的失败率，而且只要稍微失败就会招来大批用户的投诉。 我们分析一下这个模块的功能：

• 正常功能：正常展示用户已经安装的应用列表
• 关键功能：正常展示用户最关心的基础应用（如日志）、火爆游戏（农场）等的应用列表

于是优化开始了……

Step1. 应用信息本地cache

由于应用列表第一个要获取的就是应用自身的信息 ...

我这几天在微博上写了一句话: 回归简单，即便开始反而会变得更加复杂。 回想起当年刚用Django写素材管理系统还历历在目，最近却已经逐渐脱离Django了。 成长总是分阶段的吧，勇敢的抛弃一些东西，接纳新的东西，也许就是成长了。 至于原因呢，也是我一直在总结的，大家可以一起看一下。 Django适合做中型项目，但却不适合小型和大型项目 为什么这么说呢？

• 对于中型项目来说，Django可以说提供了你需要用到的一切，session，orm，admin等等，只要你按照Django规定的思路来，你会发现开发和维护是如此顺手。
• 但是如果是小型项目呢？ 我可能不需要session，我也不需要数据库，但是我却要为Django那些繁琐的东西配置半天。当我被这些繁琐而无用的东西搞晕的时候，我感觉更像是在搭积木，而不是在创造一个伟大的东西。
• 而对于大型项目来说，Django默认带的组件又满足不了需求，甚至连架构都可能要被替换，所以Django所自带的很多特性都将无法使用。 由于工作的关系，在大型项目中，有一类不得不说的服务，那就是SNS应用。 SNS应用的特点是什么？注册用户量极大，活跃很少。大批的用户蜂拥进入可能只是看一眼就再没回来，但是你的数据却因为这些无用的用户变得庞大无比。进而导致Django默认的那些Model，admin全部都形同虚设，Django的那些所谓的优势荡然无存。 博友反馈这里没说清楚，我再描述一下:
  1. 互联网的数据模型与关系数据模型不匹配。互联网数据更适合NoSQL，所以Admin对关系（外键、关联）的处理就没有任何用处了，而直接展示一个blob字段也并没有比用sql语句直观多少。（BTW ...

前段时间在做文件扫描的时候，有一些关于字节、字符数统计的需求，考虑到有同学也可能用的到，所以整理一下记录在这里。

1.统计当前字符之前的所有字节数

command! -nargs=0 CountBytesBack        :normal mxvgg"ay`x:echo strlen(@a)<CR>

2.统计当前字符之后的所有字节数

command! -nargs=0 CountBytesForward     :normal mxv$G"ay`x:echo strlen(@a)<CR>

3.统计当前文件所有字节数

command! -nargs=0 CountBytesAll         :normal mxggVG"ay`x:echo strlen(@a)<CR>

4.统计当前文件所有字符数

command! -nargs=0 CountCharsAll         :%s ...