首页 文章 精选 留言 我的

精选列表

搜索[大型语言模型],共10000篇文章
优秀的个人博客,低调大师

大型网站技术架构之秒杀系统架构设计

秒杀活动的技术挑战 1. 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必须会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪。 2. 高并发下的应用、数据库负载 用户在秒杀开始前,通过不停刷新浏览器页面以保证不会错过秒杀,这些请求如果按照一般的网站应用架构,访问应用服务器、连接数据库,会对应用服务器和数据库服务器造成极大的负载压力。 3. 突然增加的网络及服务器带宽 假设商品页面大小200K(主要是商品图片大小),那么需要的网络和服务器带宽是2G(200K×10000),这些网络带宽是因为秒杀活动新增的,超过网站平时使用的带宽。 4. 直接下单 秒杀的游戏规则是到了秒杀时间才能开始对商品下单购买,在此时间点之前,只能浏览商品信息,不能下单。而下单页面也只是一个普通的URL,如果得到这个URL,不用等到秒杀开始就可以下单了。 秒杀系统的应对策略 1. 秒杀系统独立部署 为了避免因为秒杀活动的高并发访问而拖垮整个网站,使整个网站不必面对蜂拥而来的用户访问,可将秒杀系统独立部署;如果需要,还可以使用独立的域名,使其与网站完全隔离,即使秒杀系统崩溃了,也不会对网站造成任何影响。 2. 秒杀商品页面静态化 重新设计秒杀商品页面,不使用网站原来的商品详情页面,页面内容静态化:将商品描述、商品参数、成交记录和用户评价全部写入一个静态页面,用户请求不需要经过应用服务器的业务逻辑处理,也不需要访问数据库。所以秒杀商品服务不需要部署动态的Web服务器和数据库服务器。 3. 租借秒杀活动网络带宽 因为秒杀新增的网络带宽,必须和运营商重新购买或者租借。为了减轻网站服务器的压力,需要将秒杀商品页面缓存在CDN,同样需要和CDN服务商临时租借新增的出口带宽。 4. 动态生成随机下单页面URL 为了避免用户直接访问下单页面URL,需要将该URL动态化,即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数,在秒杀开始的时候才能得到。 秒杀系统架构设计 秒杀系统为秒杀而设计,不同于一般的网购行为,参与秒杀活动的用户更关心的是如何能快速刷新商品页面,在秒杀开始的时候抢先进入下单页面,而不是商品详情等用户体验细节,因此秒杀系统的页面设计应尽可能简单。 商品页面中的购买按钮只有在秒杀活动开始的时候才变亮,在此之前及秒杀商品卖出后,该按钮都是灰色的,不可以点击。 下单表单也尽可能简单,购买数量只能是一个且不可以修改,送货地址和付款方式都使用用户默认设置,没有默认也可以不填,允许等订单提交后修改;只有第一个提交的订单发送给网站的订单子系统,其余用户提交订单后只能看到秒杀结束页面。 除了上面提到的秒杀系统的技术挑战及应对策略,还有一些其他问题需要处理。 1. 如何控制秒杀商品页面购买按钮的点亮 购买按钮只有在秒杀开始的时候才能点亮,在此之前是灰色的。如果该页面是动态生成的,当然可以在服务器端构造响应页面输出,控制该按钮是灰色还 是点亮,但是为了减轻服务器端负载压力,更好地利用CDN、反向代理等性能优化手段,该页面被设计为静态页面,缓存在CDN、反向代理服务器上,甚至用户 浏览器上。秒杀开始时,用户刷新页面,请求根本不会到达应用服务器。 解决办法是使用JavaScript脚本控制,在秒杀商品静态页面中加入一个JavaScript文件引用,该JavaScript文件中包含 秒杀开始标志为否;当秒杀开始的时候生成一个新的JavaScript文件(文件名保持不变,只是内容不一样),更新秒杀开始标志为是,加入下单页面的 URL及随机数参数(这个随机数只会产生一个,即所有人看到的URL都是同一个,服务器端可以用redis这种分布式缓存服务器来保存随机数),并被用户 浏览器加载,控制秒杀商品页面的展示。这个JavaScript文件的加载可以加上随机版本号(例如xx.js?v=32353823),这样就不会被浏 览器、CDN和反向代理服务器缓存。 这个JavaScript文件非常小,即使每次浏览器刷新都访问JavaScript文件服务器也不会对服务器集群和网络带宽造成太大压力。 2. 如何只允许第一个提交的订单被发送到订单子系统 由于最终能够成功秒杀到商品的用户只有一个,因此需要在用户提交订单时,检查是否已经有订单提交。如果已经有订单提交成功,则需要更新 JavaScript文件,更新秒杀开始标志为否,购买按钮变灰。事实上,由于最终能够成功提交订单的用户只有一个,为了减轻下单页面服务器的负载压力, 可以控制进入下单页面的入口,只有少数用户能进入下单页面,其他用户直接进入秒杀结束页面。假设下单服务器集群有10台服务器,每台服务器只接受最多10 个下单请求。在还没有人提交订单成功之前,如果一台服务器已经有十单了,而有的一单都没处理,可能出现的用户体验不佳的场景是用户第一次点击购买按钮进入 已结束页面,再刷新一下页面,有可能被一单都没有处理的服务器处理,进入了填写订单的页面,可以考虑通过cookie的方式来应对,符合一致性原则。当然 可以采用最少连接的负载均衡算法,出现上述情况的概率大大降低。 小结 秒杀是对网站架构的极大考验,在难以预计和控制的高并发访问的冲击下,稍有不慎,系统就会被用户秒杀,导致整个系统宕机,活动失败,构成重大事故。因此在 遵循秒杀活动游戏规则的基础上,为了保证系统的安全,保持适度的公平公正即可。即使系统出了故障,也不应该给用户显示出错页面,而是显示秒杀活动结束页 面,避免不必要的困扰。 本文转自邴越博客园博客,原文链接:http://www.cnblogs.com/binyue/p/4238888.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

