189 8069 5689
1、性能
成都创新互联主要从事网站建设、成都网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务仁化,十年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220
都比较高，性能对我们来说应该都不是瓶颈。
总体来讲，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。
2、操作的便利性
memcache 数据结构单一。（key-value）
redis 丰富一些，数据操作方面，redis 更好一些，较少的网络 IO 次数，同时还提供 list，set，
hash 等数据结构的存储。
mongodb 支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。
3、内存空间的大小和数据量的大小
redis 在 2.0 版本后增加了自己的 VM 特性，突破物理内存的限制；可以对 key value 设置过
期时间（类似 memcache）
memcache 可以修改最大可用内存,采用 LRU 算法。Memcached 代理软件 magent，比如建立
10 台 4G 的 Memcache 集群，就相当于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务
不要和别的服务在一起。
4、可用性（单点问题）
对于单点问题，
redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整
个快照,无增量复制，因性能和效率问题，
所以单点问题比较复杂；不支持自动 sharding,需要依赖程序设定一致 hash 机制。
一种替代方案是，不用 redis 本身的复制机制，采用自己做主动复制（多份存储），或者改成
增量复制的方式（需要自己实现），一致性问题和性能的权衡
Memcache 本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的 hash 或者环
状的算法，解决单点故障引起的抖动问题。
mongoDB 支持 master-slave,replicaset（内部采用 paxos 选举算法，自动故障恢复）,auto sharding 机制，对客户端屏蔽了故障转移和切分机制。
5、可靠性（持久化）
对于数据持久化和数据恢复，
redis 支持（快照、AOF）：依赖快照进行持久化，aof 增强了可靠性的同时，对性能有所影
响
memcache 不支持，通常用在做缓存,提升性能；
MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性
6、数据一致性（事务支持）
Memcache 在并发场景下，用 cas 保证一致性redis 事务支持比较弱，只能保证事务中的每个操作连续执行
mongoDB 不支持事务
7、数据分析
mongoDB 内置了数据分析的功能(mapreduce),其他不支持
8、应用场景
redis：数据量较小的更性能操作和运算上
memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写
少，对于数据量比较大，可以采用 sharding）
MongoDB:主要解决海量数据的访问效率问题。
表格比较：
memcache redis 类型 内存数据库 内存数据库
数据类型 在定义 value 时就要固定数据类型 不需要
有字符串，链表，集 合和有序集合
虚拟内存 不支持 支持
过期策略 支持 支持
分布式 magent master-slave，一主一从或一主多从
存储数据安全 不支持 使用 save 存储到 dump.rdb 中
灾难恢复 不支持 append only file(aof)用于数据恢复
性能
1、类型——memcache 和 redis 都是将数据存放在内存，所以是内存数据库。当然，memcache 也可用于缓存其他东西，例如图片等等。
2、 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。
3、 虚拟内存——当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘。
4、 过期策略——memcache 在 set 时就指定，例如 set key1 0 0 8,即永不过期。Redis 可以通
过例如 expire 设定，例如 expire name 10。
5、 分布式——设定 memcache 集群，利用 magent 做一主多从;redis 可以做一主多从。都可
以一主一从。
6、 存储数据安全——memcache 断电就断了，数据没了；redis 可以定期 save 到磁盘。
7、 灾难恢复——memcache 同上，redis 丢了后可以通过 aof 恢复。
Memecache 端口 11211
yum -y install memcached
yum -y install php-pecl-memcache
/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid
-d 启动一个守护进程
-p 端口
-m 分配的内存是 M
-c 最大运行并发数-P memcache 的 pid
//0 压缩（是否 MEMCACHE_COMPRESSED） 30 秒失效时间
//delete 5 是 timeout
《HTTP_X_FORWARDED_FOR REMOTE_ADDR》
在 ASP 中使用 Request.ServerVariables("REMOTE_ADDR") 来取得客户端的 IP 地址，但如果客户端是使用代理服务器来访问，那取到的就是代理服务器的 IP 地址，而不是真正的客户端 IP 地址。要想透过代理服务器取得客户端的真实 IP 地址，就要使用 Request.ServerVariables("HTTP_X_FORWARDED_FOR") 来读取。
不过要注意的事，并不是每个代理服务器都能用 Request.ServerVariables("HTTP_X_FORWARDED_FOR") 来读取客户端的真实 IP，有些用此方法读取到的仍然是代理服务器的 IP。
还有一点需要注意的是：如果客户端没有通过代理服务器来访问，那么用Request.ServerVariables ("HTTP_X_FORWARDED_FOR") 取到的值将是空的。因此，如果要在程序中使用此方法，可以这样处理：
......
userip = Request.ServerVariables("HTTP_X_FORWARDED_FOR")
If userip = "" Then userip = Request.ServerVariables("REMOTE_ADDR")
......
即：如果客户端通过代理服务器，则取 HTTP_X_FORWARDED_FOR 的值，如果没通过代理服务器，就取 REMOTE_ADDR 的值。
redis作为一款优秀的NoSQL代表软件，正变得越来越流行，虽然Redis很容易就可以启动并使用，但是要想在线上用好它却也并非易事。redis的高可用和可扩展无论是自带的Redis Sentinel还是Redis Cluster都要求客户端进行额外的支持，而目前基本上没有合适的客户端能够做这些事情，实际上客户端来做这些事情也并不合适，它会让维护变得特别困难。因此在客户端和redis服务端之间加一层代理成了一种理想的方案，代理屏蔽后端Redis实现细节向客户端提供redis服务，可以完美的解决Redis的高可用和扩展性问题，同时代理的引入也使得Redis维护变得更加简单。在本文所要介绍的代理predixy之前，已经有几款流行的redis代理，它们各具特色。接下来，我们就来比较以下代理：
简单来说，predixy既支持Redis Sentinel也支持Redis Cluster
作为redis代理，高性能是硬性要求，为了测试上面四款代理的性能接下来我们就来做个简单的评测，测试平台及各代理具体的版本信息如下：
redis-server、各代理、redis-benchmark均在这一台机器上运行。
redis部署：
以下测试的结果中，横坐标为数据大小、纵坐标为qps或者毫秒。
这里单线程是指四款代理都运行在单线程下（下同），redis-benchmark默认并发50个客户端连接，每个连接每次发送一个命令收到响应后再发下一个命令。这是很多线上实际的场景。
在吞吐上，四款代理的性能排列的整齐有序，predixy大幅领先于另外三款代理，而twemproxy又以较大优势领先另外两个，剩下的两个codis在数据量小于512的时候稍稍领先cerberus，而当数据量大于512的时候，codis对cerberus的领先越来越大。整体上在数据量达到16KB时，由于redis-benchmark本身成为瓶颈，predixy和twemproxy的SET成绩差不多了。
在延时上，codis由于语言的问题，一直都大于另外三款代理，后续测试也一样。
在有些场景下，客户端可能在处理一个请求时可能需要发起多次redis请求，这时如果把多个redis请求pipeline一起请求的话，会大幅改善性能。本轮测试就来看看当客户端一次发送多个请求时我们各代理表现如何？Redis-benchmark依旧是并发50个连接，但是一次发送20个命令。
在吞吐上，redis-benchmark一次pipeline 20个命令后，各代理的吞吐量全都猛增。predixy更是一骑绝尘，遥遥领先另外三个，而最后看到在GET 4K数量据的时候predixy表现和其它代理差不多是因为对predixy来说，当数据量大于2K时redis-benchmark自身已经成为瓶颈。另外三款代理，在上轮测试中落后的cerberus在本轮测试一开始表现远好过twemproxy和codis，但cerberus还是存在随着数据量变大性能迅速降低的问题。twemproxy和codis在本轮测试中表现基本相当。
在时延上，codis固有的问题表现较差，另外三款在数据量较小时差别较小，而当数据量超过512时，predixy则表现出较明显的优势。
测完了单线程，现在我们开始多线程测试，由于twemproxy不支持多线程，因此twemproxy不参与多线程的测试。考虑到redis-benchmark本身是个单线程程序，在多线程代理下如果我们再测单个命令的性能，那redis-benchmark很可能就是瓶颈，则无法更明确的看出各代理的性能差异，因此我们直接测试pipeline，还跟上轮一样，50个并发连接，一次发送20个命令。
总体趋势和第二轮单线程pipeline测试一致，predixy在本轮测试中依旧取得了领先，不过在开始阶段cerberus和predixy遥遥领先于codis，cerberus和predixy差距不大。但是随着数据量的变大，cerberus再次显示出了性能急剧降低的问题，到1K以后甚至就比codis差了。
在功能的对比上，predixy相比另外三款代理更为全面，基本可以完全适用原生redis的使用场景。在性能上，predixy在各轮测试中都以较大优势领先。对各代理的总结如下：