腾讯新闻之海量服务探讨，郑坚，OMG移动媒体部
移动新闻产品特点：次高频使用，用户覆盖面广
- 聚焦核心需求，少既是多
- 不要过度设计，考虑普适性
- 宁要90%，不要80%
- 功能多闭环，多问一个now what
开发篇
- 快速迭代，小步快跑（开发模式）：push系统优化
- 快，稳定 超过 精巧性
- 快，允许出错 超过 慢，不出错
- 边重构边生活 : 评论系统升级，图片，LBS，各种聚合
运营篇
- 快速灰度策略
- 有损服务
- 先扛住再优化 ：新评论体系
- 立体监控
有损服务实例：突发新闻PUSH
- 突发性，新闻事件突发性很强，用户关心度高，可以准备的时间短，如空难，恐怖袭击，明星绯闻等
- 同时到达用户量大（同时到达用户>X000万）
- push底层页转化到新闻列表页的比例高达到50%，优质内容会带来更多二次点击
- 推送时间短（2分钟左右）流量在2分钟左右达到峰值，平时瞬间峰值流量是平均流量的3倍左右
一个典型案例：马航飞机失联报道
背景：马来西亚总理开新闻发布会确认失联客机坠毁后，进行了新闻push
数据：发送IOS用户X000万，android用户X000万 发送时长2分钟，点击率达到了
25%，并且在首页头图放置了一个专题，在首页靠前放置了一个图文直播，这两个接口逻辑都比较复杂。
这个push带来了近七倍的日常流量和接近3倍的接口调用量
背景：马来西亚总理开新闻发布会确认失联客机坠毁后，进行了新闻push
数据：发送IOS用户X000万，android用户X000万 发送时长2分钟，点击率达到了
25%，并且在首页头图放置了一个专题，在首页靠前放置了一个图文直播，这两个接口逻辑都比较复杂。
这个push带来了近七倍的日常流量和接近3倍的接口调用量
服务分级：无损，有损
重点接口重点保障，次要接口有损保障，资源区分隔离部署。
重点接口每天只有7亿左右的请求量，全天23亿请求量，重点接口只占总请求的30%，我们用60%的设备支持30%的重要接口，支持突发流量，其余70%次要接口，可以有损（82原则）
再次要接口使用能够紧急降级，甚至消除图文直播优化，自刷新时间延长，与离开首屏不再进行自刷新模式，改为提示两处优化新闻push底层页接口由原来的2次减少为1次
重点接口重点保障，次要接口有损保障，资源区分隔离部署。
重点接口每天只有7亿左右的请求量，全天23亿请求量，重点接口只占总请求的30%，我们用60%的设备支持30%的重要接口，支持突发流量，其余70%次要接口，可以有损（82原则）
再次要接口使用能够紧急降级，甚至消除图文直播优化，自刷新时间延长，与离开首屏不再进行自刷新模式，改为提示两处优化新闻push底层页接口由原来的2次减少为1次
缓存前移，分布化
新闻push解决超级热key问题和大Key（超过200K）的问题超级热K（读热点）：push新闻时会会集中在某个热点新闻，新闻是原子key，无法打散，单机处理能力成为瓶颈解决：前端proxy缓存, 使热K突破单机瓶颈
新闻push解决超级热key问题和大Key（超过200K）的问题超级热K（读热点）：push新闻时会会集中在某个热点新闻，新闻是原子key，无法打散，单机处理能力成为瓶颈解决：前端proxy缓存, 使热K突破单机瓶颈
优化TCP协议
- 提高TCP初始化拥塞窗口大小（从3调到10）, 减少用户和服务器之间RTT（往返延时）提高数据传输速度。
- Android客户端和服务器之间实现长链接模式，把请求首页建立21次链接请求减少到2次，并开启GZIP压缩尽量让每个请求都在一次RTT内完成传输
- 服务端Cwnd（拥塞窗口）值调整。IOS和主流安卓客户端都是比较大
- 容量模型，建立合理容量模型，接口设置最大连接数，及早拒绝，防止雪崩
- 其他性能优化，APC缓存，高并发时底层页静态化降低后台请求，以及分区域保障，一线城市重点，二线城市有损
