网站cname,深圳招聘网最新招聘信息,wordpress 页面路由,河北抖音seo系统Redis 序列化器
针对数据的序列化/反序列化提供了多种可选择策略 比如RedisSerializer#xff0c;接下来我们详细看看 1、JdkSerializationRedisSerializer 用于 POJO 对象的存取场景#xff0c;使用 JDK 本身序列化机制#xff0c;将 pojo 类通过ObjectInputStream/Object…Redis 序列化器
针对数据的序列化/反序列化提供了多种可选择策略 比如RedisSerializer接下来我们详细看看 1、JdkSerializationRedisSerializer 用于 POJO 对象的存取场景使用 JDK 本身序列化机制将 pojo 类通过ObjectInputStream/ObjectOutputStream 进行序列化操作最终 redis-server 中将存储字节列。是目前最常 用的序列化策略。 2、StringRedisSerializer用于Key和value为字符串的场景根据指定的charset对数据的字节序列编码成string是 new String(bytes, charset)和 string.getBytes(charset)的直接封装是最轻量级和高效的策略。 3、JacksonJsonRedisSerializer 是 jackson-json 工具提供的 javabean 与 json 之间的转换能力可以将 pojo 实例序列化成 json 格式存储在 redis 中也可以将 json 格式的数据转换成 pojo 实例。因为 jackson 工具在序列化和反序列化时需要明确指定 Class 类型因此此策略封装起来稍微复杂。
缓存与数据库双写不一致 缓存可以提升性能、缓解数据库压力但是使用缓存也会导致数据不一致性的问题。一般写数据操作使用缓存 有三种经典的缓存模式 Cache-Aside Pattern Read-Through/Write through Write behind 这三种常见的更新策略实际上都是保证数据的最终一致性的方法可以总结为 1、先更新数据库再更新缓存后续线程会读取旧数据 2、先删除缓存再新数据库并发线程读取旧数据并写到缓存 3、先更新数据库再删除缓存后续线程会读取旧数据常见解决方案是延时双删但是延时的时长不好控制 小小总结一下 总结 1、并发几率很小的数据几乎不用考虑加上缓存过期时间缓存失效后查询主动更新 2、业务上是否能容忍一定时间的不一致如能容忍的话加上缓存过期时间如果不能容忍缓存数据不一致可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队读读的时候相当于无锁。 3、可以用阿里开源的 canal 通过监听数据库的 binlog 日志及时的去修改缓存但是引入了新的中间件增加了系统的复杂度
Cache-Aside Pattern 即旁路缓存模式读操作读的时候先读缓存缓存命中的话直接返回数据缓存没 有命中的话就去读数据库从数据库取出数据放入缓存后同时返回响应。写操作更新的时候先更新 数据库然后再删除缓存。 Read-Through/Write-Through 读写穿透模式中读操作从缓存读取数据读到直接返回如果读取不到的 话从数据库加载写入缓存后再返回响应。写操作Write-Through 模式下当发生写请求时也是由缓存抽象层完成数据源和缓存数据的更新Write behind 异步缓存一般写入是同步更新缓存和数据Write Behind 则是只更新缓存不直接更新数据库通过批量异步的方式来更新数据库。适合频繁写的场景MySQL 的 InnoDB Buffer Pool 机制就使用到这种模式
Redis 持久化
Redis 为了保证效率数据缓存在了内存中但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中以保证数据的持久化。总的目的把数据保存到硬盘有 RDB 和 AOF 两种。 RDB 持久化方案: RDB 是一次的全量备份快照形式是周期性直接把内存中的数据保存到一个 dump 文件中定时保存。是 redis 默认的存储方式推荐使用。 优点: 性能消耗的比较小速度快 缺点: 容易丢失数据 AOF 持久化方案把所有的对 Redis 的服务器进行修改的命令都存到一个文件里是命令的集合。 优点: 不容易丢失数据 缺点: 性能差给客户的体验度不好 当 Redis 重启时会优先使用 AOF 文件来还原数据集因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。甚至可以关闭持久化功能让数据只在服务器运行时存储
RDB 持久化
RDB 是默认的持久化方案推荐使用的。Redis 生成二进制压缩的快照文件 xxx.rdb 保存到磁盘。 RDB 工作原理当 Redis 需要做持久化时Redis 会 fork 一个子进程子进程将数据写到磁盘上一个临时 RDB文件中。当子进程完成写临时文件后将原来的 RDB 替换掉这样的好处是可以 copy-on-write。定时生成 RDB 快照非常便于进行数据库备份并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度快。Redis4.0 支持同时开启 RDB 和 AOF系统重后Redis 会优先使用 AOF 来恢复数据这样丢失的数据会最少。 需要查看配置文件满足三个条件中一个触发生成快照 rdb 文件。可以配置符合快照触发条件默认的是 1 分钟内改动 1 万次或者 5 分钟改动 10 次或者是 15 分钟改动一次 save 900 1 save 300 10 save 60 10000 启动服务器的时候需要通过命令行启动进入 reids 的安装目录 redis-server.exe redis.conf save 命令save 时只管保存其他不管全部阻塞 bgsave 命令redis 会在后台进行快照操作快照操作的同时还可以响应客户端的请求可以通过 lastsave 命令获取最后一次成功执行快照的时间。
AOF 持久化
AOF 日志存储的是 redis 服务器的顺序指令序列即对内存中数据进行修改的指令记录。当 redis 收到客户端修改指令后先进行参数校验如果校验通过把该指令存储到 AOF 日志文件中也就是先存到磁盘然后再执行该修改指令。当 redis 宕机后重启后可以读取该 AOF 文件中的指令进行数据恢复恢复的过程就是 把记录的指令再顺序执行一次这样就可以恢复到宕机之前的状态。 打开 AOF 配置 redis.conf 中的 appendonly yes 就可以打开 AOF 功能例如 appendfsync no 当设置 appendfsync为 no 的时候Redis 不会主动调用 fsync 去将 AOF 日志内容同步到磁盘所以这一切就完全依赖于操作系统的调试了。对大多数 Linux 操作系统是每 30 秒进行一次 fsync将缓冲区中的数据写到磁盘上。 appendfsync everysec 当设置 appendfsync 为 everysec 的时候Redis 会默认每隔一秒进行一次 fsync 调用将缓冲区中的数据写到磁盘。但是当这一次的 fsync 调用时长超过 1 秒时。Redis 会采取延迟 fsync 的策略再等一秒钟。也就是在两秒后再进行 fsync这一次的 fsync 就不管会执行多长时间都会进行。这时候由于在 fsync 时文件描述符会被阻塞所以当前的写操作就会阻塞。 在绝大多数情况下Redis 会每隔一秒进行一次 fsync。在最坏的情况下两秒钟会进行一次 fsync 操作。这一操作在大多数数据库系统中被称为 group commit就是组合多次写操作的数据一次性将日志写到磁盘。 appendfsync always 每一次写操作都会调用一次 fsync这时数据是最安全的当然由于每次都会执行 fsync所以其性能也会受到影响
AOF 重写 因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态的那么就会涉及到很多无用的命令如 set ab 和 set a c 以及 set a d其实就最后一条有意义。 Redis 会 fork 一个进程来读取现在 redis 生成的 AOF 文件然后在内存中去除冗余命令在此过程中不会影响原来 AOF 文件的继续写入如果有新的命令会缓存在重写缓冲中当重写完全结束后会替换掉原来的 AOF文件 重写触发条件手动命令 BGREWRITEAOF 和配置自动调用 RDB 与 AOF 的选择 宕机后会优先加载 AOF 文件。RDB 保存的数据AOF 保存的命令RDB 文件比 AOF 小。恢复速度 RDB 小更快。RDB 一次写入的数据较多时间间隔会比 AOF 长出现宕机丢失的数据会更多各有优劣如果能综合就好了所幸的是在 redis4.0 后通过配置 aof-use-rdbpreamble 就可以开启两者混合 持久化取长补短。
单机性能建议 因为 RDB 文件只用作后备用途只要 15 分钟备份一次就够了只保留 save 900 1 这条规则。 如果 Enable AOF好处是在最恶劣情况下也只会丢失不超过两秒数据启动脚本较简单只 load 自己的 AOF 文件就可以了。 代价一是带来了持续的 IO二是 AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可应该尽量减少 AOF rewrite 的频率AOF 重写的基础大小默认值 64M 太小了可以设到 5G 以上。 默认超过原大小 100%大小时重写可以改到适当的数值。
