memcached演练(6) 高可用实例HA(伪集群方案 )

本系列文章<memcached的演练>,这是第6篇,前面文章,已经阐述了,memcached的安装,访问,session管理,存储管理。从本篇开始,就分开有几篇演练下memcached的高可用相关。

memcached的安全,承载着后台数据库的巨大访问,意义重大。

简单介绍下HA的梗概,如果时间允许尽量都演练下个方案,然后横向比较下各方案的优缺点。

本篇主要内容

伪集群方案的测试

明确memcached的高可用方案

通过比较memcached和redis两种NOSQL的方案,很容易发现,memcached的集群方案设计很简单,主要在client实现。

伪集群方案测试步骤

  1. 准备演练环境
主机 memcached主目录 端口
192.168.163.146 (hadoop1) /usr/local/memcached/ 11211
192.168.163.156 (hadoop2) /usr/local/memcached/ 11211
192.168.163.166 (hadoop3) /usr/local/memcached/ 11211

安装不久罗列了,请参照《memcached演练(1) 搭建memcached服务》

2.准备测试代码

    public void testSet() throws ExecutionException, InterruptedException, IOException {
        final MemcachedClient mcc =  new MemcachedClient(new BinaryConnectionFactory(),AddrUtil.getAddresses("192.168.163.146:11211 192.168.163.156:11211 192.168.163.166:11211"));
        for(int i=0;i<50;i++){
            mcc.set("clusterKey_"+StringUtils.leftPad(""+i,4,"0"), 19000, "clusterValue_"+i);
        }
        System.out.println("set ok");

        for(int i=0;i<50;i++){
            Object o = mcc.get("clusterKey_" + StringUtils.leftPad(""+i,4,"0"));
            System.out.println(o);
        }
//        mcc.shutdown();
    }

3.测试结果分析

[[email protected] scripts]# ./memcached-tool hadoop1:11211 dump |sort
Dumping memcache contents
  Number of buckets: 1
  Number of items  : 16
Dumping bucket 1 - 16 total items
add clusterKey_0002 0 1471374793 14
add clusterKey_0005 0 1471374793 14
add clusterKey_0008 0 1471374793 14
add clusterKey_0011 0 1471374793 15
add clusterKey_0014 0 1471374793 15
add clusterKey_0017 0 1471374793 15
add clusterKey_0020 0 1471374793 15
add clusterKey_0023 0 1471374793 15
add clusterKey_0026 0 1471374793 15
add clusterKey_0029 0 1471374793 15
add clusterKey_0032 0 1471374793 15
add clusterKey_0035 0 1471374793 15
add clusterKey_0038 0 1471374793 15
add clusterKey_0041 0 1471374793 15
add clusterKey_0044 0 1471374793 15
add clusterKey_0047 0 1471374793 15

[[email protected] scripts]# ./memcached-tool hadoop2:11211 dump |sort
Dumping memcache contents
  Number of buckets: 1
  Number of items  : 17
Dumping bucket 1 - 17 total items
add clusterKey_0000 0 1471374795 14
add clusterKey_0003 0 1471374795 14
add clusterKey_0006 0 1471374795 14
add clusterKey_0009 0 1471374795 14
add clusterKey_0012 0 1471374795 15
add clusterKey_0015 0 1471374795 15
add clusterKey_0018 0 1471374795 15
add clusterKey_0021 0 1471374795 15
add clusterKey_0024 0 1471374795 15
add clusterKey_0027 0 1471374795 15
add clusterKey_0030 0 1471374795 15
add clusterKey_0033 0 1471374795 15
add clusterKey_0036 0 1471374795 15
add clusterKey_0039 0 1471374795 15
add clusterKey_0042 0 1471374795 15
add clusterKey_0045 0 1471374795 15
add clusterKey_0048 0 1471374795 15

[[email protected] scripts]# ./memcached-tool hadoop3:11211 dump |sort
Dumping memcache contents
  Number of buckets: 1
  Number of items  : 17
Dumping bucket 1 - 17 total items
add clusterKey_0001 0 1471374794 14
add clusterKey_0004 0 1471374794 14
add clusterKey_0007 0 1471374794 14
add clusterKey_0010 0 1471374794 15
add clusterKey_0013 0 1471374794 15
add clusterKey_0016 0 1471374794 15
add clusterKey_0019 0 1471374794 15
add clusterKey_0022 0 1471374794 15
add clusterKey_0025 0 1471374794 15
add clusterKey_0028 0 1471374794 15
add clusterKey_0031 0 1471374794 15
add clusterKey_0034 0 1471374794 15
add clusterKey_0037 0 1471374794 15
add clusterKey_0040 0 1471374794 15
add clusterKey_0043 0 1471374794 15
add clusterKey_0046 0 1471374794 15
add clusterKey_0049 0 1471374794 15

