|
什么是urlhash架构 url hash架构对url进行一次hash算法，然后通过hash结果找到对应的服务器。因为针对单一个url的hash结果是一样的，所以理论上这个url会被永久分配到固定的一台服务器上。另外因为经过了hash算法，所以分配url就很均匀，同时访问量也可以达到均衡。 为什么要用urlhash架构 图片服务器的特点一是访问量很大，二是容量也很大，通过简单的负载均衡，可以解决访问量大的问题，但是容量的问题并没有改善。所以会造成容灾问题。 容灾问题：系统某个时间段被访问的数据严重超出缓存集群中最小单机的容纳容量就会造成容灾，容灾会使大量单一链接穿透，直接对后台的IO性能影响很大。 虽然可以通过增加缓存容量的配置来解决容灾问题，但是内存总是有限的，为每一台机器增加超大内存成本上也开销很大，另外在squid中也不宜配置很大的磁盘缓存，否则squid中的hash表会很大，性能很差。 通过hash架构，可以充分利用缓存集群的内存，容灾问题就不再取决于缓存集群中最小单机的容纳容量，而是缓存集群中所有机器的容纳容量之和。 各种urlhash架构 基于dns的hash架构 基于haproxy的自动hash架构 基于nginx的手动hash架构 基于dns的hash架构图 {{./pasted_image.bmp}} 基于dns的hash架构说明 这个架构适合面向用户的图片系统，比如论坛、相册、博客中的图片上传。这样它才能够保证文件名有一致的规范。 这个架构图分了36个域名，图片文件名是用md5值起的，在md5值中取一位字母就可以表明它是在哪个域名里，域名就对应了机器，上传分发的时候也是根据此字母来分发。 基于dns的hash架构优缺点 优点 使用了dns分流，成本较低，而且dns性能高，不用维护。 可突破IE默认每主机2个线程的限制。 缺点 可用性方面，如果有一台机器宕机，则指向这台机器的请求无法读取。 分流方面，只能全部同步，成本较高 只适用于面向用户的系统 基于nginx的自动hash架构图 {{./pasted_image001.bmp}} 基于nginx的自动hash架构说明 这是一种新的缓存架构，由nginx作为最前端，代理到缓存机器。 nginx后面是缓存组，由nginx经过url hash后将请求分到缓存机器。 这个架构方便纯squid缓存升级，可以在squid的机器上加装nginx。 nginx有缓存的功能，可以将一些访问量特大的链接直接缓存在nginx上，就不用经过多一次代理的请求。比如favicon.ico和网站的logo。 基于nginx的自动hash架构优缺点 优点 高性能 使用方便，后台是什么样关系不大 有很高的可用性 缓存架构，分流方便 可直接在nginx代理缓存部分链接 缺点 url分流可控性弱，增减缓存机器都会引起缓存重新分配，意味着缓存全部失效。 基于nginx的手动hash架构说明 这个架构图和自动hash的架构是一样的，唯一有差别的是hash算法的变化，自动hash是用nginx upstream hash模块自带的hash算法来实现分流，这个手动架构是自己设计一个算法来实现。 算法设计思路是从url中取一个字符来作分流依据，比如定义链接的倒数第10个字符来分流，同样可以分配得很均匀。 手动架构可以避免自动架构中增减机器带来的缓存失效问题，另外可以精确知道一个链接到底存在哪台缓存上。 基于nginx的手动hash架构优缺点 优点 基本可以继承自动架构的优点 避免增减机器的问题 精确知道链接存储在哪台缓存上 缺点 配置较复杂，要分配均匀配置不易。 采用Hash架构对bbs架构优化 先前讲的bbs架构采用的是lvs+squid作为前端，这样的话squidclient更新缓存时需要更新所有的squid，这个效率很低下，使用hash架构就可以使squidclient每次只需要清理一台squid，效率大为提升。 推荐的是使用nginx手动hash架构，它可以精确知道链接会存在哪台机器上，这样就可以配置精确的备份机器。 |
|
|