大型网站技术架构——核心原理与案例分析(三)

集群环境下,Session管理的主要方式: 1、Session复制 适用于集群规模较小 2、Session绑定 将来源于同一IP的地址,分配到固定的服务器 3、利用Cookie记录Session 缺点 Cookie受大小限制,如果关闭Cookie,访问就会受限。、 4、Session服务器 将应用服务器状态分离、分离成有状态的Session服务器,无状态的应用服务器 高可用服务的策略: 1、分级管理 2、超时设置 3、异步调用 4、服务降级、拒绝服务 关闭功能 5、幂等性设计 指应用调用服务失败后,会将调用请求重新发送到其他服务器,但是这个失败可能是虚假的失败。缺点,服务重复调用是无法避免的,因此必须在服务层保证服务重复调用和调用一次产生的结果相同,即服务具有幂等性。 高可用的数据 保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本,失效转移机制是保证当一个数据副本不可访问时,可以快速切换访问数据的其他副本。 高可用数据有以下几层含义: 1、数据持久性 2、数据可访问性 3、数据一致性 CAP原理 数据一致性(Consisency): a、数据强一致:各个副本数据在物理存储中总是一致的 b、数据用户一致 :即数据在物理存储中各个副本的数据可能不一致,但是终端用户访问时,通过纠错和校验机制,可以确定一个一致的且正确的数据返回给用户 c、数据最终一致、系统经过一段时间(比较短)的自我修复和修正,数据最终达到一致 数据可用性(Avalibility) 分区耐受性(Patition) 数据备份: 冷备: 热备:Master - Slave 失效转移 1、失效确认(心跳检测和应用程序访问失败报告) 2、访问转移 3、数据恢复 高可用网站的软件质量保证: 1、网站发布 集群中一部分的替换 2、自动化测试 3、预发布验证 4、代码控制 5、自动发布 6、灰度发布 7、网站运行监控(重点)

优秀的个人博客,低调大师

大型网站技术架构——核心原理与案例分析(二)