上面数据,简单整理成图,很直观,数据分布很分散的。这样的好处,可以减少热点。

值得注意的是

 final MemcachedClient mcc =  new MemcachedClient(new BinaryConnectionFactory(),AddrUtil.getAddresses("192.168.163.146:11211 192.168.163.156:11211 192.168.163.166:11211"));

AddrUtil.getAddresses参数,可以重复添加节点信息,这就相当于机器有权重的感觉了,明显会造成数据分布不均匀。

4.测试下权重情况下的数据分布

public class SpyMemcachedClusterTest extends TestCase
{

    public void testSet() throws ExecutionException, InterruptedException, IOException {
        final MemcachedClient mcc =  new MemcachedClient(new BinaryConnectionFactory(),AddrUtil.getAddresses("192.168.163.146:11211 192.168.163.146:11211 192.168.163.146:11211 192.168.163.156:11211 192.168.163.156:11211 192.168.163.166:11211"));
        for(int i=0;i<150;i++){
            mcc.set("clusterKey_"+StringUtils.leftPad(""+i,4,"0"), 19000, "clusterValue_"+i);
        }
        System.out.println("ok");
//        mcc.shutdown();
        for(int i=0;i<150;i++){
            Object o = mcc.get("clusterKey_" + StringUtils.leftPad(""+i,4,"0"));
            System.out.println(o);
        }

    }
}

测试结果截图

两图比较:是不是很容易,就看出来了。一致性可以从数据分布方面考虑,还是非常平均的,但数据量的分布,就和权重有关系。基本就是 3:2:1。和上面程序代码中配置的权重基本一致。

继续做实验。

5.剔出一个节点,看看命中率

public void testGets() throws ExecutionException, InterruptedException, IOException{
    final MemcachedClient mcc =  new MemcachedClient(new BinaryConnectionFactory(),AddrUtil.getAddresses(" 192.168.163.146:11211 192.168.163.146:11211 192.168.163.156:11211 192.168.163.156:11211 192.168.163.166:11211"));
    int nohit=0;
    for(int i=0;i<150;i++){
        String key = "clusterKey_" + StringUtils.leftPad("" + i, 4, "0");
        Object o = mcc.get(key);
        if(o==null){
            System.out.println(key+"未命中");
            nohit++;
        }
    }
    System.out.println("丢失:"+nohit);
}

修改内容,hadoop1:hadoop2:hadoop3,有原来的 3:2:1分布,修改成2:2:1分布。

测试结果

clusterKey_0001未命中    
clusterKey_0002未命中    
clusterKey_0010未命中    
clusterKey_0011未命中    
clusterKey_0019未命中    
clusterKey_0020未命中    
clusterKey_0028未命中    
clusterKey_0037未命中    
clusterKey_0039未命中    
clusterKey_0046未命中    
clusterKey_0048未命中    
clusterKey_0049未命中    
clusterKey_0055未命中    
clusterKey_0057未命中    
clusterKey_0058未命中    
clusterKey_0064未命中    
clusterKey_0066未命中    
clusterKey_0067未命中    
clusterKey_0069未命中    
clusterKey_0073未命中    
clusterKey_0075未命中    
clusterKey_0076未命中    
clusterKey_0078未命中    
clusterKey_0079未命中    
clusterKey_0082未命中    
clusterKey_0084未命中    
clusterKey_0085未命中    
clusterKey_0087未命中    
clusterKey_0088未命中    
clusterKey_0089未命中    
clusterKey_0091未命中    
clusterKey_0093未命中    
clusterKey_0094未命中    
clusterKey_0096未命中    
clusterKey_0097未命中    
clusterKey_0098未命中    
clusterKey_0099未命中    
clusterKey_0100未命中    
clusterKey_0101未命中    
clusterKey_0109未命中    
clusterKey_0110未命中    
clusterKey_0118未命中    
clusterKey_0127未命中    
clusterKey_0129未命中    
clusterKey_0136未命中    
clusterKey_0138未命中    
clusterKey_0139未命中    
clusterKey_0145未命中    
clusterKey_0147未命中    
clusterKey_0148未命中    
丢失:50

丢失了1/3。

及时改成 3:2,丢失也基本上到达1/3。 这个问题需要重视,否则非常容易产生缓存穿透情况。

在以后,会研究下spymemcached的一致性算法。

时间: 2024-08-24 08:13:02

memcached演练(6) 高可用实例HA(伪集群方案 )的相关文章

高可用(HA)集群的搭建 --图形化搭建(针对rhel6.5)

