memcache监控哪些数据库，Memcache储存原理

本文目录一览

1，Memcache储存原理
2，zabbix 监控 redis 哪些参数
3，memcache到底是怎么运行的
4，怎么部署mysql和memcache的关系
5，如何在AWS上部署千万用户级别服务

1，Memcache储存原理

1. Memcache采用键值对存储方式。它本质是一个大的 hash表，key的最大长度为255个字符，最长过期时间为30天。2. 它的内存模型如下：Memcache预先将可支配的内存空间进行分区（Slab），每个分区里再分为多个块（Chunk）最大1M，但同一个分区中块的大小是固定的。然后，插入数据时，会根据数据大小寻找最合适的块，然后插入，当然这样也就会有部分内存浪费，但可一定程度上减少内存碎片，总体上，利大于弊。当Memcache的内存满后，它清除旧数据的原则为：LRU闲置>过期>最少访问。而且它采用的是惰性删除，它并没有提供监控数据过期的机制，而是惰性的，当查询到某个key的数据时，如果过期，那么直接抛弃。3. 详细请参考：http://blog.csdn.net/wang379275614/article/details/47777759

额再看看别人怎么说的。

Memcache储存原理

2，zabbix 监控 redis 哪些参数

1、目的通过自定义脚本获取redis的性能信息数显示在zabbix系统上2、简要步骤2.1 zabbix server端自定义模板文件redis模板文件导出为后缀xml，后附2.2 zabbix server端定义需要监控的服务器这里定义redis组的b103/g12/h12共计3台凡是充当redis服务器都应增加2.1中的两个模板2.3 zabbix client端配置定义3台服务器的zabbix_agentd.conf 增加如下配置：

zabbix：是一套服务器性能监控软件，这个没怎么用过，没有发言权。redis：你可以当成是数据库，和MYSQL差不多（实际上差很多）nginx：是一个web 服务器，提供网页服务（如果它坏了，用户输入域名就不能正常访问网站）memcached：基于内存的分布式缓存系统，是redis的长江前浪。这几个东西和PHP都没关系，但可以这样理解：nginx 可以做php的WEB服务器redis 可以做php的数据库或缓存memcached 可以做PHP的缓存zabbix 既然能监控服务器性能，能把他们全都监控起来？

zabbix 监控 redis 哪些参数

3，memcache到底是怎么运行的

memcache是libevent+多线程架构的, 监听线程accept的连接利用管道+队列+互斥锁触发工作线程获取连接加入线程自己的libevent监听中, 对于UDP则直接采取了惊群方式监听, 数据存储方面采取哈希表+内存池slab + slab桶内LRU维护缓存过期机制, 整个哈希表与内存池的操作是加同一把全局锁的, 所以都说memcache锁粒度大, 另外每个Hash node采用reference的方式保证足够高的并发读能力, 这个设计是很巧妙的, 对于Node内容的更新, 则采用了移除旧结点, 插入新结点的策略, 保证了读写的高并发能力, 这里面涉及到reference和哈希表和内存池slab回收的共同作用, 简单说就是读操作是依靠reference维护NODE内存生命期的，写操作是依靠大粒度锁保证互斥操作的。源码很简单，我花了3天看完的，如果C编程基础不行的话还是继续用就行了。另外，缓存与数据库不要求一致性，一般都是写数据库或者读数据库之后就立即更新一下缓存，缓存具有有效期，合理的设置即可，当然也不是所有业务都适合使用分布式缓存，还是需要考虑具体需求使用，另外缓存的使用分读缓存和写缓存，读缓存是指数据库读之后插入缓存以便下次加速访问，写缓存是指数据写操作先写入缓存，当累计一定次数后一次性写入数据库，看需求使用。再另外不得不提，如果缓存不适合业务而不能使用，可以考虑数据库优化，比如分区分表，读写分离，甚至是冗余。回复 ngnix

memcache到底是怎么运行的

