- 保证可扩展性,横向扩展和纵向扩展。
- 保证冗余性,其中的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是该算法的一个实现。
- 各大公司都有自己的分布式文件存储系统。