redis总结(一)

一. 数据结构

redis 数据结构 分 为

string :和java的 string 没有什么区别  ,在redis里是二进制安全的,所以可以接受任何格式的数据,比如图形数据或json数据,最打容量是512M

hash(哈希):看成具有String key 和String value的map容器

list:java的LinkedList,按照插入顺序排序的字符串链表 

set:和list相似 没有顺序的字符串链表 ,插入时 如果不存在就生成一个链表

zset:有序的set,每个都会有一个分数与之相连 ,分数可以重复 ,原来排序

redis的高级数据结构

Bitmaps 

不是一个真实的数据结构。而是String类型上的一组面向bit操作的集合。由于
strings是二进制安全的blob，并且它们的最大长度是512m，所以bitmaps能最大设置
2^32个不同的bit

Hyperloglogs

在redis的实现中，您使用标准错误小于1％的估计度量结束。这个算法的神奇在于不再
需要与需要统计的项相对应的内存，取而代之，使用的内存一直恒定不变。最坏的情况
下只需要12k，就可以计算接近2^64个不同元素的基数。

GEO

Redis的GEO特性在 Redis3.2版本中推出，这个功能可以将用户给定的地理位置（经
度和纬度）信息储存起来，并对这些信息进行操作

二. 持久化策略

1.AOF

执行 save 即可在redis数据目录生成数据文件 dump.rdb
也可以异步执行 bgsave

所有的命令行记录以 redis 命令请求协议的格式完全持久化存储)保存为aof 文件

将备份文件 (dump.rdb) 移动到 redis 数据目录并启动服务即可恢复

优点:

（1）数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行
一次命令操作就记录到 aof 文件中一次。
（2）通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-
check-aof 工具解决数据一致性问题。
（3）AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会
对命令进行合并重写），可以删除其中的某些命令（比如误操作的
flushall）)

缺点

（1）AOF 文件比 RDB 文件大，且恢复速度慢。
（2）数据集大的时候，比 rdb 启动效率低。

2. RDB

如果 appendonly 配置为 yes，则以 AOF 方式备份 Redis 数据，那么此时 Redis 会按
照配置，在特定的时候执行追加命令，用以备份数据

优点:

（1）只有一个文件 dump.rdb，方便持久化。
（2）容灾性好，一个文件可以保存到安全的磁盘。
（3）性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以
      是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操
      作，保证了 redis 的高性能)
（4）相对于数据集大时，比 AOF 的启动效率更高。

缺点：
(1)数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生
故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

(2)保存后的二进制文件，不同版本直接存在兼容性问题

3.混合模式 

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB何AOF两部分恢复数据，即保证了数据完整性，又提高了恢复的性能。恢复数据会从RDB和AOF两部分恢复数据，即保证了数据完整性，又提高了恢复的性能