java领域分享

分布式系统设计是实现复杂性和收益的平衡，既要尽可能地安全可靠，也要避免过度设计。Redlock 确实能够提供更安全的分布式锁，但也是有代价的，需要更多的 Redis 节点。在实际业务中，一般使用基于单点的 Redis 实现分布式锁就可以满足绝大部分的需求，偶尔出现数据不一致的情况，可通过人工介入回补数据进行解决，正所谓“技术不够，人工来凑”！。

在面临缓存穿透的时候，我们其中一个解决方案是：查询数据库如果没有数据，则约定一个空数据格式放入缓存中，当再次查询的时候，先查询缓存，发现是一个空数据格式，则直接返回空，避免数据库被瞬间流量击垮。如果在删除缓存后，马上有新线程查询缓存，新线程发现缓存不存在（刚被删），新线程查询数据库后将数据放于缓存，老线程删除数据库成功。缓存一致性问题的表现：同一份数据，缓存中的数据与数据库中的数据不一致，那么上升到业务层面就有着千奇百怪的现象了，比如每次读都是读的老数据，或者每次读是一份过时的数据等。如果删除缓存失败呢？

Redis 是一个kv型数据库，我们所有的数据都是存放在内存中的，但是内存是有大小限制的，不可能无限制的增量。想要把不需要的数据清理掉，一种办法是直接删除，这个咱们前面章节有详细说过；另外一种就是设置过期时间，缓存过期后，由Redis系统自行删除。这边需要注意的是，缓存过期之后，并不是马上删除的，那Redis是怎么删除过期数据的呢？主要通过两个方式惰性删除通过定时任务，定期选取部分数据删除。

Redis无论是惰性删除还是定期删除，都可能存在删除不尽的情况，无法删除完全，比如每次删除完过期的 key 还是超过 25%，且这些 key 再也不会被客户端访问。这样的话，定期删除和堕性删除可能都彻底的清理掉。如果这种情况长时间持续下去，可能会导致内存耗尽，所以Redis必须有一个完善的内存淘汰机制来保障。这就是我们这一篇的重点，Redis内存自动淘汰机制。

redis 缓存穿透、缓存击穿、缓存雪崩区别和解决方案

Redis 集群（包括很多小集群）实现了对 Redis 的水平扩容，即启动 N 个 redis 节点，将整个数据库分布存储在这 N 个节点中，每个节点存储总数据的 1/N，即一个小集群存储 1/N 的数据，每个小集群里面维护好自己的 1/N 的数据。Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。该模式的 redis 集群特点是：分治、分片。普通方式登录：可能直接进入读主机，存储数据

主机数据更新后根据配置和策略， 自动同步到备机的 master/slaver 机制，Master 以写为主，Slave 以读为主，主从复制节点间数据是全量的。

AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写 (也是先写临时文件最后再 rename)，redis4.0 版本后的重写，是指把 rdb 的快照，以二进制的形式附在新的 aof 头部，作为已有的历史数据，替换掉原来的流水账操作。AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof。...

Redis

Redis_事务秒杀案例

Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。Redis 事务的主要作用就是串联多个命令防止别的命令插队。...

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。Redis 客户端可以订阅任意数量的频道。

Redis 数据类型

Redis 是一个开源的 key-value 存储系统。和 Memcached 类似，它支持存储的 value 类型相对更多，包括 string (字符串)、list (链表)、set (集合)、zset (sorted set –有序集合) 和 hash（哈希类型）。这些数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis 支持各种不同方式的排序。...