Redis

存储数据：存储字符串、整数或者浮点数

操作数据范围：可以对整个字符串或者字符串的其中一部分执行操作，对整数和浮点数执行自增或者自减

存储数据：链表，链表上每个节点都包含了一个字符串

操作数据范围：可以操作链表两端，也可以根据偏移量修建链表，读取单个或多个元素，根据值查找或者移除元素

存储数据：无序收集器，每个字符串不能相同

操作数据范围：添加、获取、移除单个元素，随机获取元素，验证元素是否存在集合中，计算交集、并集、差集

存储数据：有序集合，字符串成员与浮点数分值之间映射，按照浮点数分值拍序

操作数据范围：添加、获取、删除单个元素，根据分值范围或者成员来获取元素

存储数据：包含键值对的无序散列表

操作数据范围：添加、获取、移除单个键值对，获取所有键值对

子主题

Redis中被multi和exec命令包围的所有命令会一个接一个地执行，直到所有命令执行完毕，当一个事务执行完毕之后，Redis才会处理其他命令

需要注意Redis在收到exec命令之后才会执行那些位于multi和exec之间的入队命令

redis使用内存来存储数据，所以会很快，但是服务器一旦重启，数据将全部丢失，这时候就需要持久化数据，以便于重启后能将数据重新从硬盘中加载数据到内存中

快照（RDB）：将某一时刻的所有数据写入硬盘里面。在进行RDB持久化时，Redis会fork出一个子进程，子进程将内存中数据写入到一个紧凑的文件中，因此保存的是某个时间点的完整数据

只追加文件：在执行写命令是将执行的写命令复制到硬盘里面，每一个修改数据的命令都会添加到aof文件中，不会丢失数据，当redis重启时，将会读取AOF文件进行恢复到redis关闭前的最后时刻

上面两种持久化方法既可以同时使用又可以单独使用

快照配置RDB

只追加文件AOF

Redis存储的数据量只有几个GB的时候使用自动保存快照没问题，当Redis占用数十个GB的时候，并且剩余的内存空间不多时，可能会导致系统长时间停顿或者引发系统大量使用虚拟内存，导致Redis性能降低到无法使用。
这时候可能需要考虑关闭自动保存，从而用手动输入bgsave或者save来持久化，bgsave需要创建子进程来备份redis，内存不够用时候可能会停顿，save会阻塞redis，但是不会创建子进程所以时间可能会快不少，通过手动方式控制Redis的停顿时间

使用固态硬盘存储的时候谨慎使用appendfsync always选项，这个选项让Redis每次只写入一个命令，而不是像其他appendfsync选项那样一次写入多个命令，这种不断写入少量数据可能会引发严重的写入放大问题，会极大降低固态硬盘寿命，最好的是使用everysec选项让Redis每秒一次同步

RDB

AOF

生成RDB文件

第一步：命令追加

第二步：文件的写入与同步

第三步：文件的载入与数据还原

AOF文件的重写

主库

从库

从库

不一定要上上面那样组成树形结构，但是这种方式是可行的，可以使用中间的从库来帮助主库复制

主库

一般来说，对于数据加锁，程序要获取排它锁，对数据操作完后再释放锁

Redis通常使用watch命令代替锁，watch命令是乐观锁，它只会在数据被其他客户端抢先修改了的情况下通知执行了这个命令的客户端，而不会阻止其他客户端对数据进行修改，这里需要人为控制

Redis虽然提供了setex来加上基本锁，但是功能并不完整，需要自行构建锁

互斥性：在任意时刻，只有一个客户端能持有锁

不会发生死锁：即时一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁

具有容错性：只要大部分的Redis节点正常运行，客户端就可以加锁和解锁

加锁与解锁必须是同一个客户端

public class RedisTool {

private static final String LOCK_SUCCESS = "OK";
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";

/**
* 尝试获取分布式锁
* @param jedis Redis客户端
* @param lockKey 锁
* @param requestId 请求标识
* @param expireTime 超期时间
* @return 是否获取成功
*/
public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

if (LOCK_SUCCESS.equals(result)) {
return true;
}
return false;

}
}

最主要的代码jedis.set(String key, String value, String nxxx, String expx, int time)

public class RedisTool {

private static final Long RELEASE_SUCCESS = 1L;

/**
* 释放分布式锁
* @param jedis Redis客户端
* @param lockKey 锁
* @param requestId 请求标识
* @return 是否释放成功
*/
public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;

}
}

可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码，上一次见到这个编程语言还是在《黑客与画家》里，没想到这次居然用上了。第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的

正常的命令是发送一条命令处理一次数据返回一次结果
管道模式则是批量发送命令，处理完后批量返回结果

在pipeline（管道）链接期间，会独占链接，不能进行非管道类型的其他操作，直到pipeline关闭
为了不干扰链接中的其他操作，可以为pipeline操作新建client链接，让管道链接和其他正常操作分离在不同client中

