30G 的redis 如何优化 - 沐訫-[教程]MongoDB 从入门到进阶（U...-Redis使用总结之与Memcached异同

当前位置: 数据库>nosql

本页文章导读:

▪30G 的redis 如何优化 - 沐訫突然发现我们的redis 已经用了30G了，好吧这是个很尴尬的数字因为我们的缓存机器的内存目前是32G的，内存已经告竭。幸好上上周公司采购了90G的机器，现在已经零时迁移到其中的一台机器上.........

▪[教程]MongoDB 从入门到进阶（User系统） - magicDict 自从MongoDB升级到2.4之后，User系统，或者说是权限系统有了翻天覆地的变化。在MongoDB2.4之前的User系统，除了用户名和密码之外，只有一个ReadOnly属性。如果一个用户在admin数据库里面进行了登.........

▪Redis使用总结之与Memcached异同 - ceecy Redis是什么？两句话可以做下概括： 1. 是一个完全开源免费的key-value内存数据库 2. 通常被认为是一个数据结构服务器，主要是因为其有着丰富的数据结构 strings、map、 list、sets、 sorted sets&n.........

[1]30G 的redis 如何优化 - 沐訫

来源: 发布时间: 2013-10-18

突然发现我们的redis 已经用了30G了，好吧这是个很尴尬的数字因为我们的缓存机器的内存目前是32G的，内存已经告竭。幸好上上周公司采购了90G的机器，现在已经零时迁移到其中的一台机器上了。(跑题下，90G的内存太爽了是我除了koding.com 之外第二次用到90G的机器，koding 是个好网站，在线编程IDE。) 但是随着数据量越来越大单机始终无法承受的，改造势在必行。经过初步思考我们得出了很简单的方案概括起来就是 "内外兼修"

1.内功修炼

先从我们的应用层说起看看redis 使用情况，有没有办法回收一些key ，先进入redis 服务器执行 info ,有删减

1: redis 127.0.0.1:6391> info

2: used_memory_human:35.58G

3: keyspace_hits:2580207188

4: db0:keys=2706740,expires=1440700

目前我们只使用了1个DB 但是key 太多了有270W个key,已经过期的有144W。第一个想到的就是我勒个去,怎么会有这么多key ,第二个想法就是可能存在过大的key

看看能不能针对过大的key 做优化？可是遗憾的是官方并没有命令显示db 的key 大小，我们只能自己想办法了

Google 一番，发现国外友人已经写好了shell

传送门: https://gist.github.com/epicserve/5699837

可以列出每个key 大小了。可是这并不适用我们，因为我们key 太大了执行了9个小时都没跑完，无力吐槽了。其实还有一个选择就是用另外一个工具

传送门:https://github.com/sripathikrishnan/redis-rdb-tools

可惜这个太重了，不想麻烦ops ，我们就只能撩起袖子，造轮子。

把shell 代码简单看了下发件DEBUG OBJECT 是个好东西啊，google 下发现官网 http://redis.io/commands/object

已经有简单的调试信息了，剩下的就好处理了

   1: #coding=utf-8   2: import redis   3:     4: COLOR_RED = "\033[31;49;1m %s \033[31;49;0m"   5:     6: COLOR_GREED = "\033[32;49;1m %s \033[39;49;0m"   7:     8: COLOR_YELLOW = "\033[33;49;1m %s \033[33;49;0m"   9:    10: COLOR_BLUE = "\033[34;49;1m %s \033[34;49;0m"  11:    12: COLOR_PINK = "\033[35;49;1m %s \033[35;49;0m"  13:    14: COLOR_GREENBLUE = "\033[36;49;1m %s \033[36;49;0m"  15:    16:    17: def getHumanSize(value):  18:     gb = 1024 * 1024 * 1024.0  19:     mb = 1024 * 1024.0  20:     kb = 1024.0  21:     if value >= gb:  22:         return COLOR_RED % (str(round(value / gb, 2)) + " gb")  23:     elif value >= mb:  24:         return COLOR_YELLOW % (str(round(value / mb, 2)) + " mb")  25:     elif value >= kb:  26:         return COLOR_BLUE % (str(round(value / kb, 2)) + " kb")  27:     else:  28:         return COLOR_GREED % (str(value) + "b")  29:    30:    31: month = 3600 * 24 * 30  32: result = []  33: client = redis.Redis(host="XXXXX", port=XXXX)  36: client.info()  37:    38: count = 0  39: for key in client.keys('*'):  40:     try:  41:         count += 1  42:         idleTime = client.object('idletime', key)  43:         refcount = client.object('refcount', key)  44:         length = client.debug_object(key)['serializedlength']  45:         value = idleTime * refcount  46:         print "%s key :%s , idletime : %s,refcount :%s, length : %s , humSize  :%s" % (count, key, idleTime, refcount, length, getHumanSize(length))  47:     except Exception:  48:         pass

