客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
|
参考文档： https://blog.csdn.net/jy692405180/article/details/72026745 redis事务 https://www.cnblogs.com/kyrin/p/5967620.html redis与memcached对比 https://www.biaodianfu.com/redis-vs-memcached.html 二 常用缓存数据库分析 三 redis支持的数据结构&底层存储结构 Redis数据类型内存结构分析
字符串是Redis值的最基础的类型。Redis中使用的字符串是通过包装的，基于c语言字符数组实现的简单动态字符串(simple dynamic string, SDS)一个抽象数据结构。其源码定义如下： struct sdshdr {
int len; //len表示buf中存储的字符串的长度。
int free; //free表示buf中空闲空间的长度。
char buf[]; //buf用于存储字符串内容。
};
Hash是一个String类型的field和value之间的映射表，即redis的Hash数据类型的key（hash表名称）对应的value实际的内部存储结构为一个HashMap，因此Hash特别适合存储对象。相对于把一个对象的每个属性存储为String类型，将整个对象存储在Hash类型中会占用更少内存。
当前HashMap的实现有两种方式：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
Redis的List类型其实就是每一个元素都是String类型的双向链表。我们可以从链表的头部和尾部添加或者删除元素。这样的List既可以作为栈，也可以作为队列使用。
Redis 集合（Set类型）是一个无序的String类型数据的集合，类似List的一个列表，与List不同的是Set不能有重复的数据。实际上，Set的内部是用HashMap实现的，Set只用了HashMap的key列来存储对象。 Set中的元素，只是存放在了底层HashMap的key上，底层HashMap的value列为空，遍历HashSet的时候从HashMap中取出keySet来遍历
SortSet顾名思义，是一个排好序的Set，它在Set的基础上增加了一个顺序属性score，这个属性在添加修改元素时可以指定，每次指定后，SortSet会自动重新按新的值排序。 三 redis的持久化 Redis的持久化方式与传统数据库的方式有比较多的差别，Redis一共支持四种持久化方式，分别是： 出现下面的情况redis会快照内存里的数据 1 用户发送bgsave命令(此时redis会fork一个子进程,子进程负责生成硬盘文件,父进程负责继续接受命令) 快照的配置信息 save 60 1000 60秒内有1000次写入"这个条件,系统就自动调用bgsave 快照保存过程： 1）Redis 调用forks. 同时拥有父进程和子进程。 快照持久化的优点 1）快照持久化的方法采用创建一个子进程的方法来将 Redis 的内存数据保存到硬盘中，因此，它并不会对 Redis 服务器性能造成多大的影响，这可以说是快照持久化方法最大的一个优点。 3) RDB的编码格式与redis内存中的数据编码格式是一致的。所以在启动redis重建数据库的时候，加载较快 快照持久化的缺点 1）如果 RDB 文件生成后，Redis 服务器继续处理了写命令导致 Redis 内存数据有更新，这时恰好 Redis 崩溃了而来不及保存新的 RDB 文件，那么 Redis 将会丢失这部分新的数据。因此，快照持久化方法只适用于那些即使丢失一部分数据也不会造成问题的应用场景。 基于语句追加方式( Append-only file） aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式时，redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容 AOF将数据写入磁盘的流程如下： aof配置 appendonly no 控制AOF的开关 appendfilename "appendonly.aof" no：从不调用fsync，由操作系统自行决定什么时候将缓冲区里的数据写入文件。大多数Linux系统是每30秒进行一次。这种模式的速度最快，效率最高，但是不能保证数据安全。 no-appendfsync-on-rewrite no 控制当执行重写时是否阻止调用fsync auto-aof-rewrite-percentage 100 用于控制AOF文件的自动重写规则。Redis会记录最后一次重写AOF文件后的文件大小（如果没有进行过重写，则记录AOF文件一开始的大小），如果当前AOF文件的大小大于指定的百分比，就会触发一次AOF重写。如果将该值指定为0，则Redis不会自动重写AOF文件。AOF的重写流程跟RDB一样。所以在新的AOF文件完全写入之前发生的写操作，都会写入旧的AOF文件以及缓存中。 auto-aof-rewrite-min-size 64mb 用于控制AOF重写的最小文件大小。如果AOF文件小于auto-aof-rewrite-min-size规定的值，则不会触发重写操作，这避免了在AOF文件不是很大的时候多次触发重写。 aof-load-truncated yes 当重启Redis进行AOF加载时，可能会发现AOF文件尾部不完整。这种情况只会发生在系统崩溃之后，尤其是使用了ext4文件系统且没有设置data=ordered的情况下。当aof-load-truncated被设置为yes时，Redis发现了问题之后会从AOF文件中尽可能地加载更多的数据，然后在log文件里记录这次错误。设置为no时，服务器会拒绝启动，此时用户可以使用redis-check-aof工具修复损坏的AOF文件 dir ./ 配置AOF文件保存的路径。RDB产生的文件也会被保存到这个路径下面 AOF rewrite 重写 aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100 就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下： AOF的优点： AOF可以将数据的损失降到最低 AOF的缺点： 比RDB更占用存储空间、加载速度慢（一是因为存储的命令较多，二是因为编码格式与内存不一致，还需要处理编码） 五redis事务 redis对事务的支持目前还比较简单。redis只能保证一个client发起的事务中的命令可以连续的执行，而中间不会插入其他client的命令。 相关命令
用于标记事务块的开始。Redis会将后续的命令逐个放入队列中，然后才能使用EXEC命令原子化地执行这个命令序列。
清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。如果使用了WATCH命令，那么DISCARD命令就会将当前连接监控的所有键取消监控。
Redis使用WATCH命令实现事务的“检查再设置”（CAS）行为。 在每个代表数据库的 redis.h/redisDb 结构类型中， 都保存了一个 watched_keys 字典， 字典的键是这个数据库被监视的键， 而字典的值则是一个链表， 链表中保存了所有监视这个键的客户端。 触发过程： 在任何对数据库键空间（key space）进行修改的命令成功执行之后 （比如 FLUSHDB 、 SET 、 DEL 、 LPUSH 、 SADD 、 ZREM ，诸如此类）， multi.c/touchWatchedKey 函数都会被调用 —— 它检查数据库的 watched_keys 字典， 看是否有客户端在监视已经被命令修改的键， 如果有的话， 程序将所有监视这个/这些被修改键的客户端的 REDIS_DIRTY_CAS 选项打开：
事务的 ACID 性质 在redis中事务总是具有原子性(Atomicity),一致性(Consistency)和隔离性(Isolation),并且当redis运行在某种特定的持久化模式下,事务也具有耐久性(Durability). ①原子性 ④持久性
五 redis lua redis支持lua脚本原子执行 |
请发表评论