网站高性能架构 一、性能测试指标 1.1、响应时间 1.2、并发数 指系统能够同时处理请求的数目,反映了系统的负载特性 1.3、吞吐量 TPS(每秒事务数) HPS(每秒HTTP请求数) QPS(每秒查询数)等 1.4、性能计数 包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标 二、性能测试方法 2.1、性能测试 与初期规划的性能指标为预期目标,不断施加压力,验证是否在可接受范围,性能是否能达到性能预期 2.2、负载测试 不断地增加并发请求以增加系统压力,直到系统的某项或是多项性能指标大致安全临界值 2.3、压力测试 超过安全负载的情况下,对系统继续施加压力,直到系统崩溃或不能再处理任何请求,以此获得系统最大压力承受能力。 2.4、稳定性测试 三、性能优化 根据网站分层架构,可分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化。 3.1、Web前端性能优化 3.1.1 浏览器访问优化 A、减少http请求 HTTP每次都要建立通信链路,进行数据传输,服务端,会启动独立的线程去处理,这些开销都很昂贵,减少HTTP请求的数据目可以有效提高访问性能。主要手段:合并CSS、合并JavaScript、合并图片 B、使用浏览器缓存 对静态资源文件可以缓存在浏览器中,通过设置HTTP头中的Cache-Control和Expires属性,可以设置浏览器缓存,针对JavaScript可以通过改变文件名实现,浏览器缓存策略在更新静态资源 时,应采用批量更新的方法,不宜一次全部更新 C、启用压缩,在服务器端对文件进行压缩,在浏览器端对文件解压,一般采用GZip压缩可达80%的压缩率 D、CSS文件放在页面最上面、JavaScript放在页面最下面(这一点深有体会) E、减少Cookie传输 3.1.2 CDN加速 3.1.3 反向代理 除了安全功能、代理服务器也可能通过配置缓存功能加速Web请求 3.2 应用服务器性能优化 3.2.1 分布式缓存 缓存的本质是一个内存Hash表,缓存主要存放那些读写比很高、很少变化的热数据。网站数据访问一般遵循二八定律、即80%的访问落在20%的数据上,将这20%的数据缓存起来,可以很好的地改善系统性能。提高数据读取速度 、降低存储访问压力 使用缓存时要注意缓存穿透(恶意的) 目前成熟的缓存产品有Memcached、Redis 3.2.2 异步操作 任何可以晚点做的事情都应该晚点再做 3.2.3 使用集群 3.2.4 代码优化 A、使用多线程 B、资源复用 单例 对象池 C、数据结构 如Time33可以很好的解决hash冲突 D、垃圾回收 垃圾回收可能会对系统的性能特性产生巨大影响,理解垃圾回收机制有助于程序优化和参数调优。 3.3 存储性能优化 3.3.1 机械硬盘 VS 固态硬盘 3.3.2 B+树 VS LSM树 传统机械磁盘具有快速顺序读写、慢速随机读写的访问特性,这个特性对磁盘存储结构和算法的选择影响很大。 传统的关系型数据库使用的是B+树。 目前许多NoSQL采用的LSM树 什么是LSM树:核心思想的核心就是放弃部分读能力,换取写入的最大化能力。LSM Tree ,这个概念就是结构化合并树的意思,它的核心思路其实非常简单,就是假定内存足够大,因此不需要每次有数据更新就必须将数据写入到磁盘中,而可以先将最新的数据驻留在磁盘中,等到积累到最后多之后,再使用归并排序的方式将内存内的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的,可以通过合并排序的方式快速合并到一起)。 3.3.3 RAID(廉价磁盘冗余阵列) VS HDFS RAID的技术有(以下假设有N块磁盘) RAID0、将数据分成N份,同时并发写N块磁盘,是一块磁盘的N倍,缺点,不做备份,一块磁盘出损坏,数据完整性被破坏 RAID1 写入时将数据同时写入两块磁盘, RAID10 结合RAID0 RAID1 缺点 对磁盘的利用率不高 RAID3 将数据分成N-1份,并发写入N-1块磁盘,在第N块磁盘记录校验数据,作何一块磁盘损坏,可以利用其他N-1块磁盘的数据修复。缺点,任何修改都会导致第N块磁盘重写校验数据,N磁盘容易损坏。RAID3很少在实践中使用 RAID5 与RAID3原理类似,但被更多使用,原因校验数据不是写入第N块磁盘,而是螺旋式地写入到所有的磁盘中,这样校验数据的修改被平均到所有磁盘上。 RAID6 与 RAID5类似,但是数据只写入N-2块磁盘,并螺旋式地在两块磁盘中写入校验信息 HDFS,以块为单位管理文件,当应用程序写文件时,每写完一个Block,HDFS就将其自动复制到另外两台机器上,保证每个Block有三个副本。 HDFS两个重要的服务器角色NameNode(只部署一个)、DataNode 性能优化的最终目的是改善用户体验,让他们感觉网站很高。

优秀的个人博客,低调大师

人脸识别如何在大型银行中大规模商用?