写了个简单的python 脚本输出每个key 的大小和idle time,和refer count 。有了这么多数据结合awk 就可以很好的统计每个key 的使用情况。有一点要注意的是这个size 是key 在redis 中的大小，并非实际的大小，这个是经过redis 压缩的。经过分析之后发现不存在过大的key ,但是存在有些key 半年都没有被访问过 Orz 。

接下来就很好处理了,我们为每个key 设置的过期时间,若key 被hit 上则更新这个expire time 。这样可以逐步淘汰冷数据，达到冷热分离

2. 外功修炼

我们对内清理了无效的key，对外我们要做到水平扩展，单机的承载

[2][教程]MongoDB 从入门到进阶（User系统） - magicDict

来源: 发布时间: 2013-10-18

自从MongoDB升级到2.4之后，User系统，或者说是权限系统有了翻天覆地的变化。

在MongoDB2.4之前的User系统，除了用户名和密码之外，只有一个ReadOnly属性。

如果一个用户在admin数据库里面进行了登陆，则admin数据库里面的Readonly属性将被沿用到其他所有的数据库。

这样的权限管理当然是最最容易管理的，任何能够登入到MongoDB的用户，如果在Admin的数据库的用户表里面存在记录，则对于整个服务器上的所有数据库的访问权限也就固定下来了。

当然，用户可以了在个别的数据库的用户表中定义自己的权限。所谓的权限也就是只读或者非只读。

到了2.4之后，MongoDB的用户模型发生了很大的变化

MongoUser（2.4之前）

用户名

密码

是否只读

MongoUser（2.4之后）

用户名

密码

角色

其他数据库角色（如果该用户在Admin数据库的User表里面登陆的话，可以个别指定对于具体数据库访问的权限）

外部验证

“角色”这个概念，也“是否只读”比起来，内容丰富多了，不同的角色可以进行的操作是不同的，有的可以管理用户，看得到用户表，有的只能看到普通的数据表。

最近一直在对用户和权限进行研究，总结了一下心得：

1.由于要顾及以前的版本，ReadOnly属性还是可以使用的，不过，ReadOnly和Role是不能共存的

2.密码和外部验证，也是不能共存的，要么用密码验证身份，要么用外部验证数据库来验证身份

3.其他数据库角色只能在Admin里面进行登录。

接下来说说坑爹的C#的驱动程序：C#的驱动程序，对于MongoUser的巨大变化，还没有开始进行对应。自己动手丰衣足食，我现在的开发都是使用自己改写的MongoUser类。

我不是很明白，为什么C#驱动不对应MongoUser的变化，我也不清楚其他语言的驱动程序是否也没有对应。。。。

这里是新的添加用户的GUI

添加了用户后，请不要忘记在启动MongoDB的时候加上 --auth的参数，不然的话，默认是不会启动认证的，不管是谁，都是完全的Admin的权限。

如果对于我的GUI工具感兴趣，Github上面有所有的代码

https://github.com/magicdict/MagicMongoDBTool

这次工具开始尝试提供性能监视工具，当然，只是一个小的尝试罢了。

再说几句题外话，最近IBM宣布和10gen（MongoDB的开发公司）进行合作。我不知道IBM准备多大限度的支持MongoDB。但是不管怎么说，对于MongoDB的爱好者来说，是一个不错的消息。

MongoDB现在还是冷门的数据库。园子里面也少有介绍MongoDB的文章，或者即使介绍，也是入门级别的。

技术就像赌博一样，谁知道明年的这个时候，Mongo是不是会大红大紫，成为另一个Oracle。不管怎么样，先投资一下吧。。。。。

