- 保证可扩展性，横向扩展和纵向扩展。
- 保证冗余性，其中的1台或者的几台服务器出现故障时，保证系统的正常运行。
- 当服务器有几百台时，运维成本上升，运维方式包含每个服务器的用途、每台服务器的运行状况、如负载、磁盘、安全设置、是否出故障，这些都必须用监视软件、管理服务器的工具等自动化运维方式，服务器挂掉后能否自动重启；
- 开发方法和开发人数都发生变化。运维和开发分开，多人协作开发的问题。应当如何标准化开发、开发过程中的实现方案、统一开发语言、统一库函数和框架、代码规范、版本管理、源代码管理、bug管理、增加人手如何保证开发效率的提高、开发规范的推行、新人的培训、人员能否更上公司的发展等等。
- 内存的的速度是硬盘的105—106倍。
- 一般的瓶颈都会在cpu或者IO上。数据库的瓶颈在IO上而应用服务器的瓶颈在CPU上，查找瓶颈时一定要定位瓶颈，IO瓶颈加内存，cpu瓶颈升级服务器、扩展服务器。
- 规模还小时，简单方法效果最好。过早优化不是最佳方案，从一开始就考虑建立完善的负载均衡方案成本太高。但是完全不假思索的开始也是欠考虑的。必须找到一个平衡点。
- 公司人多以后，沟通是个问题，保存沟通记录备查等都需要去做。
- 数据量过大无法再内存中处理，如果内存足够大数据能放在内存中处理，那么处理速度回非常快。
- 一定记住，以后对任何东西的评估，一定要有评估数据，用数据说话。不要想当然。
- 映像中出现过瓶颈的地方有cup、io、网络带宽、网线、机房、服务器整体配置、网络分布。
- 扩展的难点在数据库扩展上。而且其瓶颈经常是IO，而Io的瓶颈比较难解决。
- IO改造方面，进可能在内存中完成。操作系统在做页级缓存。内存做虚拟内存、页面缓存、系统内存充足时，会做页面缓存，导致刚刚加上去的内存很快就别用了，但是能提供访问的速度。如果一台运行中的机器被重新启动后期缓存没有，如果一下子来过多的请求，就导致其不能快速响应，其必须去后端的服务在磁盘上进行计算，导致大量堵塞，可能导致系统崩溃。所有一台新服务器上去后，一定要先预热，让所有的业务都基本跑过一遍，把数据缓存起来，以后。在拉入集群，其方能接得住集群的压力。否则其会被压死的。
- 对于大量更新的数据，可以进行一定的缓存以后然后批量更新，可能导致一定的数据丢失。
- 数据库IO分散方式-------拆（拆表、拆成新的数据库）。按业务拆表、按数据，有的列里面包含了较多的数据拆表、按安全性拆表。表做hasH， 做表映射，其带来的问题是进一步扩展很麻烦。同时保持一定的冗余。减少联合查询。
- 根据不同的业务或者请求来源，让其走不通的负载通道，如一般请求走一个负载通道，百度、google的机器人走一个请求通道、其他的走另外的通道。实现请求分开处理。
- 通过增加内存无法解决Io瓶颈就通过分布式去解决。分布式，只有在单机实在是不能解决的时候才使用。
- 数据库字段类型存储,不同的字段类型,对一个有几亿数据的表来说,最终的表大小差距会很巨大的.
- 索引：B树、B+树、二叉树。索引的效果，无索引是是线性表O(n)，有索引是（B树二分查找）O(logn)，如果数据是4000万。无索引时最坏情况要查找4000万次。而b树时只要25.25次。差距如此巨大。其减少了IO的次数，减少了cup的运输量。复合索引、聚集索引、非聚集索引。
- 数据库扩展，主从，一主多从（至少4台构成，一个一主多从，主写，从读，一个损坏时，能用一个做备份还原，一旦分割其将，一下从4变8,8变12、12变16以4为一组递增）；多主多从；访问量非常高的情况，多主多从层级分发。分割表、hash映射。 或者建立hash映射表。早期规划时，预留得有更多的hash映射表，因为hash映射，扩展比较麻烦。
- 差存储已经排序的数据。如[3、5、20、21、23、76、78]可以用如下的方式存储[3、2、15、1、2、53、1、1]，前面的数用累加即可以得出值。
- 算法复杂度，O(1)<O(logn)<O(n)<O(nlogn)<O(n2)< O(n3)…..< O(nk)< O(2n),其中 O(1)表示计算话费的时间，与算法无关，时间是固定的效果最好；
- 基于比较排序的算法无论怎么优化，也不可能比O(nlogn)快，因此排序算法能达到其就是最高速度了。
- 时间复杂度、空间复杂度，有时为了速度牺牲空间。有时空间不足牺牲时间保证算法的快速完成。
- 数据压缩，一般的服务器要开启GZIP压缩。
- 一种叫做Trie的数据结构，其用数据结构高效存储字符串，而且其树结构可以将搜索对象数据的公共前缀综合到一起。
- Web服务基础设施的三个重点。1.低成本、高效率。2.重点就是可扩展性、响应性方面的设计。3.web服务规格经常发生变化，基础设施要灵活应对，基础设施要重视开发速度，现在的web变化太快，反应过慢就会被淘汰了。
- 云的特点：价格便宜、可扩展优秀（最大优点）。其要求必须符合云服务规则，其的IO表现不好，内存扩展有限。云服务，不在自己的完全掌控中。
- 自行高级基础设施：1硬件配置灵活。2.灵活应对服务3.可以控制瓶颈。
- 大规模站的的最高境界就是各层可扩展。
- 服务器冗余保证，服务可以不间断运行。如果某台服务器崩溃可能引起雪崩效应。
- 服务器坏后自动切换，回复后能自动拉入集群工作。
- 多主库时，引入第3方判断，使第3方的判断一致投票向高可靠的机器运行。如主库A有，主库B，然后还有判断方C，如果A/B都正常运行，则C投票给A，使A作为真正的主库，如果A损坏C投票给B，则B作物真正的主库。其拥有听随 C，C投票给拿台机器，那台机器就做为，真正的主库。另一台作为主库的备份主库运行。
- 开发符合自己公司要求的文件系统，用廉价机器集群做文件系统。
- 把真实的机器用虚拟机分成很多台，使各个虚拟机的性能差不多。
- 系统部稳定的因素：功能增加，开发了新功能很受欢迎，负载突然增加、内存泄露导致负载上升。地雷，只有在特定数据量的情况下，才会出现的bug，很难排查，其数据量过大时，处理能力有限等。用户访问模式如，某个图片被google等大型站点引用，被引用的文件访问量突然增加，导致负载上升。数据量增加导致系统运行部稳定，某些运用大量的执行数据更新，可以延长批量更新解决。使用的一些外部服务不稳定，突然坏掉。
内存、硬盘故障。网卡故障。
- 消灭不稳定因素，降低sql负载、减少内存泄露、异常时自主控制。
- Dos攻击时，同一IP，返回403.
- 稳定措施，内存、cup极限是使用到70%，一般是25%。
- 自动终止很耗时的查询，或者操作。
- 一台物理机器当前可能cpu资源比较空闲，而IO资源紧张。就可以建立web服务器的虚拟机。如果IO空闲、Cpu紧张则可以建立数据库服务器。进可能的使用资源。
- 虚拟机，解除了物理限制，资源可以动态更改，虚拟机操作系统迁移和复制比较容易，这样就可以轻松的增加服务器，保证可扩展性。
- 虚拟机导致了额外的开销：CPU大约2%到2%；内存性能10%；网络性能50%；IO性能降低5%；
- 自己组装廉价应用集群，降低成本，本书大量讲述，自己组装机器，而又能满足性能要求，以达到降低成本。
- 网络分界点，超过1Gbps（从路由性能来看应该是30万pps（300k）），PC路由的极限。
- 超过500台主机一个子网的极限，500台机器左右的时候ARP表大约为800多，而其实际值能容纳极限在900左右，超过后大量丢包。
- 全球化，一个数据中心的极限。
- CDN，选择好点的CDN厂商。
- 超过10Gbps，时必须获取AS（autonomous system number）号，并连接IX（Internet exchange）交换流量，或者用BGP（Border Gateway Protocol）这种物联网路由控制协议。这些东西比较高层，而且比较活跃，如果一旦控制错误，就会影响网络，是某些地区的某些网站无法访问，导致区域性网络，无法查看网站。
- Web服务的特点：低成本、高扩展、冗余、提供效率、网络稳定、强大的运维稳定。
- 作业队列系统：客户端放入作业，服务端存储作业，然后不停的执行作业。作业过程中，保留日子，用日志来分析程序性能等。
- 选择存储系统的依据：平均数据大小、最大大小、新增数据频率、更新频率、删除频率、访问频率，作为选择存储系统的判断依据。提供的系统：常规的数据库系统、Kev-vlue存储（memcached）、分布式文件系统、其他存储系统(NFS分布式文件系统)。
- 反向代理，用squid作为缓存服务器。Squid常见问题：squid效率越高，故障时影响越大。如果2太做squid一台损坏时，另一台无法，承受转移过来的压力，导致雪崩。
- 大量日子并行处理。用MapReduce计算模型，处理。Hadoop是该算法的一个实现。
- 各大公司都有自己的分布式文件存储系统。