高可用(HA)集群的搭建 --图形化搭建(针对rhel6.5) 实验环境:iptables selinux关闭,三台主机做好解析 实验主机IP: 172.25.0.251 172.25.0.2 172.25.0.3 高可用集群包括RHCS,pacemaker+lvs,heartbeat,keepalievd. 在做实验前,先了解RHCS套件,6以下才有,7就取消了. 一些服务进程的含义如下: Luci/ricci>>web方式的集群管理(配置)工具: Ccs>>集群配置服务,(例如

Linux 高可用(HA)集群之Heartbeat安装

大纲一.Heartbeat 的定义二.Heartbeat 的版本与组件三.Heartbeat 的各版本之间的区别 四.Heartbeat 集群的一般拓扑图 五.安装heartbeat 六.配置heartbeat 七.使用集群的其他几个相关配置 八.实验 推荐阅读: CentOS 6.3下DRBD+Heartbeat+NFS配置笔记 http://www.linuxidc.com/Linux/2013-06/85599.htm Heartbeat_ldirector+LB+NFS实现HA及LB.文

Linux 高可用(HA)集群基本概念

一.什么是集群 简单的说,集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源.这些单个的计算机系统就是集群的节点(node).一个理想的集群是,用户从来不会意识到集群系统底层的节点,在他/她们看来,集群是一个系统,而非多个计算机系统.并且集群系统的管理员可以随意增加和删改集群系统的节点. 更详细的说,集群(一组协同工作的计算机)是充分利用计算资源的一个重要概念,因为它能够将工作负载从一个超载的系统(或节点)迁移到集群中的另一个系统上.其处理能力是与专用计算机(小型机,大

Linux 高可用(HA)集群之keepalived

一.keepalived介绍 1.Keepalived 定义 Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案,可以利用其来避免单点故障.一个LVS服务会有2台服务器运行Keepalived,一台为主服务器(MASTER),一台为备份服务器(BACKUP),但是对外表现为一个虚拟IP,主服务器会发送特定的消息给备份服务器,当备份服务器收不到这个消息的时候,即主服务器宕机的时候, 备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性.Keepalived是VRRP的

高可用(HA)集群

1.HA集群介绍 HA即(high available)高可用,又被叫做双机热备,用于关键性业务.可以这样理解,有两台机器A和B,正常情况下,A提供服务,B待命闲置,当A宕机或服务宕掉,会切换至B机继续提供该服务.常用实现高可用的开源软件有heartbeat和keepalived,其中keepalived有负载均衡的功能. 如图所示为一个HA架构,一个交换机下面有两台机器Web1和Web2,其中Web1为主节点,正常使它提供服务,而Web2备用节点是闲置的.Web1和Web2中间有一根心跳线,检

Linux 高可用(HA)集群基本概念详解

大纲一.高可用集群的定义二.高可用集群的衡量标准三.高可用集群的层次结构四.高可用集群的分类 五.高可用集群常用软件六.共享存储七.集群文件系统与集群LVM八.高可用集群的工作原理 推荐阅读: CentOS 6.3下DRBD+Heartbeat+NFS配置笔记 http://www.linuxidc.com/Linux/2013-06/85599.htm Heartbeat_ldirector+LB+NFS实现HA及LB.文件共享 http://www.linuxidc.com/Linux/20

Linux 高可用(HA)集群基本概念详解一

目录: 一.高可用集群的定义 二.高可用集群的衡量标准 三.高可用集群的层次结构 四.高可用集群的分类 五.高可用集群常用软件 六.共享存储 七.集群文件系统与集群LVM 八.高可用集群的工作原理 一.高可用集群的定义 高可用集群,英文原文为High Availability Cluster,简称HACluster,简单的说,集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源.这些单个的计算机系统 就是集群的节点(node). 高可用集群的出现是为了使集群的整体服务尽可

Linux 高可用(HA)集群之keepalived详解

http://freeloda.blog.51cto.com/2033581/1280962 大纲 一.前言 二.Keepalived 详解 三.环境准备 四.LVS+Keepalived 实现高可用的前端负载均衡器 一.前言 这篇文章是前几篇文章的总结,我们先简单的总结一下我们前面讲解的内容,前面我们讲解了,LVS(负载均衡器).Heartbeat.Corosync.Pacemaker.Web高可用集群.MySQL高可用集群.DRDB.iscsi.gfs2.cLVM等,唯一没有讲解的就是LVS

Heartbeat+Drbd+Mysql高可用(HA)集群架构的部署

主机环境 redhat6.5 64位 实验环境 服务端1 ip 172.25.25.111   主机名:server1.example.com          服务端2 ip172.25.25.112    主机名:server2.example.com 安装包   heartbeat-3.0.4-2.el6.x86_64.rpm             heartbeat-devel-3.0.4-2.el6.x86_64.rpm   ldirectord-3.9.5-3.1.x86_64.r