一、CacheCloud为什么之前不支持密码

• Redis是为内网设计的。
• “keep it simple”是Redis一直倡导的，密码会增加复杂性和成本(服务端和客户端)。
• Redis性能很高，简单的密码很容易被暴力破解。
• 很多公司不使用密码。

二、CacheCloud为什么现在要做

• 现今很多Redis的公有云服务。
• Redis出现过安全漏洞：当然这个和自身机房安全级别也有关系。
• CacheCloud可以满足多方面的环境需求(例如接入已经存在)。

三、使用方法

1

所有代码提交到dev和master分支，等待成熟后1.3 release(已经自测通过)。

add sql schema:

1

alter table app_desc add column password varchar(255) default '' comment 'redis密码';

1. 接入已经存在的Redis

使用方法不变，可以参考：已存在Redis接入CacheCloud

只不过添加了一个选项：

声明：本文内容来自《Redis开发与运维》一书第12章，如转载请声明。

热门新闻事件或商品通常会给系统带来巨大的流量，但对存储这类信息的Redis来说是一个巨大的挑战。以Redis Cluster为例，它会造成整体流量的不均衡，个别节点出现OPS过大的情况，极端情况下热点key甚至会超过Redis本身能够承受的OPS，因此寻找热点key对于开发和运维人员非常重要。

1.客户端

客户端其实是距离key”最近”的地方，因为Redis命令就是从客户端发出的，例如在客户端设置全局字典(key和调用次数)，每次调用Redis命令时，使用这个字典进行记录，如下所示。

1
2
3
4
5
6
7
8
9
10
11
12

public static final AtomicLongMap<String> ATOMIC_LONG_MAP = AtomicLongMap.create(); 
String get(String key) {
    counterKey(key);
    //ignore
}
String set(String key, String value) {
    counterKey(key);
    //ignore
}
void counterKey(String key) {
    ATOMIC_LONG_MAP.incrementAndGet(key);
}

《Redis开发与运维》勘误列表

第1版第1次印刷

1. 第46页

1

lpsh应该是lpush，拼写错误

1

感谢ChowRex

2. 第110页

1

多了一个句号

声明：本文内容来自《Redis开发与运维》一书第八章，如转载请声明。

Redis所有的数据都在内存中，而内存又是非常宝贵的资源。对于如何优化内存使用一直是Redis用户非常关注的问题。本文让我们深入到Redis细节中，学习内存优化的技巧。分为如下几个部分：

一. redisObject对象
二. 缩减键值对象
三. 共享对象池
四. 字符串优化
五. 编码优化
六. 控制key的数量

一. redisObject对象

Redis存储的所有值对象在内部定义为redisObject结构体，内部结构如下图所示。

Redis存储的数据都使用redisObject来封装，包括string,hash,list,set,zset在内的所有数据类型。理解redisObject对内存优化非常有帮助，下面针对每个字段做详细说明：

声明：本文内容来自《Redis开发与运维》一书第12章，如转载请声明。

通常来看，Redis开发和运维人员更加关注的是Redis本身的一些配置优化，例如AOF和RDB的配置优化、数据结构的配置优化等，但是对于操作系统是否需要针对Redis做一些配置优化不甚了解或者不太关心，然而事实证明一个良好的系统操作配置能够为Redis服务良好运行保驾护航。

众所周知Redis的作者对于Windows操作系统并不感冒，目前大部分公司都会将Web服务器、数据库服务器等部署在Linux操作系统上，Redis也不例外。所以接下来介绍Linux操作系统如何优化Redis，包含如下七个方面。

一. 内存分配控制
二. swappiness
三. Transparent Huge Pages
四. OOM killer
五. 使用NTP
六. ulimit
七. TCP backlog

一. 内存分配控制

1. vm.overcommit_memory

Redis在启动时可能会出现这样的日志：

1
2

# WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the 
command 'sysctl vm.overcommit_memory=1' for this to take effect.

CacheCloud将在1.3版本添加机器监控统计功能，目前已经在master分支提交了部分代码，如果需要使用还要做部分源码改动(去掉某些注释~哈哈)

1

ps: 目前该功能只对master分支有效。

一. 功能展示

CacheCloud会每5分钟收集机器的相关指标，例如CPU、内存、负载、网络、磁盘等绘制成报表，例如下面分别是从全局、CPU、内存、磁盘展示：

1.全局

本文部分内容来自《Redis开发与运维》一书，转载请声明。

一、现象和危害

线上有台机器内存接近了90%，总内存为24G，整个部署如下图：

现要将Redis-2迁移走，由于特殊原因此节点没有slave节点，需要添加一个slave节点，然后做failover操作。

通过对日志的观察，发现主从不停地做全量复制。

本文部分内容来自《Redis开发与运维》一书，转载请声明。

在Redis客户端的使用过程中，无论是客户端使用不当或者Redis服务端出现问题，客户端会反应出一些异常，下面分析一下Jedis使用过程中常见的异常情况：

一.无法从连接池获取到连接

JedisPool中的Jedis对象个数是有限的，默认是8个。这里假设使用的默认配置，如果有8个Jedis对象被占用，并且没有归还，如果调用者还要从JedisPool中借用Jedis，就需要进行等待(例如设置了maxWaitMillis>0)，如果在maxWaitMillis时间内仍然无法获取到Jedis对象就会抛出如下异常。

1
2
3
4

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
	…
Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
	at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)

还有一种情况，就是设置了blockWhenExhausted=false，那么调用者发现池子中没有资源时，会立即抛出异常不进行等待，下面的异常就是blockWhenExhausted=false时的效果。

1
2
3
4

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
	…
Caused by: java.util.NoSuchElementException: Pool exhausted
	at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:464)

1

本文以Redis-Cluster为例子，实际使用中Redis-Sentinel和Redis Standalone也是一样的。

一、现有问题

由于Redis本身的一些特性(例如复制)以及使用场景，造成Redis不太适合部署在不同的机房，所以通常来看Redis集群都是在同一个机房部署的。虽然Redis集群自身已经具备了高可用的特性，即使几个Redis节点异常或者挂掉，Redis Cluster也会实现故障自动转移，对应用方来说也可以在很短时间内恢复故障。但是如果发生了机房故障(断电、断网等极端情况)，如果应用方降级或者容错机制做的不好甚至业务本身不能降级，或者会丢失重要数据，或者可能瞬间会跑满应用的线程池造成服务不可用，对于一些重要的服务来说是非常致命的。

为了应对像机房故障这类情况，保证应用方在这种极端情况下，仍然可以正常服务(系统正常运行、数据正常)，所以需要给出一个Redis跨机房的方案。

二、实现思路和目标：

1.思路

• 使用CacheCloud开通两个位于两个不同机房的Redis-Cluster集群(例如：兆维、北显)：一个叫major，作为主Redis服务，一个叫minor，作为备用Redis服务。
• 开发定制版的客户端，利用netflix的hystrix组件能够解除依赖隔离的特性，在major出现故障时，将故障隔离，并将请求自动转发到minor，并且对于应用的主线程池没有影响。（有关hystrix的请求流程流程见下图，有关hystrix使用请参考：http://hot66hot.iteye.com/blog/2155036

1. 机器级别全面监控，已经开发完成

2. 更为详细的报警：覆盖info大部分有用参数、机器更全面报警、客户端全面报警

3. 水平扩容流程优化：现在操作不是很方便

4. 云备份功能：定期备份RDB到分布式存储。

5. 持久化相关监控:aof和rdb监控和统计

6. 密码相关