Redis 负载监控——redis-monitor
- - ITeye资讯频道redis-monitor是一个Web可视化的 redis 监控程序. 使用 Flask 来开发的，代码结构非常简单，适合移植到公司内网使用. redis 服务器信息，包括 redis 版本、上线时间、 os 系统信息等等. 实时的消息处理信息，例如处理 command 数量、连接总数量等. 内存占用、 cpu 消耗实时动态图表.
Redis中存储亿级键值对
标签：
tuicool
| 发表时间：2019-04-25 00:00 | 作者：
出处：http://itindex.net/relian
迁移系统时，有时你必须建立一个小脚手架。我们最近不得不这样做：在Instagram上，于遗留原因，我们需要将大约3亿张照片映射到创建它们的用户的ID，以便了解要查询的分片（请参阅有关 我们的更多信息） 分片设置）。虽然所有客户端和API应用程序都已更新并向我们返回 完整信息，但仍有许多人缓存的旧数据。我们需要一个解决方案：
1. 查找键并快速返回值
2. 将数据存在内存中，理想情况下是在EC2高内存类型（17GB或34GB，而不是68GB实例类型）中
3. 兼容我们现有的基础结构
4. 持久化，以便在服务器宕机时我们不必重跑
这个问题的一个简单解决方案是将它们简单地存储在数据库行中，其中包含“Media ID”和“User ID”列。但是，考虑到这些ID从未更新（仅插入），SQL数据库似乎是多余的。不需要事务，也和其他表没有任何关系。
相反，我们转向 Redis，一个我们在Instagram上广泛使用的键值存储。Redis是一把key-value的瑞士军刀; 而不是像Memcached那样普通的“Set key，get key”机制，它提供了强大的聚合类型，如有序集合和列表。它具有可配置的持久化模型，其中后台以指定的时间间隔保存，并且可以设置主从同步。我们所有的Redis都在主从服务器上运行，从服务器设置为每分钟保存到磁盘。
首先，我们决定以最简单的方式使用Redis：对于每个ID，key将是媒体ID，值将是用户ID：
SET media:1155315 939
GET media:1155315
> 939
然而，在对此解决方案进行模型设计时，我们发现Redis需要大约70 MB才存储1,000,000个key。根据我们需要的300,000,000，大约要21GB的数据，已经比亚马逊EC2上的17GB实例类型更大。
我们向Redis的核心开发人员之一，乐于助人的 Pieter Noordhuis提出了意见，他建议我们使用Redis哈希。Redis中的哈希是字典，可以非常有效地编码在内存中; Redis设置'hash-zipmap-max-entries'配置散列可以有效编码的最大条目数。我们发现这个设置最好在1000左右; 任何更高的配置HSET命令都会引起很明显的CPU使用。有关更多详细信息，你可以 查看zipmap源文件。
为了用散列类型，我们将所有媒体ID分配到1000个桶中（我们只取ID，除以1000并丢弃剩余部分）。这决定了属于哪个键，接下来在该键的散列中，Media ID是散列中的查找键，用户ID是值。一个例子，给定媒体ID为1155315，它属于桶1155（1155315/1000 = 1155）：
HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
> "939"
内存差异非常惊人; 使用我们的1,000,000个key（编码为1000个哈希，每个1000个子key），Redis只需要16MB存储。扩展到3亿个key，总数不到5GB，事实上，它甚至适合亚马逊上更便宜的m1.large实例类型，大约是我们原本需要的更大实例成本的1/3。最重要的是，散列中的查找仍然是O（1），非常快。
如果你对尝试这些感兴趣，我们用于运行这些测试的脚本 可以作为GitHub上的Gist（我们在脚本中有Memcached用于比较， 百万个key需要大约52MB）。
更多文章欢迎访问: http://www.apexyun.com
公众号:银河系1号
联系邮箱：[email protected]
(未经同意，请勿转载)
相关 [redis] 推荐：
Redis 起步
- - 博客园_首页Rdis和JQuery一样是纯粹为应用而产生的，这里记录的是在CentOS 5.7上学习入门文章：. Redis是一个key-value存储系统. 和Memcached类似，但是解决了断电后数据完全丢失的情况，而且她支持更多无化的value类型，除了和string外，还支持lists（链表）、sets（集合）和zsets（有序集合）几种数据类型.
redis 配置
- - 谁主沉浮# 当配置中需要配置内存大小时，可以使用 1k, 5GB, 4M 等类似的格式，其转换方式如下(不区分大小写). # 内存配置大小写是一样的.比如 1gb 1Gb 1GB 1gB. # daemonize no 默认情况下，redis不是在后台运行的，如果需要在后台运行，把该项的值更改为yes. # 当redis在后台运行的时候，Redis默认会把pid文件放在/var/run/redis.pid，你可以配置到其他地址.
Cassandra代替Redis?
- - Tim[后端技术]最近用Cassandra的又逐渐多了，除了之前的360案例，在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例. 而这篇 百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例. 考虑到到目前仍然有不少网友在讨论Redis的用法问题，Redis是一个数据库、内存、还是Key value store?以及Redis和memcache在实际场景的抉择问题，因此简单谈下相关区别.
redis 部署
- - CSDN博客云计算推荐文章一、单机部署
tar xvf redis-2.6.16.tar.gz
cd redis-2.6.16
make
make PREFIX=/usr/local/redis install #指定安装目录为/usr/local/redis，默认安装安装到/usr/local/bin. # chkconfig: 2345 80 10 #添加redhat系列操作系统平台，开机启动需求项(运行级别，开机时服务启动顺序、关机时服务关闭顺序)
# description: Starts, stops redis server.
nagios 监控redis
- - C1G军火库下载check_redis.pl. OK: REDIS 2.6.12 on 192.168.0.130:6379 has 1 databases (db0) with 49801 keys, up 3 days 14 hours - connected_clients is 1, blocked_clients is 0 | connected_clients=1 blocked_clients=0.
转 redis vs memcached
- - 数据库 - ITeye博客传统MySQL+ Memcached架构遇到的问题. 实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：. 1.MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间.
Redis优化
- - 数据库 - ITeye博客键名：尽量精简，但是也不能单纯为了节约空间而使用不易理解的键名. 键值：对于键值的数量固定的话可以使用0和1这样的数字来表示，（例如：male/female、right/wrong）. 当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能，不过一般都要持久化比较安全，而且是快照和aof同时使用比较安全.
笔记--redis
- - 移动开发 - ITeye博客接着准备面试内容，今天学习了下redis，继续我的笔记加深印象. 1.为什么要使用redis. 答：主要是 性能和 并发两个方面，另外redis也可以做分布式锁和消息队列等其他功能. 但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis.
[转]Redis作者谈Redis应用场景
- notsobad - heiyeluren的blog（黑夜路人的开源世界）文章来源：http://blog.nosqlfan.com/html/2235.html. 毫无疑问，Redis开创了一种新的数据存储思路，使用Redis，我们不用在面对功能单调的数据库时，把精力放在如何把大象放进冰箱这样的问题上，而是利用Redis灵活多变的数据结构和数据操作，为不同的大象构建不同的冰箱.