想要直接体验工具的：http://www.wojilu.com/Forum1/Topic/4601 Net3.5是必须的。。。。

本文链接：http://www.cnblogs.com/TextEditor/p/3262608.html，转载请注明。

[3]Redis使用总结之与Memcached异同 - ceecy

来源: 发布时间: 2013-10-18

Redis是什么？两句话可以做下概括：
1. 是一个完全开源免费的key-value内存数据库
2. 通常被认为是一个数据结构服务器，主要是因为其有着丰富的数据结构 strings、map、 list、sets、 sorted sets

Redis不是什么？同样从两个方面来做下对比：
1. 不是sql server、mySQL等关系型数据库，主要原因是：
     . redis目前还只能作为小数据量存储（全部数据能够加载在内存中），海量数据存储方面并不是redis所擅长的领域
     . 设计、实现方法很不一样.关系型数据库通过表来存储数据，通过SQL来查询数据。而Redis通上述五种数据结构来存储数据，通过命令来查询数据
2.   不是Memcached等缓存系统，主要原因有以下几个：
     .网络IO模型方面：Memcached是多线程，分为监听线程、worker线程，引入锁，带来了性能损耗。Redis使用单线程的IO复用模型，将速度优势发挥到最大，也提供了较简单的计算功能
     .内存管理方面：Memcached使用预分配的内存池的方式，带来一定程度的空间浪费并且在内存仍然有很大空间时，新的数据也可能会被剔除，而Redis使用现场申请内存的方式来存储数据，不会剔除任何非临时数据 Redis更适合作为存储而不是cache
     .数据的一致性方面：Memcached提供了cas命令来保证.而Redis提供了事务的功能，可以保证一串命令的原子性，中间不会被任何操作打断
     . 存储方式方面：Memcached只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能

一句话小结一下：Redis是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。

Redis有什么用？只有了解了它有哪些特性，我们在用的时候才能扬长避短，为我们所用：
1. 速度快：使用标准C写，所有数据都在内存中完成，读写速度分别达到10万/20万
2. 持久化：对数据的更新采用Copy-on-write技术，可以异步地保存到磁盘上，主要有两种策略，一是根据时间，更新次数的快照（save 300 10 ）二是基于语句追加方式(Append-only file，aof)
3. 自动操作：对不同数据类型的操作都是自动的，很安全
4. 快速的主--从复制，官方提供了一个数据，Slave在21秒即完成了对Amazon网站10G key set的复制。
5. Sharding技术：很容易将数据分布到多个Redis实例中，数据库的扩展是个永恒的话题，在关系型数据库中，主要是以添加硬件、以分区为主要技术形式的纵向扩展解决了很多的应用场景，但随着web2.0、移动互联网、云计算等应用的兴起，这种扩展模式已经不太适合了，所以近年来，像采用主从配置、数据库复制形式的，Sharding这种技术把负载分布到多个特理节点上去的横向扩展方式用处越来越多。

这里对Redis数据库做下小结：
1. 提高了DB的可扩展性，只需要将新加的数据放到新加的服务器上就可以了
2. 提高了DB的可用性，只影响到需要访问的shard服务器上的数据的用户
3. 提高了DB的可维护性，对系统的升级和配置可以按shard一个个来搞，对服务产生的影响较小
4. 小的数据库存的查询压力小，查询更快，性能更好

写到这里，可能就会有人急不可待地想用它了，那怎么用呢？可以直接到官方文档，里面帮我们整理好了各个语言环境下的客户端，主要有Ruby、Python、 PHP、Perl、Lua、Java、C#....有几种语言，我也没见过，所以就不多说了，你懂的....

最后，把我使用过程中的一些经验与教训，做个小结：
1. 要进行Master-slave配置，出现服务故障时可以支持切换。
2. 在master侧禁用数据持久化，只需在slave上配置数据持久化。
3. 物理内存+虚拟内存不足，这个时候dump一直死着，时间久了机器挂掉。这个情况就是灾难！
4. 当Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了，就开始做swap,内存碎片大
5. 当达到最大内存时，会清空带有过期时间的key，即使key未到过期时间.
6. redis与DB同步写的问题，先写DB，后写redis，因为写内存基本上没有问题

本文链接：http://www.cnblogs.com/ceecy/p/3279407.html，转载请注明。