和百度的一前辈吃饭，被问陌陌服务器的idle,有无30%?我只能.....

　　前几天和百度的一前辈吃饭，被问陌陌服务器的 idle，30%?我嘿嘿。20% 总有吧？我只能继续嘿嘿，估计当时和东莞市长的心情差不多。

　　陌陌的高峰是晚 10 点到 12 点，部分服务器，每天晚上都是战备状态，同学们也都在应战。我们碰到的问题很有挑战性，主要为两个方面：

　　一方面是技术，另一方面是兼容历史，后者更难处理一些。好比我们要把一辆正在正在行使奇瑞 QQ 改装成布加迪威航，要更快，而且整个过程绝不允许停下来、更不允许出现任何差错，是的，是“任何“这两个字。

　　陌陌 API 每天的请求已超过 20 亿，每秒算下来大约 2.5 万请求的样子。传递给数据层的量则会更大一些，一个请求里经常会有数百次的 IO。IO 这么频繁，性能还没问题，第一功劳要给 redis 的作者 antirez。redis 作为一个银弹，完美的支撑了陌陌的快速发展，超高的性能、超简单的使用方式、无范式的灵活。redis 的各种优势我们都体验了，各种坑（使用与运维方面）也踩的差不多了，经验绝对丰富，下一步估计会争取自动化，以及比较系统的总结与分享。

　　API 用的 php，线上开启 xhprof，相应数据进入 api-stat 平台，通过 nginx 来隔离不同服务的 php 服务器（所以开头说的是部分服务，以前一直会因为一个服务 down 掉整个服务），这样客户端用起来还是统一的。 版本也很新，是从 5.3 升到 5.5 之后的。php 和 redis 一样，强大的灵活性支撑了产品各种需求与想法以最快的速度落实在用户服务中。

　　但 php 与 redis 有个问题，就是 redis 的连接数。已不允许 php 再大规模的增加机器。我们调整过 redis 连接数上限，但这不是长久之计，另外，也不清楚连接数过高会不会在线上环境带来什么附加问题。有时候，测试数据代表不了线上的真实情况。 也尝试性的 redis 长连接改成短连接，但服务根本受不了，cpu 瞬间爆掉。也想过在中间加一层 proxy 之类的东西，但估计也和改成短连接的效果差不多。还有一个方案，就是忍受，然后加倍增加机器数量，但这个方案看起来终究有点 low。 你只能竭尽全力，做的更好。

　　附近，是陌陌一个核心要素，在产品里比比皆是。最开始的时候是直接用 mongo 的，后来 mongo 顶不住了，就分库，再后来分库也顶不住了。服务层的同学就做了陌陌自己的附近计算，省了不少机器。此外，我们的运维在网络质量、反 DNS 劫持等方面也做了大量的工作。 DNS 劫持是件很可恶的事情，在这方面我们做了一些工作，但不展开了。

　　但是，按照目前的用户增长速度，接下来我们碰到的技术问题会更棘手，就现在而言，我们要做的很多，但可做的十分有限，毕竟有各方面的资源限制，这更要求我们要做更好的产品。

　　从紧迫度上讲，我觉得是这样的：

　　首先是继续快速的完成各种产品需求，保障各类服务质量。 

　　其次是调整技术架构，这里不允许豪爽的唱起从头再来，只能积少成多，慢慢改进从客户端到服务端各个方面。

　　再次则是推动手工工作的平台、自动化，以及经验总结、知识沉淀方面的工作。

　　最后是转换观念，提高管理、规范、流程化方面的工作。 

　　叨叨到最后了，该干活了......如果你能较好的解决上述任何一个问题，还望能留下大名，指教一二。