架构师训练营 - 学习笔记 - 第七周
不知不觉,赛程过半(7/15),最近学习明显感觉智慧老师讲的知识点多了,有点难消化了。看来自己的知识体系结构还是差的很远的。
思考与感悟
实践出真知
在架构师训练营里,智慧老师只能把技术点指出来,更多的还需自己在实践中加深对某门技术的理解,印到脑子里。
多层次、多维度去理解并解决问题
遇到问题多问问为什么,不要一头钻进技术细节里。比如:网络 IO 遇到瓶颈时,不要想着搞个大框架去优化代码,而是可以从1G 网卡升级到 10G 网卡。
不要拿着锤子砸钉子,先找到钉子,找到问题
我们应该先找到问题,根据问题,再去寻找解决方案、工具等。举个反面例子,就好像新入职的同学会说:“你们怎么 xx 工具、xx 框架都不用,这么 low“. 先找到问题,然后再去解决,这样更容易打动人。
Tips
领悟关键技术点,其他的就一通百通了。比如:领悟了线程就绪态,运行态,阻塞态后,理解锁,死锁等就容易多了。
性能测试与优化 - 2020/7/16 - 周四
性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准。
主观视角:用户感受到的性能
客观视角:性能指标衡量的性能
性能测试指标
响应时间
系统发出请求开始到收到最后响应数据所需要的时间。
完成一次任务花费的时间
并发数
系统能够同时处理请求的数目,这个数字也反映了系统的负载特性。对于网站而言,并发数即系统并发用户数,指同时提交请求的用户数目,于此相对应,还有在线用户数(当前登录系统的用户数)和系统用户数(可能访问系统的总用户数)。
吞吐量
单位时间内系统处理的请求的数量,体现了系统的处理能力。对于网站,可以用”请求数/秒“或者是”页面数/秒“来衡量,也可以用”访问人数/天“或是”处理的业务数/小时“等来衡量。
TPS: 每秒事务数
HPS: 每秒 HTTP 请求数
QPS: 每秒查询数
吞吐量 = ( 1000 / 响应时间 ms ) x 并发数
性能计数器
是描述服务器或操作系统性能的一些数据指标。包括 System Load、对象与线程数、内存使用、CPU 使用、磁盘与网络 I/O 等指标。这些指标也是系统监控的重要参数,对这些指标设置报警阀值,当监控系统发现性能计数器超过阀值的时候,就向运维和开发人员报警,及时发现处理系统异常。
性能测试方法
性能测试是一个总称,具体可细分为性能测试、负载测试、压力测试、稳定性测试。
性能测试
以系统设计初期规划的性能指标为预期目标,对系统不断施加压力,验证系统在资源可接受范围内,是否能达到性能预期。
负载测试
对系统不断地增加并发请求以增加系统压力,直到系统的某项或多项性能指标达到安全临界值,如某种资源已经呈饱和的状态,这时候继续对系统施加压力,系统的处理能力不但不能提高,反而会下降。
压力测试
超过安全负载的情况下,对系统继续施加压力,直到系统崩溃或不能再处理任何请求,以此获得系统最大压力承受能力。
稳定性测试
被测系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,使系统运行一段较长时间,以此检测系统是否稳定。在生产环境,请求压力是不均匀的,呈波浪特性,因此为了更好地模拟生产环境,稳定性测试也应不均匀地对系统施加压力。
全链路压测
全链路压测其实指的就是在特定的业务场景下,将相关的链路完整的串联起来同时施压,尽可能模拟出真实的用户行为,当系统整站流量都被打上来的时候,必定会爆露出性能瓶颈,才能够探测出系统整体的真实处理能力,以及有指导的在大促前进行容量规划和性能优化,这便是线上实施全链路压测的真正目的。
全链路压测的挑战
数据构造
数据隔离
流量构造
全链路压测平台化
如何优化
软件性能优化的连个基本原则
你不能优化一个没有测试的软件
你不能优化一个你不了解的软件
性能优化的一般方法
性能测试,获得性能指标
指标分析,发现性能与资源瓶颈点
架构与代码分析,寻找性能与资源瓶颈关键所在
架构与代码优化,优化关键技术点,平衡资源利用
性能测试,进入性能优化闭环
系统性能优化的分层思想(7层协议)
机房与骨干网络的优化
服务器与硬件性能的优化
操作系统性能优化
JVM 虚拟机性能优化
基础组件性能优化
软件架构性能优化 - 三板斧
缓存
从内存获取数据,减少响应时间
减少数据库访问,降低存储设备负载压力
缓存结果对象,而不是原始数据,减少 CPU 计算
缓存主要优化读操作
异步
即时响应,更好的用户体验
控制消费速度,合适的负载压力
异步主要优化写操作
集群
古老谚语:如果一匹马拉不动车,无需更换一匹更强的马,而是用两匹马拉车。
更多的用用户访问需要消耗更多的计算资源,单一服务器计算资源的增加是有极限的,所以需要增加更多的服务器。关键是如何利用起来这些服务器。
集群的技术目标只有一个:如何使很多台服务器对使用者而言看起来像一台服务器。
软件代码性能优化
遵循面向对象的设计原则与设计模式编程,避免写出“烂代码”
并发编程,多线程与锁
资源复用,线程池与对象池
异步编程,生产者消费者
数据结构,数组、链表、hash 表、树
操作系统与文件系统 - 2020/7/18 - 周六
操作系统 - 架构所需
程序运行时架构
程序是静态的,被加载到内存运行起来后,被称作进程。
操作系统多任务运行环境
进程分时执行,共享 CPU 的一个时间片,让用户看起来好像是同时执行。
进程的运行期状态
运行:一个进程在 CPU 上运行。处于运行状态的进程的数目小于等于 CPU 的数目。
就绪:当一个进程获得了除了 CPU 以外的一切所需资源,只要得到 CPU 即可运行,则称此进程处于就绪状态,就绪状态有时候也被称为等待运行状态。
阻塞:也称为等待或者睡眠状态,但一个进程正在等待某一事件发生(例如等待 I/O 完成,等待锁等)而暂时停止运行,这时,即使把 CPU 分配给进程也无法运行,故称改进程处于阻塞状态。
进程 VS 线程
进程被切分为若干个独立执行的线程。进程间 CPU 开销大,所以使用单进程多线程。进程从操作系统获得基本的内存空间,所有的线程共享着进程的内存地址空间。而每个线程也会拥有自己私有的内存地址范围,其他线程不能访问。
线程栈
线程有独立的线程栈。
线程安全
当某些代码修改内存堆(进程共享内存)里的数据的时候,如果有多个线程在同时执行,就有可能会出现同时修改数据的情况。
临界区
多个线程访问共享资源的这段代码被称为临界区,解决线程安全问题的主要方法是使用锁,将临界区的代码加锁,只有获得锁的线程才能执行临界区代码。
阻塞导致高并发系统崩溃
锁(IO)会引起线程阻塞。阻塞导致线程既不能继续执行,也不能释放资源。进而导致资源耗尽,最终导致系统崩溃。
避免阻塞引起的崩溃
限流: 控制进入计算机的请求书,进而减少创建的线程数。
降级:关闭部分功能程序的执行,尽早释放线程。
避免阻塞:异步 I/O,无临界区(Actor 模型)
锁
锁原语 CAS(V,E,N)
V 表示要更新的变量
E 表示预期值
N 表示新值
如果 V 值等于 E 值,则将 V 的值设为 N, 若 V 值和 E 值不同,什么都不做。
CAS 是一种系统原语,原语的执行必须是连续的,在执行过程中不允许被中断。
偏向锁 轻量级锁 重量级锁
偏向锁:指一段同步代码一直被一个线程所访问,那么该线程会自动获取锁,降低获取锁的代价。
轻量级锁:指当锁是偏向锁时,被另一个线程所访问,偏向锁就会升级为轻量级锁,其他线程会通过自旋的形式尝试获取锁,不会阻塞,提高性能。
重量级锁:指当锁时轻量级锁时,另一个线程虽然自旋,但自旋不会一直持续下去,当自旋到一定次数时,还没获取到锁,就会进入阻塞,该锁膨胀为重量级锁,重量级锁会让其他申请的线程进入阻塞,性能降低。
多 CPU 情况下的锁
总线锁与缓存锁
总线锁:使用处理器的 LOCK #信号,当一个处理器在内存总线上输出次信号的时候,其他处理器的请求将被阻塞,该处理器独占内存。
缓存锁:是指内存区域如果被缓存在处理器的缓存行中,并且在LOCK 操作期间被锁定,那么当它执行锁操作回写到内存时,处理器不在总线上声言LOCK# 信号,而是修改内部的内存地址,并允许它的缓存一致性机制来保证操作的原子性,因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据,当其他处理器回写已被锁定的缓存行数据时,会使缓存行无效。
公平锁 非公平锁
公平锁:多个线程按照申请锁的顺序来获取锁。
非公平锁:多个线程后去锁的顺序并不是按照申请锁的顺序,有可能后申请的线程比先申请的线程有限获取锁,可能会造成饥饿现象。
可重入锁
某个线程已经获得某个锁,可以再次获取锁而不会出现死锁。
独享锁/互斥锁 共享锁 读写锁
独享锁/互斥锁:该锁一次只能被一个线程所持有。
共享锁:该锁可以被多个线程所持有。
读写锁:多个读线程之间并不互斥,而写线程则要求与任何线程互斥。
乐观锁 悲观锁
悲观锁认为对于同一个数据的并发操作,一定是会发生修改的,哪怕没有修改,也会认为修改。因此对于同一个数据的并发操作,悲观锁采取加锁的形式。悲观的认为,不加锁的并发操作一定会出问题。
乐观锁则认为对于同一个数据的并发操作,是不会发生修改的。在更新数据的时候,检查是否已经被修改过,如果修改过,就放弃。
分段锁
分段锁的设计目的是细化锁的粒度,当操作不需要更新整个数组的时候,就仅仅针对数组的一段进行加锁操作。比如:JDK ConcurrentHashMap 是通过分段锁的形式来实现高效并发操作的。
自旋锁
自旋锁是指尝试获取锁的线程不会立即阻塞,而是采用循环的方式去尝试获取锁,这样的好处是减少线程上下文切换的消耗,缺点是循环会消耗 CPU.
文件系统
机械硬盘 VS 固态硬盘
B+ 树
LSM 树
文件控制块 FCB
文件系统将硬盘空间以块为单位进行划分,每个文件占据若干个块,然后再通过一个文件控制块 FCB 记录每个文件占据的硬盘数据库。
Linux Inode 文件控制块
inode 中记录着文件权限、所有者、修改时间和文件大小等文件属性信息,以及文件数据块硬盘地址索引。
inode 是固定结构的,能够记录的硬盘地址索引数也是固定的,只有 15 个索引。
每个 inode 最多可以存储 12+256+256*256 + 256*256*256 个数据块,如果每个数据块的大小为 4k, 也就是说单个文件最大不超过 70G.
RAID 独立硬盘冗余阵列
分布式文件系统 HDFS
评论