人脸识别已经在金融领域大显身手,很多明星AI公司均具备了完成“刷脸”的能力。 国内众多银行也开始大范围使用人脸识别技术,把其应用在手机银行刷脸登录、辅助远程坐席和柜员客户身份核验以及小额支付等业务当中,但真正把“刷脸取款”服务应用在线下ATM自动取款机中的银行却非常少。 目前把“刷脸取款”在全国范围内大规模应用的只有农业银行和招商银行,其中农行的刷脸取款服务则覆盖了全国2万多个分支机构,深入到县乡镇。 作为农行2万家刷脸取款服务的软硬件算法方案提供商,云从科技在成立2年的时间里推出了48种银行业解决方案,连接ATM/VTM、人证合一、红外双目等多种硬件的金融科技平台。 在本期雷锋网(公众号:雷锋网)公开课上,云从科技金融事业部总经理张兴旺基于自己多年的研究和行业经验,从“刷脸取款”切入,深入分享 AI 技术将怎样以全产业链、智能硬件和大数

优秀的个人博客,低调大师

由大型物联网僵尸网络驱动的DDoS攻击

基于物联网设备的僵尸网络 随着信息安全技术的不断发展,物联网僵尸网络现在也成为了信息安全领域内最为危险的安全威胁之一。近期,我们检测到了两起由这些物联网基础设施所驱动的网络攻击,而这两次攻击的规模是我们此前从未见到过的。 安全研究人员在报告中指出,近期由物联网僵尸网络驱动的DDoS攻击(分布式拒绝服务攻击)用大量恶意HTTP流量对目标网站进行了攻击。在某个特定的时段内,流量峰值曾一度超过了每秒一百万个请求数。据了解,这些基于物联网设备的僵尸网络其背后的始作俑者就是Mirai恶意软件,攻击者可以利用这款恶意软件来扫描网络中存在漏洞的物联网设备。 为此,Cloudflare公司的安全研究专家对近期的两起基于物联网僵尸网络的DDoS攻击进行了分析,并且发布了相关的研究报告。这两次攻击可以算得上是DDoS攻击历史上的一个里程碑了,因为攻击者已经不再像往常一样针对网络层来进行攻击了,现在他们发动的是针对HTTP应用层的攻击。 恶意流量分析 根据该公司透露的信息,他们的自动化DDoS攻击防护系统检测到了这次DDoS攻击。在收集到了相关数据之后,该公司的安全研究人员对攻击进行了详细分析,并且得到了此次攻击中每秒并发的HTTP请求数量。 经过Cloudflare公司的确认,这两次DDoS攻击的峰值超过了每秒钟175万次请求,其中发动攻击的独立IP地址数量总共有52,000个。具体数据如下图所示: Cloudflare公司的安全研究人员在报告中说到: “此次攻击总共持续了将近十五分钟,从01:40起攻击流量就开始逐渐增加,并且迅速超过了1Mrps,大约在01:50时达到了流量峰值(1.75Mrps)。需要注意的是,这些HTTP请求的平均长度只有121个字节,而且HTTP头部也没有任何其他的数据。统计数据显示,总共有52,467个独立的IP地址参与到了此次的攻击中。” Cloudflare公司的这份安全研究报告显示,此次攻击是由上百个匿名网络系统所驱动的,其中恶意流量贡献最多的网络系统来源于乌克兰(AS15895)和越南(AS45899)。 除了上述这个DDoS攻击之外,Cloudflare的报告中还提及到了另外一起DDoS攻击事件。在这一DDoS攻击中,流量峰值达到了360Gbps,并且利用了更长的HTTP请求。 这次DDoS攻击持续了大约一个小时,参与攻击的独立IP地址数量有128,833个,其中大部分攻击流量来源于德国的法兰克福。 Cloudflare在报告中提到: “这次DDoS攻击的HTTP请求中带有很长的payload,这也就使得攻击者可以产生大量有杀伤力的恶意流量。攻击者有时会使用GET请求来进行这种攻击,但有时他们也会使用POST请求。除此之外,这次特殊的DDoS攻击持续了大约一个小时,总共有128,833个独立IP地址参与到了此次攻击中。” 通过对参与了这两次新型DDoS攻击的物联网设备进行分析之后,我们可以看到这些物联网设备并没有对流经端口23(telnet)的数据流量进行过滤。 分析结果表明,越南网络系统中绝大多数的物联网设备为联网的监控摄像头,而这些摄像头的80端口基本上都处于开放状态。 物联网设备的安全问题不容小觑 为了了解目前物联网设备的安全问题,安全研究人员使用Shodan搜索引擎来对存在安全漏洞的物联网设备进行了一次大规模扫描。扫描结果显示,目前网络中大约有五十多万台物联网设备中存在安全漏洞。其中受影响最为严重的前三个国家分别为越南(80,000台)、巴西(62,000台)和土耳其(40,000台)。具体数据如下图所示: 未来还会发生什么? 目前,大规模的DDoS攻击仍然会影响全球的Web服务。由于物联网设备中存在着各种各样的安全问题,使得它们成为了攻击者首选的攻击面。 不仅如此,随着物联网的不断发展,越来越多会接入互联网,例如冰箱、洗衣机、健身追踪器、以及睡眠监测系统等等。所以攻击者肯定不会放过任何的机会,他们肯定会继续尝试利用物联网设备来进行网络攻击。所以无论是信息安全领域的从业人员,还是物联网设备的制造商,现在是时候认真考虑一下物联网设备的安全性问题了。 作者:Alpha_h4ck 来源:51CTO

