首页 文章 精选 留言 我的

精选列表

搜索[Vite构建]，共10000篇文章
优秀的个人博客,低调大师

利用memcached构建高性能的Web应用程序

面临的问题 对于高并发高访问的Web应用程序来说，数据库存取瓶颈一直是个令人头疼的问题。特别当你的程序架构还是建立在单数据库模式，而一个数据池连接数峰值已经达到500的时候，那你的程序运行离崩溃的边缘也不远了。很多小网站的开发人员一开始都将注意力放在了产品需求设计上，缺忽视了程序整体性能，可扩展性等方面的考虑，结果眼看着访问量一天天网上爬，可突然发现有一天网站因为访问量过大而崩溃了，到时候哭都来不及。所以我们一定要未雨绸缪，在数据库还没罢工前，想方设法给它减负，这也是这篇文章的主要议题。 大家都知道，当有一个request过来后，web服务器交给app服务器，app处理并从db中存取相关数据，但db存取的花费是相当高昂的。特别是每次都取相同的数据，等于是让数据库每次都在做高耗费的无用功，数据库如果会说话，肯定会发牢骚，你都问了这么多遍了，难道还记不住吗？是啊，如果app拿到第一次数据并存到内存里，下次读取时直接从内存里读取，而不用麻烦数据库，这样不就给数据库减负了？而且从内存取数据必然要比从数据库媒介取快很多倍，反而提升了应用程序的性能。 因此，我们可以在web/app层与db层之间加一层cache层，主要目的：1. 减少数据库读取负担；2. 提高数据读取速度。而且，cache存取的媒介是内存，而一台服务器的内存容量一般都是有限制的，不像硬盘容量可以做到TB级别。所以，可以考虑采用分布式的cache层，这样更易于破除内存容量的限制，同时又增加了灵活性。 Memcached 介绍 Memcached是开源的分布式cache系统，现在很多的大型web应用程序包括facebook，youtube，wikipedia，yahoo等等都在使用memcached来支持他们每天数亿级的页面访问。通过把cache层与他们的web架构集成，他们的应用程序在提高了性能的同时，还大大降低了数据库的负载。具体的memcached资料大家可以直接从它的官方网站[1]上得到。这里我就简单给大家介绍一下memcached的工作原理： Memcached处理的原子是每一个（key，value）对（以下简称kv对），key会通过一个hash算法转化成hash-key，便于查找、对比以及做到尽可能的散列。同时，memcached用的是一个二级散列，通过一张大hash表来维护。 Memcached有两个核心组件组成：服务端（ms）和客户端（mc），在一个memcached的查询中，mc先通过计算key的hash值来确定kv对所处在的ms位置。当ms确定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以memcached交互带给网络的影响是最小化的。 举例说明：考虑以下这个场景，有三个mc分别是X，Y，Z，还有三个ms分别是A，B，C： 设置kv对X想设置key=”foo”,value=”seattle”X拿到ms列表，并对key做hash转化，根据hash值确定kv对所存的ms位置B被选中了X连接上B，B收到请求，把（key=”foo”,value=”seattle”）存了起来 获取kv对Z想得到key=”foo”的valueZ用相同的hash算法算出hash值，并确定key=”foo”的值存在B上Z连接上B，并从B那边得到value=”seattle”其他任何从X，Y，Z的想得到key=”foo”的值的请求都会发向B Memcached服务器(ms) 内存分配 默认情况下，ms是用一个内置的叫“块分配器”的组件来分配内存的。舍弃c++标准的malloc/free的内存分配，而采用块分配器的主要目的是为了避免内存碎片，否则操作系统要花费更多时间来查找这些逻辑上连续的内存块（实际上是断开的）。用了块分配器，ms会轮流的对内存进行大块的分配，并不断重用。当然由于块的大小各不相同，当数据大小和块大小不太相符的情况下，还是有可能导致内存的浪费。 同时，ms对key和data都有相应的限制，key的长度不能超过250字节，data也不能超过块大小的限制 --- 1MB。因为mc所使用的hash算法，并不会考虑到每个ms的内存大小。理论上mc会分配概率上等量的kv对给每个ms，这样如果每个ms的内存都不太一样，那可能会导致内存使用率的降低。所以一种替代的解决方案是，根据每个ms的内存大小，找出他们的最大公约数，然后在每个ms上开n个容量=最大公约数的instance，这样就等于拥有了多个容量大小一样的子ms，从而提供整体的内存使用率。 缓存策略 当ms的hash表满了之后，新的插入数据会替代老的数据，更新的策略是LRU（最近最少使用），以及每个kv对的有效时限。Kv对存储有效时限是在mc端由app设置并作为参数传给ms的。 同时ms采用是偷懒替代法，ms不会开额外的进程来实时监测过时的kv对并删除，而是当且仅当，新来一个插入的数据，而此时又没有多余的空间放了，才会进行清除动作。 缓存数据库查询现在memcached最流行的一种使用方式是缓存数据库查询，下面举一个简单例子说明： App需要得到userid=xxx的用户信息，对应的查询语句类似： “SELECT * FROM users WHERE userid = xxx” App先去问cache，有没有“user:userid”（key定义可预先定义约束好）的数据，如果有，返回数据；如果没有，App会从数据库中读取数据，并调用cache的add函数，把数据加入cache中。 当取的数据需要更新，app会调用cache的update函数，来保持数据库与cache的数据同步。 从上面的例子我们也可以发现，一旦数据库的数据发现变化，我们一定要及时更新cache中的数据，来保证app读到的是同步的正确数据。当然我们可以通过定时器方式记录下cache中数据的失效时间，时间一过就会激发事件对cache进行更新，但这之间总会有时间上的延迟，导致app可能从cache读到脏数据，这也被称为狗洞问题。（以后我会专门描述研究这个问题） 数据冗余与故障预防 从设计角度上，memcached是没有数据冗余环节的，它本身就是一个大规模的高性能cache层，加入数据冗余所能带来的只有设计的复杂性和提高系统的开支。 当一个ms上丢失了数据之后，app还是可以从数据库中取得数据。不过更谨慎的做法是在某些ms不能正常工作时，提供额外的ms来支持cache，这样就不会因为app从cache中取不到数据而一下子给数据库带来过大的负载。 同时为了减少某台ms故障所带来的影响，可以使用“热备份”方案，就是用一台新的ms来取代有问题的ms，当然新的ms还是要用原来ms的IP地址，大不了数据重新装载一遍。 另外一种方式，就是提高你ms的节点数，然后mc会实时侦查每个节点的状态，如果发现某个节点长时间没有响应，就会从mc的可用server列表里删除，并对server节点进行重新hash定位。当然这样也会造成的问题是，原本key存储在B上，变成存储在C上了。所以此方案本身也有其弱点，最好能和“热备份”方案结合使用，就可以使故障造成的影响最小化。 Memcached客户端（mc） Memcached客户端有各种语言的版本供大家使用，包括java，c，php，.net等等，具体可参见memcached api page[2]。大家可以根据自己项目的需要，选择合适的客户端来集成。 缓存式的Web应用程序架构有了缓存的支持，我们可以在传统的app层和db层之间加入cache层，每个app服务器都可以绑定一个mc，每次数据的读取都可以从ms中取得，如果没有，再从db层读取。而当数据要进行更新时，除了要发送update的sql给db层，同时也要将更新的数据发给mc，让mc去更新ms中的数据。 假设今后我们的数据库可以和ms进行通讯了，那可以将更新的任务统一交给db层，每次数据库更新数据的同时会自动去更新ms中的数据，这样就可以进一步减少app层的逻辑复杂度。如下图： 不过每次我们如果没有从cache读到数据，都不得不麻烦数据库。为了最小化数据库的负载压力，我们可以部署数据库复写，用slave数据库来完成读取操作，而master数据库永远只负责三件事：1.更新数据；2.同步slave数据库；3.更新cache。如下图： 以上这些缓存式web架构在实际应用中被证明是能有效并能极大地降低数据库的负载同时又能提高web的运行性能。当然这些架构还可以根据具体的应用环境进行变种，以达到不同硬件条件下性能的最优化。 未来的憧憬Memcached的出现可以说是革命性的，第一次让我们意识到可以用内存作为存储媒介来大规模的缓存数据以提高程序的性能。不过它毕竟还是比较新的东西，还需要很多有待优化和改进的地方，例如：如何利用memcached实现cache数据库，让数据库跑在内存上。这方面，tangent software 开发的memcached_engine[3]已经做了不少工作，不过现在的版本还只是处于实验室阶段。如何能方便有效的进行批量key清理。因为现在key是散列在不同的server上的，所以对某类key进行大批量清理是很麻烦的。因为memcached本身是一个大hash表，是不具备key的检索功能的。所以memcached是压根不知道某一类的key到底存了多少个，都存在哪些server上。而这类功能在实际应用中却是经常用到。
2017-10-08
优秀的个人博客,低调大师

