互联网后台的奥秘 - 腾讯一大牛的分享

这是前两天腾讯一技术总监来华科做的一个演讲, 今天才整理出来. 因为里面有些内容好逗, 为了免除给大牛带来烦恼, 就不署名了. 都是纯纯的干货, 都是亲身经历获得的经验, 十分感谢这位大牛. 为了穿插成文, 里面有些我自己的想法, 如有错误, 谢谢指出, 和大牛无关.

大纲

提升系统性能主要从提高CPU利用率, 和减小IO入手.

作者举了一个异步的例子, 是关于获取时间的. 获取时间涉及到内核调用, 内核调用涉及到用户态和内核态的上下文切换, 会比较耗时. 但是在程序中很多地方都需要获得系统时间. 怎么办呢? 答案就是再开一个线程, 专门用于取时间, 所有其他需要时间的, 都向这个线程查询时间. 这样, 通过减少内核态用户态切换, 就可以提高性能.

在腾讯, 写的比较好服务, 其CPU平均利用率在36%左右. 但是写的不好的服务, CPU利用率10%都不到，而且压都压不上来. 这就是因为涉及到线程等待, CPU一直在等待, 想出力都没地方出. 可见正确的使用多进程/线程很重要. 而且还可推断出, 对现在的应用来说, 性能确实慢慢不是问题了, 好的服务36%左右, 说明电脑性能还有很大一部分没有压榨出来.

以前, 无论是初创, 还是一般的大型公司, 都会倒在100万访问这个坎上. 因为倒在了IO上, 当100万访问时, 直接读数据库完全不可取, 数据库抗不住. 这种状况直到memcached出来后才有救.

凡涉及IO的操作最终都会涉及到内核调用, 比如打log, 最终写硬盘就需要切换到内核态. 这里作者举了一个例子, 在原来开发的一个系统中, 性能怎么都提升不上去, 后来检查到log上, 因为log最终要写到硬盘上, 是同步的, 必须一个log写完, 再写下一条, 内核切换+同步写, 导致了性能瓶颈. 解决办法如果说出来巧妙但简单, 和上文获得时间的解决办法十分一致, 就是单独开一个线程, 里面有个消息队列, 每次写log, 都是直接向消息队列中添加数据, 然后最终写硬盘时, 不在一次写一条, 而是一次写一千条. 就这样, 再也没有遇到过因为log导致系统性能大幅度下降了.

关于内存共享, 作者举了Reddis的一个例子. 他们使用Reddis+多线程. 但是Reddis的缓存偶尔莫名其妙的不可用, 说数据遭到破坏. 检查了好久的原因, 知道后来发现, 他们使用多线程, 当其中一个线程在读取链表时, 忽然被杀掉了, 这样就导致内存缓存坏掉. 以后他们都是先更新到一个临时区, 然后一次性更新所有数据.

关于缓存失效过载, 作者举了一个初创公司的例子. 一个公司, 因为断电, 服务器挂掉, 重启后, 打开服务就宕机, 开开就挂掉, 然后重启, 重启后继续挂掉. 直到发现是因为断电导致cache失效, 所有连接就去数据库查询, 查询量太大数据库扛不住, 挂掉. 重启后, 缓存还是没有准备好, 继续查数据库, 继续挂掉.

关于epoll, 不懂得童鞋可以看下这篇文章, 非常通俗易懂. 作者使用epoll讲了自己的成长例子. 当时epoll技术出来后, 他觉得好玩, 就自己在家里写个简单程序, 然后压力测试, 看看能比现在的select技术好多少. 后来老大问有谁有epoll开发经验, 组里就只有他举手了, 然后机会就这样落在头上, 所以说机会都是给有准备的人的, 是没错的.

作为一个工程师, 随着我们经验的积累, 我们应该慢慢的能自己评估程序能够扛多少压力, 自己心里有数, 当然这需要大量的积累和测试。

可用性

06年成立架构组，解决可用性问题。 主要指: 1. 容错 容灾 2. 多台负载 3. 自动切换

运行逻辑的服务器很好解决, 简单备份下就好. 关键是涉及到数据的服务器, 尤其是数据热备份, 十分难解决.

容灾

作者讲到一个例子, 以前没有听到过, 但是感觉理直居服, 无可反驳. 911发生后, 很多公司都倒闭了. 为什么呢? 楼倒了, 数据都没有了, 客户信息都丢了。这就说明了容灾的重要性. 而且作者讲到亲身经历的例子, 简直忍俊不禁. 租的机房总会出问题，比如光纤被挖断; 比如空调坏了，机房温度过高导致起火。……

自动调度

当一台服务器出现问题时, 需要进行自动调度，不依赖dns. 腾讯最初是就近接入, 然是可能会导致跨网问题. 移动电信直接连接速度很慢, 宽带很窄. 后来发展成快接入, 和哪个服务器通信快, 就和哪个服务器接入.

快速部署，迁移

准实时监控，实时告警

