1、简述Redis事务实现

1、事务开始

MULTI命令的执行，标识着一个事务的开始。MULTI命令会将客户端状态的flag属性中打开REDIS_MULTI标识来完成的。

2、命令入队

当一个客户端切换到事务状态后，服务器会根据这个客户端发送来的命令来执行不同的操作。如果客户端发送的命令为MULTI、EXEC、WATCH、DISCARD中的一个，立即执行这个命令，否则将命令放入一个事务队列里面，然后向客户端返回QUEUED回复。

如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个，那么服务器立即执行这个命令。
如果客户端发送的是四个命令以外的其他命令，那么服务器并不立即执行这个命令。
首先检查命令的格式是否正确、如果不正确，服务器会在客户端状态（redisClient）的flags属性关闭REDIS_MULTI标识，并且返回错误信息给客户端。如果正确，将这个命令放入一个事务队列里面，然后向客户端返回QUEUED回复

事务队列是按照FIFO的方式保存入队的命令。

3、事务执行

客户端发送EXEC命令，服务器执行EXEC命令逻辑

如果客户端状态的flags属性不包含REDIS_MULTI标识，或者包含REDIS_DIRTY_CAS或者REDIS_DIRTY_EXEC标识，那么就直接取消事务的执行。
否则客户端处于事务状态（flags有REDIS_MULTI标识），服务器会遍历客户端的事务队列，然后执行事务队列中的所有的命令，最后将返回结果全部返回给客户端；

redis不支持事务回滚机制，但是它会检查每一个事务中的命令是否错误。

Redis事务不支持检查哪些程序员自己的逻辑错误。例如对String类型的数据库执行对HashMap类型的操作！！！

WATCH命令是一个乐观锁，可以为Redis事务提供check-and-set（CAS)行为，可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
MULTI命令有用于开启一个事务，它总是返回OK，MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。当操作被打断时，返回空值NULL。
通过调用DISCARD,客户端可以清空事务队列，并放弃执行事务，并且客户端会从事务状态中退出。
UNWATCH命令可以取消watch对所有key的监控。

2、redis集群方案

主从

哨兵模式：
sentinel，哨兵是redis集群中非常重要的一个组件，主要有一下功能：

集群监控：负责监控redis master 和slave进程是否正常工作。
信息通知：如果某个redis实例有故障，那么哨兵负责发送信息作为报警通知给管理员
故障转移：如果master node挂掉了，会自动转移到slave node上。
配置中心：如果故障转移发生了，通知client客户端新的master地址

哨兵用于实现redis集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

故障转移时，判断一个master node是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的
哨兵通常需要3个实例，来保证自己的健壮性。
哨兵+redis主从的部署架构，是不保证数据零丢失的，只能保证redis集群的高可用性。
对于哨兵+redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

redis Cluster 是一种服务端Sharding技术，3.0版本开始正式提供。采用==slot（槽）==的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行

方案说明：

通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽（哈希值）区间的数据，默认分配了16384个槽位
每份数据分片会存储在多个互为主从的节点上
数据写入先写主节点，再同步到从节点（支持配置为阻塞同步）
同一分片多个节点间的数据不保持一致性
读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
扩容时需要把旧节点的数据迁移一部分到新节点

在redis cluster架构下，每个redis要开放两个端口号，比如一个是6379，另外一个就是加1w的端口号，比如16379.

16379端口号是用来进行节点间通信的，也就是cluster bus的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus用了另外一种二进制的协议，gossip协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

优点：

无中心架构，支持动态扩容，对业务透明
具备Sentine的监控和自动Failover（故障转移）能力
客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
高性能，客户端直连redis服务，免去了proxy代理的损耗

缺点：

运维也很复杂、数据迁移需要人工干预
只能使用0号数据库
不支持批量操作（pipeline管道操作）
分布式逻辑和存储模块耦合等

Redis Sharding是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的Key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。java redis客户端驱动jedis，支持Redis Sharing功能，即ShardedJedis以及结合缓存池的ShardegjedisPool

优点：

优势在于非常简单，服务端的redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。

缺点：
由于sharding处理放到客户端，规模进一步扩大时给运维带来挑战。
客户端sharding不支持动态增删改节点。服务端redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化

3、redis主从复制的核心原理

通过执行slaveof命令或设置slaveof选项，让一个服务器去复制另一个服务器的数据。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般只是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

全量复制：

1、主节点通过bgsave命令fork子进程进行RDB持久化，该过程是非常消耗CPU、内存（页表复制）、硬盘IO的
2、主节点通过网络将RDB文件发送给从节点，对主节点的带宽都会带来很大的消耗
3、从节点清空老数据，载入新RDB文件的过程是阻塞的，无法响应客户端的命令；如果从节点执行bgrewriteaof，也会带来额外的消耗

部分复制：

1、复制偏移量：执行复制的双方，主从节点，分别会维护一个复制偏移量offset
2、复制积压缓冲区：主节点内部维护了一个固定长度的、先进先出（FIFO)队列作为复制积压缓冲区，当主从节点offset的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。
3、服务器运行ID（runid）：每个Redis节点，都有其运行ID,运行ID由节点在启动时自动生成，主节点会将自己的运行ID发送给从节点，从节点会将主节点的运行ID存起来。从节点Redis断开重连的时候，就是根据运行ID来判断同步的进度：

如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制（到底能不能部分复制还要看offset和复制积压缓冲区的情况）

如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制。

4、CAP理论，BASE理论

CAP理论

Consistency(一致性）：

即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。
对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。
从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。

Availability（可用性）：

即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况

Partition Tolerance（分区容错性）：

即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中由某一个或几个机器宕机了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

CP和AP：分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能2选1.

BASE是Basically Available(基本可用）、soft state（软状态）和Eventually consisten（最终一致性）

BASE理论是对CPA中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特定，采用适当的方式来使系统达到最终一致性

基本可用：