随着网络应用的发展和普及，Web服务器性能优化成为网站运营中的关键任务之一。而缓存技术作为提升性能的重要手段之一，在台湾地区的Web服务器优化中发挥着重要作用。下面将从缓存技术的作用、常见类型、实践经验和优化效果等方面进行探讨。
1、缓存技术的作用：
缓存技术通过将经常请求的数据或页面存储在服务器内存或硬盘中，以供后续访问使用，从而减少对后端资源的访问和压力，提高数据获取速度和响应时间，改善用户体验。
2、常见缓存技术：
在台湾地区的Web服务器优化中，常见的缓存技术包括：
3、实践经验：
在实际应用中，台湾的Web服务器优化者通常会采取以下实践经验：
4、优化效果和注意事项：
缓存技术的优化效果取决于缓存策略的设计和实施，以及网站的特点和访问模式。在实践中需要注意以下几点：
通过以上实践经验和优化方法，台湾地区的Web服务器可以有效提升网站性能和用户体验，满足不断增长的访问需求和用户期待。同时，持续关注新技术和最佳实践，不断优化和改进缓存策略，将为网站运营带来更多的收益和成果。
好主机测评广告位招租-300元/3月
怎样利用缓存服务器来负载均衡
根据一些专家的调查分析，发现企业在使用数据库的时候，90%以上主要用来查询。 有些企业这个比例甚至更高。 也就说，用户对数据库的操作，其实更新操作占的比例很少。 大部分的操走都只是查询操作。 如一些论坛，大部分用户只会看贴，而不会发帖。 这就是一个典型的查询操作比例大大超过更新操作比例的例子。 针对这种情况，其查询操作往往是其数据库性能的瓶颈。 如何有效提高查询的性能，这就使各个数据库专家在考虑的问题。 在SQL Server数据库中，已经有了一个现成的解决方案。 数据库管理员可以利用缓存服务器来提高数据库的性能。 笔者这里就以SQLServer2008为例，谈谈如何利用缓存服务器来实现负载均衡，来提高数据库的查询效率。 一、 数据查询与数据更新分开走。 如上图所示，如果用户要查看某个帖子，其就会打开某个连接。 此时WEB应用服务器就会从后台数据库中查询相关的记录。 这里需要注意的是，由于其只是查看帖子，而不涉及到更新的操作，为此WEB应用服务器就只从缓存服务器中读取数据。 这个缓存服务器中的记录跟数据库服务器的内容是同步的。 WEB应用服务器在从数据库缓存服务器读取数据之前，还会先判断一下哪台数据库服务器比较空。 会优先连接到比较空闲的数据缓存服务器中，然后从这台服务器中读取数据。 所以，当访问这个论坛的用户比较多时，这个数据缓存服务器能够实现负载均衡的需要。 如果用户看了某个帖子，现在需要发表一个评论，此时后台数据库会怎么操作呢?注意，当WEB应用服务器发送了一个 Update更新操作的时候，其应用服务器会自动连接到数据库服务器，而不会再连接到数据库缓存服务器。 而是直接向数据库服务器发送更新操走的语句。 当数据库服务器更新了相关的内容之后，会与数据库缓存服务器实现数据的同步。 从上图中可以看出，整个数据查询与数据更新WEB应用服务器是分两条路走。 其实这就好像是公路上分道行驶，机动车走机动车道;非机动车走非机动车道。 如此的话，就不会因为非机动车比较慢，而影响到机动车的速度。 在这个方案中，将数据库的更新操作与查询操作分开来走，也是类似的道理。 在查询时，数据流是单向流动的，所以能够在很大程度上提高查询的效率。 从而让数据负载均衡的效果更加明显。 总之，当某个应用程序查询操作大大超过更新操作时，通过在多个数据库间缓存只读数据，并在数据库间均匀连接客户端以分发负载，则就可以向外扩展工作负荷的读取分区，即实现负载均衡的目的。 二、 采用这个方案需要注意的地方。 在部署这个解决方案时，仍然有些数据库管理员需要关注的内容。 如以下这些内容，数据库管理员需要根据企业的实际情况来进行调整，以提高这个方案的价值。 首先需要考虑数据缓存服务器与数据库服务器之间同步的频率问题。 这个同步操作是一把双刃剑。 若同步的频率太高，会影响数据库服务器与缓存服务器的性能;若同步频率比较低的话，则数据库缓存服务器中的数据得不到及时的更新。 如此的话，用户查询时可能在短时间内无法获取最新的数据。 所以，一般来说，系统滞后的时间应该尽量的短，即数据库服务器的更新内容必须尽快与数据库缓存服务器进行同步。 理想的状态时，在更新数据库服务器的同时更新数据库缓存服务器。 但是，这么做是以牺牲数据库与数据库缓存服务器的性能为代价的。 为此数据库管理员在实施这个解决方案时，往往不会这么做。 而是设置在一段时间之后同步。 如可以设置为10秒、60秒、300秒或者更长的时间后进行同步。 具体这个同步的时间间隔多少为好，没有一个统一的标准。 这需要数据库管理员根据企业对数据同步的要求不同而定。 一般来说，数据库管理员在满足用户需要的前期下，可以将这个时间设置的相对长一点。 这可以避免因为过多的同步操作而降低了这个方案的价值。 其实，对于大部分用户来说，60秒左右的时间差异还是可以接受的。 如在论坛中，一个人发帖后，在一分钟之后看到一般不会有什么问题。 对于人的感觉来说，这个一分钟时间不长。 但是对于数据库服务器来说，这一分钟可以做很多事情。 所以，适当延长这个同步时间，却可以在很大程度上提高数据库服务器性能。 这个时间的代价，有时候还是值得的。 其次，在数据库服务器与数据库缓存服务器之间，应该建立比较直接的、快速的网络连接。 当用户比较多时，数据库服务器与数据库缓存服务器之间若发生同步操作，则会造成很多的网络流量。 有时候同步操作发生时，影响这个工作的效率可能并不是数据库服务器或者数据库缓存服务器本身，而是他们之间的网络连接。 由于其可用的带宽跟不少数据库服务器系统的吞吐量，从而影响到了同步操作的效率。 为此，在数据库服务器与数据库缓存服务器之间的网路连接，应该尽量的直接。 如最好不要在中间夹着其他的不必要的网络设备;也最好不要在他们之间配备防火墙等安全策略。 这些安全策略与网络设备都会在很大程度上影响到这个同步操作的效率。 另外，最好也不要有其他的应用服务来争抢带宽。 所以简单的说，如果可能的话，在数据库服务器上部署多张网卡，直接与数据库源服务器实现双机互联，而那传输同步操作需要的数据，这是一个很不错的手段。 由于其数据传输更直接、而且其他设备或者应用服务也会来争夺其带宽，同时又可以克服他们的非法攻击。 为此，只要他们之间多距离比较短的话，采用这种方案可能效果会比较好，可以在最大程度内缩短这个同步操作所需要的时间，从而让其他用户尽早看到更新的数据。 第三为同步选择合适的复制方案。 那么该如何实现数据库服务器与缓存服务器之间的同步呢?在SQLServer数据库中，有三个方案可供数据库管理员选择。 这三个方案分别为快照复制、合并复制与事务复制。 这三个复制模型各有各的特点。 不过从最终效果来看，其都可以实现数据库服务器与数据库缓存服务器之间的同步。 不过由于其内部的实现机制不同，为此其虽然结果相同，但是从性能等方面考虑，还是有差异的。 各种复制模型的原理与特点属于基本知识的范畴，笔者在这里就不做过多阐述了。 笔者认为，在利用这个数据库缓存服务器来实现负载均衡的方案中，最好采用事务复制的同步方案。 因为相比其他方案来说，事务日志能够满足事务的一致性、数据库服务器系统比较大的吞吐量、同步时尽量少的开销、以及系统比较短的滞后时间等等需求。 另外在有些企业中采用这个方案的话，还要考虑到表与记录的过滤需求。 而通过事务复制的话，就可以实现对列和行的过滤。 而其他复制模型的话，只能够部分满足这些需求。 所以，笔者认为，在选择数据同步方案时，可能选择事务复制来实现同步，更加的合适。 不过最终是否真是如此，还是要求数据库管理员根据企业的实际需要，然后分别采用几个复制模型来进行测试，才能够得出真正合理的结果。 转载，仅供参考。
JAVA几种缓存技术介绍说明
1、TreeCache / JBossCacheJBossCache是一个复制的事务处理缓存，它允许你缓存企业级应用数据来更好的改善性能。 缓存数据被自动复制，让你轻松进行JBoss服务器之间 的集群工作。 JBossCache能够通过JBoss应用服务或其他J2EE容器来运行一个MBean服务，当然，它也能独立运行。 2、WhirlyCacheWhirlycache是一个快速的、可配置的、存在于内存中的对象的缓存。 它能够通过缓存对象来加快网站或应用程序的速度，否则就必须通过查询数据库或其他代价较高的处理程序来建立。 3、SwarmCacheSwarmCache是一个简单且有效的分布式缓存，它使用IP multicast与同一个局域网的其他主机进行通讯，是特别为集群和数据驱动web应用程序而设计的。 SwarmCache能够让典型的读操作大大超过写操作的这类应用提供更好的性能支持。 4、JCacheJCache是个开源程序，正在努力成为JSR-107开源规范，JSR-107规范已经很多年没改变了。 这个版本仍然是构建在最初的功能定义上。 5、ShiftOneShiftOne Java Object Cache是一个执行一系列严格的对象缓存策略的Java lib，就像一个轻量级的配置缓存工作状态的框架。
asp.net 服务器缓存技术
实现 要实现页面输出缓存，只要将一条 OutputCache 指令添加到页面即可。 ＜%@ OutputCache Duration=60 VaryByParam=* %＞ 如同其他页面指令一样，该指令应该出现在 ASPX 页面的顶部，即在任何输出之前。 它支持五个属性（或参数），其中两个是必需的。 Duration 必需属性。 页面应该被缓存的时间，以秒为单位。 必须是正整数。 Location 指定应该对输出进行缓存的位置。 如果要指定该参数，则必须是下列选项之一：Any、Client、Downstream、None、Server 或 ServerAndClient。 VaryByParam 必需属性。 Request 中变量的名称，这些变量名应该产生单独的缓存条目。 none 表示没有变动。 * 可用于为每个不同的变量数组创建新的缓存条目。 变量之间用 ; 进行分隔。 VaryByHeader 基于指定的标头中的变动改变缓存条目。 VaryByCustom 允许在 中指定自定义变动（例如，Browser）。 利用必需的 Duration 和 VaryByParam 选项的组合可以处理大多数情况。 例如，如果您的产品目录允许用户基于 categoryID 和页变量查看目录页，您可以用参数值为 categoryID;page 的 VaryByParam 将产品目录缓存一段时间（如果产品不是随时都在改变，一小时还是可以接受的，因此，持续时间是 3600 秒）。 这将为每个种类的每个目录页创建单独的缓存条目。 每个条目从其第一个请求算起将维持一个小时。 VaryByHeader 和 VaryByCustom 主要用于根据访问页面的客户端对页面的外观或内容进行自定义。 同一个 URL 可能需要同时为浏览器和移动电话客户端呈现输出，因此，需要针对不同的客户端缓存不同的内容版本。 或者，页面有可能已经针对 IE 进行了优化，但需要能针对 Netscape 或 Opera 完全降低优化（而不仅仅是破坏页面）。 后一个例子非常普遍，我们将提供一个说明如何实现此目标的示例： 示例：VaryByCustom 用于支持浏览器自定义 为了使每个浏览器都具有单独的缓存条目，VaryByCustom 的值可以设置为 browser。 此功能已经内置在缓存模块中，并且将针对每个浏览器名称和主要版本插入单独的页面缓存版本。 ＜%@ OutputCache Duration=60 VaryByParam=None VaryByCustom=browser %＞ 片段缓存，用户控件输出缓存 缓存整个页面通常并不可行，因为页面的某些部分是针对用户定制的。 不过，页面的其他部分是整个应用程序共有的。 这些部分最适合使用片段缓存和用户控件进行缓存。 菜单和其他布局元素，尤其是那些从数据源动态生成的元素，也应该用这种方法进行缓存。 如果需要，可以将缓存的控件配置为基于对其控件（或其他属性）的更改或由页面级输出缓存支持的任何其他变动进行改变。 使用同一组控件的几百个页面还可以共享那些控件的缓存条目，而不是为每个页面保留单独的缓存版本。 实现 片段缓存使用的语法与页面级输出缓存一样，但其应用于用户控件（ 文件）而不是 Web 窗体（ 文件）。 除了 Location 属性，对于 OutputCache 在 Web 窗体上支持的所有属性，用户控件也同样支持。 用户控件还支持名为 VaryByControl 的 OutputCache 属性，该属性将根据用户控件（通常是页面上的控件，例如，DropDownList）的成员的值改变该控件的缓存。 如果指定了 VaryByControl，可以省略 VaryByParam。 最后，在默认情况下，对每个页面上的每个用户控件都单独进行缓存。 不过，如果一个用户控件不随应用程序中的页面改变，并且在所有页面都使用相同的名称，则可以应用 Shared=true 参数，该参数将使用户控件的缓存版本供所有引用该控件的页面使用。 示例 ＜%@ OutputCache Duration=60 VaryByParam=* %＞ 该示例将缓存用户控件 60 秒，并且将针对查询字符串的每个变动、针对此控件所在的每个页面创建单独的缓存条目。 ＜%@ OutputCache Duration=60 VaryByParam=none VaryByControl=CategoryDropDownList %＞ 该示例将缓存用户控件 60 秒，并且将针对 CategoryDropDownList 控件的每个不同的值、针对此控件所在的每个页面创建单独的缓存条目。 ＜%@ OutputCache Duration=60 VaryByParam=none VaryByCustom=browser Shared=true %＞ 最后，该示例将缓存用户控件 60 秒，并且将针对每个浏览器名称和主要版本创建一个缓存条目。 然后，每个浏览器的缓存条目将由引用此用户控件的所有页面共享（只要所有页面都用相同的 ID 引用该控件即可）。 页面级和用户控件级输出缓存的确是一种可以迅速而简便地提高站点性能的方法，但是在 中，缓存的真正灵活性和强大功能是通过 Cache 对象提供的。 使用 Cache 对象，您可以存储任何可序列化的数据对象，基于一个或多个依赖项的组合来控制缓存条目到期的方式。 这些依赖项可以包括自从项被缓存后经过的时间、自从项上次被访问后经过的时间、对文件和/或文件夹的更改以及对其他缓存项的更改，在略作处理后还可以包括对数据库中特定表的更改。 在 Cache 中存储数据 在 Cache 中存储数据的最简单的方法就是使用一个键为其赋值，就像 HashTable 或 Dictionary 对象一样： Cache[key] = value; 这种做法将在缓存中存储项，同时不带任何依赖项，因此它不会到期，除非缓存引擎为了给其他缓存数据提供空间而将其删除。 要包括特定的缓存依赖项，可使用 Add() 或 INSERT() 方法。 其中每个方法都有几个重载。 Add() 和 Insert() 之间的唯一区别是，Add() 返回对已缓存对象的引用，而 Insert() 没有返回值（在 C# 中为空，在 VB 中为 Sub）。 示例 (key, myXMLFileData, new (())); 该示例可将文件中的 xml 数据插入缓存，无需在以后请求时从文件读取。 CacheDependency 的作用是确保缓存在文件更改后立即到期，以便可以从文件中提取最新数据，重新进行缓存。 如果缓存的数据来自若干个文件，还可以指定一个文件名的数组。 (dependentkey, myDependentData, new (new string[] {}, new string[] {key})); 该示例可插入键值为 key 的第二个数据块（取决于是否存在第一个数据块）。 如果缓存中不存在名为 key 的键，或者如果与该键相关联的项已到期或被更新，则 dependentkey 的缓存条目将到期。 (key, myTimeSensitiveData, null, (1), ); 绝对到期：此示例将对受时间影响的数据缓存一分钟，一分钟过后，缓存将到期。 注意，绝对到期和滑动到期（见下文）不能一起使用。 (key, myFrequentlyAccessedData, null, , (1)); 滑动到期：此示例将缓存一些频繁使用的数据。 数据将在缓存中一直保留下去，除非数据未被引用的时间达到了一分钟。 注意，滑动到期和绝对到期不能一起使用。 更多选项 除了上面提到的依赖项，我们还可以指定项的优先级（依次为 low、high、NotRemovable，它们是在 枚举中定义的）以及当缓存中的项到期时调用的 CacheItemRemovedCallback 函数。 大多数时候，默认的优先级已经足够了 — 缓存引擎可以正常完成任务并处理缓存的内存管理。 CacheItemRemovedCallback 选项考虑到一些很有趣的可能性，但实际上它很少使用。 不过，为了说明该方法，我将提供它的一个使用示例： CacheItemRemovedCallback 示例 callback = new (OnRemove); (key,myFile,null, , , , callback); . . . public static void OnRemove(string key, object cacheItem, reason) { AppendLog(The cached value with key + key + was removed from the cache. Reason: + ()); } 该示例将使用 AppendLog() 方法（这里不讨论该方法，请参阅 Writing Entries to Event Logs）中定义的任何逻辑来记录缓存中的数据到期的原因。 通过在从缓存中删除项时记录这些项并记录删除的原因，您可以确定是否在有效地使用缓存或者您是否可能需要增加服务器上的内存。 注意，callback 是一个静态（在 VB 中为 Shared）方法，建议使用该方法的原因是，如果不使用它，保存回调函数的类的实例将保留在内存中，以支持回调（对 static/Shared 方法则没有必要）。 该特性有一个潜在的用处 — 在后台刷新缓存的数据，这样用户永远都不必等待数据被填充，但数据始终保持相对较新的状态。 但实际上，此特性并不适用于当前版本的缓存 API，因为在从缓存中删除缓存的项之前，不触发或不完成回调。 因此，用户将频繁地发出尝试访问缓存值的请求，然后发现缓存值为空，不得不等待缓存值的重新填充。 我希望在未来的 版本中看到一个附加的回调，可以称为 CachedItemExpiredButNotRemovedCallback，如果定义了该回调，则必须在删除缓存项之前完成执行。 缓存数据引用模式 每当我们尝试访问缓存中的数据时，都应该考虑到一种情况，那就是数据可能已经不在缓存中了。 因此，下面的模式应该普遍适用于您对缓存的数据的访问。 在这种情况下，我们假定已缓存的数据是一个数据表。 public DataTable GetCustomers(bool BypassCache) { string cacheKey = CustomersDataTable; object cacheItem = Cache[cacheKey] as DataTable; if((BypassCache) (cacheItem == null)) { cacheItem = GetCustomersFromDataSource(); (cacheKey, cacheItem, null, (GetCacheSecondsFromConfig(cacheKey), ); } return (DataTable)cacheItem; } 关于此模式，有以下几点需要注意： ? 某些值（例如，cacheKey、cacheItem 和缓存持续时间）是一次定义的，并且只定义一次。 ? 可以根据需要跳过缓存 — 例如，当注册一个新客户并重定向到客户列表后，最好的做法可能就是跳过缓存，用最新数据重新填充缓存，该数据包括新插入的客户。 ? 缓存只能访问一次。 这种做法可以提高性能，并确保不会发生 NullReferenceExceptions，因为该项在第一次被检查时是存在的，但第二次检查之前就已经到期了。 ? 该模式使用强类型检查。 C# 中的 as 运算符尝试将对象转换为类型，如果失败或该对象为空，则只返回 null（空）。 ? 持续时间存储在配置文件中。 在理想的情况下，所有的缓存依赖项（无论是基于文件的，或是基于时间的，还是其他类型的依赖项）都应该存储在配置文件中，这样就可以进行更改并轻松地测量性能。 我还建议您指定默认缓存持续时间，而且，如果没有为所使用的 cacheKey 指定持续时间，就让 GetCacheSecondsFromConfig() 方法使用该默认持续时间。 相关的代码示例是一个 helper 类，它将处理上述所有情况，但允许通过一行或两行代码访问缓存的数据。 请下载 。 小结 缓存可以使应用程序的性能得到很大的提高，因此在设计应用程序以及对应用程序进行性能测试时应该予以考虑。 应用程序总会或多或少地受益于缓存，当然有些应用程序比其他应用程序更适合使用缓存。 对 提供的缓存选项的深刻理解是任何 开发人员应该掌握的重要技巧。 尽早缓存；经常缓存 您应该在应用程序的每一层都实现缓存。 向数据层、业务逻辑层、UI 或输出层添加缓存支持。 内存现在非常便宜 — 因此，通过以智能的方式在整个应用程序中实现缓存，可以获得很大的性能提高。 缓存可以掩盖许多过失 缓存是一种无需大量时间和分析就可以获得足够良好的性能的方法。 这里再次强调，内存现在非常便宜，因此，如果您能通过将输出缓存 30 秒，而不是花上一整天甚至一周的时间尝试优化代码或数据库就可以获得所需的性能，您肯定会选择缓存解决方案（假设可以接受 30 秒的旧数据）。 缓存正是那些利用 20% 付出获得 80% 回报的特性之一，因此，要提高性能，应该首先想到缓存。 不过，如果设计很糟糕，最终却有可能带来不良的后果，因此，您当然也应该尽量正确地设计应用程序。 但如果您只是需要立即获得足够高的性能，缓存就是您的最佳选择，您可以在以后有时间的时候再尽快重新设计应用程序。 页面级输出缓存 作为最简单的缓存形式，输出缓存只是在内存中保留为响应请求而发送的 HTML 的副本。 其后再有请求时将提供缓存的输出，直到缓存到期，这样，性能有可能得到很大的提高（取决于需要多少开销来创建原始页面输出 - 发送缓存的输出总是很快，并且比较稳定）。 你详细看看
发表评论