如果没有监控, 就不知道自己出现了问题，只能靠用户反馈，这样耗时太久, 也许用户不想反馈, 直接不用你的服务了. 主要完成 流量监控，耗时监控. 如果出现问题, 反馈时不仅要带上今天和昨天的监控图，还要带上今天和上周的监控图 作者举了一个例子, 腾讯的一个集群有2万台服务器，其中有300台专门做监控.

set部署 集装箱式部署

这里写图片描述

多机房 自动化 全网调度 1个set，一批qq号, 对应在游戏上, 就是一区一区的玩，一是防止级别差别过大，二是防止全区全服数据访问. 你们知道第一个全区全服的游戏是什么么? 暴雪? no,no,no too naive 当然是QQ农场了 :)

灰度发布

这个词以前没有涉及到, 是指应用发布是全部用户都发还是只针对一部分用户发, 用于验证版本的可行性. 就像最近的win10, 有Insider用户的内测版, 有面向所有人群的beta[:(]版. 终端软件比较容易灰度 然后作者举了两个腾讯内如何灰度的例子, 听过后差点笑疯. 1. 黄钻灰度，比如七级黄钻以后才能先可见。毕竟一个功能上线, 先要有人试验一下效果如何. 而且程序员和产品经理都喜欢这个:). 2. 根据qq号长度做灰度. (⊙v⊙)嗯, 因为短号现在都是大v，微博上说下功能怎么能这样呢, 你就傻了。。。长号都是小学生, 嗯, 诺克萨斯之手晕倒在路边…. 当然, 正常途径都是 按照模块 或者 按照set来做灰度的.

染色

是指如何快速定位一个用户. 比如老板的qq出问题，让你解决，你要快速定位老板的数据, 然后才能根据数据找到解决办法. - 哭着的解决办法 grep….那么多日志, 根据qq, 慢慢找吧, 生命在于折腾. - 对框架要求很高. 让用户在操作一下, 在接入层遇到用户后标记，把所有协议都打标签, 然后让经过的所有服务器生成的log都汇聚到同一个服务器. 接下来分析这台服务器上的数据就够了. 这个需要框架里面的支持，对架构要求较高. 而且这是事后解决方案，必须需要用户配合. 用户如果不配合怎么办呢? “那我送你三十个qq币，你帮我测一下呗”

缓存和存储

有个公司以自己的实力提升整个互联网的水平, 它就是Google, 最近又开源全球最精准自然语言解析器SyntaxNet。 缓存cache主要考虑性能. 存储主要考虑数据安全性, 数据一致性问题. 这里作者讲到了数据一致性问题, NOSQL不保证数据的完全一致性，只考虑最终一致性. 讲到了数据库优化的一些手段, 比如 不是每次sql都立即回写到sql数据库中. 每十次才回写到sql数据库中一次.

还要考虑数据的安全性,冷热备份,一致性

sql数据如何搬迁:

将数据写缓存，数据不落地，三小时后sql数据搬迁成功后再写到sql中

cache搬迁

搬迁用户时，只能读，不能写. 然后是一个个用户的搬迁, 这样的话, 正好在搬迁用户的时候, 其发生写行为的概率很低. 而且如果发生, 可以直接发送个错误回去. 让用户重新写.

数据分析和统计

脚本 shell sed awk 数据库 mysql oracle 分布式 hadoop spark 这里作者又提到了谷歌的伟大之处，oracle数据库单机一年几十万, 上面说集群二万台, 恩嗯. Hadoop的出现救了好多公司的命. Spark（数据不落地，不IO，数据处理很快）

这里作者分析了bat和创业的公司的好坏. 互联网分工很细，在bat没有办法完全了解整个流程。轮子都做完了，只能去做逻辑。但是bat快速看到最先进的技术，眼界和学识都很厉害。

典型后台关键组件

可扩展自动生成二进制协议 corba组件 高性能分布式框架 写逻辑 高性能接入层 高性能缓存 完善的运营体系 数据一致性,多备容灾 离线数据分析平台

技术背后的意识

意识是技术的进一步抽象 1. 万有一失 2. 大系统小做 浏览器几千个模块 3. 柔性可用 原来的网页十几个数据，取十几次数据，一个接口失败，页面就没有办法生成。 作者讲了一个例子, 如QQ空间, 白天浏览量少, 图片会预加载. 但是带宽费用是按峰值来算的。那么晚上八九点，浏览量大增的时候, 大图片缩小，取消预加载，防止宽带过大。 4. 边重构边生活 拥抱变化 九个人的活，十个人做，其中一个人专门做架构，逻辑优化。

工程型开发已经到一个平台期，未来是什么

以前每年每个阶段，都有眼前一亮的技术。 现在所有功能基本都能实现, 没有很大的技术门槛，只有好坏，速度快慢。

未来: 13年之后，深度学习火起，从工程型到算法型转变。 数学基础，机器学习，深度学习，图像，声音，语意，AI。 对编码要求能力低，对基础背景要求高。 GPU代表未来。

作为程序猿,最重要的是什么?

保持好奇心→_→