最近阅读了《 Redis 开发与运维》，非常不错。这里对书中的知识整理一下，方便自己回顾 Redis 的整个体系，来对相关知识点查漏补缺。

前言

Google 出的 Guava 是 Java 核心增强的库，应用非常广泛。

我平时用的也挺频繁，这次就借助日常使用的 Cache 组件来看看 Google 大牛们是如何设计的。

缓存

本次主要讨论缓存。缓存在日常开发中举足轻重，如果你的应用对某类数据有着较高的读取频次，并且改动较小时那就非常适合利用缓存来提高性能。

缓存之所以可以提高性能是因为它的读取效率很高，就像是 CPU 的 L1、L2、L3 缓存一样，级别越高相应的读取速度也会越快。

但也不是什么好处都占，读取速度快了但是它的内存更小资源更宝贵，所以我们应当缓存真正需要的数据。其实也就是典型的空间换时间。下面谈谈 Java 中所用到的缓存。

阅读全文

前言

之前在 Java-Interview 中提到过秒杀架构的设计，这次基于其中的理论简单实现了一下。

本次采用循序渐进的方式逐步提高性能达到并发秒杀的效果，文章较长请准备好瓜子板凳(liushuizhang?)。

本文所有涉及的代码：

• https://github.com/crossoverJie/SSM
• https://github.com/crossoverJie/distributed-redis-tool

阅读全文

原文链接 译者：Emalia

Redis设计方案

Rdis设计方案是在新功能实际实施之前让社区了解新功能设计的一种方法。这样做是希望从用户基础获得良好的反馈，如果发现缺陷或者可能的改进，可能会导致设计的改变。
阅读全文

原文链接

事务

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务的基础。事务允许一次独立的执行一组命令，并且拥有两个重要的保证。

• Redis事务的执行是单步的独立的操作：所有的在事务中的命令都是序列化和顺序地。它在执行事务中永远不会被另一个客户端打断。
• Redis的事务是原子性的：所有的命令，要么全部执行，要么全部不执行。
  • EXEC的命令触发执行Redis事务中的所有命令，所以如果这个客户端之前调用了MULTI命令却断开了redis事务中的连接，那么这个事务的将不会被执行。
  • 当我们使用了AOF序列化(append-only-file)时，Redis会确保去使用单独的同步Write(2)写入磁盘中。然而如果Redis服务阻塞或者被系统管理员杀死，那么将可能导致只有部分的操作被执行。Redis在重启的时候将会检测当前状态，并退出这个错误。它可以使用Redis-Check-AOF工具移除部分的事务，去修复这个AOF文件，所以Redis可以再次启动。

阅读全文

原文链接：

发布/订阅（Pub/Sub）

SUBSCRIBE、UNSUBSCRIBE 和 PUBLISH 这三个命令实现了发布/订阅消息模式（引用自维基百科），发送者（发布者）并不是直接发送它们的消息给指定的接收者（订阅者），而是将消息发布到特定的消息通道，并且不需要知道订阅者（如果有的话）的任何信息。订阅者可以订阅一个或多个感兴趣的消息通道，同时也只会收到他们感兴趣通道的信息，而不用去关心是谁发布的。这种发布者与订阅者的解耦，使其具备更强的扩展性并得到一个更加动态的网络拓扑。

阅读全文

原文链接 译者:humyna

本节提供了Redis安全主题概述，包括控制访问、代码安全以及诸于恶意注入攻击拦截等。
对于安全相关的交流可以在github上建一个issue；如果担心沟通的安全，可以使用文末的GPG密钥。
阅读全文

原文链接 译者：cndpzc

Redis实现了自己的事件库，代码在ae.c中。想要理解Redis事件库的工作原理，最好的方法就是去理解Redis如何使用它。
阅读全文

原文链接  译者：cndpzc

为什么需要一个事件库（Event Library）？

让我们通过一系列Q&A来弄明白。
阅读全文

原文链接
Redis的源代码并不大（2.2版只有2万行），我们努力让代码简单易懂，但还是需要一些文档来解释Redis中某些部分的内部实现机制。

阅读全文

作者：carlosfu

一、背景 

 1. 什么是缓存无底洞问题：

阅读全文

原文链接

Redis Sentinel 文档

Redis Sentinel为Redis提供了高可用解决方案。实际上这意味着使用Sentinel可以部署一套Redis，在没有人为干预的情况下去应付各种各样的失败事件。

Redis Sentinel同时提供了一些其他的功能，例如：监控、通知、并为client提供配置。

阅读全文

原文链接 译者：Alexandar Mahone

这篇文章从技术层面描述了Redis持久化，建议所有读者阅读。如果希望更多了解Redis持久化和持久性保障，建议阅读Redis持久化揭秘。

Redis 持久化

提供了多种不同级别的持久化方式：

• RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
• AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

了解 RDB 持久化和 AOF 持久化之间的异同是非常重要的， 以下几个小节将详细地介绍这这两种持久化功能， 并对它们的相同和不同之处进行说明。

阅读全文

原文链接  译者：boyhou （WeChat：HouYongBo923）

如果你使用redis作为缓存，当添加新数据时，若有内存大小等限制，系统默认会根据一定的规则自动清理旧数据。这种处理方式在开发社区中众所周知，因为它也是非常流行的缓存系统 memcached 的默认处理方式。

LRU（LRU全称是Least Recently Used，即最近最久未使用）实际上只是Redis支持的内存回收策略中的一种。这篇文章将要讲述Redis的 maxmemory 配置选项，该配置选项用来限制 Redis 的内存使用大小，同时深入研究 LRU（确切的说是近似LRU算法） 算法在 Redis 中的应用。

阅读全文

原文链接 译者：carvin

Redis 不是一个 简单的 key-value 存储，实际上它是一个数据结构服务器，它支持不同类型的值。也就是说，在传统的key-value存储中，你将一个字符串的key关联到一个字符串的值上；而在Redis中，值不仅仅局限于简单的字符串，还同时支持其他复杂的数据结构。以下的列表是所有Redis支持的数据结构，在这篇指南中将一一介绍：

阅读全文