L170311的博客

spring boot链接AOP实现防止重复提交

在学习Reids时，关于缓存的三大问题：缓存雪崩、缓存穿透、缓存击穿，其中缓存穿透最好的解决办法就是依靠布隆过滤器，什么是布隆过滤器呢？布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。——百度百科。

本文是对的文章部分内容的翻译和总结，上次写 Redlock 的原因就是看到了 Martin 的这篇文章，写得很好，特此翻译和总结。感兴趣的同学可以翻看原文，相信会收获良多。开篇作者认为现在 Redis 逐渐被使用到数据管理领域，这个领域需要更强的数据一致性和耐久性，这使得他感到担心，因为这不是 Redis 最初设计的初衷（事实上这也是很多业界程序员的误区，越来越把 Redis 当成数据库在使用），其中基于 Redis 的分布式锁就是令人担心的其一。

在 Cache-Aside Pattern 下，发生读请求的时候，如果 cache 中不存在对应的数据，是由客户端自己负责把数据写入 cache，而 Read Through Pattern 则是 cache 服务自己来写入缓存的，这对客户端是透明的。可以短暂地允许数据库和缓存数据不一致的场景 ：更新DB的时候同样更新cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。cache 中存在，则先更新 cache，然后 cache 服务自己更新 DB（

Redis 官方站这篇文章提出了一种权威的基于 Redis 实现分布式锁的方式名叫Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：安全特性：互斥访问，即永远只有一个 client 能拿到锁避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区容错性：只要大部分 Redis 节点存活就可以正常提供服务。

主从链(拓扑结构)复制模式全量复制：Master 全部同步到 Slave部分复制：Slave 数据丢失进行备份问题点同步故障复制数据延迟(不一致)读取过期数据(Slave 不能删除数据)从节点故障主节点故障配置不一致maxmemory 不一致:丢失数据优化参数不一致:内存不一致.避免全量复制选择小主节点(分片)、低峰期间操作.如果节点运行 id 不匹配(如主节点重启、运行 id 发送变化)，此时要执行全量复制，应该配合哨兵和集群解决.

非常推荐大家看一下《redis实战》这本书，感觉书中的很多理论性东西还是很不错的。很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置。Redis不同于Memcached的很重一点就是，Redis支持持久化，而且支持两种不同的持久化操作。Redis的一种持久化方式叫快照（snapshotting，RDB）,另一种方式是只追加文件（append-only file,AOF）

简单来说Redis 就是一个使用 C 语言开发的数据库，不过与传统数据库不同的是Redis 的数据是存在内存中的，也就是它是内存数据库，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。另外，Redis 除了做缓存之外，Redis 也经常用来做分布式锁，甚至是消息队列。Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务 、持久化、Lua 脚本、多种集群方案。