《虚拟数据中心构建指南》——3.11 VMware 存储API

3.11 VMware 存储API VMware提供的API允许管理员和发布者扩展vSphere 5功能。 3.11.1 vStorage API for Array Intergration vStorage API for Array Intergration（VAAI）是一组应用编程接口，提供VMware和存储阵列制造商之间的互操作性，以更智能的方式与VMware通信。有些任务负载可以转移到存储阵列，减轻ESXi主机的负载。 注意：处理器制造商已经在芯片中集成了Intel VT和AMDV指令，减少高消耗的CPU侦听。处理器制造商对服务器所做的正是VAAI对存储阵列所做的。这些API现在对于获得高级别的整合似乎是必不可少的。 表3-4列出了vSphere 4.1中的VAAI和vSphere 5中的VAAI2。 下面是表3-4中列出的各种特性的简单说明。 硬件加速锁：没有这个API，SCSI保留就会在全局LUN级别上完成。有了这个API，SCSI保留工作在块级别而不是LUN级别上完成，这样与SCSI保留相关的问题较少，而且减少了VM启动的时间，在虚拟桌面基础架构（VDI）项目中更是如此。 硬件加速置零：没有这个API，创建数据存储时，“置零”由服务器完成，服务器向存储阵列发送SCSI命令。有了这个API，ESX服务器初始化一个命令，存储阵列负责重复这个操作并在结束时通知ESX服务器。这减少了ESXi服务器和存储阵列之间的流量。 硬件加速复制：没有这个API，复制操作从ESX服务器向存储阵列进行。有了这个API，数据由存储阵列的阵列中移动，没有通过服务器。这减少了ESXi服务器的负载和数据迁移所需的时间。 在vSphere 5中，为VAAI 2定义了一些新的概念：死空间回收（Dead Space Reclaim）：当虚拟磁盘被删除，或者精简配置LUN上使用Storage vMotion将一个虚拟磁盘从数据存储中迁移到另一个数据存储之后，可以恢复不再使用的空间。ESXi 5.0通过VAAI命令将释放数据块的有关信息发送给存储系统，然后存储系统恢复这些数据块。 精简配置空间用尽（Thin Provisoning Out of Space）API：预防精简配置LUN上的存储空间问题。 精简配置LUN报告：在vCenter中可以识别使用的存储阵列。 超过限额：当数据存储中超过容量阈值时，在vCenter中显示警告。 空间用尽行为：VM在写入之前确定空间是否足够。如果存储空间已满，在vCenter中显示警告信息，然后VM暂停（其他VM继续运行）。 NAS VAAI存储定义了如下概念。 全文件复制：NAS可以冷方式进行vmdk文件的复制和快照操作，类似于VMFS块复制（全复制）。扩展统计：可以看到NFS数据存储上已经消耗的空间。空间保留：允许为NAS存储创建厚配置模式vmdk文件。 3.11.2 vSphere 存储API：存储感知 vStorage API for Storage Awareness（VASA）是一个存储检测API，可直接从vCenter进行存储阵列相关信息的虚拟化，这些信息包括复制、RAID类型、压缩、重复数据消除、精简或者厚格式、磁盘类型、快照状态和性能（IOPS/MBps）。此外，vStorage API可用于配置驱动存储。 3.12 多路径 多路径（multipathing）可以定义为使用冗余组件（如适配器和交换机）以创建服务器和存储设备之间逻辑路径的一种解决方案。 3.12.1 可插入存储架构 可插入存储架构（Pluggable Storage Architecture，PSA）是一组API，允许存储制造商在VMkernel层中直接插入代码，从而开发第三方软件（如EMC PowerPath VE），提供与存储阵列技术直接相关的更高级负载均衡功能。但是VMware也提供标准的基本多路径机制，即原生多路径（Native MultiPathing，NMP），这些功能分布在以下API中：存储阵列类型插件（Storage Array Type Plug-in，SATP）负责与存储阵列通信；路径选择插件（Path Selection Plug-in，PSP）提供路径之间的负载均衡。 如图3-22所示，VMware提供三种PSP。 最近使用（Most Recently Used，MRU）：选择ESXi启动时发现的第一个路径。如果这一路径不可访问，ESXi选择替代路径。 固定：使用设计为首选路径的专用路径。如果没有配置，则使用启动时发现的路径。这一路径无法再使用时，随机选择可用路径。当该路径再次可用时，ESXi又会使用固定首选路径。 循环（Round Robin，RR）：自动选择所有可用路径，以循环的方式将I/O发送到每条路径，这能实现基本的负载均衡。PSA协调NMP操作，第三方软件协调多路径插件（MPP）软件。 NMP循环路径选择策略有一个I/O操作限制参数，控制每条路径切换到下条路径之前发送的I/O操作数量。默认值为1000，因此，NIP默认在向给定路径发送1000次I/O之后转向另一条路径。调整循环路径选择I/O操作限制，能够显著地改进某种工作负载下的性能（例如联机事务处理[online transaction processing，OLTP]）。在随机和OLTP工作负载环境中，将循环路径选择参数设置为较低的数字可以得到最好的吞吐率，但是对于顺序工作负载，降低该值不会得到同样显著的改进。因此，有些硬件存储公司建议将NMP循环路径选择I/O操作限制参数设置为较低的值（可以设置为1）。 第三方软件解决方案使用更高级的算法，因为循环选择算法有一个局限性，在进行自动分配的时候没有考虑路径级别上的实际活动。有些软件建立动态负载均衡，设计为在任何时候都使用所有路径，而不是像循环路径算法那样，在同一时间仅用一条路径来负担所有I/O负载。 3.12.2 模式访问共享存储空间的数据是虚拟环境的基础。VMware强烈建议实施多种LUN访问路径。最小值是两条路径，但是VMware建立使用四条路径。多路径提供冗余的LUN访问路径，从而减少了服务中断。路径不可用时，会使用另一条路径，这不会造成服务中断。这些切换机制被称作多路径I/O（MultiPath I/O，MPIO）。 在VMware中，如图3-23所示，存储可以采用不同的模式。 主动/主动：在给定时刻，一个LUN同时连接到多个存储控制器。I/O可以同时来自多个控制器。主动/被动：在给定时刻，一个控制器拥有一个LUN（从属LUN）。只要LUN链接到该控制器，其他控制器就不能向它发送I/O。ALUA：对LUN的访问不是直接的（无优化的），而是通过辅助控制器以不对称方式发生。
2017-08-01
优秀的个人博客,低调大师

