CPU不是瓶颈，网络才是；
墨菲定律：任何事情都没表面看起来那么简单；会出错的总会出错；
可靠性：
集群：无状态集群；有状态集群，很难处理，尽量剥离出状态部分做集中式部署，其他做无状态部署；
mater/slave，极端情况下快速切换，恢复系统的可用性，软件层面和硬件层面；
数据：raid磁盘阵列，双写（同步，可靠性高，影响效率；异步，可靠性低）；
跨机房，跨网络（电信，移动），跨交换机部署；
限流/流量切换：超过系统预估负载能力时，可选择直接将部分请求丢弃，来保证部分用户的适用，一般在硬件或http服务器层面实现。一个系统中，可能不同的部分，其访问量是不同的，对于有极大瞬发访问量的系统，应该将其独立出来，防止瞬发高并发带来的风险扩散到小流量系统上；如通过域名分离秒杀系统的商品页，和普通商品页；
异步：大流量系统调用小流量系统时，可将瞬发的大流量请求异步化，平摊到小流量系统各个时段。关键点，中间件，确保系统做出的保证一定会成功。猜测支付宝与银行系统的交互即是此种方式；
系统化/服务化：将内聚性高的功能独立出来单独服务，专业的人做专业的事；系统间通过高性能web service框架通讯，有在保证功能、性能的情况下，极大提高系统可靠性；
降级：如果系统依赖了第三方服务，需要系统能在第三方服务宕机的情况下正常工作，尽量不做到对第三方系统的强依赖；
高并发：
单机：
应用层面的数据库优化：是否做读写分离，是否做分布式；合理的表设计，尽量避免大数据量表间的关联，可通过合理的数据冗余实现；合理区分冷热数据的存储；合理规划索引，参考sql执行计划，优化sql；纯数据库层面的，应该由相关专业人员完成；
业务层面：优化业务流程，使系统能通过更少的业务流程完成请求；
并发：大部分并发是可以通过合理的规划，避免竞态；无法避免的，尽量通过atomic包同步；
异步化：如果一个请求，需要非常长的业务流程才能完成，可将这一串业务流程分为必需和可延后的两部分，将必需的处理完成后，将可延后流程交给中间件去异步执行，系统依据中间件的可靠性保证语义，预先返回业务流程正常完成；
动静分离&异步：静态内容可通过缓存，动态内容实时调用；异步加载耗时长的内容，加快请求相应速度；
流量前置：本质是通过如缓存业务结果、cdn 等手段，将本来需要n个业务流程完成的请求，由<n个的业务流程完成处理；
缓存：jvm缓存/集中式缓存，jvm缓存无网络开销，但其在集群、和功能等方面较弱。宽泛来说，缓存可看做流量前置的一种手段。关键点：高命中率，缓存失效策略（此处更多考虑系统能否容忍不一致的情况）。缓存策略，和失效策略会极大影响缓存命中率，缓存策略一般遵循局部性原理（2-8原则），根据具体的业务逻辑设计。缓存还可用作容灾手段，缓存数据，在第三方系统异常的情况，作为数据的后备来源；
集群：尽量采用无状态架构，即使必需有状态，也尽量要将状态剥离，做单独的集中式部署。
负载均衡：f5，lvs。考虑使用的算法；lvs尽量采用响应流量由处理请求的服务器直接发送的方式，避免负载均衡成为系统的瓶颈；
分布式：没实际经验，感觉其规划层面和编码层面都比较难；
后续记录在实际系统中应用；
 --信号内核表示)
