redisson和mq区别

转载

蓝月亮 2024-10-17 22:52:26

文章标签 redisson和mq区别 redis 持久化 rdb 数据 文章分类 Redis 数据库

基本数据类型:

redis相对memcache来说,支持了更多的数据类型,在使用场景上面无疑是更加的便捷

String: 可以存储任何形式的字符串,内部实现结构有int,sds(simple dynamisc string),当值为整型时,使用int结构存放,非整型时使用sds存储
List: 当list的节点小于配置: hash-max-ziplist-entries 或者elem_value字符串的长度小于 hash-max-ziplist-value,采用ziplist存储,以便节约内存, 当大于时采用双向链表存储 ,list两端的查询复杂度为O(1),中间为O(N)
Map:新建的Hash类型也使用ziplist存储value，保存数据过多时，转而使用hast table。
SortSet：如果新建的Sortset包含value数大于配置或者value长度大于配置值，则直接使用hash table和skip list存储value，skip list实现对value的排序；否则直接使用skip list存储value。
Set :value 值为int时采用intset存储,当值的个数大于配置时,采用hash table

高级特性:

简易事务的支持
redis提供的事务更像是一组命令的批处理,和关系型数据库最大的区别在于不会回滚.

watch:监测某一个key是否发生变动
mulit:开始事务,标记事务的开始,在此之后的命令会顺序存放到队列
exec:向服务器提交所有开始事务后的命令,然后恢复到正常连接
discard:清除队列里的命令,当在使用mulit后使用discard,会清除队列里的所有命令,当有watch命令时,会清除当前连接的监控
unwhatch:取消监控,如果调用了EXEC或DISCARD命令，就不需要手动调用UNWATCH命令。

使用方法:

reids.mulit; 开始事务
 redis.set(key,value);
 redis.set(key1,value1);
 redis.exec;

pipeline:批量提交多组命令,减少网络请求压力
我们知道,redis是基于单线程的, 对于批量操作多个key这种场景来说,每次请求无疑会增加网络请求耗时,所以redis提供了这种命令用来提供个批量写入这种场景使用,不保证一个管道里的命令全部成功.
lua:脚本.详见后续文档

持久化方式:

两种方式

RDB：支持多长时间内多少次写入触发.fork子进程,建议最大使用内存,最多丢失上一次快照保存之后的数据,在执行快照时间,服务器会一直阻塞,阻塞时间和日志大小有关
AOF: 三种策略 ,性能依次从低到高

always 总是写入
everysec 每秒保存
no 禁用同步策略,只追加命令,何时落盘,由操作系统保证(大多数Liunx系统,每30s进行一次fsync,将缓存区的数据落入磁盘)

两种方式的区别

RDB实际上是fork出一个子进程,通过子进程来写入临时文件,当临时文件完成后通过写复制模式的原子性替换旧的文件
AOF实际上是追加命令,通过类似于日志的方式记录每一条写的命令(包含新增,修改,删除),存储的文件格式相对简单,便于查看,解析。

两种方式的优缺点

RDB的优点：

使用RDB做持久化的时候,整个redis只会有一份数据文件,对于文件备份来说,可以很轻易的备份任意时间点的数据。
性能高,是已知redis持久化方式中性能最高的一种。
灾备恢复最快,当数据集过大时,RDB的恢复效率更高，这是相对于AOF来说，RDB的文件相对较小。

RDB的缺点：

持久化的力度过粗,如果在这一次fork还为完成的时候机器宕机,那么上一次持久化之后的数据都会丢失。
RDB的机制在fork子进程执行持久化的时候,会阻塞主线程,在数据集过大的情况下会导致服务终端几百毫秒甚至几秒。

AOF的优点：

1.更完整的持久化机制,这种方式给我们提供了三种策略,其中 always是同步持久化,也就是说数据变更会立即落入磁盘。
2. AOF是通过追加的方式来实现持久化,因此当服务器宕机的时候,也不会损坏已经追加完成的数据,最多丢失当前写入的那条数据.如果在写入中途宕机,导致文件损坏,在下一次启动前可以通过redis-check-aof来解决文件问题。
3. AOF的保存文本格式更清晰，更易于理解,当意外flush db 的时候，在服务还没有rewrite之前,我们可以通过该文件手动修改命令,让该命令失效。