优秀的个人博客,低调大师

Scrapy大型爬虫框架讲解【一】

这是Scrapy爬虫框架的第一篇,本系列专题将包含以下内容: 介绍Scrapy框架的主体以及各个组件的意义; 举实例讲解其具体应用。 开始第一节:介绍Scrapy框架的主体以及各个组件的意义。 Scrapy是一个为了爬取网站数据,提取结构性数据而编写的应用框架。 可以应用在包括数据挖掘,信息处理或存储历史数据等一系列的程序中。 其最初是为了 页面抓取 (更确切来说, 网络抓取 )所设计的, 也可以应用在获取API所返回的数据(例如 Amazon Associates Web Services ) 或者通用的网络爬虫。 安装Scrapy需要一些依赖: Python Python Package: pip and setuptools. 现在 pip 依赖 setuptools ,如果未安装,则会自动安装setuptools 。 lxml. 大多数Linux发行版自带了lxml。如果缺失,请查看 Installing lxml OpenSSL. 除了Windows(请查看 平台安装指南)之外的系统都已经提供。 当安装好这些依赖之后,只需要运行pip install Scrapy,即可安装完Scrapy。 然后运行: scrapystartprojecttutorial 即可自动创建官方标准的代码目录。 tutorial/ scrapy.cfg tutorial/ __init__.py items.py pipelines.py settings.py spiders/ __init__.py ... 其中: tutorial/: 该项目的python总模块。 tutorial/items.py: 项目中的item文件,编写爬取的字段名称等; tutorial/pipelines.py: 项目中的pipelines文件; tutorial/settings.py: 项目的设置文件,较为重要; tutorial/spiders/: 放置spider代码的主目录; Scrapy整体架构神图: Scrapy中的数据流由执行引擎控制,其过程如下: 引擎打开一个网站(open a domain),找到处理该网站的Spider并向该spider请求第一个要爬取的URL(s)。 引擎从Spider中获取到第一个要爬取的URL并在调度器(Scheduler)以Request调度。 引擎向调度器请求下一个要爬取的URL。 调度器返回下一个要爬取的URL给引擎,引擎将URL通过下载中间件(请求(request)方向)转发给下载器(Downloader)。 一旦页面下载完毕,下载器生成一个该页面的Response,并将其通过下载中间件(返回(response)方向)发送给引擎。 引擎从下载器中接收到Response并通过Spider中间件(输入方向)发送给Spider处理。 Spider处理Response并返回爬取到的Item及(跟进的)新的Request给引擎。 引擎将(Spider返回的)爬取到的Item给Item Pipeline,将(Spider返回的)Request给调度器。 (从第二步)重复直到调度器中没有更多地request,引擎关闭该网站。 以上是老生常谈,下面谈一些经验: 如果需要大批量分布式爬取,建议采用Redis数据库存储,可安装scrapy-redis,使用redis数据库来替换scrapy原本使用的队列结构(deque),并配合其它数据库存储,例如MySQL或者MongoDB,爬取效率将会极大提高。并且其自带的dupefilter.py负责执行requst的去重,使用redis的set数据结构,通过settings文件正确设置后,即便停止scrapy爬虫,当下次重新开始后也能自动去重。原因就是在redis已经存储了request的信息。 当涉及到代理IP,Headers头中间请求信息处理的时候,可以通过中间件Middleware来实现。Spider中间件是介入到Scrapy的spider处理机制的钩子框架,可以添加代码来处理发送给 Spiders的response及spider产生的item和request。 合理设置settings文件,需要熟练掌握 settings 的各种设置。 可以重新定义def start_requests(self)函数来加载cookie信息,form信息的提交用scrapy.FormRequest以及scrapy.FormRequest.from_response这两个函数,scrapy.FormRequest.from_response能实现自动提交form数据。 采用Scrapy+phantomJS,。 downloadMiddleware 对从 scheduler 送来的 Request 对象在请求之前进行预处理,可以实现添加 headers, user_agent,还有 cookie 等功能 。但也可以通过中间件直接返回 HtmlResponse 对象,略过请求的模块,直接扔给 response 的回调函数处理。 classCustomMetaMiddleware(object): defprocess_request(self,request,spider): dcap=dict(DesiredCapabilities.PHANTOMJS) dcap["phantomjs.page.settings.loadImages"]=False dcap["phantomjs.page.settings.resourceTimeout"]=10 driver=webdriver.PhantomJS("D:xx\xx",desired_capabilities=dcap) driver.get(request.url) body=driver.page_source.encode('utf8') url=driver.current_url driver.quit() returnHtmlResponse(request.url,body=body) 综上,是对Scrapy的各个组件一些个人的经验总结。 本文作者:蚍蜉撼大树 来源:51CTO

