Cache synchronization strategies

Introduction A system of record is the authoritative data source when information is scattered among various data providers. When we introduce a caching solution, we automatically duplicate our data. To avoid inconsistent reads and data integrity issues, it’s very important to synchronize the database and the cache (whenever a change occurs in the system). There… Continue reading Cache synchronization strategies

Cache-Aside pattern

Load data on demand into a cache from a data store. This can improve performance and also helps to maintain consistency between data held in the cache and data in the underlying data store. Context and problem Applications use a cache to improve repeated access to information held in a data store. However, it’s impractical… Continue reading Cache-Aside pattern

缓存和DB一致性问题

以下是从网络上摘取的一些缓存一致性方案,供参考。 产生原因 主要有两种情况,会导致缓存和 DB 的一致性问题: 并发的场景下,导致读取老的 DB 数据,更新到缓存中。 缓存和 DB 的操作,不在一个事务中,可能只有一个操作成功,而另一个操作失败,导致不一致。 当然,有一点我们要注意,缓存和 DB 的一致性,我们指的更多的是最终一致性。我们使用缓存只要是提高读操作的性能,真正在写操作的业务逻辑,还是以数据库为准。例如说,我们可能缓存用户钱包的余额在缓存中,在前端查询钱包余额时,读取缓存,在使用钱包余额时,读取数据库。 更新缓存的设计模式 1.Cache Aside Pattern(旁路缓存) 这是最常用最常用的pattern了。其具体逻辑如下: 失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。 命中:应用程序从cache中取数据,取到后返回。 更新:先把数据存到数据库中,成功后,再让缓存失效。 一个是查询操作,一个是更新操作的并发,首先,没有了删除cache数据的操作了,而是先更新了数据库中的数据,此时,缓存依然有效,所以,并发的查询操作拿的是没有更新的数据,但是,更新操作马上让缓存的失效了,后续的查询操作再把数据从数据库中拉出来。而不会像文章开头的那个逻辑产生的问题,后续的查询操作一直都在取老的数据。 要么通过2PC或是Paxos协议保证一致性,要么就是拼命的降低并发时脏数据的概率,而Facebook使用了这个降低概率的玩法,因为2PC太慢,而Paxos太复杂。当然,最好还是为缓存设置上过期时间。 2.Read/Write Through Pattern 在上面的Cache Aside套路中,我们的应用代码需要维护两个数据存储,一个是缓存(Cache),一个是数据库(Repository)。所以,应用程序比较啰嗦。而Read/Write Through套路是把更新数据库(Repository)的操作由缓存自己代理了,所以,对于应用层来说,就简单很多了。可以理解为,应用认为后端就是一个单一的存储,而存储自己维护自己的Cache。 Read Through Read Through 套路就是在查询操作中更新缓存,也就是说,当缓存失效的时候(过期或LRU换出),Cache Aside是由调用方负责把数据加载入缓存,而Read Through则用缓存服务自己来加载,从而对应用方是透明的。 Write Through Write Through 套路和Read Through相仿,不过是在更新数据时发生。当有数据更新的时候,如果没有命中缓存,直接更新数据库,然后返回。如果命中了缓存,则更新缓存,然后再由Cache自己更新数据库(这是一个同步操作) 下图自来Wikipedia的Cache词条。其中的Memory你可以理解为就是我们例子里的数据库。 3.Write Behind Caching Pattern Write Behind 又叫 Write Back。write back就是Linux文件系统的Page Cache的算法。… Continue reading 缓存和DB一致性问题

几个还算有用的Apache htaccess配置

开启Apache的.htaccess文件可以让站点进行1些个性化的应用配置。这里提供了几个不错的.htaccess片段,希望能够根据你的实际情况优化你的网站,包括重定向、性能、可用性等! 强制后缀反斜杠(在URL的尾部加上反斜杠似乎对SEO有利) <IfModule mod_rewrite.c> RewriteCond %{REQUEST_URI} /+[^\.]+$ RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L] </IfModule> 防盗链 RewriteEngine On #Replace ?mysite\.com/ with your url RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC] RewriteCond %{HTTP_REFERER} !^$ #Replace /images/nohotlink.jpg with your “don’t hotlink” image url RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L] 重定向移动设备(如果你的网站支持移动设备访问的话,最好还是重定向移动设备的访问到专门定制的页面) RewriteEngine On RewriteCond %{REQUEST_URI} !^/m/.*$ RewriteCond %{HTTP_ACCEPT} “text/vnd.wap.wml|application/vnd.wap.xhtml+xml” [NC,OR] RewriteCond %{HTTP_USER_AGENT} “acs|alav|alca|amoi|audi|aste|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-” [NC,OR] RewriteCond %{HTTP_USER_AGENT}… Continue reading 几个还算有用的Apache htaccess配置

简要的Web缓存技术