但是每个redis-server同时所能支撑的pipeline链接的个数是有限的，受限于server的物理内存或网络接口的缓冲能力

pipeline打包命令越多，缓存消耗内存越多

Pipeline pipe = jedis.pipelined(); // 先创建一个 pipeline 的链接对象
for (int i = 0; i < 10000; i++) {
pipe.set(String.valueOf(i), String.valueOf(i));批量写入10000条数据
}
pipe.sync(); // 获取所有的 response

 public Pipeline pipelined() {
Pipeline pipeline = new Pipeline();
pipeline.setClient(client);
return pipeline;
}

//使用管道的sadd
public Response<Long> sadd(String key, String... member) {
getClient(key).sadd(key, member);
return getResponse(BuilderFactory.LONG);//没有手动调用flush(),而是返回一个固定值。
}

//让我们来看看pipeline的sync()方法:
public void sync() {
if (getPipelinedResponseLength() > 0) {
List<Object> unformatted = client.getAll();
for (Object o : unformatted) {
generateResponse(o);
}
}
}

//client.getAll()调用了getAll(0)
public List<Object> getAll(int except) {
List<Object> all = new ArrayList<Object>();
flush();//也就是说在调用pipeline.sync()时手动触发的flush()方法,一次pipeline操作真正意思上只有一次tcp
while (pipelinedCommands > except) {
try {
all.add(readProtocolWithCheckingBroken());
} catch (JedisDataException e) {
all.add(e);
}
pipelinedCommands--;
}
return all;
}


//未使用管道的sadd方法
public Long sadd(final String key, final String... members) {
checkIsInMulti();
client.sadd(key, members);//这里的sadd将会执行下面的sendCommand发送指令
return client.getIntegerReply();//客户端立即发送数据到服务端。客户端等待服务端返回
}

//所有的发送指令都要调用该方法,但是该方法并没有真正发送数据。
protected Connection sendCommand(final ProtocolCommand cmd, final byte[]... args) {
try {
connect();
Protocol.sendCommand(outputStream, cmd, args);
pipelinedCommands++;
return this;
} catch (JedisConnectionException ex) {
// Any other exceptions related to connection?
broken = true;
throw ex;
}
}

public Long getIntegerReply() {
flush();//sendCommand方法调用后,还没有真正将数据写到服务端,当调用flush()后才真正触发发送数据
pipelinedCommands--;
return (Long) readProtocolWithCheckingBroken();
}

领头人的选举规则是谁发现客观下线谁就可以马上要求其他哨兵认自己做老大，其他哨兵会无条件接受第一个发过来的人，并告知老大，如果超过一半人都同意了，那他老大的位置就坐实了。

一共有四个因素影响选举的结果，分别是断开连接时长、优先级排序、复制数量、进程id

遇到海量存储需求的时候，单一的主从结构就会出问题，因为BGSAVE指令生成的RDB文件非常巨大，这样主从复制就会很慢

主流方案有三种，分别是Twemproxy、Codis和Redis Cluster。
Twemproxy，是推特开源的，它最大的缺点就是无法平滑的扩缩容，而Codis解决了Twemproxy扩缩容的问题，而且兼容了Twemproxy，它是由豌豆荚开源的，和Twemproxy都是代理模式。其实Codis能发展起来的一个主要原因是它是在Redis官方集群方案漏洞百出的时候率先成熟稳定的。以现在的Redis官方集群方案，这两个好像没有太大差别了，哪个性能好不确定

Redis Cluster是由官方出品的，用去中心化的方式实现，不属于代理模式

如果有存储海量数据的需求，同步就会非常缓慢，所以应该把一个主从结构变成多个，把存储的key分摊到各个主从结构中来分担压力

在Codis里面，它把所有的key分为1024个槽，每一个槽位都对应了一个分组，具体槽位的分配，可以进行自定义。
现在如果有一个key进来，首先要根据CRC32算法，针对key算出32位的哈希值
然后除以1024取余，然后就能算出这个KEY属于哪个槽
然后根据槽与分组的映射关系，就能去对应的分组当中处理数据了。

负责转发key到各个主从结构中，也是redis-client端的直接接触

本身也存在单点问题，需要做集群

集群的proxy使用Zookeeper来保存和同步映射关系。（还支持etcd和本地文件的方式）

Codis-HA是负责监视proxy运行状态，当某个proxy出现异常，则会直接干掉并重新拉起一个proxy

codis-ha在Codis整个架构中是没有办法直接操作代理和服务，因为所有的代理和服务的操作都要经过dashboard处理。所以部署的时候会利用k8s的亲和性将codis-ha与dashboard部署在同一个节点上

codis自己开发了集群管理界面，集群管理可以通过界面化的方式更方便的管理集群，这个模块叫codis-fe