redis各种类型的存储情况分析
redis各种类型的存储情况分析
1：SORT命令的时间复杂度是0(n+mlogm)，其中n表示要排序的列表（集合或有序集合）中的元素个数，m表示要返回的元素个数
& &所以开发中使用SORT命令时需要注意以下几点。
（1）尽可能减少待排序键中元素的数量（使n尽可能小）。
（2）使用LIMIT参数只获取需要的数据（使m尽可能小）。
（3）如果要排序的数据数量较大，尽可能使用STORE参数将结果缓存
2： 任务队列
& &与任务队列进行交互的实体有两类，一类是生产者（producer），一类是消费者（consumer）。生产者会将需要处理的任务放入任务队列中，
而消费者则不断地从任务队列中读入任务信息并执行。
& 使用任务队列的好处：1：松耦合，2：易于扩展消费者可以有多个。
&#无限循环读取任务队列中的内容
task=RPOR queue
#如果任务队列中有任务则执行它
execute( task)
#如果没有则等待1秒以免过于频繁地请求数据
wait 1 second
BRPOP命令和RPOP命令相似，唯一的区别是当列表中没有元素时BRPOP命令会一直阻
塞住连接，直到有新元素加入。如上段代码可改写为：
#如果任务队列中没有新任务，BRPOP 命令会一直阻塞，不会执行execute()。
task=BRPOP queue, 0
#返回值是一个数组（见下介绍），数组第二个元素是我们需要的任务。
execute( task[1])
BRPOP命令接收两个参数，第一个是键名，第二个是超时时间，单位是秒
当获得一个元素后BRPOP命令返回两个值，分别是键名和元素值
3：优先级队列
&&BRPOP命令可以同时接收多个键，其完整的命令格式为BLPOP key [key …]timeout，如BLPOP queue:1 queue:2 0。
意义是同时检测多个键，如果所有键都没有元素则阻塞，如果其中有一个键有元素则会从该键中弹出元素
BRPOP queue:confirmation.email,
queue:notification.email,
xecute( task[1])
4：发布/订阅模式
&&“发布/订阅”模式中包含两种角色，分别是发布者和订阅者。订阅者可以订阅一个或若干个频道（channel），
而发布者可以向指定的频道发送消息，所有订阅此频道的订阅者都会收到此消息。
发布者发布消息的命令是PUBLISH，用法是PUBLISH channel message，PUBLISH命令的返回值表示接收到这条消息的订阅者数量。
订阅频道的命令是SUBSCRIBE，可以同时订阅多个频道，用法是SUBSCRIBE&channel[channel …]
进入订阅状态后客户端可能收到三种类型的回复。每种类型的回复都包含3个值，第一个
值是消息的类型，根据消息类型的不同，第二、三个值的含义也不同。消息类型可能的取值有：
（1）Subscribe。表示订阅成功的反馈信息。第二个值是订阅成功的频道名称，第三个值是
当前客户端订阅的频道数量。
（2）message。这个类型的回复是我们最关心的，它表示接收到的消息。第二个值表示产生
消息的频道名称，第三个值是消息的内容。
（3）unsubscribe。表示成功取消订阅某个频道。第二个值是对应的频道名称，第三个值是当
前客户端订阅的频道数量，当此值为0时客户端会退出订阅状态，之后就可以执行其他非“发
布/订阅”模式的命令了。
redis C＞PSUBSCRIBE channel.?＊
Reading messages... (press Ctrl-C to quit)
1) &psubscribe&
2) &channel.?＊&
3) (integer) 1
规则channel.?＊可以匹配channel.1和channel.10，但不会匹配channel.。
注意 使用PUNSUBSCRIBE命令只能退订通过PSUBSCRIBE命令订阅的规则，不会影响直接通过SUBSCRIBE命令订阅的频道；
同样UNSUBSCRIBE命令也不会影响通过PSUBSCRIBE命令订阅的规则
&Redis的每个键值都是使用一个redisObject结构体保存的，redisObject的定义如下：
typedef struct redisObject {
unsigned type:4;
unsigned notused:2; /＊ Not used ＊/
unsigned encoding:4;
unsigned lru:22; /＊ lru time (relative to server.lruclock) ＊/
其中type字段表示的是键值的数据类型，取值可以是如下内容：
#define REDIS_STRING 0
#define REDIS_LIST 1
#define REDIS_SET 2
#define REDIS_ZSET 3
#define REDIS_HASH 4
encoding字段表示的就是Redis键值的内部编码方式，取值可以是：
#define REDIS_ENCODING_RAW 0 /＊ Raw representation ＊/
#define REDIS_ENCODING_INT 1 ed as integer ＊/
#define REDIS_ENCODING_HT 2 /＊ Encoded as hash table ＊/
#define REDIS_ENCODING_ZIPMAP 3 /＊ Encoded as zipmap ＊/
#define REDIS_ENCODING_LINKEDLIST 4 /＊ Encoded as regular linked list ＊/
#define REDIS_ENCODING_ZIPLIST 5 /＊ Encoded as ziplist ＊/
#define REDIS_ENCODING_INTSET 6 /＊ Encoded as intset ＊/
#define REDIS_ENCODING_SKIPLIST 7 /＊ Encoded as skiplist ＊/
字符串类型：
&&1．字符串类型
Redis使用一个sdshdr类型的变量来存储字符串，而redisObject的ptr字段指向的是该变量
的地址。sdshdr的定义如下：
struct sdshdr {
char buf[];
其中len字段表示的是字符串的长度，free字段表示buf中的剩余空间，而buf字段存储的才是字符串的内容。
Redis启动后会预先建立10000个分别存储从0到9999这些数字的redisObject类型变量作为共享
对象，如果要设置的字符串键值在这10000个数字内（如SET key1 123）则可以直接引用共享对
象而不用再建立一个redisObject了，也就是说存储键值占用的空间是0字节
当执行了SET key1 123和SET key2 123后，key1和key2两个键都直接引用了一个已经建立好的共享对象，节省了存储空间
提示 当通过配置文件参数maxmemory设置了Redis可用的最大空间大小时，Redis不会使用共享对象，因为对于每一个键值都需要使用一个redisObject来记录其LRU信息。
&&散列类型的内部编码方式可能是REDIS_ENCODING_HT或
REDIS_ENCODING_ZIPLIST① 。在配置文件中可以定义使用REDIS_ENCODING_ZIPLIST方式编码散列类型的时机：
&&hash-max-ziplist-entries 512
& hash-max-ziplist-value 64
当散列类型键的字段个数少于hash-max-ziplist-entries参数值且每个字段名和字段值的长
度都小于hash-max-ziplist-value参数值（单位为字节）时，Redis就会使用REDIS_
ENCODING_ZIPLIST来存储该键，否则就会使用REDIS_ENCODING_HT。
REDIS_ENCODING_HT编码即散列表，可以实现O(1)时间复杂度的赋值取值等操作，其
字段和字段值都是使用redisObject存储的
REDIS_ENCODING_ZIPLIST编码类型是一种紧凑的编码格式，它牺牲了部分读取性能以
换取极高的空间利用率，适合在元素较少时使用
该编码类型同样还在列表类型和有序集合
类型中使用。REDIS_ENCODING_ZIPLIST编码结构如图4-7所示，其中zlbytes是uint32_t类型，
表示整个结构占用的空间。zltail也是uint32_t类型，表示到最后一个元素的偏移，记录zltail使得
程序可以直接定位到尾部元素而无需遍历整个结构，执行从尾部弹出（对列表类型而言）等操
作时速度更快。zllen是uint16_t类型，存储的是元素的数量。zlend是一个单字节标识，标记结构
的末尾，值永远是255
第一个部分用来存储前一个元素的大小以实现倒序查找，当前一个元素的大小小于254字
节时第一个部分占用1个字节，否则会占用5个字节。
第二、三个部分分别是元素的编码类型和元素的大小，当元素的大小小于或等于63个字
节时，元素的编码类型是ZIP_STR_06B（即0＜＜6），同时第三个部分用6个二进制位来记录元
素的长度，所以第二、三个部分总占用空间是1字节。当元素的大小大于63且小于或等于16383
字节时，第二、三个部分总占用空间是2字节。当元素的大小大于16383字节时，第二、三个部
分总占用空间是5字节。
第四个部分是元素的实际内容，如果元素可以转换成数字的话Redis会使用相应的数字类
型来存储以节省空间，并用第二、三个部分来表示数字的类型（int16_t、int32_t等）。
使用REDIS_ENCODING_ZIPLIST编码存储散列类型时元素的排列方式是：元素1存储字
段1，元素2存储字段值1，依次类推，
例如，当执行命令HSET hkey foo bar命令后，hkey键值的内存结构如下图所示，
我的热门文章
即使是一小步也想与你分享redis（28）
以下内容复制自：
INFO [section]
以一种易于解释（parse）且易于阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。
通过给定可选的参数&section&，可以让命令只返回某一部分的信息：
除上面给出的这些值以外，&section&参数的值还可以是下面这两个：
当不带参数直接调用&&命令时，使用&default&作为默认参数。
不同版本的 Redis 可能对返回的一些域进行了增加或删减。
因此，一个健壮的客户端程序在对&&命令的输出进行分析时，应该能够跳过不认识的域，并且妥善地处理丢失不见的域。
redis&&INFO
redis_version:2.9.11
redis_git_sha1:
redis_git_dirty:0
redis_build_id:8ef22
redis_mode:standalone
os:Linux&3.13.0-35-generic&x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.8.2
process_id:4716
run_id:26186aac3f2380aaee9eef21cc50aecd542d97dc
tcp_port:6379
uptime_in_seconds:362
uptime_in_days:0
lru_clock:1725349
config_file:
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:508536
used_memory_human:496.62K
used_memory_rss:7974912
used_memory_peak:508536
used_memory_peak_human:496.62K
used_memory_lua:33792
mem_fragmentation_ratio:15.68
mem_allocator:jemalloc-3.2.0
#&Persistence
rdb_changes_since_last_save:6
rdb_bgsave_in_progress:0
rdb_last_save_time:
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
total_connections_received:2
total_commands_processed:4
instantaneous_ops_per_sec:0
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0
#&Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
used_cpu_sys:0.21
used_cpu_user:0.17
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
cluster_enabled:0
#&Keyspace
db0:keys=2,expires=0,avg_ttl=0
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：63678次
积分：1740
积分：1740
排名：第17635名
原创：69篇
转载：303篇
(1)(20)(2)(10)(9)(42)(8)(22)(27)(45)(5)(7)(4)(4)(8)(6)(9)(7)(30)(20)(16)(9)(3)(25)(29)(5)Redis正确使用的十个技巧
投稿：lijiao
字体：[ ] 类型：转载 时间：
Redis已经走过了很长的一段路，随之而来的一系列最佳实践，使得大多数人可以正确地使用Redis，下面我们将探索正确使用 Redis 的10个技巧。
Redis 在当前的技术社区里是非常热门的。从来自 Antirez 一个小小的个人项目到成为内存数据存储行业的标准，Redis已经走过了很长的一段路。
1、停止使用 KEYS *
Okay，以挑战这个命令开始这篇文章，或许并不是一个好的方式，但其确实可能是最重要的一点。很多时候当我们关注一个redis实例的统计数据， 我们会快速地输入”KEYS *”命令，这样key的信息会很明显地展示出来。平心而论，从程序化的角度出发往往倾向于写出下面这样的伪代码：
for key in 'keys *':
doAllTheThings()
但是当你有1300万个key时，执行速度将会变慢。因为KEYS命令的时间复杂度是O(n)，其中n是要返回的keys的个数，这样这个命令的复杂度就取决于数据库的大小了。并且在这个操作执行期间，其它任何命令在你的实例中都无法执行。
作为一个替代命令，看一下 SCAN 吧，其允许你以一种更友好的方式来执行… SCAN 通过增量迭代的方式来扫描数据库。这一操作基于游标的迭代器来完成的，因此只要你觉得合适，你可以随时停止或继续。
2、找出拖慢 Redis 的罪魁祸首
由于 Redis 没有非常详细的日志，要想知道在 Redis 实例内部都做了些什么是非常困难的。幸运的是 Redis 提供了一个下面这样的命令统计工具：
127.0.0.1:6379& INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10
通过这个工具可以查看所有命令统计的快照，比如命令执行了多少次，执行命令所耗费的毫秒数(每个命令的总时间和平均时间)
只需要简单地执行 CONFIG RESETSTAT 命令就可以重置，这样你就可以得到一个全新的统计结果。
3、将 Redis-Benchmark 结果作为参考，而不要一概而论
Redis 之父 Salvatore 就说过：“通过执行GET/SET命令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。很多时候人们跑到我这里，他们想知道为什么自己的 Redis-Benchmark统计的结果低于最优结果 。但我们必须要把各种不同的真实情况考虑进来，例如：
可能受到哪些客户端运行环境的限制？
是同一个版本号吗？
测试环境中的表现与应用将要运行的环境是否一致？
Redis-Benchmark的测试结果提供了一个保证你的 Redis-Server 不会运行在非正常状态下的基准点，但是你永远不要把它作为一个真实的“压力测试”。压力测试需要反应出应用的运行方式，并且需要一个尽可能的和生产相似的环境。
4、Hashes 是你的最佳选择
以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种前所未有的体验。之前我曾看到过许多类似于下面这样的key结构：
foo:first_name
foo:last_name
foo:address
上面的例子中，foo 可能是一个用户的用户名，其中的每一项都是一个单独的 key。这就增加了 犯错的空间，和一些不必要的 key。使用 hash 代替吧，你会惊奇地发现竟然只需要一个 key ：
127.0.0.1:6379& HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379& HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379& HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379& HGETALL foo
1) "first_name"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379& HGET foo first_name
5、设置 key 值的存活时间
无论什么时候，只要有可能就利用key超时的优势。一个很好的例子就是储存一些诸如临时认证key之类的东西。当你去查找一个授权key时——以 OAUTH为例——通常会得到一个超时时间。这样在设置key的时候，设成同样的超时时间，Redis就会自动为你清除！而不再需要使用KEYS *来遍历所有的key了，怎么样很方便吧？
6、选择合适的回收策略
既然谈到了清除key这个话题，那我们就来聊聊回收策略。当 Redis 的实例空间被填满了之后，将会尝试回收一部分key。根据你的使用方式，我强烈建议使用 Volatile-lru 策略——前提是你对key已经设置了超时。但如果你运行的是一些类似于 cache 的东西，并且没有对 key 设置超时机制，可以考虑使用 allkeys-lru 回收机制。我的建议是先在这里查看一下可行的方案。
7、如果你的数据很重要，请使用 Try/Except
如果必须确保关键性的数据可以被放入到 Redis 的实例中，我强烈建议将其放入 try/except 块中。几乎所有的Redis客户端采用的都是“发送即忘”策略，因此经常需要考虑一个 key 是否真正被放到 Redis 数据库中了。至于将 try/expect 放到 Redis 命令中的复杂性并不是本文要讲的，你只需要知道这样做可以确保重要的数据放到该放的地方就可以了。
8、不要耗尽一个实例
无论什么时候，只要有可能就分散多redis实例的工作量。从3.0.0版本开始，Redis就支持集群了。Redis集群允许你基于key范围分离出部分包含主/从模式的key。完整的集群背后的“魔法”可以在这里找到。但如果你是在找教程，那这里是一个再适合不过的地方了。如果不能选择集群，考虑一下命名空间吧，然后将你的key分散到多个实例之中。关于怎样分配数据，在redis.io网站上有这篇精彩的评论。
9、内核越多越好吗？
当然是错的。Redis 是一个单线程进程，即使启用了持久化最多也只会消耗两个内核。除非你计划在一台主机上运行多个实例——希望只会是在开发测试的环境下！——否则的话对于一个 Redis 实例是不需要2个以上内核的。
10、高可用
到目前为止 Redis Sentinel 已经经过了很全面的测试，很多用户已经将其应用到了生产环境中（包括 ObjectRocket ）。如果你的应用重度依赖于 Redis ，那就需要想出一个高可用方案来保证其不会掉线。当然，如果不想自己管理这些东西，ObjectRocket 提供了一个高可用平台，并提供7×24小时的技术支持，有意向的话可以考虑一下。
以上就是关于Redis正确使用的十个技巧，希望对大家的学习有所帮助，果断收藏吧
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具Redis&(一)试用
服务端安装
Redis的官方下载站是http://redis.io/download，可以去上面下载最新的安装程序下来，我写此文章时的的稳定版本是3.0.7。
步骤一:&下载Redis
进入软件安装包存放目录:cd&/var/install/software/
　　[root@localhost&software]#&wget&http://download.redis.io/releases/redis-3.0.7.tar.gz
步骤二:&编译源程序
　　[root@localhost&software]#&tar&xzf&redis-3.0.7.tar.gz
　　[root@localhost&software]#&cd&redis-<font COLOR="#.0.7
　　[root@localhost&redis-<font COLOR="#.0.7]#&make
步骤三:&启动Redis服务
　　[root@localhost&redis-<font COLOR="#.0.7]#&cd&src
　　[root@localhost
src]#&./redis-server
　　Redis&服务端的默认连接端口是&6379。此时查看端口可以看出:
netstat&&atln
步骤四:&将Redis作为&Linux&服务随机启动
　　vi&/etc/rc.local,&使用vi编辑器打开随机启动配置文件，并在其中加入下面一行代码。
　　/var/install/software/redis-3.0.7/src/redis-server
步骤五:&客户端连接验证
　　新打开一个Session进入安装目录下的&src&,并输入：./redis-cli，如果出现下面提示，那么您就可以开始Redis之旅了。
　　[root@localhost
src]#&./redis-cli
步骤六:&查看Redis日志
　　查看服务端session，即可对Redis的运行状况进行查看或分析了。
步骤七:&停止Redis实例
　　最简单的方法是在已经启动的实例session中，直接使用Control-C来将实例停止。
　　我们还可以用客户端来停止服务，如可以用shutdown来停止Redis实例,&具体如下:
　　[root@localhost
src]#&./redis-cli&shutdown
操作Redis数据库
　　下面我们来简单的操作一下数据库。在实例开启的情况下：
　　1、插入数据
　　redis&127.0.0.1:6379&&set&name&wwl
　　设置一个key-value对。
　　2、查询数据
　　redis&127.0.0.1:6379&&get&name
　　取出key所对应的value。
　　3、删除键值
　　redis&127.0.0.1:6379&&del&name
　　删除这个key及对应的value。
　　4、验证键是否存在
　　redis&127.0.0.1:6379&&exists&name
　　(integer)&0
　　其中0，代表此key不存在;1代表存在。
执行src目录下的redis-server可以启动Redis进程，不过最好先配置一下redis.conf文件，常用的几个要注意的参数如下：
　　daemonize&yes
　　指定Redis以守护进程的方式运行。
　　pidfile&/home/banping/redis/redis.pid
　　当Redis以守护进程方式运行时，把pid写入指定的文件。
　　port&6379
　　指定监听端口，默认端口为6379。
　　bind&192.168.0.35
　　绑定的主机IP地址。
　　logfile&stdout
　　指定日志的记录方式，默认为标准输出。
　　databases&16
　　设置数据库的数量。
　　Redis默认配置文件中提供了三个条件：
　　save&900&1
　　save&300&10
　　save&60&10000
分别表示900秒(15分钟)内有1个更改，300秒(5分钟)内有10个更改以及60秒内有10000个更改的时候，同步数据到磁盘文件。
　　rdbcompression&yes
　　指定存储至本地数据库时是否压缩数据，默认为yes。
　　dbfilename&dump.rdb
　　指定本地数据库文件名。
　　dir&/home/banping/redis/data
　　指定本地数据库存放目录。
　　requirepass&foobared
　　设置Redis连接密码，默认关闭。
　　maxclients&128
　　设置最大客户端连接数，默认无限制。
　　maxmemory
　　指定Redis能使用的最大内存。
　　其他更详细的参数说明请参见官方文档。修改完配置文件后，我们可以用指定的配置文件启动Redis服务：
　　[root@localhost&src]#&./redis-server&/var/install/software/redis-3.0.7/redis.conf
　　这样一个redis服务进程就启动了，它监听6379端口来提供服务。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。redis所有key莫名消失——redis被攻击 - 数据库当前位置:& &&&redis所有key莫名消失——redis被攻击redis所有key莫名消失——redis被攻击&&网友分享于：&&浏览：0次redis全部key莫名消失——redis被攻击
redis全部key莫名消失——redis被攻击刚刚接触redis不久，对redis也只是做了一些简单的配置，所以，在刚刚使用的时候，也仅仅是将redis的环境搭建好，至于redis的端口（6379）和密码（redis默认配置没有密码）也没有做更改。前一段时间，偶然的发现，有时候redis里面的数据莫名其妙的全部被清除掉了，刚开始总是以为是redis哪里配置的有问题，可能配置的有定时清空数据库的机制吧，但是找了一圈没有发现redis有类似的配置。随后开始研究redis.conf配置文件，首先将redis的log级别提升到最高，也就是debug的级别，debug的打印信息如下：[16279] 08 Dec 17:39:09.340 - DB 0: 70 keys (0 volatile) in 128 slots HT.[16279] 08 Dec 17:39:09.340 - 0 clients connected (0 slaves), 829448 bytes in use[16279] 08 Dec 17:39:13.047 * 10 changes in 300 seconds. Saving...[16279] 08 Dec 17:39:13.047 * Background saving started by pid 16324[16324] 08 Dec 17:39:13.070 * DB saved on disk[16324] 08 Dec 17:39:13.071 * RDB: 0 MB of memory used by copy-on-write[16279] 08 Dec 17:39:13.147 * Background saving terminated with success[16279] 08 Dec 17:39:14.349 - DB 0: 70 keys (0 volatile) in 128 slots HT.会将当前连接的客户端个数，你使用的数据库，当前存储的key个数，设置过期的key个数(0 volatile)，快照的保存时间，状态，打印出来。当有客户端连接，会将客户端的ip打印[16279] 08 Dec 17:40:05.187 - Accepted 123.57.41.84:44459过了大概两天左右，又发现数据被清除了，这时在看看redis的log[16279] 10 Dec 07:05:39.105 - DB 0: 78 keys (0 volatile) in 128 slots HT.[16279] 10 Dec 07:05:39.105 - 0 clients connected (0 slaves), 856544 bytes in use[16279] 10 Dec 07:05:40.468 - Accepted 221.194.44.175:34038[16279] 10 Dec 07:05:40.508 * DB saved on disk[16279] 10 Dec 07:05:40.530 - Client closed connection[16279] 10 Dec 07:05:40.565 - Accepted 221.194.44.175:34041[16279] 10 Dec 07:05:40.584 - Accepted 221.194.44.175:34042[16279] 10 Dec 07:05:40.627 * DB saved on disk[16279] 10 Dec 07:05:40.627 - Client closed connection[16279] 10 Dec 07:05:40.627 - Accepted 221.194.44.175:34043[16279] 10 Dec 07:05:40.645 - Client closed connection[16279] 10 Dec 07:05:40.660 - Client closed connection[16279] 10 Dec 07:05:40.681 - Accepted 221.194.44.175:34045[16279] 10 Dec 07:05:40.705 - Client closed connection[16279] 10 Dec 07:05:40.722 - Accepted 221.194.44.175:34047[16279] 10 Dec 07:05:40.736 - Client closed connection[16279] 10 Dec 07:05:44.136 - DB 0: 1 keys (0 volatile) in 4 slots HT.[16279] 10 Dec 07:05:44.136 - 0 clients connected (0 slaves), 755920 bytes in use很明显，在七点零五分的时候还有78个key，此时有客户端连接上来，数据悲剧了，只剩下了一个key，立马打开redis的aof文件，看看是不是此时有人执行了清空redis的操作$8flushall*3$3set$7crackit$398ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApC0OZYaozpKXFCagPTUQ0eqIXbeX+u/tSYDVrMpMXxswTxi9uZ4SKUsOKemVsGcp5YNGJ8HhB8KBoejGkTrAE7v9Sl5zwG6xMAjSj0ZBlcW80h4M0uC5Ntb95BX9bUBbUPJf70eZ5Phe2zrO9RM1Rd96HZxuFjNOw3JKMIs/Lw/qm33FIm4z1j9dnMJ5h7BYz1Fkr6hl12GvhpTZWcfgg/BzZsb0oAJGLJd5km6KPGmn0oJGMaqCbiD2ynfgQo0kpTlJExikfZe8BE0CAHAxrXNGb+cPOc1HZt7cwXQfo+Y88vG4BdfNRC1CyQTr8ZcIV7KUxSwsc/8HuUEuPVZm7Q== *4$5很明显的看到flushall的命令，就是将redis中所有的key清除，并且写了一个key为crackit的一堆有关于ssh的神马东西，ok当下百度了一下redis crackit，铺天盖地的redis被黑的新闻，好吧，终于知道原因了，由于没有设置密码，还有使用了默认的redis端口，黑客通过扫描redis的端口，不是用密码也可以连接到你的redis库中，既然连接了上来肯定是要来搞一些事情，把你的redis清空并不是目的，看到存入的那一段ssh的东西了吗，这个才是关键。利用redis将服务器的ssh公钥替换，也就是说如果你使用的root用户启动的redis，可以将自己的公钥或者其他恶意程序写入目标服务器中，从而可以直接控制目标服务器。经过试验，确实可以使用ssh免密登录到目标服务器中（具体的步骤可以百度一下redis crackit）,目前大多数人的解决方案：1，以非 root 权限启动 Redis2，增加 Redis 密码验证3，禁止公网开放 Redis 端口, 例如可以在青云防火墙上禁用 6379 Redis 的端口4，检查 authorized_keys 是否非法也可以根据情况对服务器的ssh进行配置，例如免密登录
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 1234567891011 Copyright & &&版权所有}