memcache

传统MySQL+ Memcached架构遇到的问题 实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题： MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。 Memcached与MySQL数据库数据一致性问题。 Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。 跨机房cache同步问题。 众多NoSQL百花齐放，如何选择 最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问 题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决 以下几种问题 少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。 这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计

memcache官方定义 Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. redis官方定义 Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. 版权相同 它们都是使用的bsd协议，使用它的项目可以用于商业用户，不必发布二次修改的代码，可以修改源代码。 数据类型 redis数据类型丰富，支持set liset等类型 memcache支持简单数据类型，需要客户端自己处理复制对象 持久性 redis支持数据落地持久化存储 memcache不支持数据持久存储 分布式存储 redis支持master-slave复制模式

本文转自：http://blog.csdn.net/zeb_perfect/article/details/54135506 前言 设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。 缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案 有很多种方法可以有效地解决缓存穿透问题， 是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存雪崩 缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。 解决方案 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写

前言 设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。 缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存雪崩 缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。 解决方案 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1

针对curd,操作如下 1，查询数据(select)，首先通过指定的Key查询(get)Memcache中间缓存层数据，如果存在相对应数据，则直接获取出数据结果，查询过程完全不需要查询数据库。如果不存在，则查询MySQL数据库，并以key对应value的形式将查询结果存储在Memcache缓存数据中，然后将结果返回给查询语句。 2，更新数据(update)，首先更新数据，然后删除相关的memcache数据(delete)。 3，增加数据(add)，首先删除相关缓存数据，然后增加数据。 4，删除数据(delete)，删除数据，并删除Memcache数据。 -------------------- 本来我一直不知道怎么来更好地优化网页的性能，然后最近做python和php同类网页渲染速度比较时，意外地发现一个很简单很白痴但是我一直没发现的好方法（不得不BS我自己）：直接像某些php应用比如Discuz论坛那样，在生成的网页中打印出“本页面生成时间多少多少秒”，然后在不停地访问网页测试时，很直观地就能发现什么操作会导致瓶颈，怎样来解决瓶颈了。 于是我发现 SimpleCD 在生成首页时，意外地竟然需要0.2秒左右，真真不能忍：对比Discuz论坛首页平均生成才0.02秒，而Discuz论坛的首页页面无疑比SimpleCD的主页要复杂不少；这让我情何以堪啊