4，怎么部署mysql和memcache的关系

怎么部署mysql和memcache的关系1.首先明确是不是一定要上缓存，当前架构的瓶颈在哪里，若瓶颈真是数据库操作上，再继续往下看。2.明确memcached和redis的区别，到底要使用哪个。前者终究是个缓存，不可能永久保存数据（LRU机制），支持分布式，后者除了缓存的同时也支持把数据持久化到磁盘等，redis要自己去实现分布式缓存（貌似最新版本的已集成），自己去实现一致性hash。因为不知道你们的应用场景，不好说一定要用memcache还是redis，说不定用mongodb会更好，比如在存储日志方面。

有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用mysql提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。1. check table 和 repair table登陆mysql 终端：mysql -uxxxxx -p dbnamecheck table tabtest;如果出现的结果说status是ok，则不用修复，如果有error，可以用：repair table tabtest;进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpmyadmin里面也可以使用check/repair的功能。2. myisamchk, isamchk其中myisamchk适用于myisam类型的数据表，而isamchk适用于isam类型的数据表。这两条命令的主要参数相同，一般新的系统都使用myisam作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：myisamchk tablename.myi进行检测，如果需要修复的话，可以使用：myisamchk -of tablename.myi关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保mysql服务器没有访问这个数据表，保险的情况下是最好在进行检测时把mysql服务器shutdown掉。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－另外可以把下面的命令放在你的rc.local里面启动mysql服务器前：[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /data_dir/*/*.myi其中的/tmp/mysql.sock是mysql监听的sock文件位置，对于使用rpm安装的用户应该是/var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而pathtochk则是myisamchk所在的位置，data_dir是你的mysql数据库存放的位置。需要注意的时，如果你打算把这条命令放在你的rc.local里面，必须确认在执行这条指令时mysql服务器必须没有启动！检测修复所有数据库(表)

5，如何在AWS上部署千万用户级别服务

基础架构 AWS分布在全球12个区域里每个区域对应着一个地理位置，里面含有多个Availability Zones(可用区)。这些区域设置在北美，南美，欧洲，中东，非洲，亚太区。每个AZ实质上是单个数据中心，尽管它们可由多个数据中心构建。每个AZ有着独立的供电系统和互联网连接。不同AZ之间以低延迟网络进行连接，这种快速网络可消除物理位置带来的速度影响。每个区域含有至少两个AZ，共计32个AZs。借助AZ可创建高可用性的程序架构。 AWS在全球还分布有53个偏远区域(Edge locations) 偏远区域的使用对象是CloudFront，这是Amazon的内容分发网络(CDN)和DNS服务器。偏远区域的存在使得全球用户都可以享用低延迟网络而不论他们身在何处。建立区块服务(Block Services) Amazon透过AWS创建了大量高可用和高容错的服务，具体的服务清单可点击这里查看。缴纳一定的费用，你就可以在个人的应用中使用这些服务而不必为高可用性而忧心。部分服务位于一个AZ中：CloudFront, Route 53, S3, DynamoDB, Elastic Load Balancing, EFS, Lambda, SQS, SNS, SES, SWF。即使是使用单个AZ的服务，其高可用架构也是足够强大的。 1个用户在这个时候，开发者=用户。你的架构看起来是这样的：运行单个实例，如t2.micro。你可以为你的服务器选择不同的CPU，内存，存储设备和网络环境。该服务器承载了全部web任务，如：web应用，数据库，管理器等。使用AmazonRoute 53进行DNS管理。为该实例附加一个Elastic IP地址。那么随着用户数的增加，我们需要如何进行升级改造，直至能为千万用户提供优质的服务呢？强调文字优化策略采用多主机模式尝试使用Amazon数据库服务，如Amazon RDS(关系数据库)，Amazon DynamoDB(NoSQL数据库)，Amazon Redshift。逐步从SQL数据库转为NoSQL数据库，特别是数据量超过5TB，你的应用对低延迟敏感的时候。使用Elastic Load Balancer(弹性负载均衡器)，它可以对主机进行健康检测以确保网络的通畅，同时可以帮助实现网络的扩展。垂直升级需要更强的实例类型，例如c4.8xlarge或者m3.2xlarge。停止使用当前的服务器，换用功能更强大的机器，如：244GB RAM，40核CPU。某些Amazon服务提供了Provisined IOPS选项以便用户自行配置变更，这样一来用户可以使用类似DynamoDB的扩展服务。类似上面的做法就叫做垂直升级。但其有个缺点，就是一旦机器出错，你的网站也会停止运作了。所以要尽量避免单个实例的做法。自动扩展如果你一直在为峰值负载而努力，如黑色星期五，那么其实是在浪费金钱。更好的解决方案列表内容是按需分配，这就是Auto Scaling(自动扩展)，在计算机群组中实现自动化的大小变更。你可以为你的容量池定义最大值和最小值。 CloudWatch是一个管理服务，已内置到所有的Amazon应用中。 CloudWatch事件会触发扩展。触发事件可以是CPU占用率，时间延迟，网速等等。你也可以向CloudWatch导入自定义基线，按照你的意愿来触发扩展。架构分解使用SOA/微服务，使你的服务层组件化。这样做的好处是单独的服务可以独立地进行扩展，从而大大增加了灵活性和可用性。 SOA是Amazon提供的重要架构组件。避免重复劳动把精力投入到能使你的业务与众不同的事情上。 Amazon提供了很多高容错的服务。例如，排队(SQS服务)，邮件，转码，搜索，数据库，监控等等。所以类似的服务都不必再次编写了。用户数>千万+ 当用户达到千万级别的时候，你考虑的策略应该是这样的：多AZs模式在不同层之间执行ELB(弹性负载平衡)。除了web层，在应用层，数据层等层里也需要进行ELB。能够自动扩展使用面向服务的架构缓存架构内和外的数据使用Amazon S3和CloudFront。S3用于存储静态数据，如js，CSS，图像等，具有足够的扩展性。CloudFront可对数据进行缓存。使用Amazon SES来进行邮件发送。使用CloudWatch进行监控。对数据写入执行如下的策略：联结 – 根据功能划分不同的数据库。分表 – 把一个数据集分解到多个主机上。把部分功能放到其他类型的数据库上（NoSQL,graph等）。不断优化你的应用和整个架构堆栈，针对瓶颈进行分析并找出解决方法。

AWS服务概述高扩展性应用建设并非把应用直接迁移到云平台上就能轻易实现，相反我们需要根据云平台的特性进行专门的设计，这包括选择合适的云服务类型并进行良好的应用架构设计。对于希望基于AWS构建千万级用户应用的开发者而言，不仅需要对区域（Region）、可用区（AZ）和边缘站点等基础设施的分布有所了解，更需要了解不同的AWS服务各自的特点和最佳实践。 AWS的服务可大致按照其所处层面分为三类，从下到上依次是基础服务层、应用服务层、部署和管理层。基础服务层也有两层，下层是计算（EC2、WorkSpaces）、存储（S3、EBS、Glacier、Storage Gateway）、网络（VPC、Direct Connect、ELB、Route53），上层是数据库（RDS、Dynamo、ElastiCache、RedShift）、数据分析（EMR、Data Pipeline、Kinesis）、内容分发（CloudFront）。应用服务层主要是把邮件服务、消息队列服务等通用的功能单独抽离出来。部署和管理层则有用于监控的CloudWatch，用于部署运维工作的BeanStalk、OpsWorks、CloudFormation和CloudTrail等，以及IAM、Federation等身份管理服务。单机到多实例传统的单机服务，到AWS上面就是跑在一个EC2实例上，这个实例上跟以前的服务器一样上面安装所有的Web应用、数据库等，搭配一个EIP，外部用Route53做DNS。遇到瓶颈后，简单的扩展就是将小的实例换成大的实例，比如small换成2xlarge、8xlarge，服务结构不变，可以快速实现，但是最终都会遇到极限。到了这一步，就要从单实例服务变成多实例。这一步骤涉及到Web实例和数据库实例的拆分，数据库可以开始考虑选择SQL或者NoSQL。SQL大家比较熟悉，优点很明显，缺点主要在规模变大之后呈现，不过一般对于百万级用户量内的应用，SQL是能够满足需求的；但如果数据量增长速度很快，数据是非结构化或者半结构化的，应用要求的延时低、写入的速度要求快，那考虑NoSQL会更合适一些。几百个用户的情况，一个RDS实例+一个Web实例即可满足需求，前端直接用一个EIP，即单机的情况；用户上千的情况，建议启动两个RDS实例+Web实例并将实例部署在不同的可用区，前端用ELB做负载均衡。对于百万级以下用户的规模，每一个可用区内会有多个Web实例和RDS实例组成的集群，其中Active RDS实例和Standby RDS实例要放在不同的可用区，其他RDS实例均为只读。到了这个规模之后，再要往上扩展到百万级，就需要改变部分工作负载的设计方式了。改变部分工作负载的设计方式第一步可以引入S3和CloudFront。把静态内容从Web实例中迁移到S3上，适合的文件类型包括静态数据（CSS、JS、图片、视频）、日志、备份等。S3具备11个9的持久性，本身是海量存储，可以支撑大量的并发访问，而且成本很低。CDN方面，CloudFront以Web Service接口的方式提供服务，支持动态和静态内容、流式视频，支持根域，支持客户化SSL证书。第二步可以引入ElastiCache和DynamoDB。ElastiCache是托管的Memcached和Redis服务，API是一样的，两者都是非常快的缓存服务（毫秒级别），区别在于Memcached使用一个AZ，Redis可以跨AZ复制。DynamoDB是NoSQL服务，后台存储基于SSD，平均延时在毫秒级别。这时候我们可以开始考虑弹性的问题，即应用的自动扩展。弹性的实现有四个前提：完善的、基于指标的监控体系自动化构建自动化部署集中化日志管理在AWS上实现自动构建部署，可以选择Beanstalk、OpsWorks或CloudFormation，也可以完全自己写脚本配合定制AMI来实现。Elastic Beanstalk是全自动化的，基于容器实现，适合常规的Web应用；OpsWorks是半自动化的，适合较为复杂的应用开发流程，可以对资源配给、配置管理、应用部署、软件升级、监控、身份控制进行定制化；CloudFormation是基于模板的管理模式，可定制的范围更大。如果以上都做到，那么一个百万级用户量的应用基本上可以比较好的管理起来。进一步到千万级用户量的规模，我们需要更多的引入面向服务的架构设计，即SOA。 SOA、SOA、SOA SOA在04、05年讲得比较多，到现在基本上已经是大家都认可的做法，非常适合大规模应用的场景，其核心在于松耦合。比如消息队列服务SQS，加在模块A和模块B之间，这样即使模块A宕掉了，模块B也仍然可以正常运行一段时间。美国大选网站就是采用了这样的思路，在SQL实例压力大的时候把实例关掉，换上一个更大的实例，因为前面有SQS顶着才可以这样做。而AWS上的通知服务（SNS）、邮件服务（SES），也建议大家多多采用，而不要自己搭建Web实例来做，因为此类服务在处理海量请求方面的能力要远远超过一般的实现。千万级规模对数据库的性能挑战是很大的，对于SQL，联邦（federation）、分片（sharding）都是常用的方法，将“热”表、快速写数据迁移到NoSQL也是一种思路。应用的性能挑战方面，重点则在于即时获得反馈（完善实时的监控+报警），以及持续的调优各个模块。

文章TAG：memcache 监控哪些数据 memcache监控哪些数据库