企业网站建设属于什么费用,网络营销策略相关理论,秦皇岛抖音推广公司,搭建本地网站环境Redis与Memcached区别#xff1a; 两者都是非关系型数据库。主要有以下不同#xff1a; 数据类型#xff1a; Memcached仅支持字符串类型。 redis支持#xff1a;String,List,set,zset,hash 可以灵活的解决问题。 数据持久化#xff1a; Memcached不支持持久化。 Redis采…Redis与Memcached区别 两者都是非关系型数据库。主要有以下不同 数据类型 Memcached仅支持字符串类型。 redis支持String,List,set,zset,hash 可以灵活的解决问题。 数据持久化 Memcached不支持持久化。 Redis采用两种持久化策略RDB快照和AOF日志。 分布式 Mencached不支持分布式只能在客户端使用一致性hash来实现分布式存储这种方式在存储和查询时都需要在客户端先计算一次数据所在的节点。 redis cluster实现了分布式的支持。 内存管理机制 redis中并不是所有数据都一直存储在内存中可以将一些很久没用的value交换到磁盘而memcached数据则候会一直在内存中。 memcached将内存分割成特定的块进行存储以完全解决内存碎片化的问题但是这种方式使得内存利用率不高如块大小128bytes只存储了100bytes的数据那么剩下的28bytes就浪费掉了。 键的过期时间 redis可以为每个键设置过期时间当键过期时自动删除该键。对于散列表这种容器只能为整个键设置过期时间(整个散列表)而不是为键里面的单个元素设置过期时间。 设置键的生存时间 expire: 指定秒 pexpire: 指定毫秒 127.0.0.1:6379 set key hello
OK
127.0.0.1:6379 expire key 1
(integer) 1
127.0.0.1:6379 get key
(nil)
127.0.0.1:6379 hset hashkey key1 1
(integer) 0
127.0.0.1:6379 hget hashkey key1
1
127.0.0.1:6379 expire hashkey 1
(integer) 1
127.0.0.1:6379 hget hashkey key1
(nil)
127.0.0.1:6379 zadd zset 0 key1 1 key2
(integer) 0
127.0.0.1:6379 zrange zset 0 -1
1) key1
2) key3
3) key2
127.0.0.1:6379 expire zset 1
(integer) 1
127.0.0.1:6379 zrange zset 0 -1
(empty list or set) 设置过期时间过期时间是一个unix时间戳 expireat:秒精度 pexpireat毫秒精度 过期键的删除策略 定时删除 在设置键的过期时间的同时创建一个定时器让定时器在键过期时间来临时立即执行对键的删除操作。 [ ] 优点对内存是友好的可以保证过期键会尽可能快被删除并释放过期键所占用的内存。 [ ] 缺点对CPU不友好在过期键较多的情况下删除键的操作会占用相当一部分的CPU时间在内存不紧张但CPU紧张的情况下将cpu时间用在删除与当前任务无关的过期键上无疑会对服务器的响应时间和吞吐量造成影响。此外定时器需要使用redis服务器的时间事件时间事件的实现方式为无序链表查找一个事件的事件复杂度为O(N)因此创建大量的定时器不现实。 惰性删除: 仅在程序取出键时才进行过期检查 [ ] 优点: CPU友好不会花费额外的时间。 [ ] 缺点对内存不友好会造成内存泄漏。 定期删除: 每隔一段时间执行一次删除过期键操作并通过限制删除操作执行的时长和频率来减少对CPU时间的影响。 数据淘汰策略6种 可以设置内存最大使用量当内存使用超出时施行数据淘汰策略。作为内存数据库出于对性能和内存消耗的考虑redis的淘汰算法实际上并未针对所有key而是抽样一小部分并且从中选出被淘汰的key。使用reids缓存数据时为提高缓存命中率需要保证缓存都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量然后启用allkeys-lru淘汰策略将最近最少未使用的数据进行淘汰。redis4.0 版本后引入了volatile-lfu和allkeys-lfu淘汰策略LFU策略通过统计访问频率将访问频率最小的键值进行淘汰。 持久化 redis是内存型数据库为了保证数据在断电后不会丢失需要将内存中的数据持久化到硬盘上。 RDB持久化 将某个时间点的所有数据都存放到硬盘上。 可以将快照复制到其他服务器从而创建具有相同数据的服务器副本。 如果系统方法故障将会丢失最后一次快照后的数据。 如果数据量很大保存快照时间会很长。 手动触发 [ ] redis命令 save生成RDB文件会阻塞服务器进程知直到RDB文件创建完毕。 bgsave 派生(fork)一个子进程然后由子进程负责创建RDB文件父进程继续处理命令请求。 自动触发 使用save相关配置如“save m n”。表示m秒中对数据集进行n次修改就触发bgsave。 如果从节点执行全量复制操作主节点自动执行bgsave生成RDB文件发送给从文件。 执行debug reload 命令重新加载redis时自动触发save操作。 默认情况下执行shutdown命令时若没有开启AOF持久化功能则自动执行bgsave。 优缺点 [ ] 优点: 适用于备份全量复制等场景。恢复数据远快于AOF方法。 [ ] 缺点没办法做到实时持久化/秒级持久化。 RDB使用特定二进制格式redis演化中有多个RDB版本存在版本不兼容情况。 AOF 持久化 将写命令添加到AOF文件的末尾(append Only File)使用AOF持久化需要设置同步选项从而保证写命令什么时候会被同步到磁盘文件上。这时因为对文件进行写入并不会马上将内容同步到磁盘上而是先存储到缓冲区然后由操作系统决定什么时候同步到磁盘。有以下同步方式 always每个写命令都同步。严重影响服务器性能 everysec每秒同步一次。可以保证系统崩溃时只丢失一秒左右的数据每秒执行一次对性能几乎没影响。 no让操作系统决定最长30秒。不能带来太多的性能提升但是会增加系统崩溃时数据丢失的数量。随着服务器写请求的增多AOF文件会越来越大。redis提供了一种将AOF重写的特性能够去除AOF文件中冗余的写命令。 为什么会变小 进程中已经超时数据不再写入文件。 旧的AOF文件含有无效命令。 多条命令合并(对同一键值的更新)。 感觉文章不错的同学麻烦动动小手点点关注订阅呗,您的肯定是对我持续更新最大的支持!
