《2022年memcached是一个高性能的分布式的内存对象缓存系统 .pdf》由会员分享，可在线阅读，更多相关《2022年memcached是一个高性能的分布式的内存对象缓存系统 .pdf（8页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、memcached 是一个高性能的分布式的内存对象缓存系统，通过在内存里维护一个统一的巨大的 hash 表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。 最初为了加速LiveJournal 访问速度而开发的,后来被很多大型的网站采用。起初作者编写它可能是为了提高动态网页应用，为了减轻数据库检索的压力，来做的这个缓存系统。它的缓存是一种分布式的，也就是可以允许不同主机上的多个用户同时访问这个缓存系统，这种方法不仅解决了共享内存只能是单机的弊端，同时也解决了数据库检索的压力，最大的优点是提高了访问获取数据的速度！基于memcached 作者对分布式cache 的理解和
2、解决方案。 memcached 完全可以用到其他地方比如分布式数据库，分布式计算等领域。1、 memcached 协议理解memcache 是为了加快http:/ 表来加快页面访问速度，和数据库是独立的。 但是目前主要用来缓存数据库的数据。允许多个 server 通过网络形成一个大的 hash，用户不必关心数据存放在哪，只调用相关接口就可。存放在内存的数据通过LRU算法进行淘汰出内存。同时可以通过删除和设置失效时间来淘汰存放在内存的数据。2、 memcached 使用入门memcached最吸引人的地方主要在于它的分布式。分布式对于互联网应用来讲，按照用途基本上可划分为三种方式：分布式计算、分
3、布式存储和两者兼而有之。memcached是分布式存储的一种。 我们常见的分布式存储大多数是将N 台设备（server或者单独的存储） 构建成盘阵，而 memcached旨在构建一个高速的内存池。更通俗一点来讲：分布式计算是将N 颗 cpu 组装成一颗cpu ，分布式慢速存储是将N 个硬盘组装成一个大硬盘，memcached是将 N 块内存组装成一块大内存。有个朋友问：那是不是代价很昂贵啊。我的回答是肯定的。如果你的网站规模只有三两台服务器的话， 我觉得你就不用考虑这样的方案了，等你的网站做大了以后，再参考这方面的资料即可。 一般都是比较大的互联网公司为了追求更好的用户体验，才进行这方面的投资
4、，对他们来讲，用户体验至上，money是小 case 。还有朋友问：有一些dbms提供内存表的功能，比如mysql的内存表，可以代替memcached。但我要建议你的是：mysql的内存表确实起到同样的作用，但它的局限也很多，往往不能让你随心所欲，所以建议你不要走弯路。二、 memcached的应用场景2.1 应用范围memcached产品或相关技术的应用，我们在前面已经提到了一些。其实它的应用还是非常普遍的， 应用作为广泛的领域：例如 sns 类网站、 blog类网站、 bbs 类网站以及im 后台服务。2.2 sns 类网站的应用是 99 年始于校园中的项目，有点像中国的校内网。几个学生纯
5、属出于爱好做了这样一个网站, 主要实现以下功能：sns 、blog 、bbs 和 rss 等。 livejournal从建立开始就采用了大量的开源软件，到现在它本身也衍生了不少开源软件。sns 网站，现在比比皆是，规模比较大的象开心、校内、51 ，它们的页面上往往需要引用大量的用户信息、好友信息以及名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 8 页 - - - - - - - - - 文章信息等， 所以跨表或跨库操作会相当多。如果这些功能全部直接操作数据库，显然会带来
6、极大的效率损耗和系统负载。memcached在这样的场景下就会发挥巨大的作用，它采用大内存把这些不变的数据全都缓存起来，当数据修改时就通知cache过期，这样应用层基本上就可以解决大部分问题了，只有很小一部分请求穿透应用层，用到数据库。2.3 blog 、bbs 类网站的应用象 这些流量巨大的blog系统， 它需要频繁读写的一些小数据。其中最典型的应用，我们通常成为“ 数字类服务 ” ，比如 blog中需要实时显示的用户点击数和阅读数，bbs 中需要记录的在线人数、在线用户等。 这些小数据的处理非常繁琐，你无论怎么去设计数据库，都很难避开跨表或者跨库。有的朋友会说，可以在数据库中增加冗余字段解
7、决这类问题，但事实上， 这既不符合数据库设计的范式规则，也很难做到数据的一致性，由此会引发更为复杂的问题。而且由于产品线的分散发展，数据已经很难做到完全的统一规划。memcached在这样的场景下就会将这些小数据进行缓存，定期持久化就可以了，查询操作一直都在内存中运行。说到这里，有的朋友又会想到一些其它的问题：“memcached server宕机了怎么办，怎么保证与数据库的数据一致 ” 。我会对你说：“ 你的问题非常好，我们将会在后面章节给出相应的解决方案” 。另外，其实这种小数据并不是关键性数据，即使偶尔发生点错误，也没太大的问题。blog 、bbs系统并不是严格的企业级系统，假如你是为银
8、行业务提供解决方案的话，memcached并不适合。2.4 im server的应用前些时间，有一些文章介绍memcached 在 Jabber上应用。写累了，喝口水，读者自己去找找资料吧，有时间的话，帮我补上吧，呵呵。我们举了几个例子来说明memcached的应用场景，似乎都局限于小数据服务，那是不是就不能用于较大数据的缓冲了？那绝不是，memcached能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等等，而且生产环境中就这么跑过，只不过让大数据量使用缓冲的话，有点太浪费了，同样数量的内存存不了几条数据，所以会明显的降低命中率。哈希分布与一致性哈希算法简介前言在我们的日
9、常web 应用开发当中memcached 可以算作是当今的标准开发配置了。相信 memcache 的基本原理大家也都了解过了， memcache 虽然是分布式的应用服务，但分布的原则是由client 端的 api 来决定的，api 根据存储用的key 以及已知的服务器列表，根据key 的 hash 计算将指定的key 存储到对应的服务器列表上。基本的原理以及分布在这里我们通常使用的方法是根据key 的 hash 值%服务器数取余数的方法来决定当前这个key 的内容发名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 -
10、 - - - - - - 第 2 页，共 8 页 - - - - - - - - - 往哪一个服务器的。 这里会涉及到一个hash 算法的分布问题， 哈希的原理用一句话解释就是两个集合间的映射关系函数，在我们通常的应用中基本上可以理解为在集合 A（任意字母数字等组合，此处为存储用的key）里的一条记录去查找集合B（如 0-232 ）中的对应记录。（题外话：md5 的碰撞或者说冲突其实就是发生在这里，也就是说多个A 的记录映射到了同一个B 的记录）实际应用显然在我们的应用中集合A 的记录应该更均匀的分布在集合B 的各个位置，这样才能尽量避免我们的数据被分布发送到单一的服务器上，在 danga 的
11、 memcached 的原始版本（perl） 中使用的是crc32 的算法用 java的实现写出来：private static int origCompatHashingAlg( String key ) int hash = 0; char cArr = key.toCharArray(); for ( int i = 0; i 16) & 0 x7fff; 分布率测试有人做过测试，随机选择的key 在服务器数量为5 的时候所有key 在服务器群组上的分布概率是：origCompatHashingAlg: 0 10% 1 9% 2 60% 3 9% 4 9% newCompatHashin
12、gAlg: 0 19% 1 19% 2 20% 3 20% 4 20% 显然使用旧的crc32 算法会导致第三个memcached 服务的负载更高，但使用新算法会让服务之间的负载更加均衡。其他常用的 hash 算法还有 FNV-1a Hash,RS Hash,JS Hash,PJW Hash,ELF Hash,AP Hash等等。有兴趣的童鞋可以查看这里：http:/ - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 8 页 - - - - - - - - - 小结至此我们了解到了在我们
13、的应用当中要做到尽量让我们的映射更加均匀分布，可以使服务的负载更加合理均衡。新问题但到目前为止我们依然面对了这样一个问题：就是服务实例本身发生变动的时候，导致服务列表变动从而会照成大量的cache 数据请求会 miss，几乎大部分数据会需要迁移到另外的服务实例上。这样在大型服务在线时，瞬时对后端数据库/硬盘照成的压力很可能导致整个服务的crash。一致性哈希 （Consistent Hashing ）在此我们采用了一种新的方式来解决问题，处理服务器的选择不再仅仅依赖key 的 hash 本身而是将服务实例（节点）的配置也进行hash 运算。1.首先求出每个服务节点的hash ，并将其配置到一个
14、0232的圆环（ continuum ）区间上。2.其次使用同样的方法求出你所需要存储的key 的 hash，也将其配置到这个圆环（continuum ）上。3.然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务节点上。如果超过232仍然找不到服务节点，就会保存到第一个memcached 服务节点上。整个数据的图例：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 8 页 - - - - - - - - - 当增加服务节点时：名师资料总结 - - -精品资料
15、欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 8 页 - - - - - - - - - 其他：只有在圆环上增加服务节点的位置为逆时针方向的第一个服务节点上的键会受到影响。小结一致性哈希算法最大程度的避免了key 在服务节点列表上的重新分布，其他附带的改进就是有的一致性哈希算法还增加了虚拟服务节点的方法，也就是一个服务节点在环上有多个映射点，这样就能抑制分布不均匀，最大限度地减小服务节点增减时的缓存重新分布。应用在 memcached 的实际应用，虽然官方的版本并不支持Consistent Hashi
16、ng ， 但是已经有了现实的Consistent Hashing 实现以及虚节点的实现，第一个实现的是last.fm （国外流行的音乐平台）开发的libketama ，其中调用的 hash 的部分的 java 版本的实现（基于md5 ）：/* * Calculates the ketama hash value for a string * param s * return */ public static Long md5HashingAlg(String key) if(md5=null) try md5 = MessageDigest.getInstance(MD5); catch (N
17、oSuchAlgorithmException e) log.error( + no md5 algorythm found ); throw new IllegalStateException( + no md5 algorythm found); 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 8 页 - - - - - - - - - md5.reset(); md5.update(key.getBytes(); byte bKey = md5.digest(); long res = (long)(bKey3&0 xFF) 24) | (long)(bKey2&0 xFF) 16) | (long)(bKey1&0 xFF) 8) | (long)(bKey0&0 xFF); return res; 在一致性哈希的算法/策略环境中，按照测试来说时间和分布性都是综合来说比较让人满意的，参见：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 8 页 - - - - - - - - -