最近在做1个项目,名叫《智慧街区》。简单进行1下项目介绍:与政府有关部门进行合作,将自助终端(其实就是1台PC机,只不过长的好看点)竖立在大街小巷,为市民提供各色服务,比如:公交、天气、商家、优惠、政策、新闻等等1些便民功能。 这样1个项目,按道理来说,是应该做成CS结构的,这样便于对终端设备上有关硬软件的控制,但无耐的是项目时间较短、用户体验要好,我们只能选择偷梁换柱,使用BS方式(C端编写1全屏置顶的小程序,嵌套web网站)来解决。 调研阶段,我们了解到该项目功能并不复杂,手上也有比较好的原型和模块代码,我们所需要解决的问题主要有2个:1是客户端缓存,因为终端是使用3G无线传输,速度和流量得不到保障,速度<200KB,按流量收费,我们只能在服务端有更新内容的时候,客户端才能更新有关数据,最大限度的节约带宽;2是控制客户端打印,因为使用JS控制打印机会弹出打印对话框的,而终端设备上我们是不允许用户进行这种操作的。 今天先说第1个问题,客户端缓存的问题,这方面我特别g了1下,也算了解到1些比较简洁比较有效的技术,当然以前也都或多或少的接触过。下面这篇文章不错,遂载,明天还有1篇文章会描述《Web缓存技术概述》。 这是一篇知识性的文档,主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见,某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文,后面参考文档和更多深入阅读部分可能是你更需要的内容。 目录: 什么是Web缓存,为什么要使用它? 缓存的类型: 浏览器缓存; 代理服务器缓存; Web缓存无害吗?为什么要鼓励缓存? Web缓存如何工作: 如何控制(控制不)缓存: HTML Meta标签 vs. HTTP头信息; Pragma HTTP头信息(为什么不起作用); 使用Expires(过期时间)HTTP头信息控制保鲜期; Cache-Control(缓存控制) HTTP头信息; 校验参数和校验; 创建利于缓存网站的窍门; 编写利于缓存的脚本; 常见问题解答; 缓存机制的实现:Web服务器端配置; 缓存机制的实现:服务器端脚本; 1.什么是Web缓存,为什么要使用它? Web缓存位于Web服务器之间(1个或多个,内容源服务器)和客户端之间(1个或多个):缓存会根据进来的请求保存输出内容的副本,例如html 页面, 图片,文件(统称为副本),然后,当下一个请求来到的时候:如果是相同的URL,缓存直接使用副本响应访问请求,而不是向源服务器再次发送请求。 使用缓存主要有2大理由: 减少相应延迟:因为请求从缓存服务器(离客户端更近)而不是源服务器被相应,这个过程耗时更少,让web服务器看上去相应更快; 减少网络带宽消耗:当副本被重用时会减低客户端的带宽消耗;客户可以节省带宽费用,控制带宽的需求的增长并更易于管理。 2.缓存的类型 浏览器缓存 对于新一代的Web浏览器来说(例如:IE,Firefox):一般都能在设置对话框中发现关于缓存的设置,通过在你的电脑上僻处一块硬盘空间用于存储你已经看过的网站的副本。浏览器缓存根据非常简单的规则进行工作:在同一个会话过程中(在当前浏览器没有被关闭之前)会检查一次并确定缓存的副本足够新。这个 缓存对于用户点击“后退”或者点击刚访问过的链接特别有用,如果你浏览过程中访问到同一个图片,这些图片可以从浏览器缓存中调出而即时显现。 代理服务器缓存 Web代理服务器使用同样的缓存原理,只是规模更大。代理服务器群为成百上千用户服务使用同样的机制;大公司和ISP经常在他们的防火墙上架设代理缓存或者单独的缓存设备; 由 于带路服务器缓存并非客户端或者源服务器的一部分,而是位于原网络之外,请求必须路由到他们才能起作用。一个方法是手工设置你的浏览器:告诉浏览器使用 那个代理,另外一个是通过中间服务器:这个中间服务器处理所有的web请求,并将请求转发到后台网络,而用户不必配置代理,甚至不必知道代理的存在; 代理服务器缓存:是一个共享缓存,不只为一个用户服务,经常为大量用户使用,因此在减少相应时间和带宽使用方面很有效:因为同一个副本会被重用多次。 网关缓存 也被称为反向代理缓存或间接代理缓存,网关缓存也是一个中间服务器,和内网管理员部署缓存用于节省带宽不同:网关缓存一般是网站管理员自己部署:让他们的网站更容易扩展并获得更好的性能; 请求有几种方法被路由到网关缓存服务器上:其中典型的是让用一台或多台负载均衡服务器从客户端看上去是源服务器; 网络内容发布商  (Content delivery networks CDNs)分布网关缓存到整个(或部分)互联网上,并出售缓存服务给需要的网站,Speedera和Akamai就是典型的网络内容发布商(下文简称CDN)。 本问主要关注于浏览器和代理缓存,当然,有些信息对于网关缓存也同样有效; 3.Web缓存无害吗?为什么要鼓励缓存?… Continue reading 简要的Web缓存技术

比较使用Linq To Entity、自已编写ORM映射、以及使用缓存保存常用数据之间的性能

第1步 建立数据库 首先我们模拟1个需求环境:会员参加活动,生成活动记录,会员有性别、所属区域字段。 第1步,建立Sql Server数据库,Members表保存成员的基本信息,其中SexId、AreaId为外键,分别关联Sex性别表、Areas区域表;Activitys表保存活动的标题;ActivityRecords表保存成员参加活动的记录,其中MemberId、ActivityId为外键,分别关联Members成员表、Activitys活动表。 下面是创建表结构的Sql语句: