地方美食网站开发意义,优秀网站配色,无法进行网站备案,房地产网站建设的目的作者#xff1a;轩辕之风O来源#xff1a;编程技术宇宙-前言-程序员经常要面临的一个问题就是#xff1a;如何提高程序性能#xff1f;这篇文章#xff0c;我们循序渐进#xff0c;从内存、磁盘I/O、网络I/O、CPU、缓存、架构、算法等多层次递进#xff0c;串联起高性能… 作者轩辕之风O来源编程技术宇宙-前言-程序员经常要面临的一个问题就是如何提高程序性能这篇文章我们循序渐进从内存、磁盘I/O、网络I/O、CPU、缓存、架构、算法等多层次递进串联起高性能开发十大必须掌握的核心技术。- I/O优化零拷贝技术- I/O优化多路复用技术- 线程池技术- 无锁编程技术- 进程间通信技术- RPC  序列化技术- 数据库索引技术- 缓存技术  布隆过滤器- 全文搜索技术- 负载均衡技术准备好了吗坐稳了发车首先我们从最简单的模型开始。老板告诉你开发一个静态web服务器把磁盘文件网页、图片通过网络发出去怎么做你花了两天时间撸了一个1.0版本主线程进入一个循环等待连接来一个连接就启动一个工作线程来处理工作线程中等待对方请求然后从磁盘读文件、往套接口发送数据完事儿上线一天老板发现太慢了大一点的图片加载都有卡顿感。让你优化这个时候你需要01▶I/O优化零拷贝技术◀上面的工作线程从磁盘读文件、再通过网络发送数据数据从磁盘到网络兜兜转转需要拷贝四次其中CPU亲自搬运都需要两次。零拷贝技术解放CPU文件数据直接从内核发送出去无需再拷贝到应用程序缓冲区白白浪费资源。Linux APIssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);函数名字已经把函数的功能解释的很明显了发送文件。指定要发送的文件描述符和网络套接字描述符一个函数搞定用上了零拷贝技术后开发了2.0版本图片加载速度明显有了提升。不过老板发现同时访问的人变多了以后又变慢了又让你继续优化。这个时候你需要02▶I/O优化多路复用技术◀前面的版本中每个线程都要阻塞在recv等待对方的请求这来访问的人多了线程开的就多了大量线程都在阻塞系统运转速度也随之下降。这个时候你需要多路复用技术使用select模型将所有等待accept、recv都放在主线程里工作线程不需要再等待。过了一段时间之后网站访问的人越来越多了就连select也开始有点应接不暇老板继续让你优化性能。这个时候你需要升级多路复用模型为epoll。select有三弊epoll有三优。select底层采用数组来管理套接字描述符同时管理的数量有上限一般不超过几千个epoll使用树和链表来管理同时管理数量可以很大。select不会告诉你到底哪个套接字来了消息你需要一个个去询问。epoll直接告诉你谁来了消息不用轮询。select进行系统调用时还需要把套接字列表在用户空间和内核空间来回拷贝循环中调用select时简直浪费。epoll统一在内核管理套接字描述符无需来回拷贝。用上了epoll多路复用技术开发了3.0版本你的网站能同时处理很多用户请求了。但是贪心的老板还不满足不舍得升级硬件服务器却让你进一步提高服务器的吞吐量。你研究后发现之前的方案中工作线程总是用到才创建用完就关闭大量请求来的时候线程不断创建、关闭、创建、关闭开销挺大的。这个时候你需要03▶线程池技术◀我们可以在程序一开始启动后就批量启动一波工作线程而不是在有请求来的时候才去创建使用一个公共的任务队列请求来临时向队列中投递任务各个工作线程统一从队列中不断取出任务来处理这就是线程池技术。多线程技术的使用一定程度提升了服务器的并发能力但同时多个线程之间为了数据同步常常需要使用互斥体、信号、条件变量等手段来同步多个线程。这些重量级的同步手段往往会导致线程在用户态/内核态多次切换系统调用线程切换都是不小的开销。在线程池技术中提到了一个公共的任务队列各个工作线程需要从中提取任务进行处理这里就涉及到多个工作线程对这个公共队列的同步操作。有没有一些轻量级的方案来实现多线程安全的访问数据呢这个时候你需要04▶无锁编程技术◀多线程并发编程中遇到公共数据时就需要进行线程同步。而这里的同步又可以分为阻塞型同步和非阻塞型同步。阻塞型同步好理解我们常用的互斥体、信号、条件变量等这些操作系统提供的机制都属于阻塞型同步其本质都是要加“锁”。与之对应的非阻塞型同步就是在无锁的情况下实现同步目前有三类技术方案Wait-freeLock-freeObstruction-free三类技术方案都是通过一定的算法和技术手段来实现不用阻塞等待而实现同步这其中又以Lock-free最为应用广泛。Lock-free能够广泛应用得益于目前主流的CPU都提供了原子级别的read-modify-write原语这就是著名的CAS(Compare-And-Swap)操作。在Intel x86系列处理器上就是cmpxchg系列指令。// 通过CAS操作实现Lock-free do {... } while(!CAS(ptrold_datanew_data ))我们常常见到的无锁队列、无锁链表、无锁HashMap等数据结构其无锁的核心大都来源于此。在日常开发中恰当的运用无锁化编程技术可以有效地降低多线程阻塞和切换带来的额外开销提升性能。服务器上线了一段时间发现服务经常崩溃异常排查发现是工作线程代码bug一崩溃整个服务都不可用了。于是你决定把工作线程和主线程拆开到不同的进程中工作线程崩溃不能影响整体的服务。这个时候出现了多进程你需要05▶进程间通信技术◀提起进程间通信你能想到的是什么管道命名管道socket消息队列信号信号量共享内存以上各种进程间通信的方式详细介绍和比较推荐一篇文章一文掌握进程间通信这里不再赘述。对于本地进程间需要高频次的大量数据交互首推共享内存这种方案。现代操作系统普遍采用了基于虚拟内存的管理方案在这种内存管理方式之下各个进程之间进行了强制隔离。程序代码中使用的内存地址均是一个虚拟地址由操作系统的内存管理算法提前分配映射到对应的物理内存页面CPU在执行代码指令时对访问到的内存地址再进行实时的转换翻译。从上图可以看出不同进程之中虽然是同一个内存地址最终在操作系统和CPU的配合下实际存储数据的内存页面却是不同的。而共享内存这种进程间通信方案的核心在于如果让同一个物理内存页面映射到两个进程地址空间中双方不是就可以直接读写而无需拷贝了吗当然共享内存只是最终的数据传输载体双方要实现通信还得借助信号、信号量等其他通知机制。用上了高性能的共享内存通信机制多个服务进程之间就可以愉快的工作了即便有工作进程出现Crash整个服务也不至于瘫痪。不久老板增加需求了不再满足于只能提供静态网页浏览了需要能够实现动态交互。这一次老板还算良心给你加了一台硬件服务器。于是你用Java/PHP/Python等语言搞了一套web开发框架单独起了一个服务用来提供动态网页支持和原来等静态内容服务器配合工作。这个时候你发现静态服务和动态服务之间经常需要通信。一开始你用基于HTTP的RESTful接口在服务器之间通信后来发现用JSON格式传输数据效率低下你需要更高效的通信方案。这个时候你需要06▶RPC序列化技术◀什么是RPC技术RPC全称Remote Procedure Call远程过程调用。我们平时编程中随时都在调用函数这些函数基本上都位于本地也就是当前进程某一个位置的代码块。但如果要调用的函数不在本地而在网络上的某个服务器上呢这就是远程过程调用的来源。从图中可以看出通过网络进行功能调用涉及参数的打包解包、网络的传输、结果的打包解包等工作。而其中对数据进行打包和解包就需要依赖序列化技术来完成。什么是序列化技术序列化简单来说是将内存中的对象转换成可以传输和存储的数据而这个过程的逆向操作就是反序列化。序列化 反序列化技术可以实现将内存对象在本地和远程计算机上搬运。好比把大象关进冰箱门分三步将本地内存对象编码成数据流通过网络传输上述数据流将收到的数据流在内存中构建出对象序列化技术有很多免费开源的框架衡量一个序列化框架的指标有这么几个是否支持跨语言使用能支持哪些语言是否只是单纯的序列化功能包不包含RPC框架序列化传输性能扩展支持能力数据对象增删字段后前后的兼容性是否支持动态解析动态解析是指不需要提前编译根据拿到的数据格式定义文件立即就能解析下面流行的三大序列化框架protobuf、thrift、avro的对比ProtoBuf厂商Google支持语言C、Java、Python等动态性支持较差一般需要提前编译是否包含RPC否简介ProtoBuf是谷歌出品的序列化框架成熟稳定性能强劲很多大厂都在使用。自身只是一个序列化框架不包含RPC功能不过可以与同是Google出品的GPRC框架一起配套使用作为后端RPC服务开发的黄金搭档。缺点是对动态性支持较弱不过在更新版本中这一现象有待改善。总体来说ProtoBuf都是一款非常值得推荐的序列化框架。Thrift厂商Facebook支持语言C、Java、Python、PHP、C#、Go、JavaScript等动态性支持差是否包含RPC是简介这是一个由Facebook出品的RPC框架本身内含二进制序列化方案但Thrift本身的RPC和数据序列化是解耦的你甚至可以选择XML、JSON等自定义的数据格式。在国内同样有一批大厂在使用性能方面和ProtoBuf不分伯仲。缺点和ProtoBuf一样对动态解析的支持不太友好。Avro支持语言C、C、Java、Python、C#等动态性支持好是否包含RPC是简介这是一个源自于Hadoop生态中的序列化框架自带RPC框架也可独立使用。相比前两位最大的优势就是支持动态数据解析。为什么我一直在说这个动态解析功能呢在之前的一段项目经历中轩辕就遇到了三种技术的选型摆在我们面前的就是这三种方案。需要一个C开发的服务和一个Java开发的服务能够进行RPC。Protobuf和Thrift都需要通过“编译”将对应的数据协议定义文件编译成对应的C/Java源代码然后合入项目中一起编译从而进行解析。当时Java项目组同学非常强硬的拒绝了这一做法其理由是这样编译出来的强业务型代码融入他们的业务无关的框架服务而业务是常变的这样做不够优雅。最后经过测试最终选择了AVRO作为我们的方案。Java一侧只需要动态加载对应的数据格式文件就能对拿到的数据进行解析并且性能上还不错。当然对于C一侧还是选择了提前编译的做法自从你的网站支持了动态能力免不了要和数据库打交道但随着用户的增长你发现数据库的查询速度越来越慢。这个时候你需要07▶数据库索引技术◀想想你手上有一本数学教材但是目录被人给撕掉了现在要你翻到讲三角函数的那一页你该怎么办没有了目录你只有两种办法要么一页一页的翻要么随机翻直到找到三角函数的那一页。对于数据库也是一样的道理如果我们的数据表没有“目录”那要查询满足条件的记录行就得全表扫描那可就恼火了。所以为了加快查询速度得给数据表也设置目录在数据库领域中这就是索引。一般情况下数据表都会有多个字段那根据不同的字段也就可以设立不同的索引。索引的分类主键索引聚集索引非聚集索引主键我们都知道是唯一标识一条数据记录的字段也存在多个字段一起来唯一标识数据记录的联合主键那与之对应的就是主键索引了。聚集索引是指索引的逻辑顺序与表记录的物理存储顺序一致的索引一般情况下主键索引就符合这个定义所以一般来说主键索引也是聚集索引。但是这不是绝对的在不同的数据库中或者在同一个数据库下的不同存储引擎中还是有不同。聚集索引的叶子节点直接存储了数据也是数据节点而非聚集索引的叶子节点没有存储实际的数据需要二次查询。索引的实现原理索引的实现主要有三种B树哈希表位图其中B树用的最多其特点是树的节点众多相较于二叉树这是一棵多叉树是一个扁平的胖树减少树的深度有利于减少磁盘I/O次数适宜数据库的存储特点。哈希表实现的索引也叫散列索引通过哈希函数来实现数据的定位。哈希算法的特点是速度快常数阶的时间复杂度但缺点是只适合准确匹配不适合模糊匹配和范围搜索。位图索引相对就少见了。想象这么一个场景如果某个字段的取值只有有限的少数几种可能比如性别、省份、血型等等针对这样的字段如果用B树作为索引的话会出现什么情况会出现大量索引值相同的叶子节点这实际上是一种存储浪费。位图索引正是基于这一点进行优化针对字段取值只有少量有限项数据表中该列字段出现大量重复时就是位图索引一展身手的时机。所谓位图就是Bitmap其基本思想是对该字段每一个取值建立一个二进制位图来标记数据表的每一条记录的该列字段是否是对应取值。索引虽好但也不可滥用一方面索引最终是要存储到磁盘上的无疑会增加存储开销。另外更重要的是数据表的增删操作一般会伴随对索引的更新因此对数据库的写入速度也是会有一定影响。你的网站现在访问量越来越大了同时在线人数大大增长。然而大量用户的请求带来了后端程序对数据库大量的访问。渐渐的数据库的瓶颈开始出现无法再支持日益增长的用户量。老板再一次给你下达了性能提升的任务。08▶缓存技术布隆过滤器◀从物理CPU对内存数据的缓存到浏览器对网页内容的缓存缓存技术遍布于计算机世界的每一个角落。面对当前出现的数据库瓶颈同样可以用缓存技术来解决。每次访问数据库都需要数据库进行查表当然数据库自身也有优化措施反映到底层就是进行一次或多次的磁盘I/O但凡涉及I/O的就会慢下来。如果是一些频繁用到但又不会经常变化的数据何不将其缓存在内存中不必每一次都要找数据库要从而减轻对数据库对压力呢有需求就有市场有市场就会有产品以memcached和Redis为代表的内存对象缓存系统应运而生。缓存系统有三个著名的问题缓存穿透: 缓存设立的目的是为了一定层面上截获到数据库存储层的请求。穿透的意思就在于这个截获没有成功请求最终还是去到了数据库缓存没有产生应有的价值。缓存击穿: 如果把缓存理解成一面挡在数据库面前的墙壁为数据库“抵御”查询请求所谓击穿就是在这面墙壁上打出了一个洞。一般发生在某个热点数据缓存到期而此时针对该数据的大量查询请求来临大家一股脑的怼到了数据库。缓存雪崩: 理解了击穿那雪崩就更好理解了。俗话说得好击穿是一个人的雪崩雪崩是一群人的击穿。如果缓存这堵墙上处处都是洞那这面墙还如何屹立吃枣药丸。关于这三个问题的更详细阐述推荐一篇文章什么是缓存系统的三座大山。有了缓存系统我们就可以在向数据库请求之前先询问缓存系统是否有我们需要的数据如果有且满足需要我们就可以省去一次数据库的查询如果没有我们再向数据库请求。注意这里有一个关键的问题如何判断我们要的数据是不是在缓存系统中呢进一步我们把这个问题抽象出来如何快速判断一个数据量很大的集合中是否包含我们指定的数据这个时候就是布隆过滤器大显身手的时候了它就是为了解决这个问题而诞生的。那布隆过滤器是如何解决这个问题的呢先回到上面的问题中来这其实是一个查找问题对于查找问题最常用的解决方案是搜索树和哈希表两种方案。因为这个问题有两个关键点快速、数据量很大。树结构首先得排除哈希表倒是可以做到常数阶的性能但数据量大了以后一方面对哈希表的容量要求巨大另一方面如何设计一个好的哈希算法能够做到如此大量数据的哈希映射也是一个难题。对于容量的问题考虑到只需要判断对象是否存在而并非拿到对象我们可以将哈希表的表项大小设置为1个bit1表示存在0表示不存在这样大大缩小哈希表的容量。而对于哈希算法的问题如果我们对哈希算法要求低一些那哈希碰撞的机率就会增加。那一个哈希算法容易冲突那就多弄几个多个哈希函数同时冲突的概率就小的多。布隆过滤器就是基于这样的设计思路当设置对应的key-value时按照一组哈希算法的计算将对应比特位置1。但当对应的key-value删除时却不能将对应的比特位置0因为保不准其他某个key的某个哈希算法也映射到了同一个位置。也正是因为这样引出了布隆过滤器的另外一个重要特点布隆过滤器判定存在的实际上不一定存在但判定不存在的则一定不存在。你们公司网站的内容越来越多了用户对于快速全站搜索的需求日益强烈。这个时候你需要09▶全文搜索技术◀对于一些简单的查询需求传统的关系型数据库尚且可以应付。但搜索需求一旦变得复杂起来比如根据文章内容关键字、多个搜索条件但逻辑组合等情况下数据库就捉襟见肘了这个时候就需要单独的索引系统来进行支持。如今行业内广泛使用的ElasticSearch简称ES就是一套强大的搜索引擎。集全文检索、数据分析、分布式部署等优点于一身成为企业级搜索技术的首选。ES使用RESTful接口使用JSON作为数据传输格式支持多种查询匹配,为各主流语言都提供了SDK易于上手。另外ES常常和另外两个开源软件Logstash、Kibana一起形成一套日志收集、分析、展示的完整解决方案ELK架构。其中Logstash负责数据的收集、解析ElasticSearch负责搜索Kibana负责可视化交互成为不少企业级日志分析管理的铁三角。无论我们怎么优化一台服务器的力量终究是有限的。公司业务发展迅猛原来的服务器已经不堪重负于是公司采购了多台服务器将原有的服务都部署了多份以应对日益增长的业务需求。现在同一个服务有多个服务器在提供服务了需要将用户的请求均衡的分摊到各个服务器上这个时候你需要09▶负载均衡技术◀顾名思义负载均衡意为将负载均匀平衡分配到多个业务节点上去。和缓存技术一样负载均衡技术同样存在于计算机世界到各个角落。按照均衡实现实体可以分为软件负载均衡如LVS、Nginx、HAProxy和硬件负载均衡如A10、F5。按照网络层次可以分为四层负载均衡基于网络连接和七层负载均衡基于应用内容。按照均衡策略算法可以分为轮询均衡、哈希均衡、权重均衡、随机均衡或者这几种算法相结合的均衡。而对于现在遇到等问题可以使用nginx来实现负载均衡nginx支持轮询、权重、IP哈希、最少连接数目、最短响应时间等多种方式的负载均衡配置。轮询upstream web-server {server 192.168.1.100;server 192.168.1.101; }权重upstream web-server {server 192.168.1.100 weight1;server 192.168.1.101 weight2; }IP哈希值upstream web-server {ip_hash;server 192.168.1.100 weight1;server 192.168.1.101 weight2; }最少连接数目upstream web-server {least_conn;server 192.168.1.100 weight1;server 192.168.1.101 weight2; }最短响应时间:upstream web-server {server 192.168.1.100 weight1;server 192.168.1.101 weight2;fair;   } 10▶总结◀高性能是一个永恒的话题其涉及的技术和知识面其实远不止上面列出的这些。从物理硬件CPU、内存、硬盘、网卡到软件层面的通信、缓存、算法、架构每一个环节的优化都是通往高性能的道路。路漫漫其修远兮吾将上下而求索。往期推荐3 周带你 Get 大厂工程师基础能力CSDN 开学见面礼什么是自动驾驶这个数据仓库竟然把淘宝和京东干翻了。。被 AI 算法“监控”的打工人点分享点收藏点点赞点在看