1、优化概述：
（1）明确优化的度量指标：QPS、RT(Response Time)
2、缓存条件：
（1）读比写多得多；
（2）查询条件足够简单，不能在查询上就耗费太多时间；
（3）本地缓存失效问题：服务器主动推送新的缓存到前端的本地缓存，一个一个地更新。
3、常用策略：
（1）动静分离：业务逻辑上和服务器都进行分离；
（2）模型松耦合---大缓存：查询和缓存时进行打包（把相关的内容一起缓存，就不用进行二次查询了）；
（3）并发：降低RT；
（4）异步：降低上下文切换开销；
（5）timeout：控制服务，防止主站被某个服务拖挂掉；
流控：前端对流量进行控制。
（6）客户端容灾：非核心业务不能影响核心业务；即使核心业务没出来，客户端也不能影响用户的基本浏览需求。
4、问题及讨论：如何为双十一作准备，如何提升系统的抗压能力？
双十一前会梳理系统业务的核心链路，评估各个节点。
分层控制：
（1）Web层：超过阈值的流量直接由Nginx拦掉；
（2）业务代码层：限流控制；
（3）服务中间件：timeout、流控等。
（二) 《人人网网站架构变迁》（关键词：服务化）
1、业务特点：异构、分散、易变动、相关联；
2、移动客户端：
（1）尽量保持一个socket；
（2）网络通信很烂的情况下如何保持数据/业务的一致性（有可能数据在传输过程中网络突然断掉）：类似svn的版本控制，采用数字进行标识。
3、问题及讨论：
（1）单个socket如何提供多个服务？
thrift原生支持（协议层支持）,协议头中用ID进行服务标识，而不用端口进行标识（共用一个端口）。
（2）thrift相关讨论
A、在生产环境下进行测试，thrift的对象封装与解封装、压缩与解压缩，甚至比Java原生的序列化更快；
B、thrift由于是跨语言的，所以在人人网的框架中增加对异常的处理(有的语言如C/C++对异常支持不友好)，异常一般情况下都返回NULL对象；
C、ICE与thrift并无高下之分，选择由ICE向thrift迁移，是因为thrift足够简单，而ICE功能太强（如集群管理等）、太重了，有些功能也用不到。节点管理等运维方面比较困难，而且在上面增加功能和进行改进比较困难。目前人人网仍有1/3的服务在使用ICE。
（三）《新浪微博稳定性经验》（关键词：稳定）
1、Design for Failure
(1)分层隔离
A、主要接入方隔离。如weibo.com、weibo.cn、api.weibo.com，从DNS上隔离；
B、业务逻辑隔离。不同的业务方拆分；
C、按功能的核心度隔离。核心功能使用一个线程池，非核心功能使用一个线程池；
2、SLA保证
3、容灾预案
（1）降级（降级有问题的资源、保护核心功能）。非核心功能有不同的等级，降级之后，在超时时间、控制策略上都对应着发生改变。
（2）在线容灾演练---TouchStone系统。采用tcpcopy将线上流量拷贝过去.进行分析。