思科携手Zenoss，用OpenStack构建NFV基础设施

Zenoss正在与思科进行合作，以共同提供集成的网络功能虚拟化基础设施（NFVI）系统，加速服务提供商网络中的SDN部署。 共同开发的Zenoss-Cisco NFVI包括思科的统一计算系统和Nexus交换机，基于Red Hat OpenStack的思科虚拟基础设施管理器（VIM）以及进行混合IT监控的Zenoss服务动态（ZSD）。 显然，思科一直使用Red Hat OpenStack发行版。思科网络功能虚拟化业务副总裁Charles Stucki表示：“思科致力于帮助服务提供商成功部署虚拟网络功能，目前业界的主要电信运营商都在实现OpenStack标准化，之前我们与多个公司合作开发OpenStack,但我们现在更关注Red Hat。” 他表示，思科利用其网络配置的专长来确保OpenStack部署时的配置方式与网络负载相关。此外，思科正在使用Docker容器技术实现OpenStack的自动安装和升级。他说：“OpenStack有很多版本且非常复杂，我们希望能够轻松部署OpenStack，最终将为小的服务提供商和大型服务提供商提供服务。” Zenoss的业务发展高级总监Steve Sigler表示：“随着思科部署NFV基础设施，我们可以在用户启动服务时自动监控这些资源，它消除了关闭操作才能手动配置的复杂性。” Zenoss-Cisco推出的组合产品可以在动态NFV环境中对系统和应用程序的监控和配置，并且可以提高性能和容量规划，以便在任何时候最大化地使用所有计算资源。 思科推出的应用为中心的基础设施（ACI）运行在其Nexus 9000系列交换机上，Stucki表示：“ACI可以用于NFVI部署，我们还将虚拟拓扑（VTS）应用于多厂商控制器。” 本文转自d1net（转载）
2017-07-03

资源下载

更多资源
Nacos

Nacos

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

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

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

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册