Memcached
什么是Memcached
许多Web 应用程序都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大，访问的集中，就会出现REBMS的负担加重，数据库响应恶化，网站显示延迟等重大影响。
Memcached是高性能的分布式内存缓存服务器。一般的使用目的是通过缓存数据库查询结果，减少数据库的访问次数，以提高动态Web 应用的速度、提高扩展性。如图：
Memcached的特点：
Memcached作为高速运行的分布式缓存服务器具有以下特点。
1.协议简单：memcached的服务器客户端通信并不使用复杂的MXL等格式，
而是使用简单的基于文本的协议。
2.基于libevent的事件处理：libevent是个程序库，他将Linux 的epoll、BSD
类操作系统的kqueue等时间处理功能封装成统一的接口。memcached使
用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高
性能。
3.内置内存存储方式：为了提高性能，memcached中保存的数据都存储在
memcached内置的内存存储空间中。由于数据仅存在于内存中，因此重
启memcached，重启操作系统会导致全部数据消失。另外，内容容量达
到指定的值之后memcached回自动删除不适用的缓存。
4.Memcached不互通信的分布式：memcached尽管是“分布式”缓存服务器，
但服务器端并没有分布式功能。各个memcached不会互相通信以共享信
息。他的分布式主要是通过客户端实现的。
Memcached的内存管理
最近的memcached默认情况下采用了名为Slab Allocatoion的机制分配，管理内存。在改机制出现以前，内存的分配是通过对所有记录简单地进行malloc 和free来进行的。但是这中方式会导致内存碎片，加重操作系统内存管理器的负担。
Slab Allocator的基本原理是按照预先规定的大小，将分配的内存分割成特定长度的块，已完全解决内存碎片问题。Slab Allocation 的原理相当简单。将分配的内存分割成各种尺寸的块（chucnk），并把尺寸相同的块分成组（chucnk的集合）如图：
而且slab allocator 还有重复使用已分配内存的目的。也就是说，分配到的内存不会释放，而是重复利用。
Slab Allocation 的主要术语
Page :分配给Slab 的内存空间，默认是1MB。分配给Slab 之后根据slab 的大小切分成chunk.
Chunk : 用于缓存记录的内存空间。
Slab Class:特定大小的chunk 的组。
在Slab 中缓存记录的原理
Memcached根据收到的数据的大小，选择最合适数据大小的Slab (图2) memcached中保存着slab内空闲chunk的列表，根据该列表选择chunk,然后将数据缓存于其中。
Memcached在数据删除方面有效里利用资源
Memcached删除数据时数据不会真正从memcached中消失。Memcached不会释放已分配的内存。记录超时后，客户端就无法再看见该记录（invisible 透明），其存储空间即可重复使用。
Lazy Expriationmemcached内部不会监视记录是否过期，而是在get时查看记录的时间戳，检查记录是否过期。这种技术称为lazy expiration.因此memcached 不会再过期监视上耗费CPU时间。
LRU:从缓存中有效删除数据的原理
Memcached会优先使用已超时的记录空间，但即使如此，也会发生追加新纪录时空间不足的情况。此时就要使用名为Least Recently Used (LRU)机制来分配空间。这就是删除最少使用的记录的机制。因此当memcached的内存空间不足时（无法从slab class）获取到新空间时，就从最近未使用的记录中搜索，并将空间分配给新的记录。
Memcached分布式
Memcached虽然称为“分布式“缓存服务器，但服务器端并没有“分布式”的功能。Memcached的分布式完全是有客户端实现的。现在我们就看一下memcached是怎么实现分布式缓存的。
例:
下面假设memcached服务器有node1～node3三台，应用程序要保存键名为“tokyo”“kanagawa”“chiba”“saitama”“gunma” 的数据。
首先向memcached中添加“tokyo”。将“tokyo”传给客户端程序库后，客户端实现的算法就会根据“键”来决定保存数据的memcached服务器。服务器选定后，即命令它保存“tokyo”及其值。
同样，“kanagawa”“chiba”“saitama”“gunma”都是先选择服务器再保存。
接下来获取保存的数据。获取时也要将要获取的键“tokyo”传递给函数库。函数库通过与数据保存时相同的算法，根据“键”选择服务器。使用的算法相同，就能选中与保存时相同的服务器，然后发送get命令。只要数据没有因为某些原因被删除，就能获得保存的值。
这样，将不同的键保存到不同的服务器上，就实现了memcached的分布式。memcached服务器增多后，键就会分散，即使一台memcached服务器发生故障无法连接，也不会影响其他的缓存，系统依然能继续运行。
分布式缓存服务器设计原理 1.数据是如何被分布到多个服务器上的？（一致性哈希算法） 假设有n台服务器， 计算这n台服务器的IP地址的哈希值， 把这些哈希值从小到大按顺时针排列组成一个“服务器节点环”， 客户端需要存储一系列的“键值对”到这些服务器上去， 计算这些“键”的哈希值， 看看这些“键”的哈希值落在“服务器环”的哪些区间， 如下图所示： 根据上图示意，数据将被存储在“顺时针方向上的下一个服务器节点” 读取数据时，也是先根据“键”的哈希值，找到这个服务器节点， 再向这个节点索取数据。 2.数据如何均匀的分布？（虚拟服务器） 假设服务器数量较少， 很可能造成有些服务器存储的数据较多、承担的压力较大， 有些服务器就比较空闲。 这时就要把一台服务器虚拟化成多台服务器， 具体的操作办法： 在计算服务器对应的哈希值时 可以在IP地址字符串加多个“尾缀” 比如：
10.0.0.1#1 10.0.0.1#2 10.0.0.1#3 .... 这样，一台物理服务器就被虚拟化成多台服务器， 对应“服务器环”上的多个节点。 3.如何实现数据的热备份？ 以顺时针方向看“服务器环” 当有客户端把数据存储在第1台服务器上后， 第1台服务器负责把该数据拷贝一份给第2台服务器 以此类推， 也就是说“服务器环”上的每一个节点，都是上一个节点的热备份节点 同时，一个服务器上存了两类数据，一类是自身的业务数据，一类是上一节点的热备数据。注意：这里所说的服务器，都是物理服务器，不是虚拟服务器。 如下图所示 4.如何让客户端发现所有服务端？ 每个服务器节点都要维护一个对照表 这个对照表中包含所有服务器，（IP地址和IP地址的哈希值对照表） 配置客户端时，只要让客户端知道任意一个服务器的IP地址即可 客户端可以通过获取这个服务器的对照表从而知道所有的服务器 客户端初始化的时候，这个对照表也存储在客户端一份 客户端根据这个对照表来存取数据
redis和memcached什么区别？为什么高并发下有时单线程的redis比多线程的memcached效率要高？ 区别： 1.mc可缓存图片和视频。rd支持除k/v更多的数据结构; 2.rd可以使用虚拟内存，rd可持久化和aof灾难恢复，rd通过主从支持数据备份; 3.rd可以做消息队列。 原因：mc多线程模型引入了缓存一致性和锁，加锁带来了性能损耗。 redis主从复制如何实现的？redis的集群模式如何实现？redis的key是如何寻址的？ 主从复制实现：主节点将自己内存中的数据做一份快照，将快照发给从节点，从节点将数据恢复到内存中。之后再每次增加新数据的时候，主节点以类似于mysql的二进制日志方式将语句发送给从节点，从节点拿到主节点发送过来的语句进行重放。 分片方式： -客户端分片 -基于代理的分片 ●Twemproxy ●codis -路由查询分片 ●Redis-cluster（本身提供了自动将数据分散到Redis Cluster不同节点的能力，整个数据集合的某个数据子集存储在哪个节点对于用户来说是透明的） redis-cluster分片原理：Cluster中有一个16384长度的槽(虚拟槽)，编号分别为0-16383。每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，可以由用户指定，也可以在初始化的时候自动生成，只有Master才拥有槽的所有权。Master节点维护着一个16384/8字节的位序列，Master节点用bit来标识对于某个槽自己是否拥有。比如对于编号为1的槽，Master只要判断序列的第二位（索引从0开始）是不是为1即可。这种结构很容易添加或者删除节点。比如如果我想新添加个节点D, 我需要从节点A、B、C中得部分槽到D上。 使用redis如何设计分布式锁？说一下实现思路？使用zk可以吗？如何实现？这两种有什么区别？ redis: 1.线程A setnx(上锁的对象,超时时的时间戳t1)，如果返回true，获得锁。 2.线程B 用get获取t1,与当前时间戳比较,判断是是否超时,没超时false,若超时执行第3步; 3.计算新的超时时间t2,使用getset命令返回t3(该值可能其他线程已经修改过),如果 t1==t3，获得锁，如果t1!=t3说明锁被其他线程获取了。 4.获取锁后，处理完业务逻辑，再去判断锁是否超时，如果没超时删除锁，如果已超时，不用处理（防止删除其他线程的锁）。 zk: 1.客户端对某个方法加锁时，在zk上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点node1; 2.客户端获取该路径下所有已经创建的子节点，如果发现自己创建的node1的序号是最小的，就认为这个客户端获得了锁。 3.如果发现node1不是最小的，则监听比自己创建节点序号小的最大的节点，进入等待。
分布式缓存的最佳实践案例分析
本文主要介绍使用分布式缓存的优秀实践和线上案例。这些案例是笔者在多家互联网公司里积累并形成的优秀实践，能够帮助大家在生产实践中避免很多不必要的生产事故。 一、缓存设计的核心要素 我们在应用中决定使用缓存时，通常需要进行详细的设计，因为设计缓存架构看似简单，实则不然，里面蕴含了很多深奥的原理，如果使用不当，则会造成很多生产事故甚至是服务雪崩之类的严重问题。 笔者在做设计评审的过程中，总结了所有与缓存设计相关的设计点，这里列出来供大家参考。 1、容量规划 ?缓存内容的大小 ?缓存内容的数量 ?淘汰策略 ?缓存的数据结构 ?每秒的读峰值 ?每秒的写峰值
2、性能优化 ?线程模型 ?预热方法 ?缓存分片 ?冷热数据的比例3、高可用 ?复制模型 ?失效转移 ?持久策略 ?缓存重建 4、缓存监控 ?缓存服务监控 ?缓存容量监控
?缓存请求监控 ?缓存响应时间监控 5、注意事项 ?是否有可能发生缓存穿透 ?是否有大对象 ?是否使用缓存实现分布式锁 ?是否使用缓存支持的脚本（Lua） ?是否避免了Race Condition 笔者在这里把这些设计点提供给读者，请读者在做缓存设计时把每一项作为一个思考的起点，思考我们在设计缓存时是否想到了这些点，以避免在设计的过程中因忽略某一项而导致严重的线上事故发生。 二、缓存设计的优秀实践 笔者在做设计评审的过程中，总结了一些开发人员在设计缓存系统时的优秀实践，如下所述：
优秀实践1 缓存系统主要消耗的是服务器的内存，因此，在使用缓存时必须先对应用需要缓存的数据大小进行评估，包括缓存的数据结构、缓存大小、缓存数量、缓存的失效时间，然后根据业务情况自行推算在未来一定时间内的容量的使用情况，根据容量评估的结果来申请和分配缓存资源，否则会造成资源浪费或者缓存空间不够。 优秀实践2 建议将使用缓存的业务进行分离，核心业务和非核心业务使用不同的缓存实例，从物理上进行隔离，如果有条件，则请对每个业务使用单独的实例或者集群，以减小应用之间互相影响的可能性。笔者就经常听说有的公司应用了共享缓存，造成缓存数据被覆盖以及缓存数据错乱的线上事故。 优秀实践3
Memcached 源码剖析笔记 Xguru Memcached是一个自由、源码开放、高性能、分布式 内存对象缓存系统，目的在于通过减轻数据库负载来使 动态Web应用程序提速。
目录 1.背景 (3) 2.memcached的安装 (4) 3.memcached的配置 (5) 4.memcached的使用 (6) 4.1.存储命令 (7) 4.2.读取命令 (8) 4.3.删除命令 (8) 4.4.高级命令 (9) 4.5.其他命令 (10) 5.Memcached内部工作机制 (11) 5.1.Memcached基本的数据结构 (11) 5.2.基本设计概念和处理流程 (12) 5.3.内部Hash机制 (15) 5.3.1.Hash函数及冲突解决 (15) 5.3.2.HashTable主要函数 (15) 5.4.slab内存处理机制 (17) 5.4.1.slab主要函数 (17) 5.4.2.slab机制中所采用的LRU算法 (19) 5.5.控制item各种函数 (20) 5.6.守护进程机制 (22) 5.7.Socket处理机制 (23) 1
5.7.1.Unix域协议 (23) 5.7.2.TCP/UDP协议 (24) 5.8.多线程处理机制 (25) 5.9.事件处理机制 (25) 6.未完善之处 (27) 7.参考文献 (28) 2
1.背景 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。 Memcached是一个自由、源码开放、高性能、分布式内存对象缓存系统，目的在于通过减轻数据库负载来使动态Web应用程序提速。 Memcached是一个在内存中对任意的数据（比如字符串，对象等）所使用的key-value 存储。数据可以来自数据库调用，API调用，或者页面渲染的结果。 Memcached设计理念就是小而强大，它简单的设计促进了快速部署、易于开发，并解决面对大规模的数据缓存的许多难题。所开放的API能用于大部分流行的程序语言 3
MemCache是一套高性能分布式的高速缓存系统，用于动态Web应用以减轻数据库负载，由LiveJournal的Brad Fitzpatrick开发。目前被许多网站使用以提升网站的访问速度，尤其对于一些大型的、需要频繁访问数据库的网站访问速度提升效果十分显著。这是一套开放源代码软件，以BSD license授权发布。 MemCache通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高了网站访问的速度。MemCache是一个存储键值对的HashMap，在内存中对任意的数据(比如字符串、对象等)所使用的key-value存储，数据可以来自数据库调用、API调用，或者页面渲染的结果。 MemCache设计理念就是小而强大，它简单的设计促进了快速部署、易于开发并解决面对大规模的数据缓存的许多难题，而所开放的API使得MemCache能用于Java、C/C++/C#、Perl、 Python、PHP、Ruby等大部分流行的程序语言。 MemCache工作原理MemCache采用C/S架构，在服务器端启动后，以守护程序的方式，监听客户端的请求。启 动时可以指定监听的IP(服务器的内网ip/外网ip)、端口号(所以做分布式测试时，一台服务器上可以启动多个不同端口号的MemCached进程)、使用的内存大小等关键参数。一旦启动，服务就会一直处于可用状态。
为了提高性能，MemCache缓存的数据全部存储在MemCache管理的内存中，所以重启服务器之后缓存数据会清空，不支持持久化。 MemCache内存管理 内存结构 每个slab_class里面包含若干个slab。 每个slab里面包含若干个page，page的默认大小是1M。 每个page里面包含若干个chunk，chunk是数据的实际存放单位，每个slab 里面的 chunk大小相同 内存分配方式 Memcached使用slab allocation机制来分配和管理内存。 先将分配的内存按照预设好的大小分割成特定长度的内存块，再把尺寸相同的内存块分 成组。数据在存放时，根据键值大小去匹配slab大小，找就近的slab存放。而传统的内存管理方式是，使用完通过malloc分配的内存后通过free来回收内存，这种方式容易产生内存碎片并降低操作系统对内存的管理效率。 存放数据时，首先slab要申请内存，申请内存以page为单位。
目录 第一阶段、Spring Boot从入门到精通（10小时） (1) 第二阶段、小型电商网站开发+设计模式+架构设计+项目管理（20小时） (2) 第三阶段、Spring Cloud从入门到精通（20小时） (3) 第四阶段、电商网站的微服务架构（20小时） (3) 第五阶段、高并发大型电商网站架构（150小时） (4) 第六阶段、高可用大型电商网站架构（30小时） (6) 第七阶段、高性能大型电商架构（30小时） (7) 第八阶段、亿级流量的大型电商系统架构（150小时） (7) 第九阶段、自己动手做多租户SaaS云ERP系统 (8) 第十阶段、底层技术+微服务中间件（50小时） (9) 第十一阶段、自己动手写仿Storm的实时计算中间件 (10) 第十二阶段、开源框架源码阅读+定制化开发mvc/ioc/orm框架（50小时） (10) 第十三阶段、自己动手写工作流框架 (10) 授课方式说明 (10) 学习进度说明 (11) 就业指导说明 (12) 学习成果说明 (12) 2万费用说明 (13) 讲师课程质量以及是否会跑路 (14) 第一阶段、Spring Boot从入门到精通（10小时） 目前市面上所有的视频课程以及书籍，都只是简单介绍Spring Boot的基础知识，没有任何一套资料深入讲解这两个技术的。而如果你自己跟着官网慢慢看，全英文官网，估计大部分同学都很难看的懂，或者学习速度非常慢。 我会将Spring Boot的所有核心技术点以及高阶技术点，全部嚼烂咬碎，深度提炼，用最精炼的语言，给大家讲透，让大家在最短的时间内彻底掌握这个未来绝对主流的开发框架，为未来的高阶的项目打好扎实的基础。 强调一下，这块技术讲解，绝对不会采取拖延时间，以及碎碎念的方式，一点一点细节慢慢
一、Memcached 1.1、memcached简介 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web 应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。但是它并不提供冗余（例如，复制其hashmap条目）；当某个服务器S停止运行或崩溃了，所有存放在S上的键/值对都将丢失。 Memcached由Danga Interactive开发，其最新版本发布于2010年，作者为Anatoly Vorobey和Brad Fitzpatrick。用于提升LiveJournal . com访问速度的。LJ每秒动态页面访问量几千次，用户700万。Memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。 1.2、Memcached是如何工作的 Memcached的神奇来自两阶段哈希（two-stage hash）。Memcached就像一个巨大的、存储了很多
《网络协议栈分析与设计》大作业 边界网关协议(BGP)RFC分析与设计Border Gateway Protocol 学生：吕卿网络1101班 201192334 2013/12/16
1.背景介绍 边界网关协议是用来连接网络上不同自治系统（AS）的路由选择协议。BGP是为了取代最初的外部网关协议EGP所设计的，也被认为是路径矢量协议。它通过维护IP路由表和前缀表来实现自治系统（AS）间的可达性。BGP的主要功能是和其他BGP系统交换网络可达性信息。必须要注意的是BGP是建立在可靠连接的基础之上的。 2.操作总结 在两个系统建立的连接中他们互相交互信息更改数据。初始数据流是整个BGP路由表。BGP不要求整个BGP路由表的周期性更新。保持存活信息定期的被发送以确保连接的存活。通知信息被发送来回馈错误通知和特殊情况。执行边际路由协议的主机不必是路由器。一个非路由器的主机可以和路由器经由EGP甚至内部路由协议进行交互。如果一个特殊的自治系统（AS）有多个BGP发言者，那么一定要注意在一个AS内要的几个发言者要有一致的路由视野。 3.信息格式 信息在可靠传输协议连接上发送。信息只有在被完全接收之后才能够被处理。最大的信息大小是4096字节。所有的实现必须支持这一最大信息规格。最小的数据规格要包含BGP头部不含数据部分。 3.1数据头格式 每个信息有个固定大小的头部。包括标识物·长度·类型。标识物：这16字节大小的领域包含信息接收方可以对信息进行确认的信息。长度：这2字节无符号整数表明这则信息的总长度。长度的值必须在19到4096之间类型：这一字节无符号整数表明这则信息的代码模式。共有四种类型： 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
memcache、redis、tair性能对比测试报告 第1章限制条件 前一周所做的分布缓存技术预言中有包括ehcache、memcache、redis、tair，还包括了基于MongoDB的分布式技术。测试中，考虑到各自功能的差异化特点，其中选择了memcache、redis、tair功能特性相近的缓存服务器进行性能对比，所以ehcache、MongoDB将不做为本次测试的规范，其原因如下： 1）Ehcache是组件级别的缓存，要搭建一个独立的缓存服务器，需要用到ehcache server 模块，这是个war包，能运行在web 容器中，决定整个缓存服务器性能的好坏因素太多，比如web服务器，集群方式等。跟memcache、redis、tair没有对比性。 2）MongoDB是面向文档的数据库，跟缓存没有可比性。 第2章测试场景概述 性能测试包括单机环境和分布式环境，主要针对memcache、redis、tair各缓存服务器在缓存了不同级别的数据下,多个线程并发操作向缓存set/get缓存数据，考虑到网络方面的负载，又将每次set/get操作的缓存数据的大小分为三个不同的级别：1KB,10KB,100KB,通过对上述的条件进行排列，取得以下的测试场景。 第3章单机环境测试 3.1.测试场景： 1.当各缓存的数据库空时，以单线程通过各缓存客户端set调用向服务端推送数据，比较 10000操作所消耗的时间，以上动作通过使用不同大小的单个缓存对象重复三次。2.在场景一完成的情况下，以单线程通过各缓存客户端get调用向服务端获取数据，比较 10000操作所消耗的时间，以上动作通过使用不同大小的单个缓存对象重复三次。3.并发200个线程通过缓存软件的客户set调用向服务端推送数据，每个线程完成10000 次的操作，比较服务器的tps大小，以上动作通过使用不同大小的单个缓存对象重复三
Memcached 什么是Memcached 许多Web 应用程序都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大，访问的集中，就会出现REBMS的负担加重，数据库响应恶化，网站显示延迟等重大影响。 Memcached是高性能的分布式内存缓存服务器。一般的使用目的是通过缓存数据库查询结果，减少数据库的访问次数，以提高动态Web 应用的速度、提高扩展性。如图： Memcached的特点： Memcached作为高速运行的分布式缓存服务器具有以下特点。 1.协议简单：memcached的服务器客户端通信并不使用复杂的MXL等格式， 而是使用简单的基于文本的协议。 2.基于libevent的事件处理：libevent是个程序库，他将Linux 的epoll、BSD 类操作系统的kqueue等时间处理功能封装成统一的接口。memcached使 用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高 性能。 3.内置内存存储方式：为了提高性能，memcached中保存的数据都存储在 memcached内置的内存存储空间中。由于数据仅存在于内存中，因此重 启memcached，重启操作系统会导致全部数据消失。另外，内容容量达
到指定的值之后memcached回自动删除不适用的缓存。 4.Memcached不互通信的分布式：memcached尽管是“分布式”缓存服务器， 但服务器端并没有分布式功能。各个memcached不会互相通信以共享信 息。他的分布式主要是通过客户端实现的。 Memcached的内存管理 最近的memcached默认情况下采用了名为Slab Allocatoion的机制分配，管理内存。在改机制出现以前，内存的分配是通过对所有记录简单地进行malloc 和free来进行的。但是这中方式会导致内存碎片，加重操作系统内存管理器的负担。 Slab Allocator的基本原理是按照预先规定的大小，将分配的内存分割成特定长度的块，已完全解决内存碎片问题。Slab Allocation 的原理相当简单。将分配的内存分割成各种尺寸的块（chucnk），并把尺寸相同的块分成组（chucnk的集合）如图： 而且slab allocator 还有重复使用已分配内存的目的。也就是说，分配到的内存不会释放，而是重复利用。 Slab Allocation 的主要术语 Page :分配给Slab 的内存空间，默认是1MB。分配给Slab 之后根据slab 的大小切分成chunk. Chunk : 用于缓存记录的内存空间。 Slab Class:特定大小的chunk 的组。 在Slab 中缓存记录的原理 Memcached根据收到的数据的大小，选择最合适数据大小的Slab (图2) memcached中保存着slab内空闲chunk的列表，根据该列表选择chunk,然后将数据缓存于其中。
我对于Memcached的接触，还是在去年看了CSDN的一系列国外大型网站架构设计而开始的。最初的时候只是简单的封装了Memcached Java版的客户端，主要是对于配置的简化以及Memcached多点备份作了一些工作，然后就作为ASF的组件一部分提供给其他Team使用。其实看过Memcached Java客户端代码的人就会了解其实客户端的事情很简单，就是要有一套高性能的Socket通信框架以及对Memcached的私有协议实现的接口，自己去做这些事情也是很简单的，不过既然有可以满足自己需求的开源部分，那么就去实现自己需要的但没有实现的。这里我用的是Whalin的客户端版本，这里为什么还要提出来讲这个，后面会提到。 在对Java客户端作了简单封装和扩展以后，由于其他Team使用的没有什么特殊需求，也就没有再去做太多的修改，直到最近自己的服务集成平台需要做服务访问控制，才重新丰富了Cache组件，也就是这个过程中对于Memcached的一些特性和小的细节有了一些新的认识。 作为服务集成平台需要对服务有所监控，包括访问频率控制以及访问次数控制。频率控制其实很类似于硬件方面的频率控制，例如硬件可以对IP的高频率访问视为攻击，列入黑名单。而作为服务的访问，对于服务访问者的控制其实涉及到了业务参数，那么硬件就不是很适合去做这方面的控制，为此我也考虑了很久，最开始打算在Apache上做一个模块控制，但是最后觉得还是放在后面的业务框架上做这件事情。当然后面我说说的方案可能并不好，但是也算是一种想法。要把频繁的访问数据记录下来同时分析，那么数据库肯定是不行的，最简单的方式就是采用Cache，又因为是集群范围内的控制，那么集中式Cache就非Memcached莫数了（分布式的Cache传播本身损耗太大，集中式Cache本来的最大缺点就是单点，但作简单的备份操作就可以基本解决此类问题）。 作为解决这个问题的方法来说只需要实现两部分工作：访问计数器，定时任务。定时任务在我做日志分析框架的时候都是采用了Jdk5的Concurrent包里面的ScheduledExecutorService，这个作简单的循环任务足够用了，同时也是有很好的多线程异步支持，复杂一点么用Quartz。计数器就要靠Memcached来实现了，本来一般的Cache最大的问题就是高并发下的事务保证，如果采用Get+Set 来完成计数的话，那么高并发下计数器就会出现读写不一致性的问题，幸好Memcached提供了计数累加功能，让这种累加动作能够在服务端一次做好，服务端控制并发写入，保证数据的一致性。 下面就看看以下几个方法： boolean storeCounter(String key, long count)：存储key的计数器，值为count。
Redis 是一个基于内存的高性能key-value数据库。(有空再补充，有理解错误或不足欢迎指正) Reids的特点 Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。 因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是已知性能最快的Key-Value DB。 Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。 另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。 Redis支持的数据类型 Redis通过Key-Value的单值不同类型来区分, 以下是支持的类型: Strings Lists Sets 求交集、并集 Sorted Set hashes
为什么redis需要把所有数据放到内存中？ Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。 如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天，redis将会越来越受欢迎。 如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。 Redis是单进程单线程的 redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销 虚拟内存 当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大. 当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value. vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的. 可能会造成比较长时间的延迟,但是对数据完整性有很好的保证. 自己测试的时候发现用虚拟内存性能也不错。如果数据量很大，可以考虑分布式或者其他数据库 分布式 redis支持主从的模式。原则：Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来同步数据。 这是一个典型的分布式读写分离模型。我们可以利用master来插入数据，slave提供检索服务。这样可以有效减少单个机器的并发访问数量。
一、背景 在高并发的分布式的系统中，缓存是必不可少的一部分。没有缓存对系统的加速和阻挡大量的请求直接落到系统的底层，系统是很难撑住高并发的冲击，分布式系统中缓存的设计是很重要的一环 使用缓存的收益： ●加速读写，缓存一般是内存操作，要比传统数据库操作要快的多 ●降低后端的负载。缓存一些复杂计算或者耗时得出的结果可以降低后端系统对CPU、 IO、线程这些资源的需求 ●本地缓存远端调用结果，减少服务间的调用，提升服务并发能力 目前问题： ●目前业务中对缓存的使用并不多，在这次直播活动中，组件性能瓶劲很多，有很大一 部分是可以通过缓存加速的 ●疫情直播活动期间，几个核心服务由于人手、改造难度问题等，最后由罗陈珑做一了 个缓存代理服务，把UC、EOMS的部分接口做了缓存代理，这些缓存本来应該由服务提供者来实现的 ●数据一致性问题，加了缓存之后，随之而来的就是数据一致性的问题，发现有数据不 能及时更新 ●目前大家对缓存使用方式不太统一，有的组件使用本地JVM缓存时封装太复杂，出现 问题不好定位，清除缓存也不好做 二、目标 ●降低分布式缓存技术使用门槛，将分布式缓存框架作为微服务开发必备的脚手架，让
开发者更易使用，避免因技术门槛而放弃使用缓存 梳理核心业务，使用分布式缓存加速服务响应速度，降低服务负载 三、分布式缓存方案 3.1 @WafCacheable 缓存 3.1.1 分布式缓存和本地jvm缓存 为了提高接口能力，需要将一些频繁访问但数据更新频率比较低的放入缓存中，不要每次从数据库或其他耗时耗资源的数据源中取。使用@WafCacheable 注解，缓存过期时间可以根据数据更新频率自由设定，不设置默认为2小时。 @WafCacheable 标记的方法被拦截后，数据获取的优先级：本地jvm缓存>redis缓存> 数据源（DB、RMI、其他耗时耗资源的操作） @WafCacheable 使用场景：高频访问低频更新的数据 注意：@WafCacheable 对同一个类里的内调方法（A调B， B上加注解不生效），如果直接用this.B()，加在B上的缓存不生效，需要使用${service}.B()调用(${service}指service实例)。 3.1.2 RMI缓存 RMI(Remote Method Invocation)是指微服务提供的SDK中FeignClient方式申请的接
大型分布式系统中的缓存架构 本文主要介绍大型分布式系统中缓存的相关理论，常见的缓存组件以及应用场景。 缓存概述 缓存概述 缓存的分类 缓存主要分为四类，如下图：
缓存的分类 CDN 缓存 CDN(Content Delivery Network 内容分发网络)的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中。 在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。 应用场景：主要缓存静态资源，例如图片，视频。CDN 缓存应用如下图：
未使用 CDN 缓存 使用 CDN 缓存CDN 缓存优点如下图： 优点
反向代理缓存 反向代理位于应用服务器机房，处理所有对 Web 服务器的请求。 如果用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。 如果没有缓冲则先向 Web 服务器发出请求，取回数据，本地缓存后再发送给用户。通过降低向 Web 服务器的请求数，从而降低了 Web 服务器的负载。 应用场景：一般只缓存体积较小静态文件资源，如css、js、图片。 反向代理缓存应用如下图：
反向代理缓存应用图开源实现如下图： 开源实现 本地应用缓存
指的是在应用中的缓存组件，其最大的优点是应用和Cache 是在同一个进程内部，请求缓存非常快速，没有过多的网络开销等。 在单应用不需要集群支持或者集群情况下各节点无需互相通知的场景下使用本地缓存较合适。 同时，它的缺点也是应为缓存跟应用程序耦合，多个应用程序无法直接的共享缓存，各应用或集群的各节点都需要维护自己的单独缓存，对内存是一种浪费。 应用场景：缓存字典等常用数据。 缓存介质如下图所示： 缓存介质 编程直接实现如下图：
豆瓣整个基础架构可以粗略的分为在线和离线两大块。在线的部分和大部分网站类似：前面用，用Nginx做反向代理，形成负载均衡的一层;应用层主要是做运算，将运算结果返回给前面的DAE平台是这两年建起来的，现在大部分豆瓣的应用基本都跑在DAE上面了;应用后面的基
以DPark能够大幅提升性能。另外，因为DPark的编写使用了函数式语言的特点，所以可以写的非常简洁： 到目前(2014年3月)，DPark的集群规模和处理数据量已经比去年多了一倍左右，一天要处 理60~100T B左右的数据。 团队 当前，我所负责的豆瓣平台部一共包括四个部分：核心系统，这块也是由我直接带领的，共6名工程师;DAE，现在是彭宇负责，共4名工程师;DBA两人;SA两人。 平台部负责的项目大多是跟业务无关的东西，贴近应用层的主要在产品线团队做，这个分工跟豆瓣工程团队的发展历史有关。早期豆瓣工程师还不多的时候，就已经分为两种倾向，一种是偏业务的，就是去做用户能看得见的东西;另一种是支持性的，运行在业务层下面、不被用户所感知的东西。下面这一层就衍变成了平台部门。 在豆瓣，不管是做产品还是做平台的工程师，技术实力都比较强，一个项目应该从哪个部门发起，并不是看这个任务的难度，而是看它是公共的还是业务特有的。有些项目即使未来可能会成为公共的，但一开始只是一个产品线需要，那么它也会从产品线发起。比如豆瓣的短信服务，最开始是产品线有需求，所以这些服务都是由他们发起完成的，平台这边主要负责提供建设服务的架构，比如DoubanService，告诉他们一个服务怎样去写、怎样去部署、怎样去对用户开放。短信服务后来成为很多产品线都在使用的服务，同时这个系统本身也越来越成熟，那么它逐渐就被转移到SA团队来进行维护。
simple-spring-memcached统一缓存的使用 实例 如何在一个中型的Java应用中使用Memcached缓存数据不是个简单的问题。当某个缓存数据需要在多个系统间共享和失效时，必须要有统一的规划才能保证不出错。经过各种实践，目前系统在使用Memcached缓存数据全部采用Simple-Spring-Memcached框架来完成，并统一规划各系统Spring和Cache key的配置。 下面对在使用过程中需要注意的点做一个详细说明： Cache整体规划 目前我们系统中有两个不同的Memcached服务器： 1session memcached服务器：主要存储用户的session 2app memcached服务器: 主要用于缓存应用数据 由于应用所有的缓存数据都放在app缓存上，为避免各应用的缓存数据出现冲突，必须规划好它们的命名空间。所幸Simple-Spring-Memcached支持namespace的概念，因此对各应用的namespace前缀规定如下： 应用namespace前缀 goodscenter goodscenter trade trade uic uic 这个namespace在生成key时，将放在最前面，稍后会有例子详述。 同一个应用中存在许多需要缓存的对象，因此约定namespace前缀之后再加上缓存对象的类名。 例子如下： 应用缓存对象完整的namespace 最终生成的key trade TcRate (id为42) trade:TcRate trade:TcRate:12 goodscenter GoodsDo(id为 42) goodscenter:GoodsDo goodscenter:GoodsDo:1 2 key的生成规则 Simple-Spring-Memcached提供的针对单个对象的注解接口提供了两种key生成方式，详情见此文
金蝶云星空 分布式缓存使用说明书 修改记录 Ver. No 发版日期编制人批准人修改的章节号V1.02017/12/08 刘兵赖碧云初始版本 V1.22018/01/03 刘兵赖碧云 6.1.2 V1.3 2018/02/24 刘兵赖碧云 6.1
目录 1.概述 (3) 1.1.目的 (3) 1.2.范围 (3) 1.3.适用对象 (3) 1.4.参考资料 (3) 2.问题与解决策略 (3) 3.目标和约束 (3) 4.部署Redis服务 (4) 4.1.安装服务--service-install(安装必须的步骤) (4) 4.2.卸载服务--service-uninstall (4) 4.3.启动服务--service-start(安装必须的步骤) (4) 4.4.停止服务--service-stop (5) 4.5.服务配置修改（服务名和端口） (5) 4.6.Redis-cli配置(如果4.1按照2，3小点进行了修改，此节配置可以忽略) (5) 5.Redis配置文件修改 (5) 6.Redis缓存代码示例 (6) 6.1.1.写缓存和读缓存 (6) 6.1.2.错误的读写缓存 (7) 7.附录 (8)
1. 概述 1.1. 目的 为系统集群及分布式应用提供基础缓存服务。 1.2. 范围 适用版本：V6.2和后续版本 1.3. 适用对象 本文档适用于： 开发工程师：部署和开发指导。 实施人员：部署指导。 1.4. 参考资料 Redis相关资料 2. 问题与解决策略 愿景关注点描述与示例 3. 目标和约束 目标： 提供单据和基础数据的分布式缓存支持；
一个社交App需实现的功能 用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等，需要提供的功能不胜枚举，所以从技术角度来说，开发者需要解决的问题也是异常复杂的。 当一款社交App发布之初，用户访问量比较小，使用一台服务器就能够支撑全部的访问压力和数据存储需求，但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象，访问量和数据量在短时间内呈现爆发式增长，这时候会面临的局面是每天上亿PV、数百万新增用户和活跃用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的，会直接导致服务器响应缓慢甚至超时，以及在高峰期时服务呈现瘫痪状态，使得后端的服务完全无法使用，用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。 社交App最初部署的后端架构解析 社交App在最初的时候，后端架构相对比较简单，最初是部署在基础网络之上。最前面放置一台绑定了公网IP的nginx服务器作负载均衡，后面放置3台应用服务器来负责处理所有业务上的请求，最后面搭建一台MySQL Database数据库。 构建私有网络 随着产品的不断迭代、用户数的持续增长、数据量的积累，App就需要改进自己的后端架构，即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创建路由器和私有网络，将后续加入的用于运行内部服务的主机放置在私用网络中，可以有效地和云平台其他用户主机，在网络上实现100%二层隔离。主机对外开放的仅仅只有80端口，这样系统安全性上多了一层保障。
在上面的架构图中，最前面的是防火墙，后面接负载均衡器，然后接路由器和私有网络，很多互联网应用都存在读多写少的情况，这个比例有时可以达到8:2，所以我们首先通过引入缓存分摊数据库读压力。其次，引入负载均衡器，替换最初架构中的nginx proxy，负责均衡器在这里其主要用于分发请求到后端多台应用服务器，，当其中一台应用服务器挂掉，负载均衡器可以进行自动隔离。 业务分区与扩展 App随着并发访问量和数据量不断增大，首先想到横向扩容Web服务。水平扩容业务服务器的前提是要保证每台服务器都是无状态的，将session信息下放到缓存或数据库中存储，保证请求被负载到任何一台服务器可以正常处理。
PHP大型网站的架构实例分析 Poppen.de是德国的一个社交网站，相对Facebook、Flickr来说是一个很小的网站，但它有一个很好的架构，融合了很多技术，如 Nigix、MySql、CouchDB、Erlang、Memcached、RabbitMQ、PHP、Graphite、Red5以及Tsung. 统计信息 200万注册用户数； 2万并发用户数； 每天20万条私有消息； 每天25万登录次数； 项目团队有11个开发人员，两个设计，两个系统管理员； 商业模式 该网站采用免费增值模式，用户可以免费使用下面任何服务： 搜索其他用户； 给好友发送消息； 上载图片和视频； 寻找好友； 视频聊天； 更多… 但如果用户想享受不受限制发送消息和上载图片，那么就得根据需要支付不同类型的会员服务，视频聊天及网站其他服务也采用同样的策略。 工具箱 Nginx Poppen.de 所有的服务都是基于Nginx服务上的。前端有两台Nginx服务器在高峰期提供每分钟15万次请求的负载，每个机器已经有四年寿命，并且只有一个CPU和3GB RAM.Poppen.de拥有三台独立的图像服务器，由三台Nginx服务器为*.bilder.poppen.de提供每分钟8万次请求服务。
Nginx架构中一个很酷的设计就是有很多请求是由Memcached处理的，因此请求从缓存中获取内容而不需要直接访问PHP机器。比如，用户信息页（user profile）是网站需要密集处理的内容，如果把用户信息页全部缓存到Memcached 上，那么请求直接从Memcached上获取内容。Poppen.de的Memcached每分钟可以处理8000次请求。 架构中有三个Nginx图像服务器提供本地图像缓存，用户上载图像到一个中央文件服务器。当向这三个Nginx之一中请求图像时，如果服务器本地中没有存在该图像，则从中央文件服务器下载到该服务器上作缓存并提供服务。这种负载均衡的分布式图像服务器架构设计可以减轻主要存储设备的负载。 PHP-FPM 该网站运行在PHP-FPM上。共有28台双CPU、6GB内存的PHP机器，每个机器上运行100个PHP-FPM的工作线程。使用启用了APC的PHP5.3.x. PHP5.3可以降低CPU和内存使用率的30%以上。 程序代码是基于Symfony1.2框架之上开发的。一是可以使用外部资源，二是能够提高项目开发进度，同时在一个著名的框架上可以让新开发人员更容易加入到团队中来。虽然没有任何事情都是十全十美的，但可以从Symfony框架中得到很多好处，让团队可以更多的精力放在Poppen.de的业务开发上去。 网站性能优化使用XHProf，这是Facebook开源出来的一个类库。这个框架非常容易个性化和配置，能够可以缓存大部分高代价的服务器计算。 MySQL MySQL是网站主要的RDBMS.网站又几个MySql服务器：一台4CPU、32GB的服务器存储用户相关信息，如基本信息、照片描述信息等。这台机器已经使用了4年，下一步计划会使用共享集群来替换它。目前仍基于这个系统上进行设计，以简化数据访问代码。根据用户ID进行数据分区，因为网站中大部分信息都是以用户为中心的，如照片、视频、消息等。 有三台服务器按主-从-从配置架构提供用户论坛服务。一台从服务器负责网站自定义消息存储，到现在有2.5亿条消息。另外四台机器为主-从配置关系。 另外由4台机器配置成NDB族群专门服务于密集型写操作数据，如用户访问统计信息。 数据表设计尽量避免关联操作，尽可能缓存最多的数据。当然，数据库的结构化规范已经完全被破坏掉了。因此，为了更容易搜索，数据库设计创建了数据挖掘表。 大部分表是MyISAM型表，可以提供快速查找。现在的问题是越来越多的表已经全表锁住了。Poppen.de正考虑往XtraDB存储引擎上迁移。