通过前三篇的教程，相信大家基本上了解了微信开发的基本流程，先判断用户传入数据的类型MsgType，然后再获取用户输入的内容content,再对content进行处理，再返回给用户 现在我们来加点料，在完成了前三篇的基础上，我们把小黄鸡的自动回复功能整合到我们的微信中，我们最终实现的目的是这样的，当用户输入xhj指令后，进行和小黄鸡的对话中，这时候用户每输入的内容都将传给小黄鸡，然后小黄鸡进行回复，我们得到小黄鸡的回复内容后再返回给用户。 主要的问题，比如当用户输入“你好”，因为微信之前有翻译功能，那么我们的微信是如何判断你想要发送的是和小黄鸡的对话还是想要翻译“你好”这个单词？ 解决这个问题就需要我们这次教程中所要用到的memcache，我们使用memcache来记录一个状态，比如mc.set(‘xhj’,' true’),那么当用户发送“你好”时，程序先从memcache中获取一个’xhj’ 这个key的值，如果是true 那么说明用户发送“你好”是为了和小黄鸡对话，当memcache中没有’xhj’ 这个key的时候，说明用户是想要翻译“你好”这个单词 这样问题看似就可以解决了，但是会有另外一个问题，当有两个用户同时发送“你好”时，A用户想要和小黄鸡对话，B用户想要翻译“你好”，那么此时，当memcache中有xhj且值为true，那么两个人得到的回复将都会是小黄鸡的回复

Memcached API set(key,val,time=0,min_compress_len=0) 无条件键值对的设置，其中的time用于设置超时，单位是秒，而min_compress_len则用于设置zlib压缩(注:zlib是提供数据压缩用的函式库) set_multi(mapping,time=0,key_prefix='',min_compress_len=0) 设置多个键值对，key_prefix是key的前缀，完整的键名是key_prefix+key, 使用方法如下 >>> mc.set_multi({'k1' : 1, 'k2' : 2}, key_prefix='pfx_') == [] >>> mc.get_multi(['k1', 'k2', 'nonexist'], key_prefix='pfx_') == {'k1' : 1, 'k2' : 2} add(key,val,time=0,min_compress_len=0) 添加一个键值对，内部调用_set()方法 replace(key,val,time=0,min_compress_len=0) 替换value，内部调用_set()方法 get(key) 根据key去获取value，出错返回None get_multi(keys,key_prefix='') 获取多个key的值，返回的是字典

　　一个大型稳健成熟的分布式系统的背后，往往会设计众多的支撑组件，将这些支撑系统成为分布式系统的基础设施。进行系统架构设计所依赖的基础设施，还包括分布式协作及配置管理组件、分布式缓存组件、持久化存储组件、分布式消息系统、搜索引擎、以及CDN系统、负载均衡系统、运维自动化系统等，还有实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等。此处主要讲讲缓存系统组件。 缓存组件层 缓存系统带来的好处： 加速读写。缓存通常是全内存的，比如Redis、Memcache。对内存的直接读写会比传统的存储层如MySQL，性能好很多。由于单台机器的内存资源和承载能力有限，并且如果大量使用本地缓存，也会使相同的数据被不同的节点存储多份，对内存资源造成较大的浪费，因此才催生出了分布式缓存。 降低后端的负载。在高并发环境下，大量的读、写请求涌向数据库，磁盘的处理速度与内存显然不在一个量级，从减轻数据库的压力和提供系统响应速度两个角度来考虑，一般都会在数据库之前加一层缓存。 缓存系统带来的成本： 数据不一致性：在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署(为了保证可用性，一定是部署多份的)，对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成(读出脏数据) 代码维护成本：加入缓存后

MemCached 个人总结 1. MemCached 简介 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态、数据库驱动网站的速度。 Memcached基于一个存储键/值对的 hashmap ， 所有数据都放在储存在内存中。 2. 使用MemCached准备 Memcached 插件，Memcached完全依赖它，在使用Memcached必须启动这个插件。双击。 这代表 Memcached插件已经启动成功，如果插件停止，那么所有的内存数据将会被销毁。 3. MemCached 用到的 jar 4. MemCached 流程 5. MemCached 实际使用个人思路 MemCacheUtil 负责 Cache 底层操作 MemCacheSupport 负责调用 Util 减化操作、 公共初始化数据↓ 创建 公共数据类 在 MemCacheUtil 进行初始化 根据特殊需要↓ EntityCache 实体CacheDao EntityCacheImpl 实体 CacheDaoImpl 继承 MemCacheSupport 6. MemCaChed 配置 服务器端口:可以设置多个Ip，实现分布式缓存 memcache.server= 127.0.0.1 : 11211

memcached最大能保存1M的数据，因此对于小的文本文件是完全可行的。 脚本函数如下，将天气预报网的某城市JSON数据保存到memcache中： function cacheData() { expir=18000 mem='10.10.10.10' tmp=`curl http://m.weather.com.cn/data/101280601.html -s` | iconv -f utf-8 -t gbk tmp_length=`expr length $tmp` #tmp_length=${#tmp} printf "set WEATHER_FORECAST_ID_$id 0 $expir $tmp_length\r\n$tmp\r\n" | nc $mem 11211 } 本例是直接将网页文件读取到变量中，亦可使用 wget -o 或者 curl -o 参数将其导出到文本。为什么使用nc而不是telnet呢？因为telnet不支持管道，也就是说不能将命令发送到telnet去执行。此外，由于服务器编码是GBK（系统编码为 echo $LANG ），而返回的数据是utf-8，可通过curl -I命令获取网页head信息从而查看到编码格式： curl -I http://m.weather.com.cn/data/101280601.html 返回头部：