优秀的个人博客,低调大师

大型网站架构 - 1.架构的演变过程

1. 第一阶段:单服务器架构 这一阶段是我们的起步阶段,比如我们创业的时候刚购买了一台云主机。 在这一阶段,为了节约成本,我们将所有的应用程序,数据库,文件全部放在这台服务器上。 然后,CPU或者内存的成本在开发阶段也使用最小能接受的成本,然后开始我们的服务器开发之路。 2. 第二阶段:应用服务和数据服务分离 随着网站的第一次上线,我们的网站如果运营得不错的话,在这之后应该会逐渐积累人气,业务 也会随着人气的发展而进一步发展。 这个时候,1台服务器显然不能满足需求了,越来越多的用户访问导致性能变差,与此同时,数据也逐渐 变多,我们考虑增加硬盘。 这个时候,首先想到的就是:将应用和数据分离 于是,网站架构变成3台服务器:应用服务器(Web Server), 文件服务器(Resource Server), 数据库服务器(Database Server) 对于3台服务器的配置要求不太一样: Web Server: 需要处理大量的业务,需要更快的CPU。 Database Server: 需要快速检索数据和存放更多的数据,需要更大更快的硬盘,硬盘最好也是固态硬盘为主。 Resource Server: 需要存放用户上传的文件,如照片,视频等等,需要更大的硬盘,硬盘大一点,但是普通硬盘即可。 3. 第三阶段:使用缓存改善网站性能 网站业务遵循二八原则,80%的业务集中在20%的数据上。 因此,如果把这一小部分数据缓存起来,就可以i暗哨数据库访问的压力。 在初始阶段可以使用一些本地服务器的内存缓存,随着业务的扩展, 可以增加远程分布式的缓存服务器,应用一些成熟的框架,如: Redis 4. 第四阶段:应用服务器集群增加并发处理能力 集群已经显然成为现代网站处理高并发,海量数据的常规手段。 当1台服务器性能不足时,我们首先考虑的不应当是更换强大的服务器,而是应该增加服务器。 这个时候,我们的架构中应该引入负载均衡调度服务器,然后请求经过负载均衡服务器,分发到位于集群上的各个 应用服务器。 5. 第五阶段:数据库读写分离 缓存并不能解决所有的数据库问题,仍有很大一部分数据由于某些原因(缓存不命中,缓存过期)需要访问数据库。 通过设置数据库的主从备份结构,可以将主数据库的数据同步更新到另外的数据库上。 从而架构改为,将数据写入主数据库,而从数据库负责读取数据。 6. 第六阶段:使用反向代理和CDN加速网站响应 CDN和反向代理的基本原理都是缓存。 区别: CDN部署在网络提供商的机房,用户可以从距离自己最近的网络提供商机房获取数据。 反向代理部署在网站的中心机房。 7. 第七阶段:使用分布式文件系统和分布式数据库 数据库需要进行拆分,拆分一般根据业务进行拆分, 将不同的数据库部署在不同的物理服务器上。 再进一步,我们可以引入NoSql和搜索引擎。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册